April 2018 - Pharo-dev - lists.pharo.org

Exception in Iceberg when removing selectors from anonymous classes

by Steven Costiou

Hi, i downloaded yesterday the latest Pharo 7 and in a playground if you do: class := Object newAnonymousSubclass. (OK) class package. "a RPackage(_UnpackagedPackage)" (OK) class compile: 'test ^nil'. (OK) (class >> #test) package. "nil" (Surprising but no problem with any pharo version since yesterday) class removeSelector: #test. (Exception, see below) An exception is raised in IceSystemEventListener class because the method package is nil: handlePackagesChange: packages IceRepository registry do: [ :repository | | changed | changed := packages anySatisfy: [ :each | repository notifyPackageModified: each name ]. "(EACH IS NIL HERE)" changed ifTrue: [ Iceberg announcer announce: (IceRepositoryModified for: repository) ]] So to fix it, the package needs to be correctly set for each method compiled in an anonymous class, but should anonymous subclasses really raise events when adding/modifying/removing methods? Steven.

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Stephan Eggermont

Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > And please support the use of baselines. Nobody wants to also mantain a > ConfigurationOf just for the catalog when using baselines. That sounds like a non-problem. One file that never needs to change. Letâs solve the problems first Stephan

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Esteban Lorenzano

> On 19 Apr 2018, at 11:25, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > And please support the use of baselines. Nobody wants to also mantain a ConfigurationOf just for the catalog when using baselines. thatâs IMO the most important part we need to cover. Esteban > > On Thu, Apr 19, 2018, 05:58 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > I also think that the catalog is important. If anything is wrong with it we should fix it. > > The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable. > > Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free. > > > On 19 Apr 2018, at 10:38, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > > > Now today you had loading trouble with Smacc from Catalog ... and now directly want to > > kill catalog. Wow! > > > > Sometimes I have the impression that our community tries to reinvent itself each day > > doing it differently (but not only better) instead of extending, improving and supporting > > what we have have done before. Which sometimes is good ... but not always. > > > > Thx > > T. > > > >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> > >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > >> Betreff: [Pharo-dev] Do we kill the catalog? > >> > >> Hi guys > >> > >> What do we do with it? > >> What alternatives? > >> > >> Stef > >> > >> > > > >

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Gabriel Cotelli

And please support the use of baselines. Nobody wants to also mantain a ConfigurationOf just for the catalog when using baselines. On Thu, Apr 19, 2018, 05:58 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I also think that the catalog is important. If anything is wrong with it > we should fix it. > > The problem is that the catalog is never working well with the current > unstable version of Pharo (today 7). Not all package developers take the > trouble of checking/porting all the time, that is perfectly understandable. > > Moving the catalog to GitHub with a STON meta description is a good idea, > of course. All we need is a clean object representing the meta info, the > rest comes for free. > > > On 19 Apr 2018, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Now today you had loading trouble with Smacc from Catalog ... and now > directly want to > > kill catalog. Wow! > > > > Sometimes I have the impression that our community tries to reinvent > itself each day > > doing it differently (but not only better) instead of extending, > improving and supporting > > what we have have done before. Which sometimes is good ... but not > always. > > > > Thx > > T. > > > >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Betreff: [Pharo-dev] Do we kill the catalog? > >> > >> Hi guys > >> > >> What do we do with it? > >> What alternatives? > >> > >> Stef > >> > >> > > > > >

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Thierry Goubier

2018-04-19 10:57 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I also think that the catalog is important. If anything is wrong with it we should fix it. I agree. Issues: - The Catalog doesn't use Metacello, so things loaded via the catalog are not registered properly (upgrades / conflicts) - The Catalog mix multiple Meta repos and you never know, given a configuration in multiple repos, which one the Catalog is giving you. - The Catalog icons are ... non understandable. > The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable. Never tried that one > Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free. Maybe. I would like a automated way of extracting the json from a baseline or configuration... to reduce the friction of using the catalog. Thierry >> On 19 Apr 2018, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Now today you had loading trouble with Smacc from Catalog ... and now directly want to >> kill catalog. Wow! >> >> Sometimes I have the impression that our community tries to reinvent itself each day >> doing it differently (but not only better) instead of extending, improving and supporting >> what we have have done before. Which sometimes is good ... but not always. >> >> Thx >> T. >> >>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr >>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: [Pharo-dev] Do we kill the catalog? >>> >>> Hi guys >>> >>> What do we do with it? >>> What alternatives? >>> >>> Stef >>> >>> >> > >

April 19, 2018

Re: [Pharo-dev] DelayScheduler cleanup & Bootstrap

by Ben Coman

On 19 April 2018 at 15:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Sun, Apr 15, 2018 at 3:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I am doing a pass to cleanup the DelayScheduler hierarchy. >> I'll be refactoring of the hierarchy to aid code understanding >> and eliminate redundant instance variables from the original code. >> The target structure is.... >> DelayNullScheduler -- minimum interface to avoid errors in rest of system >> (6 empty methods) >> |__DelayBasicScheduler -- fully working sans race protection (equivalent >> to Courageous scheduler) >> |__DelaySpinScheduler -- plus race protection >> >> Can someone advise how/where the Bootstrap loads Delay and the >> DelaySchedulers? >> > > Delay and Delay schedulers are atomically loaded during bootstrap (because > they are part of the Kernel package so far). > So there should be nothing special to do there. > > >> where the invocation of Delay_class>>#initialize selects the delay >> scheduler. >> > > Once the image is created, the first method invoked is > > PharoBootstrapInitialization >> initializeCommandLineHandlerAn > dErrorHandling > > which is in the image. You can change it as you please :). > > >> I need to determine whether during transition the Bootstrap might need to >> temporarily hop to a different scheduler, >> and how to provide the new structure in the Image for operational testing >> before switching. >> > > In the bootstrap there is no "switching". A new image is created from > scratch with the code that you provide... > Initially the image has no delay scheduler process, so calling `Delay > class initialize` will create it for you. > > So as soon as you define > > Delay class >> initialize > "Delay initialize" > Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. > Scheduler := *MyNewScheduler new*. > Scheduler startTimerEventLoop. > SessionManager default > registerSystemClassNamed: self name > atPriority: 20. > > The bootstrap will take it into account. > I had hoped it would be something simple like that. Thanks for confirming. > And tests will be run with that configuration. > > Maybe there is something else to it? > You want to do test the switching also? Because for this I would do it > with normal smalltalk code... no bootstrap involved... > > >> >> cheers -ben >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Sven Van Caekenberghe

I also think that the catalog is important. If anything is wrong with it we should fix it. The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable. Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free. > On 19 Apr 2018, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > Now today you had loading trouble with Smacc from Catalog ... and now directly want to > kill catalog. Wow! > > Sometimes I have the impression that our community tries to reinvent itself each day > doing it differently (but not only better) instead of extending, improving and supporting > what we have have done before. Which sometimes is good ... but not always. > > Thx > T. > >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] Do we kill the catalog? >> >> Hi guys >> >> What do we do with it? >> What alternatives? >> >> Stef >> >> >

April 19, 2018

Re: [Pharo-dev] Environment variables encoding ?

by Sven Van Caekenberghe

> On 19 Apr 2018, at 10:21, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > I think this problem is not environment variable exclusive. It also affects file paths and others. So far Pharo does not detect the locale to perform the encoding and it should be nice to do it. Sure, it would be nice/good/helpful to detect locale (BTW, don't we have that already more or less). But I would be surprised if an OS API would deliver different encoded data to a process, depending on the locale - I mean in general. That would be setting up things for a huge distaster, IMHO. A modern OS should just deliver UTF-8 (full Unicode data points) and be done with it. > On Tue, Apr 17, 2018 at 10:56 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Damien Pollet wrote > > It seems macOS normalizes UTF-8 differently from everyone else in file > > names (I think base character + composing instead of precomposed > > codepoint). That might affect PWD. > > For environment variables, even if most sensible platforms should have > > adopted UTF-8 by now, I wouldn't be surprised if there's no official > > encoding whatsoever (i.e. they're just bytes with a 0 at the endâ¦) > > > > On 17 April 2018 at 09:36, Sven Van Caekenberghe < > > > sven@ > > > > wrote: > > > >> Hi, > >> > >> The dictionary > >> > >> OSPlatform current environment > >> > >> contains a copy of the OS's environment variables (more correctly of the > >> VM process), as key/value pairs. > >> > >> These are obtained via the following system calls: > >> > >> on macOS & *nix > >> > >> LIBC environ > >> > >> on Windows > >> > >> KERNEL32 GetEnvironmentStrings > >> > >> It is however a bit unclear how these are encoded. On macOS & *nix that > >> seems to be UTF8, on Windows there are some reports that it appears to be > >> Latin1 - but both might be locale specific, I don't know either way. > >> > >> Does anyone know for sure ? > >> > >> I furthermore think that OSEnvironment and its subclasses, who do this > >> call, should be responsible for decoding the C strings into proper Pharo > >> strings, and not leave that responsibility to its users. > >> > >> Fundamentally, in the following, the decoding is still not done correctly > >> and that is wrong/confusing IMHO. > >> > >> $ FOO=benoÃ®t ./pharo Pharo.image eval 'OSEnvironment current > >> associations' > >> {'TERM_PROGRAM'->'Apple_Terminal'. 'TERM'->'xterm-256color'. > >> 'SHELL'->'/bin/bash'. 'TMPDIR'->'/var/folders/sy/ > >> sndrtj9j1tq06j0lfnshmrl80000gn/T/'. 'FOO'->'benoÃÂ®t'. > >> 'Apple_PubSub_Socket_Render'->'/private/tmp/com.apple.launchd.uWk7pivcLT/Render'. > >> 'TERM_PROGRAM_VERSION'->'404'. > >> 'TERM_SESSION_ID'->'845BECCD-0AB0-4686-B7F9-3A0FF84BDCB7'. > >> 'USER'->'sven'. > >> 'SSH_AUTH_SOCK'->'/private/tmp/com.apple.launchd.y5oCwdUyaG/Listeners'. > >> 'PATH'->'/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/opt/X11/bin'. > >> 'PWD'->'/tmp/benoiÃât'. 'XPC_FLAGS'->'0x0'. 'XPC_SERVICE_NAME'->'0'. > >> 'HOME'->'/Users/sven'. 'SHLVL'->'2'. 'LOGNAME'->'sven'. > >> 'LC_CTYPE'->'UTF-8'. 'DISPLAY'->'/private/tmp/com. > >> apple.launchd.lsgASYFiWW/org.macosforge.xquartz:0'. > >> 'SECURITYSESSIONID'->'186a9'. 'OLDPWD'->'/tmp/benoiÃât'. > >> '_'->'/tmp/benoiÃât/pharo-vm/Pharo.app/Contents/MacOS/Pharo'. > >> '__CF_USER_TEXT_ENCODING'->'0x1F5:0x0:0x0'} > >> > >> Of course, if we change this, we will need to fix callers. > >> > >> Opinions ? > >> > >> Sven > >> > >> PS: Furthermore, I note that there is a subtle difference in how $FOO and > >> $PWD in the above are UTF-8 encoded. In the former, normalisation was > >> done, > >> in the latter not. Maybe that could lead to problems (when > >> comparing/composing them). This is a difficult/complex subject ( > >> https://medium.com/concerning-pharo/an-implementation-of-unicode- > >> normalization-7c6719068f43). > >> > >> > >> > >> > > > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > If by different, you mean that it actually normalizes the file names, then > yes. > All Mac filenames are in a well defined form; NFD. > On linux, they're just arrays of bytes, and anything goes. > That the bytes mostly happen to be valid utf8 strings in NFC, is just a > by-product of the fact that's the format most programs use when calling the > file primitives. > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

April 19, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Torsten Bergmann

Now today you had loading trouble with Smacc from Catalog ... and now directly want to kill catalog. Wow! Sometimes I have the impression that our community tries to reinvent itself each day doing it differently (but not only better) instead of extending, improving and supporting what we have have done before. Which sometimes is good ... but not always. Thx T. > Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Do we kill the catalog? > > Hi guys > > What do we do with it? > What alternatives? > > Stef > >

April 19, 2018

Re: [Pharo-dev] Environment variables encoding ?

by Guillermo Polito

Hi, I think this problem is not environment variable exclusive. It also affects file paths and others. So far Pharo does not detect the locale to perform the encoding and it should be nice to do it. On Tue, Apr 17, 2018 at 10:56 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Damien Pollet wrote > > It seems macOS normalizes UTF-8 differently from everyone else in file > > names (I think base character + composing instead of precomposed > > codepoint). That might affect PWD. > > For environment variables, even if most sensible platforms should have > > adopted UTF-8 by now, I wouldn't be surprised if there's no official > > encoding whatsoever (i.e. they're just bytes with a 0 at the endâ¦) > > > > On 17 April 2018 at 09:36, Sven Van Caekenberghe < > > > sven@ > > > > wrote: > > > >> Hi, > >> > >> The dictionary > >> > >> OSPlatform current environment > >> > >> contains a copy of the OS's environment variables (more correctly of the > >> VM process), as key/value pairs. > >> > >> These are obtained via the following system calls: > >> > >> on macOS & *nix > >> > >> LIBC environ > >> > >> on Windows > >> > >> KERNEL32 GetEnvironmentStrings > >> > >> It is however a bit unclear how these are encoded. On macOS & *nix that > >> seems to be UTF8, on Windows there are some reports that it appears to > be > >> Latin1 - but both might be locale specific, I don't know either way. > >> > >> Does anyone know for sure ? > >> > >> I furthermore think that OSEnvironment and its subclasses, who do this > >> call, should be responsible for decoding the C strings into proper Pharo > >> strings, and not leave that responsibility to its users. > >> > >> Fundamentally, in the following, the decoding is still not done > correctly > >> and that is wrong/confusing IMHO. > >> > >> $ FOO=benoÃ®t ./pharo Pharo.image eval 'OSEnvironment current > >> associations' > >> {'TERM_PROGRAM'->'Apple_Terminal'. 'TERM'->'xterm-256color'. > >> 'SHELL'->'/bin/bash'. 'TMPDIR'->'/var/folders/sy/ > >> sndrtj9j1tq06j0lfnshmrl80000gn/T/'. 'FOO'->'benoÃÂ®t'. > >> 'Apple_PubSub_Socket_Render'->'/private/tmp/com.apple. > launchd.uWk7pivcLT/Render'. > >> 'TERM_PROGRAM_VERSION'->'404'. > >> 'TERM_SESSION_ID'->'845BECCD-0AB0-4686-B7F9-3A0FF84BDCB7'. > >> 'USER'->'sven'. > >> 'SSH_AUTH_SOCK'->'/private/tmp/com.apple.launchd.y5oCwdUyaG/Listeners'. > >> 'PATH'->'/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ > texbin:/opt/X11/bin'. > >> 'PWD'->'/tmp/benoiÃât'. 'XPC_FLAGS'->'0x0'. 'XPC_SERVICE_NAME'->'0'. > >> 'HOME'->'/Users/sven'. 'SHLVL'->'2'. 'LOGNAME'->'sven'. > >> 'LC_CTYPE'->'UTF-8'. 'DISPLAY'->'/private/tmp/com. > >> apple.launchd.lsgASYFiWW/org.macosforge.xquartz:0'. > >> 'SECURITYSESSIONID'->'186a9'. 'OLDPWD'->'/tmp/benoiÃât'. > >> '_'->'/tmp/benoiÃât/pharo-vm/Pharo.app/Contents/MacOS/Pharo'. > >> '__CF_USER_TEXT_ENCODING'->'0x1F5:0x0:0x0'} > >> > >> Of course, if we change this, we will need to fix callers. > >> > >> Opinions ? > >> > >> Sven > >> > >> PS: Furthermore, I note that there is a subtle difference in how $FOO > and > >> $PWD in the above are UTF-8 encoded. In the former, normalisation was > >> done, > >> in the latter not. Maybe that could lead to problems (when > >> comparing/composing them). This is a difficult/complex subject ( > >> https://medium.com/concerning-pharo/an-implementation-of-unicode- > >> normalization-7c6719068f43). > >> > >> > >> > >> > > > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > If by different, you mean that it actually normalizes the file names, then > yes. > All Mac filenames are in a well defined form; NFD. > On linux, they're just arrays of bytes, and anything goes. > That the bytes mostly happen to be valid utf8 strings in NFC, is just a > by-product of the fact that's the format most programs use when calling the > file primitives. > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 19, 2018