- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZeroConf for Pi VM

by Sven Van Caekenberghe

+10 this would be very nice to have ! Last time I played with Pharo on the RPi I took the VM from http://files.pharo.org/vm/pharoS/raspbian/latest.zip which worked fine for 4.0 > On 01 Oct 2015, at 00:51, Torsten Bergmann <astares(a)gmx.de> wrote: > > 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. >

Oct. 1, 2015

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

by Jan Vrany

On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs 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 .. The limit is actually 260 characters. Not that it helps much :-) However, there's a way (well, hack) to overcome this limit using special UNC pathnames like \\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path. The "only" issue is that not all tools in the chain are using this hack... Jan

Oct. 1, 2015

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

by Dale Henrichs

1. the original code from Otto put each method in a file 2. I liked the idea of using git to manage method versions - and it is a really cool feature as git is able to maintain the history of a method (file) as the method is moved from class to class 3. Using directory structure actually enhanced the ability to create a cross-platform scheme, since directory structure parsing is easier than coming to an agreement on a common "fileout" format With that said, assuming that a common fileout format can be agreed upon ... there's no reason that a file per package or file per class format could be invented ... If you or anyone else has the time to create such a beast then I say go for it ... Given that we have a functional disk representation in hand, I don't think that searching for a new format (that will have it's own flaws) is a top priority ... regardless of what the disk format looks like there is a real void when it comes to the tool set .... Finally the smalltalk community is not the only group that has trouble using git on windows because of the file path limitation ... so these guys that do file per package still run into trouble when using git on windows:) Dale On 9/30/15 11:57 AM, Alexandre Bergel wrote: > 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 > <mailto:dale.henrichs@gemtalksystems.com>> a Ã©crit :

Oct. 1, 2015

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