August 2017 - Pharo-dev - lists.pharo.org

Impediment to contributing

by stephan

I feel frustrated, and blocked in contributing. I miss up to date information on how to cleanly install Pharo so that I can use Iceberg with Metacello, and the process to use to contribute to both Pharo itself and to the different projects on github. Every time I try to do something that comes close to using git, I run into issues. Stephan

Aug. 10, 2017

[Pharo 70] build 25 / PR 182

by Pavel Krivanek

Hi, next Pharo 7 build is available: https://pharo.fogbugz.com/f/cases/20286/Bootstrap- packages-are-dirty-in-a-fresh-image https://github.com/pharo-project/pharo/pull/182 -- Pavel

Aug. 10, 2017

vm crash when using rairedTo: with fractions

by Andrei Chis

Hi, I was executing this code '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10. Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. Cheers, Andrei 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor 0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri enderer 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure

Aug. 10, 2017

Re: [Pharo-dev] post-download preparation of Pharo 7 image

by Guillermo Polito

On Thu, Aug 10, 2017 at 11:55 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > currently we are fighting with several issues that make contributions to > Pharo 7 much more complicated than we would like. Even in case you have no > troubles with long paths (on Windows) nor SSH keys, it is now not easy now > to start to contribute or review pull requests. > > Let's say you already have: > - a Github fork of pharo-project/pharo repository > - a local clone of pharo-project/pharo repository on your disk > - this repository has a 'remote' pointing to your fork that is named by > your GitHub user name > > During bootstrap the Iceberg registers a repository from which the image > was bootstrapped and binds Monticello working copies history to it. This > repository is hidden by default, to see it in the repositories list you > need to enable Iceberg setting named 'Include system repositories by > default'. If you will do it, you will see that this repository is red. You > need to manually set the real path to you local clone (Edit). > > Then you should set your fork as default push target (in Iceberg: select > 'pharo' repository - 'Remotes' tab - context menu on your fork remote - > Make default push remote). > > It is good to synchronize your fork with the origin so it will contain > recent commits on the development branch. You can do it by doing PULL from > the origin (pharo-project/pharo) and PUSH to your fork. The alternative is > to create a pull request from the original repository to your fork in the > GitHub web interface and then let merge it) > > The next optional step is to checkout the particular commit hash from > which the image was bootstrapped. It is optional because the Iceberg now > supports cherry picking so you can avoid of committing changes you do not > want. But to start your branches from a state when the image working copy > is in sync with the git working copy is of course cleaner. > > Currently the bootstrapped image has some packages that are marked as > dirty and it will make mess if you will try to commit your changes. You can > avoid it by reloading of these dirty packages. This will be not needed in > future. > > All these steps you can automatized by the following code. You need to at > least customize your repository clone path and GitHub user name. It is > supposed to be run only once on freshly downloaded Pharo 7 image. > > | location userName pharoRepository fork | > > location := '/path/to/your/pharo/repository'. > userName := 'github-user-name'. > > Iceberg showSystemRepositories: true. > pharoRepository := IceRepository registry detect: [ :each | each name = > 'No name' ]. > pharoRepository location: location asFileReference. > fork := pharoRepository remotes detect: [ :remote | remote remoteName = > userName ]. > pharoRepository pushRemote: fork. > pharoRepository pullRemote: pharoRepository origin. > > pharoRepository checkoutBranch: 'development'. > pharoRepository backend pullFrom: pharoRepository origin. > Take into account this particular two lines can break your working copy if you have uncommited changes. > pharoRepository push. > pharoRepository checkoutBranch: (SystemVersion current commitHash). > > [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do: > [ :warning | warning resume: true ] > And this is a patch because bootstrapped images have 3 dirty packages. We should just fix the issue instead of patching it. In any case, I vote to put this in the Pharo plugin in iceberg. > > > As the result you should get a clean image based on the latest code that > is ready to to create or review pull requests. > > Cheers, > -- Pavel > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Updating the CI

by Guillermo Polito

Hi all, I'm updating some CI plugins right now. Will notify as soon as everything is smooth again. The issue related to the update is here: https://pharo.fogbugz.com/f/cases/20299/Update-CI-plugins-to-latest-git-plu… (yes, we have an issue so we can keep track of the plugins we have) -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

post-download preparation of Pharo 7 image

by Pavel Krivanek

Hi, currently we are fighting with several issues that make contributions to Pharo 7 much more complicated than we would like. Even in case you have no troubles with long paths (on Windows) nor SSH keys, it is now not easy now to start to contribute or review pull requests. Let's say you already have: - a Github fork of pharo-project/pharo repository - a local clone of pharo-project/pharo repository on your disk - this repository has a 'remote' pointing to your fork that is named by your GitHub user name During bootstrap the Iceberg registers a repository from which the image was bootstrapped and binds Monticello working copies history to it. This repository is hidden by default, to see it in the repositories list you need to enable Iceberg setting named 'Include system repositories by default'. If you will do it, you will see that this repository is red. You need to manually set the real path to you local clone (Edit). Then you should set your fork as default push target (in Iceberg: select 'pharo' repository - 'Remotes' tab - context menu on your fork remote - Make default push remote). It is good to synchronize your fork with the origin so it will contain recent commits on the development branch. You can do it by doing PULL from the origin (pharo-project/pharo) and PUSH to your fork. The alternative is to create a pull request from the original repository to your fork in the GitHub web interface and then let merge it) The next optional step is to checkout the particular commit hash from which the image was bootstrapped. It is optional because the Iceberg now supports cherry picking so you can avoid of committing changes you do not want. But to start your branches from a state when the image working copy is in sync with the git working copy is of course cleaner. Currently the bootstrapped image has some packages that are marked as dirty and it will make mess if you will try to commit your changes. You can avoid it by reloading of these dirty packages. This will be not needed in future. All these steps you can automatized by the following code. You need to at least customize your repository clone path and GitHub user name. It is supposed to be run only once on freshly downloaded Pharo 7 image. | location userName pharoRepository fork | location := '/path/to/your/pharo/repository'. userName := 'github-user-name'. Iceberg showSystemRepositories: true. pharoRepository := IceRepository registry detect: [ :each | each name = 'No name' ]. pharoRepository location: location asFileReference. fork := pharoRepository remotes detect: [ :remote | remote remoteName = userName ]. pharoRepository pushRemote: fork. pharoRepository pullRemote: pharoRepository origin. pharoRepository checkoutBranch: 'development'. pharoRepository backend pullFrom: pharoRepository origin. pharoRepository push. pharoRepository checkoutBranch: (SystemVersion current commitHash). [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do: [ :warning | warning resume: true ] As the result you should get a clean image based on the latest code that is ready to to create or review pull requests. Cheers, -- Pavel

Aug. 10, 2017

[ Pharo 70 ] build 24 / PR 188

by Guillermo Polito

This PR is only jenkins related, it does not modify any pharo code. https://pharo.fogbugz.com/f/cases/20297/Avoid-deadlocks-in-jenkins https://github.com/pharo-project/pharo/pull/188 It produced build 24. Build artifacts in here: http://files.pharo.org/image/70/ -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Re: [Pharo-dev] [Pharo-users] [ann] moldable brick editor - alpha

by Stephane Ducasse

Hi alex I added https://pharo.fogbugz.com/f/cases/20298/Check-and-remove-Athens-dependency-… But it would be better that you enter bug entry and not me because IT DOES NOT SCALE. Stef On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Stef, > > Can you be more precise so that we can take action? > > > In ConfigurationOfOSWindow there is the following dependency: > > spec > *with*: 'OSWindow-SDL2' > with: [ spec requires: #('OSWindow-Core' 'Athens' ) ] > > > The problem is that OSWindow-SDL2 depends on Athens which is strange, > because windowing system should not know anything about rendering and > Athens (or Pompeii or Sparta). > In Bloc we use OSWindow to support native windows and have a corresponding > dependency in BaselineOfBloc. It means that when loading Bloc monticello > (or metacello) updates OSWindow which requests loading of Athens. At the > same time there are some Morphic classes that were removed in Pharo 7 while > Athens adds extension methods to those classes. So we should either update > Athens to remove those extensions method and (which is better) make > OSWindow independent from Athens. > > Just remember that we will not add new things in Pharo if we do not remove >> the equivalent already in the system. >> I'm fed up to have three different half working mechanisms. > > > Key class exists in Pharo by default and is already used by morphic: > KeyboardEvent>>#key. We just reuse existing stuff :) > > Cheers, > Alex > > On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> >> >> On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>> Hi Denis, >>> >>> Thanks a lot for looking into it :) >>> See my answers for every point below: >>> >>> 1) Loading in Pharo 7 signal dependency error: >>> >>> That is true, but I can not do anything about it now :( OSWindow-SDL >>> depends on Athens (while it should not). In Bloc we don't use / need Athens >>> but because of OSWindow's dependency Athens tries to update itself. >>> Additionally the classes you mentioned were removed from the system, while >>> Athens adds extension methods to them => error during installation. In >>> Pharo 6 there is no error, though. >>> >> >> Can you be more precise so that we can take action? >> >> >> >> >>> >>> 2) Text cursor up/down is not working correctly when text is wrapped. >>> >>> Indeed, up/down movement is a bit tricky :) But its implementation is in >>> fact very interesting. Take a look at this video: â >>> Bloc-FocusNavigationLong.mov >>> <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive…> >>> â >>> Bloc has support of element-independent *visual* focus navigation. In >>> the editor we reuse it for the cursor (one cursor for a moment but we >>> target to support multiple). However, because of text's special nature it >>> is not super smooth but will be improved :) >>> >>> 3) I look a bit at text commands (TextEditorCommand) and found that >>>> current KeyMapping package ($a asShortcut) is not used. Instead there is >>>> new hierarchy of BlKeyCombination. >>> >>> >>> It is a special bloc feature that requires its own announcement. As a >>> teaser I can say that we rely on *Key* and not on *Character + >>> modifiers* while defining shortcuts. It allows us to build any *key* >>> combinations possible. For example we distinguish left and right shift, >>> left and right meta, etc. Shortcuts can consist only of one Key or be just >>> only right shift :) It is super flexible but we will come to it later ;) >>> >> >> Just remember that we will not add new things in Pharo if we do not >> remove the equivalent already in the system. >> I'm fed up to have three different half working mechanisms. >> >> >> >>> P.S. arrows are also treated at shortcuts and not as keystroke: meaning >>> that there is no need to do this: >>> >>> [image: Inline images 1] >>> >>> 4) I thing we should try to use Commander for new UI widgets. For >>>> example It is very naturally applied to TextEditorCommand hierarchy. And it >>>> will automatically remove hardcoded shortcuts defined in method >>>> BrTextEditor>>onAttached: >>> >>> >>> Commander didn't yet made it into release :) Just as prove of concept I >>> hardcoded shortcuts in onAttached: tin order to show that *they all* >>> are in one single place. There is no other place where we check if any >>> modifier keys pressed! It is beautiful and will allow us to ship editor >>> with fully customisable shortcuts (nothing should stop us from having vim >>> bindings). >>> >>> Cheers, >>> Alex >>> >>> On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> Good job guys. >>>> >>>> Here is my feedback: >>>> >>>> 1) Loading in Pharo 7 signal dependency error: >>>> >>>> This package depends on the following classes: >>>> NewList >>>> NewListRenderer >>>> TabActionButton >>>> Tab >>>> TabBar >>>> >>>> Then I proceed and it was loaded fine. And editor works like in demo. >>>> >>>> 2) Text cursor up/down is not working correctly when text is wrapped. >>>> >>>> - it jumps between real text line instead of visual wrapped lines. >>>> >>>> - it skips empty lines >>>> >>>> - sometimes it is just not moved (not found concrete case) >>>> >>>> >>>> 3) I look a bit at text commands (TextEditorCommand) and found that >>>> current KeyMapping package ($a asShortcut) is not used. Instead there is >>>> new hierarchy of BlKeyCombination. >>>> What the reason for this? >>>> >>>> 4) I thing we should try to use Commander for new UI widgets. For >>>> example It is very naturally applied to TextEditorCommand hierarchy. And it >>>> will automatically remove hardcoded shortcuts defined in method >>>> BrTextEditor>>onAttached: >>>> >>>> >>>> >>>> >>>> 2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>>> Hi, >>>>> >>>>> We are very happy to announce the alpha version of a moldable editor >>>>> built in Brick (https://github.com/pharo-graphics/Brick) which is >>>>> based on Bloc (https://github.com/pharo-graphics/Bloc) This is >>>>> primarily the work of Alex Syrel. The project was initially >>>>> financially sponsored by ESUG and it is currently supported by feenk. And >>>>> of course, the project is based on the tremendous work that went into >>>>> Bloc and Brick by all contributors. >>>>> >>>>> Take a look at this 2 min video: >>>>> https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be >>>>> >>>>> The basic editor works and it is both flexible and scalable. For >>>>> example, the last example shown in the video is an editor opened on 1M >>>>> characters, which is reasonably large, and as can be seen see one can >>>>> interact with it as smoothly as with the one screen text. It actually works >>>>> just as fine with 100M characters. >>>>> >>>>> The functionality of the editor includes: rendering, line wrapping, >>>>> keypress and shortcut handling, navigation, selection and text styling. >>>>> Currently, the editor is 1260 lines of code including method and class >>>>> comments. This is not large for a text editor and this is possible because >>>>> most of the work is done by generic concepts that already exist in Bloc >>>>> such as layouts and text measurements. Beside the small maintenance cost, >>>>> the benefit is that we have the option to build all sorts of variations >>>>> with little effort. That is why we call this a moldable text editor. >>>>> >>>>> Another benefit of using elements and layouts is that we can also >>>>> embed other kinds of non-text elements with little effort (such as >>>>> pictures), and obtain a rich and live text editor. We already have basic >>>>> examples for this behavior, and we will focus more in the next period on >>>>> this area. >>>>> >>>>> The next immediate step is to add syntax highlighting. Beside the text >>>>> attributes problem, this issue will also exercise the thread-safety >>>>> the implementation is. The underlying structure ( >>>>> https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically >>>>> thread-safe, but it still needs to be proven in practice. >>>>> >>>>> We think this is a significant step because the editor was the main >>>>> piece missing in Brick and it will finally allow us to build value that can >>>>> be directly perceived by regular users on top of Brick and this, in turn, >>>>> will generate more traction. Please also note that because now Bloc is >>>>> directly embeddable in Morphic it means that we can actually start using it >>>>> right away. For example, the picture below shows the text element being >>>>> shown through a live preview in the GTInspector. >>>>> >>>>> [image: Playground @ â¢ a8rEditorE1ement x Page â BrRopedText string: >>>>> Emphasizing everything text : nothing' text attributes: { >>>>> BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri >>>>> bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: >>>>> from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } >>>>> from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng >>>>> to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever >>>>> thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: >>>>> Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. >>>>> BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 >>>>> from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: >>>>> (BrTextEdi tor new text: text) .] >>>>> >>>>> This is another puzzle piece towards the final goal of engineering the >>>>> future of the Pharo user interface. There is still a long way to go to >>>>> reach that goal, but considering the work that is behind us, that goal that >>>>> looked so illusive when Alain and Stef initiated the Bloc project is now >>>>> palpable. >>>>> >>>>> We will continue the work on this over the next period and we expect >>>>> to announce new developments soon. >>>>> >>>>> If you want to play with it, you can load the code like this (works in >>>>> both Pharo 6 and 7): >>>>> Iceberg enableMetacelloIntegration: true. >>>>> Metacello new >>>>> baseline: 'Brick'; >>>>> repository: 'github://pharo-graphics/Brick/src'; >>>>> load: #development >>>>> >>>>> Please let us know what you think. >>>>> >>>>> Cheers, >>>>> Alex and Doru >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "What is more important: To be happy, or to make happy?" >>>>> >>>>> >>>> >>> >> >

Aug. 10, 2017

[ Pharo 70 ] build 23 / PR 132

by Stephane Ducasse

Hi https://pharo.fogbugz.com/f/cases/17848/SequenciableCollection-first-raise-… https://github.com/pharo-project/pharo/pull/132 Stef

Aug. 10, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

Tx On Thu, Aug 10, 2017 at 7:21 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Wed, Aug 09, 2017 at 08:23:50PM +0200, Stephane Ducasse wrote: >> Tx! >> So that I do not make mistake: >> The fix is the second solution. Now do we have somewhere the first one? > > Not yet. My patch also fixes some inconsistencies in path > canonicalisation. > > I'll separate the code out in to two separate patches and post. > > Cheers, > Alistair > > > >> On Wed, Aug 9, 2017 at 10:08 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hi >> > >> > 2017-08-09 8:47 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> >> >> Hi Stef, >> >> >> >> On Tue, Aug 08, 2017 at 07:00:04PM +0200, Stephane Ducasse wrote: >> >> > Hi Alistair >> >> > >> >> > I'm going over the green build first. >> >> > >> >> > - Then also >> >> > https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… >> >> > I read it but do you suggest to drop it and close it? >> >> >> >> I don't think this issue should be dropped, there is a regular stream of >> >> questions to the mailing list from newcomers getting confused by the >> >> current behaviour. >> >> >> >> There are basically two opposing proposals: >> >> >> >> 1. Modify FileReference>>/ to accept a path and parse it correctly >> >> (which is what I proposed). >> >> 2. Modify FileReference>>/ to explicitly reject an argument which >> >> includes the path delimiter (and it should suggest using #resolve:). >> >> >> >> The first proposal is more "practical", and the second is more "pure", >> >> keeping the to original design goals and abstractions. >> >> >> >> Both have had multiple people support them, and both are better than the >> >> current situation, however it is subjective as to which of the two >> >> proposals is better. >> > >> > >> > I would vote for first solution >> > >> >> >> >> >> >> I'm not sure what the normal tie-breaking process is, but I'm happy to >> >> defer to the Pharo Association (Esteban? / Marcus? / yourself?). >> >> >> >> Cheers, >> >> Alistair >> >> >> > >> >

Aug. 10, 2017