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

Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found
by Stephane Ducasse April 11, 2018

April 11, 2018

Because now when I load pillar Metacello new baseline: 'Pillar'; repository: 'github://pillar-markup/pillar:newpipeline/src'; load I get an error because Magritte-MOrph-SeasnDeNigris.95 is not found So I cannot build pillar anymore! :(

5 13

What about removing forks in Monticello browser
by Stephane Ducasse April 11, 2018

April 11, 2018

Hi I have the impression that the forks around the monticello browser are introducing more mess than they solve. Would not be good to remove such behavior? Stef

1 0

[Pharo 7.0-dev] Build #760: 21687-make-a-deprecated-Key-as-subclass-of-KeyboardKey
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2018

April 11, 2018

There is a new Pharo build available! The status of the build #760 was: FAILURE. The Pull Request #1190 was integrated: "21687-make-a-deprecated-Key-as-subclass-of-KeyboardKey" Pull request url: https://github.com/pharo-project/pharo/pull/1190 Issue Url: https://pharo.fogbugz.com/f/cases/21687 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Images, VMs and 32 vs 64bit
by Guillermo Polito April 11, 2018

April 11, 2018

VMs share most of the code. At least the basic interpreter, primitives and garbage collector. But there are some platform specificities such as how some plugins are managed. Also there are different JIT backends, one per platform. I don't know if a VM comes shipped with all of them or just the one needed. For more details, better ask the vm-dev mailing list. On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org>, "Peter UhnÃ¡k" < > i.uhnak(a)gmail.com> > Cc: > Bcc: > Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC) > Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit > Thanks! > > I don't really care about the image format, my question was more oriented > towards the code itself. As I don't have a Mac, I was curious as to > whether there would be code differences between platforms, VMs and 32 vs > 64bit distributions, code-wise! > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter UhnÃ¡k < > i.uhnak(a)gmail.com> wrote: > > > > images for different platforms (Mac, Linux, Windows) > > yes > It is the responsibility of the VM to contain the differences. Note that > there's some "platform-specific" code, but the image contains the code for > all platforms at once. > Generally speaking you can code on one platform, copy the image files to > another and continue your work (although doing this can cause trouble, as > e.g. some file paths may now point to non-existing locations). > You can download the images independently of the platform too (e.g. Pharo > 6 images: http://files.pharo.org/image/60/ ) > > > VMs (32bit, 64bit) > > yes? > the files are different, but I don't know if there's code difference, or > if the images are just built with different memory layouts > > Peter > > On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Bcc: > Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC) > Subject: Images, VMs and 32 vs 64bit > I was wondering if images for different platforms (Mac, Linux, Windows) > and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do > they all have the exact same code base or some classes/methods are in some > and not in others or different? > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > > -- 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

3 2

Executive Programming
by Ben Coman April 11, 2018

April 11, 2018

This article about the "Mining Industry's Impending Digital Metamorphosis" https://medium.com/@CORE_Innovation/minings-impending-metamorphosis-155d668… is a little off topic, except where it says "All levels, including management and executives will need to have some level coding experience and understanding." made me think this must be pervasive across many industries and that an interesting strategy for Pharo would be teaching a course called... "Executive Programming". Pharo could be ideally suited to filling this niche... * Executives don't need to learn the *most* efficient language (i.e. C), * and don't need to learn a system suited to large groups of developers (i.e. Java) * and don't have the time to wait for things to compile (i.e. big tick immediate feedback) They are never going to "do the work" but just need to gain a general understanding of "programming" to better strategise at a higher level and interact with developers. What better language is there for this than Pharo? But guess what happens when the boss is familiar with and likes one particular language... ? /cue maniacal laugh cheers -ben P.S. I'd be interested in collaborating on something that is not an end user book, but more of an Instructors manual for such a course.

3 4

Re: [Pharo-dev] Images, VMs and 32 vs 64bit
by Peter UhnÃ¡k April 10, 2018

April 10, 2018

> images for different platforms (Mac, Linux, Windows) yes It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once. Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations). You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ ) > VMs (32bit, 64bit) yes? the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts Peter On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Bcc: > Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC) > Subject: Images, VMs and 32 vs 64bit > I was wondering if images for different platforms (Mac, Linux, Windows) > and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do > they all have the exact same code base or some classes/methods are in some > and not in others or different? > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

2 1

DateAndTime Offset Bug Proposal
by Sean P. DeNigris April 10, 2018

April 10, 2018

I was bitten by this very annoying bug again. As most of us probably know due to the steady stream of confused ML posts in the past, the bug in summary is that we have an incomplete timezone implementation that doesn't properly take into account historical DST changes. This flares up without warning especially when DST toggles. I created a wiki page to document the situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco Here's an example blowup: at 11:59pm before DST changes, eval aDate := '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" offsets render equal dates unequal depending on when the objects were created. The more I think about it, the more I think that we should just assume UTC for all Date[AndTime]s that don't explicitly specify an offset, rather than pretend to set an offset which is only sometimes correct. More advanced users can use one of the available libraries to get full timezone support. What do you think? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

11 27

[Pharo 7.0-dev] Build #759: 21680-haltIfTest-and-haltIfNotTest-and-comments
by ci-pharo-ci-jenkins2＠inria.fr April 10, 2018

April 10, 2018

There is a new Pharo build available! The status of the build #759 was: SUCCESS. The Pull Request #1187 was integrated: "21680-haltIfTest-and-haltIfNotTest-and-comments" Pull request url: https://github.com/pharo-project/pharo/pull/1187 Issue Url: https://pharo.fogbugz.com/f/cases/21680 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Metacello/Iceberg Error: IceUndefinedRemote DNU #projectPath
by Sean P. DeNigris April 9, 2018

April 9, 2018

I was loading a project via: Metacello new baseline: 'BabyPhexample'; repository: 'github://seandenigris/Baby-Phexample/repository'; onConflict: [ :ex | ex allow ]; load. into a Moose 6.1 image obtained from Launcher which already contained StateSpecs and got this: IceUndefinedRemote(Object)>>doesNotUnderstand: #projectPath IceMetacelloRepositoryAdapter>>projectPath IceMetacelloRepositoryAdapter>>hasNoLoadConflicts: MetacelloRepositorySpec>>hasNoLoadConflicts: MetacelloRepositoriesSpec>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloGenericProjectSpec)>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloProjectSpec)>>hasLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasConflictWithBaselineSpec: MetacelloMCBaselineOfProjectSpec>>hasConflictWithProjectSpec: MetacelloProjectRegistration>>hasLoadConflicts: Ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 2

Multiple Inheritance
by Sean P. DeNigris April 9, 2018

April 9, 2018

I was just thinking about all the freedom brought by stateful traits, and the thought occurred: why not just simplify and remove another hurdle by having multiple inheritance with the conflict resolution and scoping of traits? Forgive me if I'm missing something obviousâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 1