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

Re: [Pharo-dev] Beacon moved to github

by Tim Mackinnon

Should/could iceberg default to this convention when you create a repo (and you modify it if you want different?). It would help us get consistency as when you start out you just don't know Tim Sent from my iPhone > On 8 Jul 2017, at 11:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 8 Jul 2017, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Peter - I just hit this yesterday with your kind help deciphering SmalltalkCI, and I have to confess that "src" was my inclination over repository for the reason you mention in that it is a repository already. >> >> I noticed other STCi projects have used "packages" . >> >> I would vote for "src" so other newcomers more easily understand what it is compared to where they came from. > > yes, I agreeâ¦ even if at first is me the one who used mc, I think âsrcâis better convention, now (thatâs why pharo is using it :P) > > Esteban > >> >> I also think it would be helpful for iceberg to default to using that so we get some consistency? >> >> Tim >> >> Sent from my iPhone >> >>>> On 7 Jul 2017, at 17:03, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>> On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: >>>> Hi. >>>> >>>> I though it was already done :) >>>> One notice. Should we all follow standard convention on repo structure? >>>> Because source directory in beacon is called "repository" instead "src" >>>> like in other repos. >>> >>> There is no standard convention for Pharo repos on github. >>> >>> In pharo-project I see >>> >>> * repository 3x >>> * mc 3x >>> * src 1x (not smalltalk code) >>> >>> And the rest of the github uses a variety of options >>> >>> * nothing >>> - imho disorganized and very messy if you have several packages >>> * repository >>> - I've been using it and recommending it for ~2 years; also used by filetree and metacello repos ;) >>> - Argument could be made that git is already a repository so it could be confusing >>> * mc >>> - because MontiCello/MetaCello I guess? I don't know how much this makes sense in the light of Iceberg >>> * src >>> - quite common in other programming languages >>> * packages >>> - well, the folder does contain just packages >>> >>> Someone could mine github to find precise numbers... but current usage shouldn't be a deciding factor. >>> >>> Peter >>> >>>> >>>> 2017-07-07 16:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >>>> >>>>> I used the git migration tool of Peter Uhnak to migrate Beacon from >>>>> smalltalkhub to github. It is available now here >>>>> >>>>> https://github.com/pharo-project/pharo-beacon >>>>> >>>>> I just need to know how I can switch a smalltalkhub project to read-only. >>>>> >>>>> FYI, >>>>> >>>>> Norbert >>>>> >>>>> >>> >> >> > >

July 9, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Tim Mackinnon

I've just realised an important difference which maybe accentuates this thread - my image is actually a v7 vm with a Pharo 6 image and the iceberg update instructions that Esteban sent around. Is it possible the working dir changes are in that new vm? If so, the problem I'm getting might be exactly what you were calling out Alasdair? Tim Sent from my iPhone > On 9 Jul 2017, at 08:55, Tim Mackinnon <tim(a)testit.works> wrote: > > Guys - I donât know if this is useful input, but Iâve just noticed a weird issue with the default directory in a new Pharo6 image (probably related to this thread). > > Iâm trying to write my first baselineOf: metacello method - and have been confused that when testing it out, I get a walkback where the directory referenced is not my image. e.g. this the the error message: > > Could not resolve: ConfigurationOfNeoJSON [ConfigurationOfNeoJSON] in /Users/name/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache > > However that Pharo-6-60495 is an earlier image before the release of pharo but its not the image I am using - which is a clean 6.0 image. > > It looks like the implementation of MCCacheRepository class>>uniqueInstance (self defaultDirectory) is returning some random directory - possibly related to the discussion here? > > When I inspect âself defaultDirectoryâ - it correctly shows: File @ pharo-local/package-cache (the relative portion) - however the default in the MCCache is as above which is wrong. > > Is there some error lurking in the new Pharo 6 images? > > Tim > >> On 3 Jul 2017, at 15:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Rajula, >> >>> On Thu, Jun 29, 2017 at 05:42:02AM -0700, Rajula Vineet wrote: >>> Hi all, >>> >>> As I have already been posting about my GSoC work and updates on my blog >>> <https://vineetreddy.wordpress.com> and on the mailing list >>> <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> >>> . In this post, I would like to go in depth of my work on 'the working >>> directory' so that I can get valuable feedback and suggestions from >>> everyone. This discussion was started on an github PR >>> <https://github.com/pharo-project/pharo/pull/96> which was conflicting my >>> PR. >> >> >> It looks like my concerns were unfounded, but many thanks for taking the >> trouble to follow up on this. >> >> It would good if you could keep a similar caching strategy to the one I >> introduced as the performance gains can be significant (as suggested by >> Cyril's comment). >> >> Thanks again, >> Alistair >> >> >> >>> Firstly, I would like to go through the current implementation of the >>> working directory. With this implementation, when you use the >>> defaultWorkingDirectory method, the directory in which the running image is >>> present in, is returned. This is not a completely good working because when >>> you run the image from a different directory like './pharo ../Pharo.image' >>> the working directory is the one in which your image resides. But that isn`t >>> your actual working directory. Due to this, >>> >>> 1. Pharo cannot be installed as a normal application in a read-only >>> environment. >>> 2. Pharo wrongly reads and writes files relative to the 'working directory'. >>> 3. It also makes scripting difficult. >>> >>> In the FogBugz issue here >>> <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there >>> is an example which explains the problem. >>> >>> Let say the Pharo VM and Image are in the directory "~/Pharo", >>> and I wrote a script in "~/Documents/Pharo-scripts" called >>> "perfect-numbers.st" >>> >>> I have 2 possibilities: >>> >>> cd ~/Pharo && pharo Pharo.image st >>> ~/Documents/Pharo-scripts/perfect-numbers.st // works >>> >>> or >>> >>> cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st >>> perfect-numbers.st // doesn't work... >>> >>> It doesn't work because when pharo wants to load the file, >>> it tries to locate it with: FileSystem disk workingDirectory !!! >>> which is NOT the current working directory." >>> >>> I hope you get the problem. >>> >>> So for the new implementation <https://github.com/rajula96reddy/pharo-cli> >>> with the help of Guille I researched about $PWD and getcwd() for a while and >>> wrote a new implementation. This is how it goes >>> 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and >>> 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI >>> 2. And a new method currentWorkingDirectoryPath and >>> currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the >>> above method and gets the working directory. >>> 3. To integrate this, I have patched the DiskStore method >>> 'defaultWorkingDirectory' to use the new methods in OSPlatform. >>> >>> I have checked all the sendors of the 'defaultWorkingDirectory' for any >>> issue. And I also wrote some unit tests. So, the new implementation is >>> working fine. With this, now I am able to get the right working directory. >>> The example mentioned above works perfectly. >>> >>> But, there may be a few cases where it can break interoperability between >>> Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' >>> directory and its methods should also be patched subsequently. In fact, >>> these problems can be tackled by running image from its own directory itself >>> (which is obvious ;) ) or by using the method imageDirectory in FileLocator >>> class explicitly when necessary. But overall a good thing is this is will >>> ensure the system will behave as in other languages. >>> >>> I have completed this implementation and submitted a PR >>> <https://github.com/pharo-project/pharo/pull/92> to github. But because of >>> some dependency issue, it has not yet been merged. With the help of my >>> mentor, I am working on the problem. >>> >>> Thanks for reading all this. Please give your feedback and comments on this >>> new implementation. Your suggestions help me in learning more about the >>> project and also about the organization. >>> >>> Thanks, >>> Rajula >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >

July 9, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Tim Mackinnon

Guys - I donât know if this is useful input, but Iâve just noticed a weird issue with the default directory in a new Pharo6 image (probably related to this thread). Iâm trying to write my first baselineOf: metacello method - and have been confused that when testing it out, I get a walkback where the directory referenced is not my image. e.g. this the the error message: Could not resolve: ConfigurationOfNeoJSON [ConfigurationOfNeoJSON] in /Users/name/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache However that Pharo-6-60495 is an earlier image before the release of pharo but its not the image I am using - which is a clean 6.0 image. It looks like the implementation of MCCacheRepository class>>uniqueInstance (self defaultDirectory) is returning some random directory - possibly related to the discussion here? When I inspect âself defaultDirectoryâ - it correctly shows: File @ pharo-local/package-cache (the relative portion) - however the default in the MCCache is as above which is wrong. Is there some error lurking in the new Pharo 6 images? Tim > On 3 Jul 2017, at 15:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Rajula, > > On Thu, Jun 29, 2017 at 05:42:02AM -0700, Rajula Vineet wrote: >> Hi all, >> >> As I have already been posting about my GSoC work and updates on my blog >> <https://vineetreddy.wordpress.com> and on the mailing list >> <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> >> . In this post, I would like to go in depth of my work on 'the working >> directory' so that I can get valuable feedback and suggestions from >> everyone. This discussion was started on an github PR >> <https://github.com/pharo-project/pharo/pull/96> which was conflicting my >> PR. > > > It looks like my concerns were unfounded, but many thanks for taking the > trouble to follow up on this. > > It would good if you could keep a similar caching strategy to the one I > introduced as the performance gains can be significant (as suggested by > Cyril's comment). > > Thanks again, > Alistair > > > >> Firstly, I would like to go through the current implementation of the >> working directory. With this implementation, when you use the >> defaultWorkingDirectory method, the directory in which the running image is >> present in, is returned. This is not a completely good working because when >> you run the image from a different directory like './pharo ../Pharo.image' >> the working directory is the one in which your image resides. But that isn`t >> your actual working directory. Due to this, >> >> 1. Pharo cannot be installed as a normal application in a read-only >> environment. >> 2. Pharo wrongly reads and writes files relative to the 'working directory'. >> 3. It also makes scripting difficult. >> >> In the FogBugz issue here >> <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there >> is an example which explains the problem. >> >> Let say the Pharo VM and Image are in the directory "~/Pharo", >> and I wrote a script in "~/Documents/Pharo-scripts" called >> "perfect-numbers.st" >> >> I have 2 possibilities: >> >> cd ~/Pharo && pharo Pharo.image st >> ~/Documents/Pharo-scripts/perfect-numbers.st // works >> >> or >> >> cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st >> perfect-numbers.st // doesn't work... >> >> It doesn't work because when pharo wants to load the file, >> it tries to locate it with: FileSystem disk workingDirectory !!! >> which is NOT the current working directory." >> >> I hope you get the problem. >> >> So for the new implementation <https://github.com/rajula96reddy/pharo-cli> >> with the help of Guille I researched about $PWD and getcwd() for a while and >> wrote a new implementation. This is how it goes >> 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and >> 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI >> 2. And a new method currentWorkingDirectoryPath and >> currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the >> above method and gets the working directory. >> 3. To integrate this, I have patched the DiskStore method >> 'defaultWorkingDirectory' to use the new methods in OSPlatform. >> >> I have checked all the sendors of the 'defaultWorkingDirectory' for any >> issue. And I also wrote some unit tests. So, the new implementation is >> working fine. With this, now I am able to get the right working directory. >> The example mentioned above works perfectly. >> >> But, there may be a few cases where it can break interoperability between >> Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' >> directory and its methods should also be patched subsequently. In fact, >> these problems can be tackled by running image from its own directory itself >> (which is obvious ;) ) or by using the method imageDirectory in FileLocator >> class explicitly when necessary. But overall a good thing is this is will >> ensure the system will behave as in other languages. >> >> I have completed this implementation and submitted a PR >> <https://github.com/pharo-project/pharo/pull/92> to github. But because of >> some dependency issue, it has not yet been merged. With the help of my >> mentor, I am working on the problem. >> >> Thanks for reading all this. Please give your feedback and comments on this >> new implementation. Your suggestions help me in learning more about the >> project and also about the organization. >> >> Thanks, >> Rajula >> >> >> >> -- >> View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

July 9, 2017

Re: [Pharo-dev] how to issue a PR that changes package structure?

by Pavel Krivanek

Yes, any change in the packages structure needs to be integrated together with the corresponding changes in baselines. BaselineOfIDE has groups so they need to be changed as well. -- Pavel 2017-07-08 20:15 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi guys > > I would like to split or/and create packages. > Should I update the Pharo baseline. > > Stef > >

July 9, 2017

Re: [Pharo-dev] how to issue a PR that changes package structure?

by Cyril Ferlicot D.

Le 08/07/2017 Ã 20:15, Stephane Ducasse a Ã©crit : > Hi guys > > I would like to split or/and create packages. > Should I update the Pharo baseline. > > Stef > I saw Pavel doing PR to remove packages by removing them from the baselines. Example: https://github.com/pharo-project/pharo/commit/c3ac94585f50e56f574249c1b5113… -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 9, 2017

Re: [Pharo-dev] wrong file on the download

by Cyril Ferlicot D.

Le 08/07/2017 Ã 20:21, Stephane Ducasse a Ã©crit : > http://pharo.org/web/download > > Pharo 7.0 image & changes > > latest.... donwloads a Pharo 60 image > This is maybe like that because the Pharo 7 images are not uploaded at files.pharo.org for now. So the latest image is the latest Pharo 6 one. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 9, 2017

Re: [Pharo-dev] latest 70 and vm

by Pavel Krivanek

the VM for Pharo 7 is available by zero-conf scripts ( http://get.pharo.org/vm70) or from files.pharo.org ( http://files.pharo.org/get-files/70/) We are currently not uploading Pharo 7 images to files.pharo.org. They can can be found here (32-bits): https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ -- Pavel 2017-07-08 21:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > I realized that I forgot where I could find the latest 70 and vm. > So I could not update the web site > > Stef > >

July 8, 2017

latest 70 and vm

by Stephane Ducasse

Hi I realized that I forgot where I could find the latest 70 and vm. So I could not update the web site Stef

July 8, 2017

Re: [Pharo-dev] Beacon moved to github

by Norbert Hartl

You are right and I like this the most. Will change any repo I see ð Norbert > Am 08.07.2017 um 14:54 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > We're using source, because you know in Smalltalk we don't like to invent abbreviations ;) > >> On Jul 8, 2017 07:18, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >> >> > On 8 Jul 2017, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > Hi Peter - I just hit this yesterday with your kind help deciphering SmalltalkCI, and I have to confess that "src" was my inclination over repository for the reason you mention in that it is a repository already. >> > >> > I noticed other STCi projects have used "packages" . >> > >> > I would vote for "src" so other newcomers more easily understand what it is compared to where they came from. >> >> yes, I agreeâ¦ even if at first is me the one who used mc, I think âsrcâis better convention, now (thatâs why pharo is using it :P) >> >> Esteban >> >> > >> > I also think it would be helpful for iceberg to default to using that so we get some consistency? >> > >> > Tim >> > >> > Sent from my iPhone >> > >> >> On 7 Jul 2017, at 17:03, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> >> >>> On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: >> >>> Hi. >> >>> >> >>> I though it was already done :) >> >>> One notice. Should we all follow standard convention on repo structure? >> >>> Because source directory in beacon is called "repository" instead "src" >> >>> like in other repos. >> >> >> >> There is no standard convention for Pharo repos on github. >> >> >> >> In pharo-project I see >> >> >> >> * repository 3x >> >> * mc 3x >> >> * src 1x (not smalltalk code) >> >> >> >> And the rest of the github uses a variety of options >> >> >> >> * nothing >> >> - imho disorganized and very messy if you have several packages >> >> * repository >> >> - I've been using it and recommending it for ~2 years; also used by filetree and metacello repos ;) >> >> - Argument could be made that git is already a repository so it could be confusing >> >> * mc >> >> - because MontiCello/MetaCello I guess? I don't know how much this makes sense in the light of Iceberg >> >> * src >> >> - quite common in other programming languages >> >> * packages >> >> - well, the folder does contain just packages >> >> >> >> Someone could mine github to find precise numbers... but current usage shouldn't be a deciding factor. >> >> >> >> Peter >> >> >> >>> >> >>> 2017-07-07 16:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> >> >>>> I used the git migration tool of Peter Uhnak to migrate Beacon from >> >>>> smalltalkhub to github. It is available now here >> >>>> >> >>>> https://github.com/pharo-project/pharo-beacon >> >>>> >> >>>> I just need to know how I can switch a smalltalkhub project to read-only. >> >>>> >> >>>> FYI, >> >>>> >> >>>> Norbert >> >>>> >> >>>> >> >> >> > >> > >> >>

July 8, 2017

wrong file on the download

by Stephane Ducasse

http://pharo.org/web/download Pharo 7.0 image & changes latest.... donwloads a Pharo 60 image

July 8, 2017