September 2017 - Pharo-users

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

by Thierry Goubier

Hi Tim, 2017-09-01 13:39 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Thanks Thierry - this is proving an interesting problem domain ... > > I too am using #bestNodeFor: although I don't find it always gives the > best node (it does if you are clearly in the target range, but if you are > on the outer boundary like the next position after a selector or next to a > "." or ";" it favours the parent and not the closest node. So in usage I > find I need to tweak it a bit. > Yes, when you are on a boundary, then finding the right node may be difficult. When developping the ancestor to smart suggestion, I considered #bestNodeFor: as good enough, but I considered looking into "up" and "down" ast navigation at a time, and I wasn't alone (I think it was active in the Pharo editor at a point). > > I'll look at smacc though - also there is that experimental setting to > allow parse errors, I don't know if it helps in any way. > There is a general question there, which is how you try to parse as much as possible while jumping over the error, making the error area as small as possible (that would be really great for syntax highlighting, by the way). The problem is that in hand-written parsers, you need to hard-code the error management in the parser. With a table-driven parser (as is SmaCC), then you can explore in a systematic way what are the possible states that would allow the parsing to continue correctly after making the error area as small as possible. This would make for a very nice internship subject... > All this said, I think I have a workable suggestion that is not much code > that might be open to scrutiny from those wiser than me. > > Looking at the keyboard handling in the system - it's quite sprawling and > tricky to follow. I think there is lots of room for refactoring. > It is very easy in Pharo to implement a nice and clean keyboard handling; all the necessary components have been in place for years, and we already have implementations (using the KM API). Now, most Pharo developpers just jump into hardcoding keyboard handling instead. Thierry > > I'm also not sure if I like the pragma usage either - I find it quite > difficult to follow what's calling what. > > Tim > > Sent from my iPhone > > On 1 Sep 2017, at 09:18, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi Tim, > > The RB ast has a specific method for finding the right node: in > AltBrowser, I use ast bestNodeFor: aTarget selectionInterval. > > For the second case (parse what is selected), you may want to look into > SmaCC: it has specific entry points (used for refactoring) to try all > possible starts in a parser for a given piece of text and returning all the > possible correct asts. As a hand-writen parser, the RBParser can't do that > unless you add the necessary entry points by hand and hack around the error > handling, because most of the parse attempts end on an error (as they > should). > > Regards, > > Thierry > > 2017-09-01 8:50 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Marcus - I'd be interested in how you thought to solve this. >> >> My solution seems to work - but it's not the most elegant. Retrying lots >> of different ways like I show, smacks a bit of desperation (this said, it >> is quite compact). >> >> Apart from that - I was actually interested in thoughts on the parse >> method - the onError naming is a bit misleading compared to other methods >> in the image. I wonder if it should be called something like >> "onErrorMerge:" to signal that it's going to reuse the results? >> >> Stef - with regards to broken source, my proposed solution reuses what is >> already there - thus if you highlight specific code, it reverts to the >> original strategy and tries to compile just that code. This bugs me however >> - so if you highlight nothing, it tries to compile the source multiple >> ways, I drop down to chopping the source up to where your cursor is - which >> seems like a decent cheap strategy. >> >> I don't know if our parser is able to recover from simple errors and just >> have error nodes in the ast, and whether the #bestNodeFor method then >> ignored error nodes... this is what I think Dolphin used to do. >> >> Tim >> >> Sent from my iPhone >> >> > On 31 Aug 2017, at 19:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > >> > >> >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >> >> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim(a)testit.works> >> wrote: >> >>> Iâm looking for some feedback on the usage of >> RBParser>>#parseMethod:onError:. >> >>> >> >>> I am looking at ways of improving the way we edit code - and making >> things work (as least for me - but maybe for everyone) a bit more like >> IntelliJ where they have some great code operations and very good keyboard >> support. We are certainly close, but at times feel a bit clumsy - which is >> a shame as we have far better infrastructure to support equivalent >> features. So I thought I would have a go. >> >> >> >> Excellent!!! >> >> >> >> >> >>> Anyway - step one (which I think Iâve come close on), was to teach >> senders/implementors to look at the AST so you donât have to highlight >> exactly what you want to search on - instead it can infer from your cursorâ¦ >> however my next step was to improve how we can select code to ease >> refactoring, bracketing etcâ¦ >> >> >> >> Yes but we have to handle broken code then. >> >> Did you check how smart suggestions did it for code that compiled? >> >> >> > >> > I looked some weeks ago and made some notes what to doâ¦ but I fear this >> has to wait for next week, >> > there is no way that I can do anything till ESUGâ¦ >> > >> > Marcus >> >> >> >

Sept. 7, 2017

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

by Alistair Grant

Hi Andreas, On Wed, Sep 06, 2017 at 04:53:27PM -0700, Andreas Sunardi wrote: > Hi Alistair, > > I found fogbugz #19717 where this was discussed. > > https://pharo.fogbugz.com/f/cases/19717/ > FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder > > The issue seems to be the current working directory is saved in instance > variable workingDirectory. When the image is moved to another directory, this > workingDirectory becomes incorrect. Instance variable 'store', through its # > defaultWorkingDirectory, always gives the right answer (however, this answer is > the image directory, not directory where the command is invoked, which is the > issue in #05723 you mentioned). > > Here's a snippet from fogbugz #19717 original problem on how to reproduce it: > QUOTE > 1/ open an image. evaluate './pharo-local' asFileReference and keep the > inspector. > 2/ save and quit > 3/ move the image to another directory > 4/ open the image > 5/ evaluate self fullName on the file reference => it will give a wrong path > with a reference to the working directory used at file reference creation. > ENDQUOTE Thanks for finding this! In #20164 I reintroduced caching the working directory, but update it when the session is stopped and started, so the above test produces the expected results. As you can see in the comments for the associated PR, caching the value was a significant peformance improvement for at least one person. https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDir… > I don't know if it's still debatable, which './pharo-local' the file reference > should refer to, but I think I agree with fogbugz #19717 that it should stay as > relative path. > > But this is a separate issue than losing the ability to change working > directory, which seems to me an unintentional side-effect in the solution. I'll > see if I can jump onto $05723 to request support for changing working > directory. > > On a side note, is current working directory the same as image directory in > Pharo? I wonder why we have these issues if they are separate things. I haven't > dived into this, so I can't say much. Yes, which was the original driver for #05723. After it is integrated the working directory will be the process working directory. The image directory can of course still be accessed with FileLocator imageDirectory. Cheers, Alistair > -- > Andreas > > On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote: > > It isn't only #changeDirectory: method that is missing. Method # > > workingDirectoryPath: and instance variable workingDirectory are also > missing. > > > > FileSystem >> changeDirectory: aPath > > self workingDirectoryPath: (self resolve: aPath) > > > > FileSystem >> workingDirectoryPath: aPath > > aPath isAbsolute > > ifFalse: [ self error: 'Cannot set the working directory to a > relative > > path' ]. > > workingDirectory := aPath > > > > > > To solve my problem, I implemented those and also fixed # > initializeWithStore: > > and changed #workingDirectoryPath > > > > FileSystem >> initializeWithStore: aStore > > store := aStore. > > workingDirectory := store defaultWorkingDirectory > > > > FileSystem >> workingDirectoryPath > > ^ workingDirectory > > > > > > Those are from Pharo 5. However, this breaks Monticello (when opening > > Monticello Browser). A FileSystem instance has instance variable > > workingDirectory set to nil. This should be impossible. I set 'self halt' > in # > > initializeWithStore:. It doesn't get triggered, which tells me the > instance > > isn't created by normal way. I don't know what's going on there. > > > > > > To fix it, I changed #workingDirectoryPath to > > > > FileSystem >> workingDirectoryPath > > workingDirectory ifNil: [ > > workingDirectory := store defaultWorkingDirectory ]. > > ^ workingDirectory > > > > > > That solves my problem, but this is a specific tool. I don't know what > other > > problems those changes will cause. This #ifNil: guard is not in Pharo 5, > so > > that makes me worry. In general, the change in FileSystem gives > impression that > > the it is intentional. But I haven't found the new Pharo 6.1 way to > change > > working directory, if there's any. > > I couldn't find a fogbugz issue relating to this - if anyone knows the > issue, please post it here as it would be good to understand the > rationale for the change. > > My interpretation of the changes are that the decision was made to hard > code the working directory to the image directory. There are quite a > few people who don't agree with this. :-) > > There is already a proposed patch to change the working directory to the > process working directory, see fogbugz #05723. > https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory > > The patch is waiting on a fix to include UFFI in the kernel. > > It currently doesn't allow the working directory to be changed, > but if I remember correctly, Rajula developed the code to change the > working directory. > > I think this approach has the advantage that it will automtically work > with forked processes, e.g. using OSProcess / OSSubprocess. > > It would be worthwhile adding a comment to the issue asking Rajula to > add the change directory functionality to the patch. > > Cheers, > Alistair > > > > > -- > > Andreas > > > > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > > > > Thanks for reporting. > > I do not remember an action around me for this change. > > Do you have the definition in Pharo 50 at hand? > > > > Stef > > > > On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi < > a.sunardi(a)gmail.com> > > wrote: > > > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've > been > > > using FileSystem>>changeDirectory to make my program (Pharo 5) runs > in > > the > > > current working directory (thus able to find local files). > > > > > > This is now broken because #changeDirectory doesn't exist anymore. > The > > > change seems intentional. > > > > > > Question: Is there a different way in Pharo 6 do set working > directory or > > is > > > this a bug? > > > > > > -- > > > Andreas

Sept. 7, 2017

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

by Stephane Ducasse

Tim Oh yes. There are still part of Pharo that we did not clean. Stef On Fri, Sep 1, 2017 at 1:39 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Thanks Thierry - this is proving an interesting problem domain ... > > I too am using #bestNodeFor: although I don't find it always gives the best > node (it does if you are clearly in the target range, but if you are on the > outer boundary like the next position after a selector or next to a "." or > ";" it favours the parent and not the closest node. So in usage I find I > need to tweak it a bit. > > I'll look at smacc though - also there is that experimental setting to allow > parse errors, I don't know if it helps in any way. > > All this said, I think I have a workable suggestion that is not much code > that might be open to scrutiny from those wiser than me. > > Looking at the keyboard handling in the system - it's quite sprawling and > tricky to follow. I think there is lots of room for refactoring. > > I'm also not sure if I like the pragma usage either - I find it quite > difficult to follow what's calling what. > > Tim > > Sent from my iPhone > > On 1 Sep 2017, at 09:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Tim, > > The RB ast has a specific method for finding the right node: in AltBrowser, > I use ast bestNodeFor: aTarget selectionInterval. > > For the second case (parse what is selected), you may want to look into > SmaCC: it has specific entry points (used for refactoring) to try all > possible starts in a parser for a given piece of text and returning all the > possible correct asts. As a hand-writen parser, the RBParser can't do that > unless you add the necessary entry points by hand and hack around the error > handling, because most of the parse attempts end on an error (as they > should). > > Regards, > > Thierry > > 2017-09-01 8:50 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >> Marcus - I'd be interested in how you thought to solve this. >> >> My solution seems to work - but it's not the most elegant. Retrying lots >> of different ways like I show, smacks a bit of desperation (this said, it is >> quite compact). >> >> Apart from that - I was actually interested in thoughts on the parse >> method - the onError naming is a bit misleading compared to other methods in >> the image. I wonder if it should be called something like "onErrorMerge:" >> to signal that it's going to reuse the results? >> >> Stef - with regards to broken source, my proposed solution reuses what is >> already there - thus if you highlight specific code, it reverts to the >> original strategy and tries to compile just that code. This bugs me however >> - so if you highlight nothing, it tries to compile the source multiple ways, >> I drop down to chopping the source up to where your cursor is - which seems >> like a decent cheap strategy. >> >> I don't know if our parser is able to recover from simple errors and just >> have error nodes in the ast, and whether the #bestNodeFor method then >> ignored error nodes... this is what I think Dolphin used to do. >> >> Tim >> >> Sent from my iPhone >> >> > On 31 Aug 2017, at 19:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > >> > >> >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.self(a)gmail.com> >> >> wrote: >> >> >> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim(a)testit.works> >> >> wrote: >> >>> Iâm looking for some feedback on the usage of >> >>> RBParser>>#parseMethod:onError:. >> >>> >> >>> I am looking at ways of improving the way we edit code - and making >> >>> things work (as least for me - but maybe for everyone) a bit more like >> >>> IntelliJ where they have some great code operations and very good keyboard >> >>> support. We are certainly close, but at times feel a bit clumsy - which is a >> >>> shame as we have far better infrastructure to support equivalent features. >> >>> So I thought I would have a go. >> >> >> >> Excellent!!! >> >> >> >> >> >>> Anyway - step one (which I think Iâve come close on), was to teach >> >>> senders/implementors to look at the AST so you donât have to highlight >> >>> exactly what you want to search on - instead it can infer from your cursorâ¦ >> >>> however my next step was to improve how we can select code to ease >> >>> refactoring, bracketing etcâ¦ >> >> >> >> Yes but we have to handle broken code then. >> >> Did you check how smart suggestions did it for code that compiled? >> >> >> > >> > I looked some weeks ago and made some notes what to doâ¦ but I fear this >> > has to wait for next week, >> > there is no way that I can do anything till ESUGâ¦ >> > >> > Marcus >> >> >

Sept. 7, 2017

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

by Stephane Ducasse

Thanks a lot andreas!!!!!! On Thu, Sep 7, 2017 at 1:53 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > Hi Alistair, > > I found fogbugz #19717 where this was discussed. > > https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-a… > > The issue seems to be the current working directory is saved in instance > variable workingDirectory. When the image is moved to another directory, > this workingDirectory becomes incorrect. Instance variable 'store', through > its #defaultWorkingDirectory, always gives the right answer (however, this > answer is the image directory, not directory where the command is invoked, > which is the issue in #05723 you mentioned). > > Here's a snippet from fogbugz #19717 original problem on how to reproduce > it: > QUOTE > 1/ open an image. evaluate './pharo-local' asFileReference and keep the > inspector. > 2/ save and quit > 3/ move the image to another directory > 4/ open the image > 5/ evaluate self fullName on the file reference => it will give a wrong path > with a reference to the working directory used at file reference creation. > ENDQUOTE > > I don't know if it's still debatable, which './pharo-local' the file > reference should refer to, but I think I agree with fogbugz #19717 that it > should stay as relative path. > > But this is a separate issue than losing the ability to change working > directory, which seems to me an unintentional side-effect in the solution. > I'll see if I can jump onto $05723 to request support for changing working > directory. > > On a side note, is current working directory the same as image directory in > Pharo? I wonder why we have these issues if they are separate things. I > haven't dived into this, so I can't say much. > > -- > Andreas > > On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote: >> > It isn't only #changeDirectory: method that is missing. Method # >> > workingDirectoryPath: and instance variable workingDirectory are also >> > missing. >> > >> > FileSystem >> changeDirectory: aPath >> > self workingDirectoryPath: (self resolve: aPath) >> > >> > FileSystem >> workingDirectoryPath: aPath >> > aPath isAbsolute >> > ifFalse: [ self error: 'Cannot set the working directory to a >> > relative >> > path' ]. >> > workingDirectory := aPath >> > >> > >> > To solve my problem, I implemented those and also fixed >> > #initializeWithStore: >> > and changed #workingDirectoryPath >> > >> > FileSystem >> initializeWithStore: aStore >> > store := aStore. >> > workingDirectory := store defaultWorkingDirectory >> > >> > FileSystem >> workingDirectoryPath >> > ^ workingDirectory >> > >> > >> > Those are from Pharo 5. However, this breaks Monticello (when opening >> > Monticello Browser). A FileSystem instance has instance variable >> > workingDirectory set to nil. This should be impossible. I set 'self >> > halt' in # >> > initializeWithStore:. It doesn't get triggered, which tells me the >> > instance >> > isn't created by normal way. I don't know what's going on there. >> > >> > >> > To fix it, I changed #workingDirectoryPath to >> > >> > FileSystem >> workingDirectoryPath >> > workingDirectory ifNil: [ >> > workingDirectory := store defaultWorkingDirectory ]. >> > ^ workingDirectory >> > >> > >> > That solves my problem, but this is a specific tool. I don't know what >> > other >> > problems those changes will cause. This #ifNil: guard is not in Pharo 5, >> > so >> > that makes me worry. In general, the change in FileSystem gives >> > impression that >> > the it is intentional. But I haven't found the new Pharo 6.1 way to >> > change >> > working directory, if there's any. >> >> I couldn't find a fogbugz issue relating to this - if anyone knows the >> issue, please post it here as it would be good to understand the >> rationale for the change. >> >> My interpretation of the changes are that the decision was made to hard >> code the working directory to the image directory. There are quite a >> few people who don't agree with this. :-) >> >> There is already a proposed patch to change the working directory to the >> process working directory, see fogbugz #05723. >> https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory >> >> The patch is waiting on a fix to include UFFI in the kernel. >> >> It currently doesn't allow the working directory to be changed, >> but if I remember correctly, Rajula developed the code to change the >> working directory. >> >> I think this approach has the advantage that it will automtically work >> with forked processes, e.g. using OSProcess / OSSubprocess. >> >> It would be worthwhile adding a comment to the issue asking Rajula to >> add the change directory functionality to the patch. >> >> Cheers, >> Alistair >> >> >> >> > -- >> > Andreas >> > >> > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse >> > <stepharo.self(a)gmail.com> >> > wrote: >> > >> > Thanks for reporting. >> > I do not remember an action around me for this change. >> > Do you have the definition in Pharo 50 at hand? >> > >> > Stef >> > >> > On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi >> > <a.sunardi(a)gmail.com> >> > wrote: >> > > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've >> > been >> > > using FileSystem>>changeDirectory to make my program (Pharo 5) >> > runs in >> > the >> > > current working directory (thus able to find local files). >> > > >> > > This is now broken because #changeDirectory doesn't exist anymore. >> > The >> > > change seems intentional. >> > > >> > > Question: Is there a different way in Pharo 6 do set working >> > directory or >> > is >> > > this a bug? >> > > >> > > -- >> > > Andreas >> > >> > >> > >> >

Sept. 7, 2017

Re: [Pharo-users] Spec "bindings"

by Stephane Ducasse

> Hi Stef, > > I think you are correct and you would still always perform actions like: > > initializeWidgets (to create components and sub-components) > initializePresenter (to define interactions between components) > > > But, there could also be a third initialization step like > > initializeSubject: aSubjectModel Yes I do not remember exactlty but I have the impression that I identified the same problem recently because I wanted to do MyApp on: aModel and I realized that the flow proposed did not let me do it that way (may be I'm incorrect). > That would allow you to initialize the domain model of each component > relative to your overall model. Yes. > Then, by exposing the aspects of your model available for viewing by a UI as > ValueHolders, it looks pretty straightforward (for simple objects) to extend > Spec to use those ValueHolders so that UI elements can implicitly update > themselves. > > The source of my inspiration is the Dolphin "Better Hello World" example(s) > here: > > http://object-arts.com/blog/files/better-hello-world.html > > > To try it out, I added a few Spec extensions and tried a little "counter" > test (like your MOOC example) displayed by a CounterApp (having an increment > button, decrement button, and label to show the count) such that > > CounterApp showOn: counter > > triggers > > CounterApp>>initializeSubject: aSubjectModel > > subject := aSubjectModel. > > countLabel initializeSubject: subject countHolder > > This results in replacing the UI label ValueHolder with the Counter's > "count" ValueHolder. If I had more aspects of my model I wanted to connect, > I would do it here, or if I wanted to connect the same thing to multiple > widgets (like a slider, for example), I would do that here as well. > > This allows direct interactions with the Counter model (for example, an > "increment" button) to be reflected directly by the UI without having to > explicitly update the value after the interaction or listening for events. > > I'll have to think about it some more, but I think Spec has what it needs > already to create a nice set of "type presenters" instead of what is > currently seems more like "widget presenters." Indeed. Thanks a lot for your analysis. > Then, instead of adding a LabelModel to a ComposableModel, you could add > something like a NumberPresenter and specify the spec you want to use (which > would in turn display the desired widget). > I didn't go that far yet, and created a NumberLabelModel for my example > above. It worked, but seems like the wrong way to go about it. Or maybe you > need both...I'm not sure! > > I also want to take a look at self-updating complex widgets as well (lists, > tables, etc...) so that telling a list presenter it's list means that adding > a value to that list could automatically update the widget and so on. > I had some crude prototyping success with that in VW before deciding > (hopefully for the last time) that "native" widgets aren't as important to > me as a solid and simple way to connect a model to a UI presentation. > This seems much easier to achieve in Pharo, and after years of intermittent > attempts I am hopeful that my knowledge level has finally become sufficient > to contribute something to this heroic effort. Superb. We are discussing with peter (but EsUG is so intense and I should finish the lectures for real now that I do not have the braincells) about a pragma driven to declare menus because this is a real lack. What I suggest is - Please please continue your experiment. - It would be great if we can compare some typical examples. - After that we can take a decision and improve/modify Spec and update the documentation. I want to write a small interface for a small app. I checked my code and I thought that it was strange that we cannot initialize presenter once the model is done GameListModel new on: GameCollector smallCollection; openWithSpec "protocol: #initialization" initializeWidgets listModel := self newList. listModel items: (collector collectionNamed: #owned) and then back then I realized that I was wrong. Stef thanks for this discussion. > > Take care, > > Rob > > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Rob >> >> Spec deserves another pass. >> I see your point with showOn: now I do not see how you could avoid the >> presenter building. But may be I'm not enough into it. >> So I'm interested in your feedback. >> >> Stef >> >> Stef >> >> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> >> wrote: >> > Hello, >> > >> > I was wondering what more experienced users than myself thought of the >> > idea >> > of an explicit Spec "connection point" to a domain model object similar >> > to >> > Dolphin's "showOn:" method, like: >> > >> > CounterApp showOn: counter. >> > >> > This would perhaps trigger something like Dolphin's Presenter>>model: >> > message (although I've always found the use of "model" confusing when >> > there >> > are so many "models" involved.) after the widgets had been created: >> > >> > ComposableModel>>initializeBindings: anObject >> > >> > In many cases, if your domain model uses ValueHolders as well (like Spec >> > does), making a connection could just mean replacing the Spec >> > ValueHolder >> > with your domain ValueHolder so changes to the domain model would >> > automatically propagate to the UI presentation without providing >> > explicit >> > code in ComposableModel>>initializePresenter. >> > >> > However, since I am still trying to understand and learn Spec, it's >> > quite >> > possible I am missing some key point and there are reasons not to >> > explore >> > this line of thinking! >> > >> > Thank you, >> > >> > Rob >> > >> >

Sept. 7, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Stephane Ducasse

Hi Manuel This is coooooool. How linked to nautilus it is? Stef On Wed, Sep 6, 2017 at 1:52 PM, Manuel Leuenberger <leuenberger(a)inf.unibe.ch > wrote: > Hi everyone, > > I built a little syntax highlighting extension for the Nautilus source > code pane, which puts a background color behind blocks, so that nested > blocks are easily recognizable. > > > Install with: > > Metacello new > baseline: 'BlockStyler'; > repository: 'github://maenu/BlockStyler/repository'; > load > > GitHub: https://github.com/maenu/BlockStyler > > Doesnât work with âFormat as you readâ, just as the IconStyler. If anybody > has an idea how to integrate it properly into Nautilus as a plugin, let me > know. Currently itâs an ugly meta-link hack to get access to the > sourceTextModel. > > Cheers, > Manuel >

Sept. 7, 2017

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

by Andreas Sunardi

Hi Alistair, I found fogbugz #19717 where this was discussed. https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-a… The issue seems to be the current working directory is saved in instance variable workingDirectory. When the image is moved to another directory, this workingDirectory becomes incorrect. Instance variable 'store', through its #defaultWorkingDirectory, always gives the right answer (however, this answer is the image directory, not directory where the command is invoked, which is the issue in #05723 you mentioned). Here's a snippet from fogbugz #19717 original problem on how to reproduce it: QUOTE 1/ open an image. evaluate './pharo-local' asFileReference and keep the inspector. 2/ save and quit 3/ move the image to another directory 4/ open the image 5/ evaluate self fullName on the file reference => it will give a wrong path with a reference to the working directory used at file reference creation. ENDQUOTE I don't know if it's still debatable, which './pharo-local' the file reference should refer to, but I think I agree with fogbugz #19717 that it should stay as relative path. But this is a separate issue than losing the ability to change working directory, which seems to me an unintentional side-effect in the solution. I'll see if I can jump onto $05723 to request support for changing working directory. On a side note, is current working directory the same as image directory in Pharo? I wonder why we have these issues if they are separate things. I haven't dived into this, so I can't say much. -- Andreas On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote: > > It isn't only #changeDirectory: method that is missing. Method # > > workingDirectoryPath: and instance variable workingDirectory are also > missing. > > > > FileSystem >> changeDirectory: aPath > > self workingDirectoryPath: (self resolve: aPath) > > > > FileSystem >> workingDirectoryPath: aPath > > aPath isAbsolute > > ifFalse: [ self error: 'Cannot set the working directory to a > relative > > path' ]. > > workingDirectory := aPath > > > > > > To solve my problem, I implemented those and also fixed > #initializeWithStore: > > and changed #workingDirectoryPath > > > > FileSystem >> initializeWithStore: aStore > > store := aStore. > > workingDirectory := store defaultWorkingDirectory > > > > FileSystem >> workingDirectoryPath > > ^ workingDirectory > > > > > > Those are from Pharo 5. However, this breaks Monticello (when opening > > Monticello Browser). A FileSystem instance has instance variable > > workingDirectory set to nil. This should be impossible. I set 'self > halt' in # > > initializeWithStore:. It doesn't get triggered, which tells me the > instance > > isn't created by normal way. I don't know what's going on there. > > > > > > To fix it, I changed #workingDirectoryPath to > > > > FileSystem >> workingDirectoryPath > > workingDirectory ifNil: [ > > workingDirectory := store defaultWorkingDirectory ]. > > ^ workingDirectory > > > > > > That solves my problem, but this is a specific tool. I don't know what > other > > problems those changes will cause. This #ifNil: guard is not in Pharo 5, > so > > that makes me worry. In general, the change in FileSystem gives > impression that > > the it is intentional. But I haven't found the new Pharo 6.1 way to > change > > working directory, if there's any. > > I couldn't find a fogbugz issue relating to this - if anyone knows the > issue, please post it here as it would be good to understand the > rationale for the change. > > My interpretation of the changes are that the decision was made to hard > code the working directory to the image directory. There are quite a > few people who don't agree with this. :-) > > There is already a proposed patch to change the working directory to the > process working directory, see fogbugz #05723. > https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory > > The patch is waiting on a fix to include UFFI in the kernel. > > It currently doesn't allow the working directory to be changed, > but if I remember correctly, Rajula developed the code to change the > working directory. > > I think this approach has the advantage that it will automtically work > with forked processes, e.g. using OSProcess / OSSubprocess. > > It would be worthwhile adding a comment to the issue asking Rajula to > add the change directory functionality to the patch. > > Cheers, > Alistair > > > > > -- > > Andreas > > > > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > > > > Thanks for reporting. > > I do not remember an action around me for this change. > > Do you have the definition in Pharo 50 at hand? > > > > Stef > > > > On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi < > a.sunardi(a)gmail.com> > > wrote: > > > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've > been > > > using FileSystem>>changeDirectory to make my program (Pharo 5) > runs in > > the > > > current working directory (thus able to find local files). > > > > > > This is now broken because #changeDirectory doesn't exist anymore. > The > > > change seems intentional. > > > > > > Question: Is there a different way in Pharo 6 do set working > directory or > > is > > > this a bug? > > > > > > -- > > > Andreas > > > > > > > >

Sept. 6, 2017

Re: [Pharo-users] Spec "bindings"

by Rob Rothwell

Hi Stef, I think you are correct and you would still always perform actions like: initializeWidgets (to create components and sub-components) initializePresenter (to define interactions between components) But, there could also be a third initialization step like initializeSubject: aSubjectModel That would allow you to initialize the domain model of each component relative to your overall model. Then, by exposing the aspects of your model available for viewing by a UI as ValueHolders, it looks pretty straightforward (for simple objects) to extend Spec to use those ValueHolders so that UI elements can implicitly update themselves. The source of my inspiration is the Dolphin "Better Hello World" example(s) here: http://object-arts.com/blog/files/better-hello-world.html To try it out, I added a few Spec extensions and tried a little "counter" test (like your MOOC example) displayed by a CounterApp (having an increment button, decrement button, and label to show the count) such that CounterApp showOn: counter triggers CounterApp>>initializeSubject: aSubjectModel subject := aSubjectModel. countLabel initializeSubject: subject countHolder This results in replacing the UI label ValueHolder with the Counter's "count" ValueHolder. If I had more aspects of my model I wanted to connect, I would do it here, or if I wanted to connect the same thing to multiple widgets (like a slider, for example), I would do that here as well. This allows direct interactions with the Counter model (for example, an "increment" button) to be reflected directly by the UI without having to explicitly update the value after the interaction or listening for events. I'll have to think about it some more, but I think Spec has what it needs already to create a nice set of "type presenters" instead of what is currently seems more like "widget presenters." Then, instead of adding a LabelModel to a ComposableModel, you could add something like a NumberPresenter and specify the spec you want to use (which would in turn display the desired widget). I didn't go that far yet, and created a NumberLabelModel for my example above. It worked, but seems like the wrong way to go about it. Or maybe you need both...I'm not sure! I also want to take a look at self-updating complex widgets as well (lists, tables, etc...) so that telling a list presenter it's list means that adding a value to that list could automatically update the widget and so on. I had some crude prototyping success with that in VW before deciding (hopefully for the last time) that "native" widgets aren't as important to me as a solid and simple way to connect a model to a UI presentation. This seems much easier to achieve in Pharo, and after years of intermittent attempts I am hopeful that my knowledge level has finally become sufficient to contribute something to this heroic effort. Take care, Rob On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Rob > > Spec deserves another pass. > I see your point with showOn: now I do not see how you could avoid the > presenter building. But may be I'm not enough into it. > So I'm interested in your feedback. > > Stef > > Stef > > On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> > wrote: > > Hello, > > > > I was wondering what more experienced users than myself thought of the > idea > > of an explicit Spec "connection point" to a domain model object similar > to > > Dolphin's "showOn:" method, like: > > > > CounterApp showOn: counter. > > > > This would perhaps trigger something like Dolphin's Presenter>>model: > > message (although I've always found the use of "model" confusing when > there > > are so many "models" involved.) after the widgets had been created: > > > > ComposableModel>>initializeBindings: anObject > > > > In many cases, if your domain model uses ValueHolders as well (like Spec > > does), making a connection could just mean replacing the Spec ValueHolder > > with your domain ValueHolder so changes to the domain model would > > automatically propagate to the UI presentation without providing explicit > > code in ComposableModel>>initializePresenter. > > > > However, since I am still trying to understand and learn Spec, it's quite > > possible I am missing some key point and there are reasons not to explore > > this line of thinking! > > > > Thank you, > > > > Rob > > > >

Sept. 6, 2017

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

by Alistair Grant

On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote: > It isn't only #changeDirectory: method that is missing. Method # > workingDirectoryPath: and instance variable workingDirectory are also missing. > > FileSystem >> changeDirectory: aPath > self workingDirectoryPath: (self resolve: aPath) > > FileSystem >> workingDirectoryPath: aPath > aPath isAbsolute > ifFalse: [ self error: 'Cannot set the working directory to a relative > path' ]. > workingDirectory := aPath > > > To solve my problem, I implemented those and also fixed #initializeWithStore: > and changed #workingDirectoryPath > > FileSystem >> initializeWithStore: aStore > store := aStore. > workingDirectory := store defaultWorkingDirectory > > FileSystem >> workingDirectoryPath > ^ workingDirectory > > > Those are from Pharo 5. However, this breaks Monticello (when opening > Monticello Browser). A FileSystem instance has instance variable > workingDirectory set to nil. This should be impossible. I set 'self halt' in # > initializeWithStore:. It doesn't get triggered, which tells me the instance > isn't created by normal way. I don't know what's going on there. > > > To fix it, I changed #workingDirectoryPath to > > FileSystem >> workingDirectoryPath > workingDirectory ifNil: [ > workingDirectory := store defaultWorkingDirectory ]. > ^ workingDirectory > > > That solves my problem, but this is a specific tool. I don't know what other > problems those changes will cause. This #ifNil: guard is not in Pharo 5, so > that makes me worry. In general, the change in FileSystem gives impression that > the it is intentional. But I haven't found the new Pharo 6.1 way to change > working directory, if there's any. I couldn't find a fogbugz issue relating to this - if anyone knows the issue, please post it here as it would be good to understand the rationale for the change. My interpretation of the changes are that the decision was made to hard code the working directory to the image directory. There are quite a few people who don't agree with this. :-) There is already a proposed patch to change the working directory to the process working directory, see fogbugz #05723. https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory The patch is waiting on a fix to include UFFI in the kernel. It currently doesn't allow the working directory to be changed, but if I remember correctly, Rajula developed the code to change the working directory. I think this approach has the advantage that it will automtically work with forked processes, e.g. using OSProcess / OSSubprocess. It would be worthwhile adding a comment to the issue asking Rajula to add the change directory functionality to the patch. Cheers, Alistair > -- > Andreas > > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Thanks for reporting. > I do not remember an action around me for this change. > Do you have the definition in Pharo 50 at hand? > > Stef > > On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been > > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in > the > > current working directory (thus able to find local files). > > > > This is now broken because #changeDirectory doesn't exist anymore. The > > change seems intentional. > > > > Question: Is there a different way in Pharo 6 do set working directory or > is > > this a bug? > > > > -- > > Andreas > > >

Sept. 6, 2017

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

by Andreas Sunardi

It isn't only #changeDirectory: method that is missing. Method #workingDirectoryPath: and instance variable workingDirectory are also missing. FileSystem >> changeDirectory: aPath self workingDirectoryPath: (self resolve: aPath) FileSystem >> workingDirectoryPath: aPath aPath isAbsolute ifFalse: [ self error: 'Cannot set the working directory to a relative path' ]. workingDirectory := aPath To solve my problem, I implemented those and also fixed #initializeWithStore: and changed #workingDirectoryPath FileSystem >> initializeWithStore: aStore store := aStore. workingDirectory := store defaultWorkingDirectory FileSystem >> workingDirectoryPath ^ workingDirectory Those are from Pharo 5. However, this breaks Monticello (when opening Monticello Browser). A FileSystem instance has instance variable workingDirectory set to nil. This should be impossible. I set 'self halt' in #initializeWithStore:. It doesn't get triggered, which tells me the instance isn't created by normal way. I don't know what's going on there. To fix it, I changed #workingDirectoryPath to FileSystem >> workingDirectoryPath workingDirectory ifNil: [ workingDirectory := store defaultWorkingDirectory ]. ^ workingDirectory That solves my problem, but this is a specific tool. I don't know what other problems those changes will cause. This #ifNil: guard is not in Pharo 5, so that makes me worry. In general, the change in FileSystem gives impression that the it is intentional. But I haven't found the new Pharo 6.1 way to change working directory, if there's any. -- Andreas On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks for reporting. > I do not remember an action around me for this change. > Do you have the definition in Pharo 50 at hand? > > Stef > > On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been > > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in > the > > current working directory (thus able to find local files). > > > > This is now broken because #changeDirectory doesn't exist anymore. The > > change seems intentional. > > > > Question: Is there a different way in Pharo 6 do set working directory > or is > > this a bug? > > > > -- > > Andreas > >

Sept. 6, 2017