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

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

Tx! So that I do not make mistake: The fix is the second solution. Now do we have somewhere the first one? 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. 9, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

Tx guille. So I will update the bug entry. On Tue, Aug 8, 2017 at 7:29 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Stef, > > On Tue, Aug 8, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi Alistair >> >> I'm going over the green build first. >> >> - Can you tell me what you think about the PR 92 05723 Default Working >> Directory >> https://pharo.fogbugz.com/f/cases/5723/ > > > This cannot be integrated yet. We have to review dependencies in the > bootstrap, because it introduces a (correct) definition of a working > directory but using FFI. And FFI is not in the kernel. > > >> >> - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-do >> esn-t-exist-but-still-exists >> I read it but do you suggest to drop it and close it? >> >> TX >> >> On Tue, Aug 8, 2017 at 6:44 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > For the moment I'm trying to understand the process and this is not >> that simple >> > because in flux. >> > >> > stef >> > >> > On Tue, Aug 8, 2017 at 3:24 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >> Hi Stef, >> >> >> >> Great, thanks! >> >> >> >> If you've got any questions or concerns, please let me know, I'm more >> >> than happy to discuss them. >> >> >> >> I've also got one more change that I haven't submitted yet. I >> >> originally developed a patch that modified FileReference>>/ to accept >> >> paths. However this directly conflicts with the change proposed in >> >> https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-do >> esn-t-exist-but-still-exists. >> >> Opinion seems to be split on which way we should go, so I'll defer to >> >> higher authority on this particular issue. My patch also separated >> >> path canonicalisation, as discussed in >> >> http://forum.world.st/FileReference-gt-gt-and-path-canonical >> isation-td4952575.html, >> >> so I might separate that out and make it a separate patch. >> >> >> >> >> >> Cheers, >> >> Alistair >> >> >> >> On 8 August 2017 at 10:27, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >>> Hi alistair >> >>> >> >>> I will go over all the FS changes and push them in Pharo 70. >> >>> I'm learning the process to integrate fixes and I attract bugs :) >> >>> >> >>> Stef >> >>> >> >> >> >> > > > -- > > > > 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 <+33%206%2052%2070%2066%2013> >

Aug. 9, 2017

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

by Stephane Ducasse

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. 9, 2017

[Pharo 70] PR 185 / Build 17

by Stephane Ducasse

Hi We do not have yet an automated mail after each integration. So I will do it by hand. I'm going over the green issues https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… And integrating the ones I understand. Then I will look at the other ones. Stef [Pharo 70] PR 185 / Build 17 SLICE-Issue-18818-Add-labelled-simple-widget https://github.com/pharo-project/pharo/commit/73ffa96a4993ca482410437c91f39…

Aug. 9, 2017

Re: [Pharo-dev] GTInspector auto refresh hooks?

by Andrei Chis

On Wed, Aug 9, 2017 at 3:32 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Actually I found trick: > > composite fastTable > > title: 'Devices'; > display: [ devices ]; > wantsAutomaticRefresh: true; > > *when: GLMPresentationRefreshRequest do: [myModel update].* > > > Event handler can be executed after actual view update because announcer > do not ensure delivering order. But in that case new value will be shown at > next refresh which should be fine. > What you thing? > Interesting trick :). But I think it should work. Like you said in the worst case the user will see the new data at the next refresh. Cheers, Andrei > > 2017-08-09 13:47 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Hi Denis, >> >> The current update mechanism in the inspector is very light, in the sense >> that it only updates the visual representation of elements and does not >> recompute them, nor offers any hooks into the update process. >> Indeed having a way to also recompute the display elements could be >> useful. We could change the update mechanism to add different kind of >> update strategies. >> >> Cheers, >> Andrei >> >> On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hi. >>> >>> Is there a way in GTInspector presentation to call some special updating >>> block before each of auto refresh operation? >>> >>> I want something like: >>> >>> composite fastTable >>> title: 'Devices'; >>> display: [ devices ]; >>> wantsAutomaticRefresh: true; >>> >>> * beforeUpdateDo: ["rows updating code"]* >>> >>> Imaging my presentation shows database table and I want query updated >>> rows. >>> >>> (I activate updating by GTInspector setEnabledStepRefreshStatus: true). >>> >>> Best regards, >>> Denis >>> >> >> >

Aug. 9, 2017

Re: [Pharo-dev] GTInspector auto refresh hooks?

by Denis Kudriashov

Actually I found trick: composite fastTable title: 'Devices'; display: [ devices ]; wantsAutomaticRefresh: true; *when: GLMPresentationRefreshRequest do: [myModel update].* Event handler can be executed after actual view update because announcer do not ensure delivering order. But in that case new value will be shown at next refresh which should be fine. What you thing? 2017-08-09 13:47 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi Denis, > > The current update mechanism in the inspector is very light, in the sense > that it only updates the visual representation of elements and does not > recompute them, nor offers any hooks into the update process. > Indeed having a way to also recompute the display elements could be > useful. We could change the update mechanism to add different kind of > update strategies. > > Cheers, > Andrei > > On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi. >> >> Is there a way in GTInspector presentation to call some special updating >> block before each of auto refresh operation? >> >> I want something like: >> >> composite fastTable >> title: 'Devices'; >> display: [ devices ]; >> wantsAutomaticRefresh: true; >> >> * beforeUpdateDo: ["rows updating code"]* >> >> Imaging my presentation shows database table and I want query updated >> rows. >> >> (I activate updating by GTInspector setEnabledStepRefreshStatus: true). >> >> Best regards, >> Denis >> > >

Aug. 9, 2017

Re: [Pharo-dev] GTInspector auto refresh hooks?

by Andrei Chis

Hi Denis, The current update mechanism in the inspector is very light, in the sense that it only updates the visual representation of elements and does not recompute them, nor offers any hooks into the update process. Indeed having a way to also recompute the display elements could be useful. We could change the update mechanism to add different kind of update strategies. Cheers, Andrei On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Is there a way in GTInspector presentation to call some special updating > block before each of auto refresh operation? > > I want something like: > > composite fastTable > title: 'Devices'; > display: [ devices ]; > wantsAutomaticRefresh: true; > > * beforeUpdateDo: ["rows updating code"]* > > Imaging my presentation shows database table and I want query updated rows. > > (I activate updating by GTInspector setEnabledStepRefreshStatus: true). > > Best regards, > Denis >

Aug. 9, 2017

Re: [Pharo-dev] Pull requests ready to be reviewed

by Alistair Grant

On Wed, Aug 09, 2017 at 12:20:17PM +0200, Guillermo Polito wrote: > On Wed, Aug 9, 2017 at 11:09 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > We have several pull requests validated successfully by the infrastructure. > They need to be reviewed by humans: > > https://github.com/pharo-project/pharo/pull/75 > > > This one has a merge coflict. This is also the subject of a current discussion, see subject "FileSystem fix integration" Cheers, Alistair > https://github.com/pharo-project/pharo/pull/66 > > > I made a little review there :) > > > > > https://github.com/pharo-project/pharo/pull/175 > > https://github.com/pharo-project/pharo/pull/172 > > https://github.com/pharo-project/pharo/pull/169 > > https://github.com/pharo-project/pharo/pull/168 > > https://github.com/pharo-project/pharo/pull/134

Aug. 9, 2017

Re: [Pharo-dev] Pull requests ready to be reviewed

by Guillermo Polito

On Wed, Aug 9, 2017 at 11:09 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > We have several pull requests validated successfully by the > infrastructure. They need to be reviewed by humans: > > https://github.com/pharo-project/pharo/pull/75 > This one has a merge coflict. > > > https://github.com/pharo-project/pharo/pull/66 > I made a little review there :) > > > https://github.com/pharo-project/pharo/pull/175 > > https://github.com/pharo-project/pharo/pull/172 > > https://github.com/pharo-project/pharo/pull/169 > > https://github.com/pharo-project/pharo/pull/168 > > https://github.com/pharo-project/pharo/pull/134 > > 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. 9, 2017

Pull requests ready to be reviewed

by Pavel Krivanek

We have several pull requests validated successfully by the infrastructure. They need to be reviewed by humans: https://github.com/pharo-project/pharo/pull/75 https://github.com/pharo-project/pharo/pull/66 https://github.com/pharo-project/pharo/pull/175 https://github.com/pharo-project/pharo/pull/172 https://github.com/pharo-project/pharo/pull/169 https://github.com/pharo-project/pharo/pull/168 https://github.com/pharo-project/pharo/pull/134 Cheers, -- Pavel

Aug. 9, 2017