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

[FUN] SNCF (french railways) is doing "Pharo"

by Noury Bouraqadi

See the adertisement I received :-) Noury

Jan. 21, 2015

Re: [Pharo-dev] [ Call for participation ] Pharo Days 2015 Project Expo

by Sven Van Caekenberghe

Hi Yiriy, I would not go all the way to the edge, I kept a 1 cm margin all around. This will be easier when other want to print the pages at home. I would also like to renew the call: please take a couple of minutes to create a one page description of your or your favourite project(s). Thanks ! Sven > On 21 Jan 2015, at 14:31, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi. > > One important question: Can I count on borderless printing? > > Uko > > >> On 06 Jan 2015, at 16:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Pharo is a platform, an enabler. The various frameworks and libraries on top of Pharo constitute the actual building blocks for real world applications. We have a healthy ecosystem, but we need to improve discoverability. >> >> One of the things that we want to do during the upcoming Pharo Days (http://pharodays2015.pharo.org/) is a Project Expo as a replacement for the traditional Show Your Project presentations. >> >> The idea is that authors, maintainers, supporters or even users create a single poster style A4 page highlighting one framework or library. Describe what it is, what the main features, advantages and applications are, give some links so where those interested can find out more, a bit like a datasheet. >> >> Here is an example: >> >> <stamp-poster.pdf> >> Obviously I am no designer, but that does not matter: you are marketing a software artefact to fellow developers. >> >> Those posters turned in before Sunday January 25th will be printed on at least A3 format (maybe larger if possible). We will then put them up during the conference. Make sure to ask around if you want to talk face to face to someone about a particular topic. >> >> Afterwards we will collect all posters into an online exhibition going forward. >> >> So please help out ! >> >> Thank you, >> >> Sven >> >> PS: >> >> You are free to create a page using any tool you like, just produce an A4 PDF without any too large coloured or filled areas (i.e. make it print friendly). And remember, small projects or sub projects are important too.

Jan. 21, 2015

Re: [Pharo-dev] [ Call for participation ] Pharo Days 2015 Project Expo

by Yuriy Tymchuk

Hi. One important question: Can I count on borderless printing? Uko > On 06 Jan 2015, at 16:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Pharo is a platform, an enabler. The various frameworks and libraries on top of Pharo constitute the actual building blocks for real world applications. We have a healthy ecosystem, but we need to improve discoverability. > > One of the things that we want to do during the upcoming Pharo Days (http://pharodays2015.pharo.org/) is a Project Expo as a replacement for the traditional Show Your Project presentations. > > The idea is that authors, maintainers, supporters or even users create a single poster style A4 page highlighting one framework or library. Describe what it is, what the main features, advantages and applications are, give some links so where those interested can find out more, a bit like a datasheet. > > Here is an example: > > <stamp-poster.pdf> > Obviously I am no designer, but that does not matter: you are marketing a software artefact to fellow developers. > > Those posters turned in before Sunday January 25th will be printed on at least A3 format (maybe larger if possible). We will then put them up during the conference. Make sure to ask around if you want to talk face to face to someone about a particular topic. > > Afterwards we will collect all posters into an online exhibition going forward. > > So please help out ! > > Thank you, > > Sven > > PS: > > You are free to create a page using any tool you like, just produce an A4 PDF without any too large coloured or filled areas (i.e. make it print friendly). And remember, small projects or sub projects are important too. > > >

Jan. 21, 2015

Stuck jobs are not aborted CI

by Stephan Eggermont

AFAIK, jobs that take too long should be aborted. That doesn't seem to happen. https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog2/ Stephan

Jan. 21, 2015

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

by Jan Vrany

On Tue, 2015-01-20 at 21:35 +0100, Sven Van Caekenberghe 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 ? Certainly not :-) On UNIX systems the encoding is undefined AFAIK. You may want to consult locale before deciding on encoding - this works quite well. nl_langinfo() is the guy to ask. Best, Jan > > > > 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 > > >

Jan. 21, 2015

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

by Nicolas Cellier

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... > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 21, 2015

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

by Paul DeBruicker

Stephan Eggermont wrote > Who is dealing with CI? The queue is still growing and nothing seems to > finish. > > Stephan > > Jenkins tells me there are only 4 jobs using any significant amount of > space: > - FileTree-Pharo30-dev, > - Fuel-Stable > - Fuel-Development > - PharoProjectCatalog2 > > The total is 43GB, so actually peanuts. > > Jobs:43 GB, Builds:43 GB, Locked builds:10 GB, Workspace:21 GB > > FileTree-Pharo30-dev 6 GB 6 GB 4 GB 196 MB > Fuel-Stable 6 GB 6 GB 251 MB 338 MB > Fuel-Development 5 GB 5 GB 363 MB 12 KB > PharoProjectCatalog2 5 GB 5 GB 449 MB - > Fuel-Serialize-All 1 GB 1 GB - - > Versionner 710 MB 710 MB 494 MB 119 MB > ... In November 2013 the config of FileTree-Pharo30-dev was set by Camillo to keep every 10th build no matter what, and to keep every buildd for the past 30 days. And to run every day. At this point in time it seems especially excessive because no one is fixing the failing tests on Pharo 3 latest when loading FileTree from SqueakSource3. I've changed it to only keep the past 3 builds, and only build when either Pharo3 latest is updated or the FileTree repo on SqueakSource 3 is updated. It could probably be deleted entirely. -- View this message in context: http://forum.world.st/pharo-contribution-CI-out-of-space-tp4800325p4800748.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 21, 2015

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

by Stephan Eggermont

I've removed all jobs from the queue. Stephan

Jan. 20, 2015

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

by Sven Van Caekenberghe

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 ? > > 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

Jan. 20, 2015

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

by Eliot Miranda

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

Jan. 20, 2015