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

[Stephane Ducasse]

Hi torsten

the wise shows the moon, the idiot sees his finger.

Stef


On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann  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" 
>> An: "Pharo Development List" 
>> Betreff: [Pharo-dev] Do we kill the catalog?
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>>
>

Re: [Pharo-dev] Hierarchy (roots) of package

[Stephane Ducasse]

Thanks Eliot.


On Thu, Apr 19, 2018 at 3:06 PM, Eliot Miranda  wrote:
> Hi Clément,
>
>
> On Apr 18, 2018, at 11:45 PM, Clément Bera  wrote:
>
> I would do that:
>
> Implementation:
> rootsInsidePackage := [ :packageName |
> | myPackage |
> myPackage := RPackageOrganizer default packageNamed: packageName.
> myPackage definedClasses select: [ :each | each superclass package ~~
> myPackage ] ].
>
>
> Don't forget nil superclasses (for proxy classes) so
>
> each superclass isNil
> or: [ each superclass package ~~ myPackage ] ]
>
>
> Example use-case:
> rootsInsidePackage value: 'OpalCompiler-Core'
>
> Is that what you expected ?
>
> On Thu, Apr 19, 2018 at 7:19 AM, Stephane Ducasse 
> wrote:
>>
>> Hi
>>
>> Given a package I would like to know the classes that are roots
>> of hierarchy inside the package.
>>
>> Do we have something like that?
>>
>> Stef
>>
>
>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/

Re: [Pharo-dev] Hierarchy (roots) of package

[Stephane Ducasse]

Thanks Clément this is a nice way to do it.
I was thinking about a more complex solution.
Tx!

On Thu, Apr 19, 2018 at 8:45 AM, Clément Bera  wrote:
> I would do that:
>
> Implementation:
> rootsInsidePackage := [ :packageName |
> | myPackage |
> myPackage := RPackageOrganizer default packageNamed: packageName.
> myPackage definedClasses select: [ :each | each superclass package ~~
> myPackage ] ].
>
> Example use-case:
> rootsInsidePackage value: 'OpalCompiler-Core'
>
> Is that what you expected ?
>
> On Thu, Apr 19, 2018 at 7:19 AM, Stephane Ducasse 
> wrote:
>>
>> Hi
>>
>> Given a package I would like to know the classes that are roots
>> of hierarchy inside the package.
>>
>> Do we have something like that?
>>
>> Stef
>>
>
>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/

Re: [Pharo-dev] [ANN] Pharo Sprint Apr 20

[Marcus Denker]

This is tomorrow.

> On 13 Apr 2018, at 14:32, Marcus Denker  wrote:
> 
> Pharo Sprint Apr 20
>   
>   https://association.pharo.org/event-2789579
> 
> We will organize a Pharo sprint / Moose dojo Apr 20 , starting at
> 10:00am. (Local Time Paris).
> 
> Goals of this sprint:
> 
>   • Pharo 7 issues
> 
> Remote Sprint
>   Remotely, you can join us on Discord. During the sprint, we synchronize 
> local and remote Pharo sprinters:
> 
> 
> Known Local Sprint meetings
> 
>   Lille/France:
>   It will be at the Inria Lille, Building B, third floor (RMoD offices). 
> As the building is not open to the public, please contact us before if you 
> plan to come
> 
> 

Re: [Pharo-dev] Slot Questions

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Question #4:
> Given:
> Object subclass: #MyClass
>   slots: { #var1 => MySlot }
>   classVariables: {  }
>   category: ''
> and
> MyClass >>#var1: anObject
>   var1 := anObject
> MySlot>#write:to: doesn't seem to be sent when I `myClassInstance var1:
> 2`.
> I tried to insert a halt, 1 inspect, etc. I am able to intercept #read: on
> the other hand

All issues from this thread seem to be resolved in latest Pharo 7, except
the above.

This seems like a bug if IIUC. Can anyone confirm?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo-users] [Pharo-Launcher] call for tests on Windows

[Richard Sargent]

The good news is that the same version of Pharo Launcher worked essentially
perfectly under Windows 10.

As expected, the launcher was installed in AppData\Local.
However, I continue to find an AppData\Roaming\pharo directory created when
the launcher was installed. Its contents are as I described in the issue
created for the Windows 7 installation.


Suggestion:
Some of the lists are quite long. It might be useful to be able to sort
them by e.g. name or date of last change, both ascending and descending.



On Mon, Apr 16, 2018 at 9:54 AM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> I ran the launcher against my Windows 7 office computer and have created
> an issue with my feedback.
> https://github.com/pharo-project/pharo-launcher/issues/93
>
>
>
> On Mon, Apr 16, 2018 at 7:13 AM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi,
>>
>> Regarding the various problems Pharo Launchers had on Windows, we worked
>> on a new installer based on Advanced Installer [1] to avoid UAC (User
>> Account Control) and write permissions problems. This new installer now
>> installs Pharo Launcher in the user’s local app data folder (where for
>> sure, he has write permissions). Pharo Launcher also now have its own icon
>> and use its own name instead of Pharo. Also, the uninstaller now works as
>> expected. Last but not least, the installer is now signed to avoid warning
>> of Windows Defender.
>> Thanks to Ben Coman who did the first version of the packaging using
>> Advanced Installer (was NSIS).
>> This version should also improve the launch of Pharo images on Windows.
>>
>> So, please could you install and test this new version: and report any
>> problem with it? http://files.pharo.org/pharo-launcher/win-alpha/
>> We do not have windows users around so it’s hard to know if it works
>> outside our tests boxes.
>>
>> Thanks,
>> Christophe
>>
>> [1] https://www.advancedinstaller.com/
>>
>
>

Re: [Pharo-dev] Slot Questions

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Another issue:
> Changing the slots in the template from "{ #var1 => MySlot adjustment: 10
> }"
> to "{ #var1 => MySlot adjustment: 100 }" has no effect unless I accept an
> intermediate "{ #var1 }"

Fixed by https://pharo.fogbugz.com/f/cases/21725/



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Hierarchy (roots) of package

[Eliot Miranda]

Hi Clément,


> On Apr 18, 2018, at 11:45 PM, Clément Bera  wrote:
> 
> I would do that:
> 
> Implementation:
> rootsInsidePackage := [ :packageName |
>   | myPackage |
>   myPackage := RPackageOrganizer default packageNamed: packageName.
>   myPackage definedClasses select: [ :each | each superclass package ~~ 
> myPackage ] ].

Don't forget nil superclasses (for proxy classes) so

each superclass isNil
or: [ each superclass package ~~ myPackage ] ]

> 
> Example use-case:
> rootsInsidePackage value: 'OpalCompiler-Core'
> 
> Is that what you expected ?
> 
>> On Thu, Apr 19, 2018 at 7:19 AM, Stephane Ducasse  
>> wrote:
>> Hi
>> 
>> Given a package I would like to know the classes that are roots
>> of hierarchy inside the package.
>> 
>> Do we have something like that?
>> 
>> Stef
>> 
> 
> 
> 
> -- 
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/

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

[Peter Uhnák]

> What do we do with it?
> What alternatives?
> Stef


Is Cargo dead? I thought that was supposed to be the alternative.


> That sounds like a non-problem. One file that never needs to change. Let’s
> solve the problems first
>

How so? If I want for the catalog to load a specific version of Git(Hub)
project, then I need to specify a tag. Which means every time I make a new
release, I need to update the configuration. At least this is how I saw
other people were addressing it.

Peter

[Pharo-dev] Exception in Iceberg when removing selectors from anonymous classes

[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. 

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

[Stephan Eggermont]

Gabriel Cotelli  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

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

[Esteban Lorenzano]

> On 19 Apr 2018, at 11:25, Gabriel Cotelli  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  > 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  > > 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"  >> >
> >> An: "Pharo Development List"  >> >
> >> Betreff: [Pharo-dev] Do we kill the catalog?
> >> 
> >> Hi guys
> >> 
> >> What do we do with it?
> >> What alternatives?
> >> 
> >> Stef
> >> 
> >> 
> > 
> 
> 

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

[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  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  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" 
> >> An: "Pharo Development List" 
> >> Betreff: [Pharo-dev] Do we kill the catalog?
> >>
> >> Hi guys
> >>
> >> What do we do with it?
> >> What alternatives?
> >>
> >> Stef
> >>
> >>
> >
>
>
>

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

[Thierry Goubier]

2018-04-19 10:57 GMT+02:00 Sven Van Caekenberghe :
> 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  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" 
>>> An: "Pharo Development List" 
>>> Betreff: [Pharo-dev] Do we kill the catalog?
>>>
>>> Hi guys
>>>
>>> What do we do with it?
>>> What alternatives?
>>>
>>> Stef
>>>
>>>
>>
>
>

Re: [Pharo-dev] DelayScheduler cleanup & Bootstrap

[Ben Coman]

On 19 April 2018 at 15:38, Guillermo Polito 
wrote:

>
>
> On Sun, Apr 15, 2018 at 3:19 PM, Ben Coman  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
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

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

[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  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" 
>> An: "Pharo Development List" 
>> Betreff: [Pharo-dev] Do we kill the catalog?
>> 
>> Hi guys
>> 
>> What do we do with it?
>> What alternatives?
>> 
>> Stef
>> 
>> 
> 

Re: [Pharo-dev] Environment variables encoding ?

[Sven Van Caekenberghe]

> On 19 Apr 2018, at 10:21, Guillermo Polito  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 
>  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/
> >> sndrtj9j1tq06j0lfnshmrl8gn/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/benoî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/benoît'.
> >> '_'->'/tmp/benoî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

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

[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" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] Do we kill the catalog?
>
> Hi guys
> 
> What do we do with it?
> What alternatives?
> 
> Stef
> 
> 

Re: [Pharo-dev] Environment variables encoding ?

[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.johan...@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/
> >> sndrtj9j1tq06j0lfnshmrl8gn/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/benoî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/benoît'.
> >> '_'->'/tmp/benoî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

[Pharo-dev] [CfP] ICOOOLPS 2018

[Tim Felgentreff]

Call for Papers: ICOOOLPS'18


13th Workshop on Implementation, Compilation, Optimization of Object- Oriented
Languages, Programs and Systems

Co-located with ECOOP 2018
held Mon 16 - Sun 22 July in Amsterdam, Netherlands

Twitter: @ICOOOLPS
URL: https://conf.researchr.org/track/ecoop-issta-2018/ICOOOLPS-2018-papers

The ICOOOLPS workshop series brings together researchers and practitioners
working in the field of language implementation and optimization. The goal of
the workshop is to discuss emerging problems and research directions as well as
new solutions to classic performance challenges.

The topics of interest for the workshop include techniques for the
implementation and optimization of a wide range of languages including but not
limited to object-oriented ones. Furthermore, meta-compilation techniques or
language-agnostic approaches are welcome, too.

### Topics of Interest

A non-exclusive list of topics of interest for this workshop is:

- Implementation and optimization of fundamental languages features (from
  automatic memory management to zero-overhead metaprogramming)
- Runtime systems technology (libraries, virtual machines)
- Static, adaptive, and speculative optimizations and compiler techniques
- Meta-compilation techniques and language-agnostic approaches for the efficient
  implementation of languages
- Compilers (intermediate representations, offline and online optimizations,…)
- Empirical studies on language usage, benchmark design, and benchmarking
  methodology
- Resource-sensitive systems (real-time, low power, mobile, cloud)
- Studies on design choices and tradeoffs (dynamic vs. static compilation,
  heuristics vs. programmer input,…)
- Tooling support, debuggability and observability of languages as well as their
  implementations

### Workshop Format and Submissions

This workshop welcomes the presentation and discussion of new ideas and emerging
problems that give a chance for interaction and exchange. More mature work is
welcome as part of a mini-conference format, too. We aim to interleave
interactive brainstorming and demonstration sessions between the formal
presentations to foster an active exchange of ideas. The workshop papers will be
published in ACM DL or an open archive (to be confirmed). Papers are to be
submitted using the sigplanconf LaTeX template
(http://www.sigplan.org/Resources/LaTeXClassFile/).

Please submit contributions via EasyChair:
https://easychair.org/conferences/submission_show_all.cgi?a=17114062

### Important Dates

   Submissions:  18 May 2018
   Author Notification:  8 June 2018

### Program Committee

The program committee consists of the organizers and the following reviewers:

Nada Amin, University of Cambridge
Clément Béra, RMOD - INRIA Lille Nord Europe
Shigeru Chiba, University of Tokyo
Benoit Daloze, JKU Linz
Görel Hedin, Lund University
Eric Jul, University of Oslo
Stefan Marr, University of Kent
Eliot Miranda, Cadence Design Systems
Sarah Mount, King's College London
Tobias Pape, Hasso Plattner Institute
Jennifer Sartor, Vrije Universiteit Brussel + University Ghent

### Workshop Organizers

Tim Felgentreff, Oracle Labs Potsdam
Olivier Zendra, INRIA / LORIA

Re: [Pharo-dev] DelayScheduler cleanup & Bootstrap

[Guillermo Polito]

On Sun, Apr 15, 2018 at 3:19 PM, Ben Coman  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 >> initializeCommandLineHandlerAndErrorHandling

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.
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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[Ben Coman]

>
> >
> > Esteban
> >
> >> On 19 Apr 2018, at 08:42, Stephane Ducasse 
> wrote:
> >>
> >> Hi guys
> >>
> >> What do we do with it?
> >> What alternatives?
> >>
> >> Stef
> >>
> >
>


On 19 April 2018 at 14:59, Esteban Lorenzano  wrote:

>
>
> > On 19 Apr 2018, at 08:46, Esteban Lorenzano  wrote:
> >
> > why to kill it?
> > right now we do not have a replacement.
>
> btw, I had this idea of
>
> - using a STON spec instead a class (I think Dale has already something
> about it)
> - using github as centralised repository to simplify the infrastructure,
> and to accept new projects as PRs :)
>
> just… no time to implement it yet, but it should be fairly easy.
>
> cheers,
> Esteban
>
>
This is a good idea.  The STON could be easily edited directly with
github's web-based text editor
which would encourage third-parties to enhance the descriptions.

Maybe good to publish it as a github pages, with a custom domain to shield
against having to move away from github.
https://help.github.com/articles/about-supported-custom-domains/#custom-subdomains

cheers -ben

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

[Esteban Lorenzano]

> On 19 Apr 2018, at 08:46, Esteban Lorenzano  wrote:
> 
> why to kill it?
> right now we do not have a replacement.

btw, I had this idea of 

- using a STON spec instead a class (I think Dale has already something about 
it)
- using github as centralised repository to simplify the infrastructure, and to 
accept new projects as PRs :)

just… no time to implement it yet, but it should be fairly easy.

cheers,
Esteban

> 
> Esteban
> 
>> On 19 Apr 2018, at 08:42, Stephane Ducasse  wrote:
>> 
>> Hi guys
>> 
>> What do we do with it?
>> What alternatives?
>> 
>> Stef
>> 
>