March 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by ducasse

I was in rush when I wrote the first answer >> I thought xml support is already migrated by Sven? >> >> https://github.com/svenvc/XML-Support-Pharo <https://github.com/svenvc/XML-Support-Pharo> >> >> Or do I mix something up here? >> Sven did not migrate the history >> ------------- >> Something else: >> In case someone wants to use it: I used Peters nice migration tool for ... >> http://smalltalkhub.com/#!/~PharoExtras/LDAP/ <http://smalltalkhub.com/#!/~PharoExtras/LDAP/> >> ... and put it to: >> https://github.com/a2b-alb/PharoExtras-LDAP <https://github.com/a2b-alb/PharoExtras-LDAP> >> I don't know if this is the right place or if you would rather have it under ... >> https://github.com/pharo-contributions/ <https://github.com/pharo-contributions/> >> ... or somewhere else. >> > Thanks > and it would be good. I do not know what is the best process to add something to pharo-contributions. May be we should fork your version and put it there and that people continue to contribute using PRs. What do you think? >> ------------- >> I started trying to do the same migration process for ... >> http://www.smalltalkhub.com/#!/~Pier/Pier3 <http://www.smalltalkhub.com/#!/~Pier/Pier3> >> ... but I failed on errors loading older mcz files: >> >> "instance of ByteString did not understand #peek" >> on: MCMczReader >> contentsForMember: >> (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) >> >> Is this wrong encoding or corrupted files >> >> How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() >> ok ? >> > I wonder if the MCMCZ was not about the delta between two commits but may be Iâm wrong. > BTW this is great to see someone pushing pier. > I would like to see how a new version of pillar can be pushed back into pier. > >> >> ------------- >> As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harnmony" with the other ones... ;-) >> -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didnât. >> > > Seriously for Pier I would first focus on making it work with the latest version and we can always say that the historuy > is in another repo. >> >> I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... >> onConflict: [ :e | e useLoaded ]; >> ... when loading pier3 from smaltalkhub. >> >> Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? >> -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? >> > Use the configuration because I have no clue. > Esteban was extending pier in the past.

March 8, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by ducasse

> On 8 Mar 2019, at 11:08, Albrecht Baur <baur.albrecht(a)googlemail.com> wrote: > > > From: Albrecht Baur <baur.albrecht(a)googlemail.com> > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > Date: 8 March 2019 at 11:08:44 CET > To: pharo-dev(a)lists.pharo.org > > > I thought xml support is already migrated by Sven? > > https://github.com/svenvc/XML-Support-Pharo <https://github.com/svenvc/XML-Support-Pharo> > > Or do I mix something up here? > > ------------- > Something else: > In case someone wants to use it: I used Peters nice migration tool for ... > http://smalltalkhub.com/#!/~PharoExtras/LDAP/ <http://smalltalkhub.com/#!/~PharoExtras/LDAP/> > ... and put it to: > https://github.com/a2b-alb/PharoExtras-LDAP <https://github.com/a2b-alb/PharoExtras-LDAP> > I don't know if this is the right place or if you would rather have it under ... > https://github.com/pharo-contributions/ <https://github.com/pharo-contributions/> > ... or somewhere else. > Thanks and it would be good. > > ------------- > I started trying to do the same migration process for ... > http://www.smalltalkhub.com/#!/~Pier/Pier3 <http://www.smalltalkhub.com/#!/~Pier/Pier3> > ... but I failed on errors loading older mcz files: > > "instance of ByteString did not understand #peek" > on: MCMczReader >> contentsForMember: > (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > Is this wrong encoding or corrupted files > > How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() > ok ? > I wonder if the MCMCZ was not about the delta between two commits but may be Iâm wrong. BTW this is great to see someone pushing pier. I would like to see how a new version of pillar can be pushed back into pier. > > ------------- > As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harnmony" with the other ones... ;-) > -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didnât. > Seriously for Pier I would first focus on making it work with the latest version and we can always say that the historuy is in another repo. > > I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... > onConflict: [ :e | e useLoaded ]; > ... when loading pier3 from smaltalkhub. > > Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? > -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? > Use the configuration because I have no clue. Esteban was extending pier in the past. > > best, > Albrecht > On 08.03.19 08:10, Peter Uhnak wrote: >> > It has the full history - but no reference to your username (because I guess Peter did not know your github name/mail address). >> >> That's not the case, maybe you are confused by the latest handful of commits that I made directly. >> The rest is migrated with monty's mail; you can see "monty authored and peteruhnak committed", or look at the patch of any commit https://github.com/pharo-contributions/OrderPreservingDictionary/commit/e41… <https://github.com/pharo-contributions/OrderPreservingDictionary/commit/e41…> >> >> Associating the mail with a github account should be enough. >> >> Peter >> >> On Thu, Mar 7, 2019 at 11:06 PM Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: >> Stef wrote: >> > > Note that Peter seem to have converted already one of the projects the XMLParser is dependent on: "OrderPreservingDictionary" >> > > which lives at: https://github.com/pharo-contributions/OrderPreservingDictionary <https://github.com/pharo-contributions/OrderPreservingDictionary> >> > > It has the full history - but no reference to your username (because I guess Peter did not know your github name/mail address). >> > >> > Ah cool I was about to do it. >> >> From the history I guess Peter did it. >> >> But we should redo it once we know Monty's github user account name to have him linked in the >> history of commits and honour his authorship. >> >> @Monty: can you tell us your github account user name/ github home? >> >> Thx >> T. > >

March 8, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Albrecht Baur

I thought xml support is already migrated by Sven? https://github.com/svenvc/XML-Support-Pharo Or do I mix something up here? ------------- Something else: In case someone wants to use it: I used Peters nice migration tool for ... http://smalltalkhub.com/#!/~PharoExtras/LDAP/ ... and put it to: https://github.com/a2b-alb/PharoExtras-LDAP I don't know if this is the right place or if you would rather have it under ... https://github.com/pharo-contributions/ ... or somewhere else. ------------- I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) Is this wrong encoding or corrupted files ? How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() ok ? ------------- As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harnmony" with the other ones...Â ;-) -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didn't. I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... onConflict: [ :e | e useLoaded ]; ... when loading pier3 from smaltalkhub. Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? best, Albrecht On 08.03.19 08:10, Peter Uhnak wrote: > >Â It has the full history - but no reference to your username > (because I guess Peter did not know your github name/mail address). > > That's not the case, maybe you are confused by the latest handful of > commits that I made directly. > The rest is migrated with monty's mail; you can see "monty authored > and peteruhnak committed", or look at the patch of any commit > https://github.com/pharo-contributions/OrderPreservingDictionary/commit/e41… > > Associating the mail with a github account should be enough. > > Peter > > On Thu, Mar 7, 2019 at 11:06 PM Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Stef wrote: > > > Note that Peter seem to have converted already one of the > projects the XMLParser is dependent on: "OrderPreservingDictionary" > > > which lives at: > https://github.com/pharo-contributions/OrderPreservingDictionary > > > It has the full history - but no reference to your username > (because I guess Peter did not know your github name/mail address). > > > > Ah cool I was about to do it. > > From the history I guess Peter did it. > > But we should redo it once we know Monty's github user account > name to have him linked in the > history of commits and honour his authorship. > > @Monty: can you tell us your github account user name/ github home? > > Thx > T. >

March 8, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Albrecht Baur

I thought xml support is already migrated by Sven? https://github.com/svenvc/XML-Support-Pharo Or do I mix something up here? ------------ Something else: In case someone wants to use it: I used Peters nice migration tool for ... http://smalltalkhub.com/#!/~PharoExtras/LDAP/ ... and put it to: https://github.com/a2b-alb/PharoExtras-LDAP I don't know if this is the right place or if you would rather have it under ... https://github.com/pharo-contributions/ ... or somewhere else. ------------ I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) Is this wrong encoding or corrupted files ? How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() ok ? ------------ As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harnmony" with the other ones...Â ;-) -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didn't. I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... onConflict: [ :e | e useLoaded ]; ... when loading pier3 from smaltalkhub. Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? best, Albrecht On 08.03.19 08:10, Peter Uhnak wrote: > >Â It has the full history - but no reference to your username > (because I guess Peter did not know your github name/mail address). > > That's not the case, maybe you are confused by the latest handful of > commits that I made directly. > The rest is migrated with monty's mail; you can see "monty authored > and peteruhnak committed", or look at the patch of any commit > https://github.com/pharo-contributions/OrderPreservingDictionary/commit/e41… > > Associating the mail with a github account should be enough. > > Peter > > On Thu, Mar 7, 2019 at 11:06 PM Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Stef wrote: > > > Note that Peter seem to have converted already one of the > projects the XMLParser is dependent on: "OrderPreservingDictionary" > > > which lives at: > https://github.com/pharo-contributions/OrderPreservingDictionary > > > It has the full history - but no reference to your username > (because I guess Peter did not know your github name/mail address). > > > > Ah cool I was about to do it. > > From the history I guess Peter did it. > > But we should redo it once we know Monty's github user account > name to have him linked in the > history of commits and honour his authorship. > > @Monty: can you tell us your github account user name/ github home? > > Thx > T. >

March 8, 2019

Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open

by Max Leske

On 8 Mar 2019, at 8:33, Alistair Grant wrote: > Hi Max, > > On Fri, 8 Mar 2019 at 08:21, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi, >> >> OSPlatform>>currentWorkingDirectoryPath (used by >> Path>>workingDirectory, >> used by Metacello to resolve local paths) always answers '/' for me >> when >> I drag the image onto the VM to open. I'm sure that's a "feature" of >> macOS but it's very annoying. >> In addition, FileLocator imageDirectory answers the correct >> workingDirectory because it uses a primitive instead of the FFI call >> to >> getCwd(). >> >> Is this a known issue? Should I open a new one? > > This is known behaviour. #imageDirectory and #workingDirectory are > distinct concepts. #imageDirectory, obviously, is the location where > the image resides, while #workingDirectory is the current working > directory for the process. > > It's unfortunate that MacOS sets cwd to "/" when starting applications > through the GUI. It sounds like you are already aware of this, but > just to be clear: if you start Pharo from a shell you should see > #workingDirectory return the same value as `pwd` in the shell. > > I'm not a Mac user, so I don't know what other applications typically > do, but maybe wrap the startup in a script that changes to something > more sensible (in your case above it sounds like changing to the > directory where the image is located). But modifying > #workingDirectory to answer the image directory isn't a good idea as > it breaks lots of other use cases. > > Cheers, > Alistair Thanks Alistair. I suspected as much. In my case the solution will be to compose the path to the repository in the baseline by hand before passing it to Metacello (e.g. `repository: 'filetree:', (FileLocator imageDirectory) pathString, '...'`. Cheers, Max

March 8, 2019

Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open

by Alistair Grant

Hi Max, On Fri, 8 Mar 2019 at 08:21, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, > used by Metacello to resolve local paths) always answers '/' for me when > I drag the image onto the VM to open. I'm sure that's a "feature" of > macOS but it's very annoying. > In addition, FileLocator imageDirectory answers the correct > workingDirectory because it uses a primitive instead of the FFI call to > getCwd(). > > Is this a known issue? Should I open a new one? This is known behaviour. #imageDirectory and #workingDirectory are distinct concepts. #imageDirectory, obviously, is the location where the image resides, while #workingDirectory is the current working directory for the process. It's unfortunate that MacOS sets cwd to "/" when starting applications through the GUI. It sounds like you are already aware of this, but just to be clear: if you start Pharo from a shell you should see #workingDirectory return the same value as `pwd` in the shell. I'm not a Mac user, so I don't know what other applications typically do, but maybe wrap the startup in a script that changes to something more sensible (in your case above it sounds like changing to the directory where the image is located). But modifying #workingDirectory to answer the image directory isn't a good idea as it breaks lots of other use cases. Cheers, Alistair

March 8, 2019

#currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open

by Max Leske

Hi, OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, used by Metacello to resolve local paths) always answers '/' for me when I drag the image onto the VM to open. I'm sure that's a "feature" of macOS but it's very annoying. In addition, FileLocator imageDirectory answers the correct workingDirectory because it uses a primitive instead of the FFI call to getCwd(). Is this a known issue? Should I open a new one? Max

March 8, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Peter Uhnak

> It has the full history - but no reference to your username (because I guess Peter did not know your github name/mail address). That's not the case, maybe you are confused by the latest handful of commits that I made directly. The rest is migrated with monty's mail; you can see "monty authored and peteruhnak committed", or look at the patch of any commit https://github.com/pharo-contributions/OrderPreservingDictionary/commit/e41… Associating the mail with a github account should be enough. Peter On Thu, Mar 7, 2019 at 11:06 PM Torsten Bergmann <astares(a)gmx.de> wrote: > Stef wrote: > > > Note that Peter seem to have converted already one of the projects the > XMLParser is dependent on: "OrderPreservingDictionary" > > > which lives at: > https://github.com/pharo-contributions/OrderPreservingDictionary > > > It has the full history - but no reference to your username (because I > guess Peter did not know your github name/mail address). > > > > Ah cool I was about to do it. > > From the history I guess Peter did it. > > But we should redo it once we know Monty's github user account name to > have him linked in the > history of commits and honour his authorship. > > @Monty: can you tell us your github account user name/ github home? > > Thx > T. >

March 8, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Torsten Bergmann

Stef wrote: > > Note that Peter seem to have converted already one of the projects the XMLParser is dependent on: "OrderPreservingDictionary" > > which lives at: https://github.com/pharo-contributions/OrderPreservingDictionary > > It has the full history - but no reference to your username (because I guess Peter did not know your github name/mail address). > > Ah cool I was about to do it. >From the history I guess Peter did it. But we should redo it once we know Monty's github user account name to have him linked in the history of commits and honour his authorship. @Monty: can you tell us your github account user name/ github home? Thx T.

March 7, 2019

[Pharo 8.0] Build #121: 2708-Deprecate-subscribesendto

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #121 was: FAILURE. The Pull Request #2711 was integrated: "2708-Deprecate-subscribesendto" Pull request url: https://github.com/pharo-project/pharo/pull/2711 Issue Url: https://pharo.fogbugz.com/f/cases/2708 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 7, 2019