January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Partner: DCyT - Universdad Nacional de Quilmes

by Ben Coman

Based on the info from the web site, looks like good steady progress building the consortium for a sustainable future for Pharo. Great work! cheers -ben On Thu, Jan 22, 2015 at 1:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > The Pharo Consortium is very happy to announce that the DCyT - Universdad > Nacional de Quilmes has joined the Consortium as an Academic Partner. > > About > > - DCyT - Universdad Nacional de Quilmes: http://www.unq.edu.ar > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > Individuals can support Pharo via the Pharo Association: > http://association.pharo.org >

Jan. 22, 2015

Re: [Pharo-dev] More people needed to review issues

by Guillermo Polito

Marcus, can the issue tracker send an email to the mailing list every morning with some report? - # of issues opened - # of issues in state X - # of issues in state Y - # of issues older than a month... We can try to do something like that this friday afternoon together if you want. Maybe if we automatize a mail like that every morning 1) you don't have to do it manually so it's less pain for you and 2) with numbers people will have another feeling. El Thu Jan 22 2015 at 10:25:38 AM, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > Hello, > > Now that so many people talk so much: > > We need more people to *regularly* look at the issue tracker: > > https://pharo.fogbugz.com/ > > -> check if reported issues are reproducable > -> check proposed solutions > -> comment on new features (âI donât like that becauseâ¦.â) > -> fix issues that are not yet fixed > -> summarise issues with long discussions and distill âThe next action > that needs to be done is:â > > â¦. > > Marcus >

Jan. 22, 2015

More people needed to review issues

by Marcus Denker

Hello, Now that so many people talk so much: We need more people to *regularly* look at the issue tracker: https://pharo.fogbugz.com/ <https://pharo.fogbugz.com/> -> check if reported issues are reproducable -> check proposed solutions -> comment on new features (âI donât like that becauseâ¦.â) -> fix issues that are not yet fixed -> summarise issues with long discussions and distill âThe next action that needs to be done is:â â¦. Marcus

Jan. 22, 2015

Re: [Pharo-dev] pharo-contribution CI out of space?

by Christophe Demarey

Le 20 janv. 2015 Ã 17:35, Stephan Eggermont a Ã©crit : > Who is dealing with CI? The queue is still growing and nothing seems to finish. I noticed that in the past. It may happen when no slave is available to execute a specific job. It happens if one or many slave go offline or if a build is stuck and no other executor is available for other jobs. I don't know if there is a good solution to manage that. My opinion is that we should just be sure that a timeout is set to every job. In addition, we could install these plugin: https://wiki.jenkins-ci.org/display/JENKINS/Purge+Build+Queue+Plugin that will ease our life if the queue grows quickly.

Jan. 22, 2015

Re: [Pharo-dev] pharo-contribution CI out of space?

by Christophe Demarey

Le 19 janv. 2015 Ã 11:58, Yuriy Tymchuk a Ã©crit : > Hi, > > Iâm getting this things in logs: > > Downloading PharoV20.sources: > http://files.pharo.org/sources//PharoV20.sources.zip > pharo-vm/PharoV20.sources: write error (disk full?). Continue? (y/n/^C) > warning: pharo-vm/PharoV20.sources is probably truncated > > > did we run out of space on pharo-contribution? No, it looks like the fils system of a slave is full. It may happen because a slave keep the last workspace for each job that has been run on it.

Jan. 22, 2015

Re: [Pharo-dev] [squeak-dev] re: Context status 2015-01-16

by Chris Muller

On Tue, Jan 20, 2015 at 7:39 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2015-01-19 15:41 GMT+01:00 Craig Latta <craig(a)netjam.org>: >> >> >> Okay, I'll add both of the execution-driven imprinters to the >> repository. They're called "active" and "passive" imprinting. >> >> Active imprinting is directed by the system that initially has the >> desired code. An ActiveImprintingServer has clients in the systems which >> will receive the code. Every time the server system runs a method in a >> certain process, it imprints that method onto each of the clients. One >> use case for this is giving the code of a demo to an audience as you run >> it. >> >> Passive imprinting is directed by the system that wants the code. >> The target system makes a remote-messaging connection to a system which >> has the code, and runs an expression which will use the code. Every time >> a method is missing from the target system (in any process), the target >> system requests the missing method from the provider system, installs >> it, and retries running that method. >> >> I have imprinted the exception-handling system, the compiler, and >> the class builder with both approaches. >> >> > > In this scheme, something is striking me. > Some images share some code (classes, compiledMethods) > But what about code mutations/updates? > > Without such mutations, is it still Smalltalk? > > Without active imprinting, such mutations might not be obvious to propagate > (for example a subclass now overrides a message of super) > > And since you import class builder and compiler in the target, on what > purpose? Is the target going to change a class locally? What if it then > imports incompatible methods from provider? Or is the goal to just replicate > some mutations from the provider? > > Maybe the scheme is more interesting for deployment of static code, but I'm > curious to know if ever live updates would still be possible... The particular scenario I was dreaming of would never have changes made to the imprinted images. At worst, the source Caddilac image might be have a patch applied in production, in which case it would need some way to invalidate the updated methods in all clients...

Jan. 21, 2015

Re: [Pharo-dev] [Pharo-users] CommandLine handler and UTF8 path

by Sven Van Caekenberghe

> On 21 Jan 2015, at 23:25, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Jan 20, 2015 at 12:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Eliot, > > > On 20 Jan 2015, at 20:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Tue, Jan 20, 2015 at 8:00 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Command line arguments enter the image level via VirtualMachine>>#getSystemAttribute: > > > > At that point they are already Strings. > > > > ByteString, according to the primitive. So if the shell supplies e.g. UTF-8 strings for command-line parameters, which the VM sees as bytes, then the ByteString instances answered by getSystemAttribute: would need decoding, right? > > > > In your case, they must already be wrong at that point. > > > > Not necessarily. The getSystemAttribute: primitive doesn't do decoding. Perhaps it should. > > Yes, probably. I just tried on Mac OS X, Pharo 4: > > $ export FOO=Ã©lÃ¨ve-FranÃ§ais > > $ echo $FOO > Ã©lÃ¨ve-FranÃ§ais > > $ ./pharo Pharo.image eval 'OSPlatform current environment at: #FOO' > 'ÃÂ©lÃÂ¨ve-FranÃÂ§ais' > > $ ./pharo Pharo.image eval '(OSPlatform current environment at: #FOO) asByteArray utf8Decoded' > 'Ã©lÃ¨ve-FranÃ§ais' > > The question is, is this true for all platforms ? Windows ? > > I'm trying to test this in Pharo 3. I get > > KeyNotFound: key #FOO not found in PlatformIndependentEnvironment > PlatformIndependentEnvironment(OSEnvironment)>>at: in Block: [ KeyNotFound signalFor: aKey ] > UndefinedObject>>ifNil: > PlatformIndependentEnvironment(OSEnvironment)>>at:ifAbsent: > PlatformIndependentEnvironment(OSEnvironment)>>at: > UndefinedObject>>DoIt > OpalCompiler>>evaluate > OpalCompiler(AbstractCompiler)>>evaluate: > SmalltalkImage>>evaluate: > EvaluateCommandLineHandler>>evaluate: in Block: [ ... > BlockClosure>>on:do: > > > Does the environment access depend on NativeBoost? Yes, I believe so. > > > On 20 Jan 2015, at 16:51, Hilaire <hilaire(a)drgeo.eu> wrote: > > > > > > Le 20/01/2015 16:34, Sven Van Caekenberghe a Ã©crit : > > >> No they are not - Strings and Characters in Pharo are using plain Unicode encoding internally. > > > > > > Thanks for the update, and the reference link. > > > > > > Hilaire > > > > > > -- > > > Dr. Geo - http://drgeo.eu > > > iStoa - http://istoa.drgeo.eu > > > > > > > > > > > > > > > > > > -- > > best, > > Eliot > > > > > > -- > best, > Eliot

Jan. 21, 2015

Re: [Pharo-dev] [Pharo-users] CommandLine handler and UTF8 path

by Eliot Miranda

On Tue, Jan 20, 2015 at 12:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Eliot, > > > On 20 Jan 2015, at 20:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Tue, Jan 20, 2015 at 8:00 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Command line arguments enter the image level via > VirtualMachine>>#getSystemAttribute: > > > > At that point they are already Strings. > > > > ByteString, according to the primitive. So if the shell supplies e.g. > UTF-8 strings for command-line parameters, which the VM sees as bytes, then > the ByteString instances answered by getSystemAttribute: would need > decoding, right? > > > > In your case, they must already be wrong at that point. > > > > Not necessarily. The getSystemAttribute: primitive doesn't do > decoding. Perhaps it should. > > Yes, probably. I just tried on Mac OS X, Pharo 4: > > $ export FOO=Ã©lÃ¨ve-FranÃ§ais > > $ echo $FOO > Ã©lÃ¨ve-FranÃ§ais > > $ ./pharo Pharo.image eval 'OSPlatform current environment at: #FOO' > 'ÃÂ©lÃÂ¨ve-FranÃÂ§ais' > > $ ./pharo Pharo.image eval '(OSPlatform current environment at: #FOO) > asByteArray utf8Decoded' > 'Ã©lÃ¨ve-FranÃ§ais' > > The question is, is this true for all platforms ? Windows ? > I'm trying to test this in Pharo 3. I get KeyNotFound: key #FOO not found in PlatformIndependentEnvironment PlatformIndependentEnvironment(OSEnvironment)>>at: in Block: [ KeyNotFound signalFor: aKey ] UndefinedObject>>ifNil: PlatformIndependentEnvironment(OSEnvironment)>>at:ifAbsent: PlatformIndependentEnvironment(OSEnvironment)>>at: UndefinedObject>>DoIt OpalCompiler>>evaluate OpalCompiler(AbstractCompiler)>>evaluate: SmalltalkImage>>evaluate: EvaluateCommandLineHandler>>evaluate: in Block: [ ... BlockClosure>>on:do: Does the environment access depend on NativeBoost? > > > On 20 Jan 2015, at 16:51, Hilaire <hilaire(a)drgeo.eu> wrote: > > > > > > Le 20/01/2015 16:34, Sven Van Caekenberghe a Ã©crit : > > >> No they are not - Strings and Characters in Pharo are using plain > Unicode encoding internally. > > > > > > Thanks for the update, and the reference link. > > > > > > Hilaire > > > > > > -- > > > Dr. Geo - http://drgeo.eu > > > iStoa - http://istoa.drgeo.eu > > > > > > > > > > > > > > > > > > -- > > best, > > Eliot > > > -- best, Eliot

Jan. 21, 2015

Re: [Pharo-dev] [FUN] SNCF (french railways) is doing "Pharo"

by Alain Rastoul

That's cool! I like very much pharo logo Marketing people who don't know yet that they are smalltalk pharoers in spirit ? May be someone should tell them, imagine how much that may change their lives ;) Or an already pharo supporter who did it's own underground campaign ? That would be really cool too , pharo deserves to be known :) Le 21/01/2015 17:43, Noury Bouraqadi a Ã©crit : > See the adertisement I received :-) > > Noury -- Regards, Alain

Jan. 21, 2015

[ANN] Pharo Consortium New Academic Partner: DCyT - Universdad Nacional de Quilmes

by Marcus Denker

The Pharo Consortium is very happy to announce that the DCyT - Universdad Nacional de Quilmes has joined the Consortium as an Academic Partner. About - DCyT - Universdad Nacional de Quilmes: http://www.unq.edu.ar <http://www.unq.edu.ar/> - Pharo Consortium: http://consortium.pharo.org <http://consortium.pharo.org/> The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org <http://association.pharo.org/>

Jan. 21, 2015