September 2015 - Pharo-dev - lists.pharo.org

ZeroConf for Pi VM

by Torsten Bergmann

http://get.pharo.org includes many configurations but I do not see one for the Raspberry pi that installs the Raspberry Pi ARM VM. Is Pi already included somehow or does a Pi user still have to grab the VM ZIP manually from CI: https://ci.inria.fr/pharo/view/RaspberryPi/job/RaspberryPi-Publish Thanks T.

Sept. 30, 2015

Re: [Pharo-dev] Code completion in comment pane and Pillar

by phil＠highoctane.be

Completion in the comment pane is a major PITA for me. There are times when it makes sense, but not that often. Phil On Wed, Sep 30, 2015 at 9:56 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > Some time ago I ran into a problem with typing left brackets into comment > pane. > > As you know, code blocks in Pillar are marked with > [[[ > > However comment pane is subject to regular code completion of > NECController, which means that every time I type '[' NEC converts it into > '[ ]'. So if I type '[[[' then I get '[ [ [ ] ] ]'. Which is good in code, > but not here. > > Now considering we are pushing for Pillar in comments I think this should > be resolved. However I don't know how. > > a) disable code completion for comments (trivial, but loosing CC > b) subclass NECController to disable this. This is probably lot more > complex, because the current one is hard-wired via Smalltalk tools > c) add configuration option to NECControler so it can run in different > modes (still a lot of work) > > d) add setting to options to disable/enable CC in comments and let users > decide. > > d) other better, faster, easier solution? > > From future perspective b) could be used to provide more extensive code > completion, specifically for Pillar. > > Thanks, > Peter >

Sept. 30, 2015

Code completion in comment pane and Pillar

by Peter Uhnak

Hi, Some time ago I ran into a problem with typing left brackets into comment pane. As you know, code blocks in Pillar are marked with [[[ However comment pane is subject to regular code completion of NECController, which means that every time I type '[' NEC converts it into '[ ]'. So if I type '[[[' then I get '[ [ [ ] ] ]'. Which is good in code, but not here. Now considering we are pushing for Pillar in comments I think this should be resolved. However I don't know how. a) disable code completion for comments (trivial, but loosing CC b) subclass NECController to disable this. This is probably lot more complex, because the current one is hard-wired via Smalltalk tools c) add configuration option to NECControler so it can run in different modes (still a lot of work) d) add setting to options to disable/enable CC in comments and let users decide. d) other better, faster, easier solution? >From future perspective b) could be used to provide more extensive code completion, specifically for Pillar. Thanks, Peter

Sept. 30, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Alexandre Bergel

Why not having just one folder level? As we would have in any other language? One folder per package, and inside a .st file per class. Alexandre > Le 30 sept. 2015 Ã 18:47, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> a Ã©crit : > > > >> On 09/29/2015 01:50 AM, Henrik Johansen wrote: >> >>> On 29 Sep 2015, at 1:48 , Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> The big issue for git and windows (in general) is that there is a 255 character limit on the paths for files .... I recently pruned some file names for Metacello (on a win-hack branch) just to get Metacello to work with filetree .. >>> >>> Working with Github Desktop[1] for Windows makes the experience of using git from the command line tolerable on Windows - you get a retty nice bash shell to work with so as a non-windows user I can work in a pretty familiar environment ... >>> >>> At the moment I'm working with Pharo3.0 on Windows, so I don't have any useful feedback right now (assuming things have changed a bit on Windows with Pharo4.0 and Pharo5.0) ... >>> >>> Dale >> >> IIRC, there is some flag you can set to make (some?) the actual git client (but not bundled tools) support long filenames on Windows: >> git config core.longpaths true >> For instance, cloning the PharoVM repo choked (or rather, failed semi-silently) on some really long selector in an obscure plugin somewhere until I found that... > > Thanks Henry, I have done the `git config core.longpaths true` and I believe that that (supposedly) addresses manipulating long file paths problem for git, it does not help an application like pharo read the files with long paths ... without additional work ... and even then it's not clear that it truly fixes the problem ... because the fundamental limit is embedded in the OS ... for example from the git bash shell, I cannot `rm` the directories that have long paths (I have to use the explorer to delete them) and when I write out a package with long paths from Pharo3.0 the long path files are silently deleted ... > > If it worked for you, that's good ... my experience was not quite as nice:) > > Dale

Sept. 30, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by phil＠highoctane.be

Yes, about the git config core.longpaths true: works here as well. It requires git for windows > 1.9 to work. My 1.8.x choked, had to upgrade. I have checked out the VM code where there was the GeniePlugin problem and the issue was gone with that setup. cp -r or rm -rf indeed give trouble. If we used the Windows subst command to map a drive to some depth in the path and work from there, it would solve the issue. That's how I've done that for Java never ending directories in the past. Operations are also very slow compared to Unix. Phil On Wed, Sep 30, 2015 at 6:47 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 09/29/2015 01:50 AM, Henrik Johansen wrote: > > > On 29 Sep 2015, at 1:48 , Dale Henrichs < > <dale.henrichs(a)gemtalksystems.com>dale.henrichs(a)gemtalksystems.com> wrote: > > The big issue for git and windows (in general) is that there is a 255 > character limit on the paths for files .... I recently pruned some file > names for Metacello (on a win-hack branch) just to get Metacello to work > with filetree .. > > Working with Github Desktop[1] for Windows makes the experience of using > git from the command line tolerable on Windows - you get a retty nice bash > shell to work with so as a non-windows user I can work in a pretty familiar > environment ... > > At the moment I'm working with Pharo3.0 on Windows, so I don't have any > useful feedback right now (assuming things have changed a bit on Windows > with Pharo4.0 and Pharo5.0) ... > > Dale > > > IIRC, there is some flag you can set to make (some?) the actual git client > (but not bundled tools) support long filenames on Windows: > git config core.longpaths true > For instance, cloning the PharoVM repo choked (or rather, failed > semi-silently) on some really long selector in an obscure plugin somewhere > until I found that... > > > Thanks Henry, I have done the `git config core.longpaths true` and I > believe that that (supposedly) addresses manipulating long file paths > problem for git, it does not help an application like pharo read the files > with long paths ... without additional work ... and even then it's not > clear that it truly fixes the problem ... because the fundamental limit is > embedded in the OS ... for example from the git bash shell, I cannot `rm` > the directories that have long paths (I have to use the explorer to delete > them) and when I write out a package with long paths from Pharo3.0 the long > path files are silently deleted ... > > If it worked for you, that's good ... my experience was not quite as nice:) > > Dale >

Sept. 30, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Dale Henrichs

On 09/29/2015 01:50 AM, Henrik Johansen wrote: > >> On 29 Sep 2015, at 1:48 , Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> The big issue for git and windows (in general) is that there is a 255 >> character limit on the paths for files .... I recently pruned some >> file names for Metacello (on a win-hack branch) just to get Metacello >> to work with filetree .. >> >> Working with Github Desktop[1] for Windows makes the experience of >> using git from the command line tolerable on Windows - you get a >> retty nice bash shell to work with so as a non-windows user I can >> work in a pretty familiar environment ... >> >> At the moment I'm working with Pharo3.0 on Windows, so I don't have >> any useful feedback right now (assuming things have changed a bit on >> Windows with Pharo4.0 and Pharo5.0) ... >> >> Dale > > IIRC, there is some flag you can set to make (some?) the actual git > client (but not bundled tools) support long filenames on Windows: > git config core.longpaths true > For instance, cloning the PharoVM repo choked (or rather, failed > semi-silently) on some really long selector in an obscure plugin > somewhere until I found that... > Thanks Henry, I have done the `git config core.longpaths true` and I believe that that (supposedly) addresses manipulating long file paths problem for git, it does not help an application like pharo read the files with long paths ... without additional work ... and even then it's not clear that it truly fixes the problem ... because the fundamental limit is embedded in the OS ... for example from the git bash shell, I cannot `rm` the directories that have long paths (I have to use the explorer to delete them) and when I write out a package with long paths from Pharo3.0 the long path files are silently deleted ... If it worked for you, that's good ... my experience was not quite as nice:) Dale

Sept. 30, 2015

Re: [Pharo-dev] [Reflectivity] Links on Slots

by Marcus Denker

> On 30 Sep 2015, at 17:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I think this should be Ok for most inspector cases because we rarely open the object in the middle of a method and expect it to be updated within that same method. Or did I get it wrong? > if you want to do change tracking by interception all writes, than any update in a loop (that accesses the ivar directly) that is active already before the inspector is opened would be not seen. I do not think this happens often. Possible solutions: - detect this case âthere is method on the stack accessing this ivar â> do slow update, or display a warning that automatic update might not work) - Implement on-stack replacement for e.g. just #before linksâ¦ - use another mechanism to detect state change Marcus

Sept. 30, 2015

Re: [Pharo-dev] Navigate from Variables to AST Node accessing that variable

by Marcus Denker

> On 30 Sep 2015, at 17:48, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Great! This is so cool. > > We should just change the gtDisplayOn: for RBGlobalNode to show something like: > BehaviorTest>>testallSuperclassesIncluding -> Object > > What do you think? Not sureâ¦ being in a method is not really that of an important property of a variable node that I would print it. Marcus

Sept. 30, 2015

Re: [Pharo-dev] Navigate from Variables to AST Node accessing that variable

by Tudor Girba

Great! This is so cool. We should just change the gtDisplayOn: for RBGlobalNode to show something like: BehaviorTest>>testallSuperclassesIncluding -> Object What do you think? Doru On Wed, Sep 30, 2015 at 2:28 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > > https://pharo.fogbugz.com/f/cases/16674/Navigate-from-Variables-to-AST-Node… > > The Slice adds the method #astNodes to LiteralVariable, Slot and > TemporaryVariable. > > e.g. inspect > > Object binding astNodes > > With the magic of GTInspector, this is a browser that show the source for > that AST node nicely highlighted: > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2015

Re: [Pharo-dev] [Reflectivity] Links on Slots

by Tudor Girba

Hi, I think this should be Ok for most inspector cases because we rarely open the object in the middle of a method and expect it to be updated within that same method. Or did I get it wrong? Cheers, Doru On Wed, Sep 30, 2015 at 5:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 30 Sep 2015, at 17:23, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Yuppee! This means that we can now implement an inspector refresh > properly, right? > > > The only problem is that the change is only active for new method > invocationsâ¦ so there might be > cases where it would not update if the change is done in a loop, for > example, and active on the stack > alreadyâ¦ > > Cheers, > Doru > > > On Wed, Sep 30, 2015 at 11:49 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> basis for annotating instanceVariables (Slots) with meta links is now >> working. >> https://pharo.fogbugz.com/f/cases/16669/MetaLinks-on-Slots >> >> This test is green: >> >> testReifySlotName >> | iVar instance link | >> iVar := ReflectivityExamples slotNamed: #ivar. >> >> link := MetaLink new >> metaObject: self; >> selector: #tagExec:; >> arguments: #(name). >> >> iVar link: link. >> self assert: iVar hasMetalink. >> self assert: (ReflectivityExamples >> #exampleIvarRead) class = >> ReflectiveMethod. >> self assert: (tag isNil). >> instance := ReflectivityExamples new. >> self assert: (instance exampleIvarRead = 33). >> self assert: (tag = #ivar). >> link uninstall. >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2015