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

Re: [Pharo-dev] Submit your Project to the ESUG Awards

by Matteo Marra

Hello Noury, I would like to participate to the innovation award @ ESUG! My project, Port, is about running pharo on a cluster and executing map/reduce-like applications on it. My research focuses on debugging such problems, and I will try give a demo of both deploying and executing applications on a cluster (surely) and debugging them (if time will allow me). Let me know if you need additional (or more detailed, or better presented) information, Kind regards, Matteo > On 21 Aug 2018, at 14:58, N. Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Hi everyone! > > This is a reminder to submit your projects to the ESUG Innovation Technology Awards. It will be held on september the 10th as part of the ESUG conference in Sardinia (https://esug.github.io/2018-Conference/conf2018.html) > > Any Pharo Smalltalk-related project is eligible. > All you need to do is provide me with few info and give a short demo during the awards session. > > I hope to hear from you soon, > Noury > >

Aug. 27, 2018

What tools or methods we have in Smalltalk (Pharo) for Model Driven programming?

by ponyatov

I mean MDP in a wide, in a more generic way, not the things like UML and other OMG derivatives. As an example, I defined a little set of generic classes <http://ponyatov.quora.com/Smalltalk-etudes-Model-Driven-MetaProgramming> for metaprogramming in terms of generic programming elements. My idea is about - creating domain-specific models, then - translate them into generic language-independent models, and finally - transform them into some code-synthesizable representation for the specific target programming language (which let me write in Smalltalk in any mainstream language and avoid no-vacancy lock) What tools or methods we have in Smalltalk (Pharo) for this approach? - data structure visualization - model transformation - logic-like inference over such a like models -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 26, 2018

Re: [Pharo-dev] [Vm-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Ben Coman

On Sat, 25 Aug 2018 at 01:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sean, > On Fri, Aug 24, 2018 at 10:03 AM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like >> the >> following: >> <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> >> >> This seems to usually signal that a crash is not far away. > > Do you mean seconds or minutes or more away from a crash? > It's doubly concerning because there is no clear way to stop the troubled >> process >> (interrupts often bring up a debugger on something else) and because, >> since >> one is now unable to save any code, it's unclear how to start over easily >> in >> a new image. > > Just some general ideas (you may have already considered) The string "Diffing..." appears in only one location in MCPatch>>initializeWithBase:target: I'm not clear on the behaviour of #on:displayProgress: whether its possible some inside loop can make that string appear multiple times, or whether it indicates #initializeWithBase:target: is being called multiple times. A specific check there for an escape key-combo might help debug this. Or a class variable reset from Iceberg that halts when it exceeds a limit on the number of loops. Or log to file five or so levels of "thisContext senders senders etc" for post crash analysis to help isolate the loop. cheers -ben P.S. While I was browsing senders-of-senders-of-senders I quickly got lost and wondered if a tool that graphically showed a senders-tree might be a useful demo for Diagrammer. >

Aug. 26, 2018

[Pharo 7.0-dev] Build #1193: 22365 Introduced dynamic presenters list builder and tests.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1193 was: SUCCESS. The Pull Request #1718 was integrated: "22365 Introduced dynamic presenters list builder and tests." Pull request url: https://github.com/pharo-project/pharo/pull/1718 Issue Url: https://pharo.fogbugz.com/f/cases/22365 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 25, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Sean P. DeNigris

EstebanLM wrote > You would ask why being an obsolete version we do not backport the good > version for Pharo 6.1 That is totally understandable. EstebanLM wrote > recommended to install themselves the correct version... Ah! I didn't realize there was still a viable upgrade path. I will check that out! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 24, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Esteban Lorenzano

> On 24 Aug 2018, at 20:41, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 24/08/2018 Ã 19:03, Sean P. DeNigris a Ã©crit : >> Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the >> following: >> <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> >> >> This seems to usually signal that a crash is not far away. It's doubly >> concerning because there is no clear way to stop the troubled process >> (interrupts often bring up a debugger on something else) and because, since >> one is now unable to save any code, it's unclear how to start over easily in >> a new image. In an extreme scenario, I recently panicked during such an >> experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting >> in an image that took hours worth of code (I know maybe not a great >> practice) with it to the grave. >> >> Any idea why this happens or what we might be able to do anything about it? >> >> p.s. I was so concerned that I immediately resolved to move to Pharo 7, but >> that turned out not to be an option do to the recently reported bug with >> extension methods (that don't exactly match the package name) >> >> > > Hi, > > IIRC the problem only happens when the commit windows is maximize. > Something happen, maybe the progress bar updating launch a redraw of the > morph, and if the iceberg window is under the progress bar it also try > to redraw it but for that it snapshots methods etc... > > When I did not maximized my windows and kept them in the center it was fine. Yes, afaik that problem was related with redrawing of some glamour lists and an infinite loop triggered by the old iceberg UI. Esteban > >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Aug. 24, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Cyril Ferlicot D.

Le 24/08/2018 Ã 19:03, Sean P. DeNigris a Ã©critÂ : > Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the > following: > <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> > > This seems to usually signal that a crash is not far away. It's doubly > concerning because there is no clear way to stop the troubled process > (interrupts often bring up a debugger on something else) and because, since > one is now unable to save any code, it's unclear how to start over easily in > a new image. In an extreme scenario, I recently panicked during such an > experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting > in an image that took hours worth of code (I know maybe not a great > practice) with it to the grave. > > Any idea why this happens or what we might be able to do anything about it? > > p.s. I was so concerned that I immediately resolved to move to Pharo 7, but > that turned out not to be an option do to the recently reported bug with > extension methods (that don't exactly match the package name) > > Hi, IIRC the problem only happens when the commit windows is maximize. Something happen, maybe the progress bar updating launch a redraw of the morph, and if the iceberg window is under the progress bar it also try to redraw it but for that it snapshots methods etc... When I did not maximized my windows and kept them in the center it was fine. > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr

Aug. 24, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Esteban Lorenzano

Hi, Please take into account that the iceberg version present on Pharo 6.1 is obsolete and most of the problems seen there should be solved in the version present on Pharo 7. You would ask why being an obsolete version we do not backport the good version for Pharo 6.1 and the answer is: Iceberg 1+ is a huge change and it may broke current P6.1 behaviour so we (I) decided not to do it. Instead, people using intensively iceberg are recommended to install themselves the correct version following the instructions here: https://github.com/pharo-vcs/iceberg#update-iceberg <https://github.com/pharo-vcs/iceberg#update-iceberg> <https://github.com/pharo-vcs/iceberg#update-iceberg> <https://github.com/pharo-vcs/iceberg#update-iceberg>Cheers, Esteban > On 24 Aug 2018, at 19:45, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I ve'seen this problem also but never been able to find a reproducible case. I've recall to see it even before Iceberg, so to me it looks like some Monticello issue. I always had the impression that Monticello it's trying to regenerate all the code definitions instead of the changes. Running exactly the same code snippet again usually worked for me. > > Anyways if someone had a reproducible case just let us know. > > On Fri, Aug 24, 2018 at 2:03 PM Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the > following: > <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>> > > This seems to usually signal that a crash is not far away. It's doubly > concerning because there is no clear way to stop the troubled process > (interrupts often bring up a debugger on something else) and because, since > one is now unable to save any code, it's unclear how to start over easily in > a new image. In an extreme scenario, I recently panicked during such an > experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting > in an image that took hours worth of code (I know maybe not a great > practice) with it to the grave. > > Any idea why this happens or what we might be able to do anything about it? > > p.s. I was so concerned that I immediately resolved to move to Pharo 7, but > that turned out not to be an option do to the recently reported bug with > extension methods (that don't exactly match the package name) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >

Aug. 24, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Gabriel Cotelli

I ve'seen this problem also but never been able to find a reproducible case. I've recall to see it even before Iceberg, so to me it looks like some Monticello issue. I always had the impression that Monticello it's trying to regenerate all the code definitions instead of the changes. Running exactly the same code snippet again usually worked for me. Anyways if someone had a reproducible case just let us know. On Fri, Aug 24, 2018 at 2:03 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the > following: > <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> > > This seems to usually signal that a crash is not far away. It's doubly > concerning because there is no clear way to stop the troubled process > (interrupts often bring up a debugger on something else) and because, since > one is now unable to save any code, it's unclear how to start over easily > in > a new image. In an extreme scenario, I recently panicked during such an > experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting > in an image that took hours worth of code (I know maybe not a great > practice) with it to the grave. > > Any idea why this happens or what we might be able to do anything about it? > > p.s. I was so concerned that I immediately resolved to move to Pharo 7, but > that turned out not to be an option do to the recently reported bug with > extension methods (that don't exactly match the package name) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Aug. 24, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Eliot Miranda

Hi Sean, On Fri, Aug 24, 2018 at 10:03 AM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the > following: > <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> > > This seems to usually signal that a crash is not far away. It's doubly > concerning because there is no clear way to stop the troubled process > (interrupts often bring up a debugger on something else) and because, since > one is now unable to save any code, it's unclear how to start over easily > in > a new image. In an extreme scenario, I recently panicked during such an > experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting > in an image that took hours worth of code (I know maybe not a great > practice) with it to the grave. > > Any idea why this happens or what we might be able to do anything about it? > No. Yes. Indirectly I hope to help debug this. I am nearly finished with an error handling facility in the VM for FFI calls that will fail an FFI callout primitive with an error code indicating the kind of exception and the pc. This should at least stop the system from crashing and give us an improved ability to make sense of the exception; at least we'll be able to examine the arguments to the call. More details as I roll out the facility. It will require integrating some support code, rewriting FFI callout signatures to include an error code, etc. p.s. I was so concerned that I immediately resolved to move to Pharo 7, but > that turned out not to be an option do to the recently reported bug with > extension methods (that don't exactly match the package name) > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html _,,,^..^,,,_ best, Eliot

Aug. 24, 2018

Sign of Impending Iceberg Doom on Pharo 6.1

by Sean P. DeNigris

Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave. Any idea why this happens or what we might be able to do anything about it? p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 24, 2018

Re: [Pharo-dev] Extension methods in p7

by Sean P. DeNigris

NorbertHartl wrote > https://github.com/pharo-project/pharo/pull/1685/files I'll try to review today. I tried to port a project to Pharo 7, but this bug made it unbearable. IMHO recategorizing methods is *not* the way to go. Let's just fix the bug! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 24, 2018

Re: [Pharo-dev] Startup Error in Recent Pharo 7

by Sean P. DeNigris

Update: It succeeded with a GH URL. The two scenarios that seemed to fail were: 1. a filetree URL 2. If I accidentally opened the same image twice via Launcher Still investigatingâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 23, 2018

Startup Error in Recent Pharo 7

by Sean P. DeNigris

Did something change in the last two or three days with Iceberg/Metcello/Monticello? I was loading a project successfully in a startup script via: Metacello new repository: 'filetree://', (repoFolder / 'src') fullName; baseline: 'DeNigrisPreferences'; onConflict: [ :ex | ex allow ]; load. That now fails with "IceCloneLocationAlreadyExists": IceGenericError: '~/Dynabook/Working Images/MM 23 1021/pharo-local/iceberg/seandenigris/Pharo-Preferences' exists and is not an empty directory. The crazy thing is that the directory does *not* exist! This only fails at startup. If I run manually after startup, the load succeeds. Ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 23, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Sean P. DeNigris

demarey wrote > I just published a new version of the launcher Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 23, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Christophe Demarey

Hi, I just published a new version of the launcher: 1.4 (http://pharo.org/download <http://pharo.org/download>) Improvements: Add Origin Template Column Simplify Timestamp Printing Bug fixes: #233 Cannot launch recent Pharo 7 images This version mainly solves the problem of launching recent Pharo 7.0 images. Once this version is downloaded, do not forget to delete the folders related to 70 vms in the Pharo/vms folder. This way, Pharo Launcher will download the latest one. By the way, it also comes with some UI improvements (contributed by Sean and Tim). I will work on a new version with a VM manager able to list locally available VMs, and a way to update or delete them. This new version will be based on Pharo 7 because Pharo Launcher development switched to github (https://github.com/pharo-project/pharo-launcher) and upcoming features are based on Pharo 7 (new UI, model refactoring). Cheers, Christophe > Le 22 aoÃ»t 2018 Ã 15:54, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > Hi Christophe, > > On Wed, 22 Aug 2018 at 15:33, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: >> >> Hi Alistair, >> >>> Le 22 aoÃ»t 2018 Ã 12:02, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : >>> >>> Hi Christophe, >>> >>> On Wed, 22 Aug 2018 at 09:36, Christophe Demarey >>> <christophe.demarey(a)inria.fr> wrote: >>>> >>>> ... >>>> >>>> As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. >>> >>> Part of the issue here is that Pharo 7 is still in development. My >>> understanding is that within the development cycle we assume that the >>> latest VM is being used (if I'm wrong, I'm sure someone will correct >>> me :-)). >>> >>> I don't use Pharo Launcher, so I'm not familiar with it, but it seems >>> to me that for the current development version (currently Pharo 7) the >>> launcher needs to ensure that it has the latest stable VM. >> >> Youâre right but the problem is that Pharo Launcher has no way to know what is the pharo version of an image before running it and evaluate a small expression. To achieve that, Pharo Launcher uses a VM that is, at least, compatible with the image format number. We do not have any guarantee that the expression evaluation of the VM will work fine for all images. For now, to detect the pharo version of Spur images, we use Pharo 61 VM. You can assume it will work well for 6. images. What if we use the 70 VM to determine pharo version of 6.* images? It will probably work better for Pharo 7 images (assuming we use the latest 70 VM) but then, no guarantee it will work for 61 images. >> >> The core of the problem is that we should not be forced to run an image to determine its pharo version. Nevertheless, I think it would be good to use the latest available VM for a given image format to determine its pharo version. It should work in most cases. > > Thanks very much for the explanation, it makes sense now. > > My understanding is that the Pharo 7 VM is backward compatible with > Pharo 6.1 (for now). Esteban's process is to release a new stable > Pharo 7 VM, and then a month later upgrade the Pharo 6.1 VM as well. > Of course, that will be superseded by the availability of > pharo.version. > > Thanks again, > Alistair

Aug. 23, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Alistair Grant

Hi Peter, On Wed, 22 Aug 2018 at 19:33, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > considering how important this is, shouldn't this become standard part of the VM? > e.g. > > ./pharo-x-vm --support pharo-y.image > > Which will return > * 1/yes/... if the VM can launch it > * 2/maybe/unclear... if the VM cannot determine it (this is futureproofing, e.g. if you tried to launch Pharo 9 image with Pharo 7 VM) > * 0/no/maxVersion/... returns the latest known VM version that was capable of launching the image (so VM will have a lookup table to check past image versions) > > or something along those lines... is there some scenario that wouldn't be covered by these three? The current scenario. As I understand it, the VM is compatible with the image format, it is just a bit old and is missing a new primitive (and since this is within the development cycle we're not trying to keep backward compatibility, if you're using the latest pharo 7 image you should be using the latest pharo 7 VM, the rules will change once pharo 7 is released). It would be useful to have a Pharo version embedded in the header of the image. That could then be queried and the latest VM for that version used to start the image. I think that would cover the majority of cases. Cheers, Alistair

Aug. 22, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Peter Uhnak

Hi, considering how important this is, shouldn't this become standard part of the VM? e.g. ./pharo-x-vm --support pharo-y.image Which will return * 1/yes/... if the VM can launch it * 2/maybe/unclear... if the VM cannot determine it (this is futureproofing, e.g. if you tried to launch Pharo 9 image with Pharo 7 VM) * 0/no/maxVersion/... returns the latest known VM version that was capable of launching the image (so VM will have a lookup table to check past image versions) or something along those lines... is there some scenario that wouldn't be covered by these three? Peter On Wed, Aug 22, 2018 at 4:34 PM Ben Coman <btc(a)openinworld.com> wrote: > On Wed, 22 Aug 2018 at 21:33, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: > > > > Hi Alistair, > > > > > Le 22 aoÃ»t 2018 Ã 12:02, Alistair Grant <akgrant0710(a)gmail.com> a > Ã©crit : > > > > > > Hi Christophe, > > > > > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > > > <christophe.demarey(a)inria.fr> wrote: > > >> > > >> ... > > >> > > >> As a workaround for now, we are thinking to ship the pharo.version > file along with the image to avoid to run images with compatible VMs that > we cannot ensure they work well with a given image. > > > > > > Part of the issue here is that Pharo 7 is still in development. My > > > understanding is that within the development cycle we assume that the > > > latest VM is being used (if I'm wrong, I'm sure someone will correct > > > me :-)). > > > > > > I don't use Pharo Launcher, so I'm not familiar with it, but it seems > > > to me that for the current development version (currently Pharo 7) the > > > launcher needs to ensure that it has the latest stable VM. > > > > Youâre right but the problem is that Pharo Launcher has no way to know > what is the pharo version of an image before running it and evaluate a > small expression. > > The VM version auto-evaluation is great, but it would be useful for > another column to explicitly show which VM version to use start an > image, which was also a drop-down list so the VM could be individually > select for each image. Entries could be "Default" (per existing > settings configuration), "Stable", "Latest" plus a list of names of > previously downloaded VMs. This would put people in the drivers seat > when the auto-evaluation misses a beat. > > cheers -ben > >

Aug. 22, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Ben Coman

On Wed, 22 Aug 2018 at 21:33, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Alistair, > > > Le 22 aoÃ»t 2018 Ã 12:02, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > > > Hi Christophe, > > > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > > <christophe.demarey(a)inria.fr> wrote: > >> > >> ... > >> > >> As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. > > > > Part of the issue here is that Pharo 7 is still in development. My > > understanding is that within the development cycle we assume that the > > latest VM is being used (if I'm wrong, I'm sure someone will correct > > me :-)). > > > > I don't use Pharo Launcher, so I'm not familiar with it, but it seems > > to me that for the current development version (currently Pharo 7) the > > launcher needs to ensure that it has the latest stable VM. > > Youâre right but the problem is that Pharo Launcher has no way to know what is the pharo version of an image before running it and evaluate a small expression. The VM version auto-evaluation is great, but it would be useful for another column to explicitly show which VM version to use start an image, which was also a drop-down list so the VM could be individually select for each image. Entries could be "Default" (per existing settings configuration), "Stable", "Latest" plus a list of names of previously downloaded VMs. This would put people in the drivers seat when the auto-evaluation misses a beat. cheers -ben

Aug. 22, 2018

Re: [Pharo-dev] Pharo and Docker (some steps)

by Ben Coman

On Mon, 20 Aug 2018 at 21:12, Torsten Bergmann <astares(a)gmx.de> wrote: > > For those interested in Docker: > > I recently played with Pharo and Docker and summarized some of my steps in a small tutorial > in my Pharo wiki: > > http://wiki.astares.com/pharo/613 > > There is also a page following Mike Filonovs suggestions on the Pharo docker file: > > http://wiki.astares.com/pharo/615 > > Maybe this is useful for others too. I see docker mentioned around a lot, but I'm not familiar with it, so its nice to see a concrete example in a domain I'm familiar with. Thanks for posting. cheers -ben

Aug. 22, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Alistair Grant

Hi Christophe, On Wed, 22 Aug 2018 at 15:33, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Alistair, > > > Le 22 aoÃ»t 2018 Ã 12:02, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > > > Hi Christophe, > > > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > > <christophe.demarey(a)inria.fr> wrote: > >> > >> ... > >> > >> As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. > > > > Part of the issue here is that Pharo 7 is still in development. My > > understanding is that within the development cycle we assume that the > > latest VM is being used (if I'm wrong, I'm sure someone will correct > > me :-)). > > > > I don't use Pharo Launcher, so I'm not familiar with it, but it seems > > to me that for the current development version (currently Pharo 7) the > > launcher needs to ensure that it has the latest stable VM. > > Youâre right but the problem is that Pharo Launcher has no way to know what is the pharo version of an image before running it and evaluate a small expression. To achieve that, Pharo Launcher uses a VM that is, at least, compatible with the image format number. We do not have any guarantee that the expression evaluation of the VM will work fine for all images. For now, to detect the pharo version of Spur images, we use Pharo 61 VM. You can assume it will work well for 6. images. What if we use the 70 VM to determine pharo version of 6.* images? It will probably work better for Pharo 7 images (assuming we use the latest 70 VM) but then, no guarantee it will work for 61 images. > > The core of the problem is that we should not be forced to run an image to determine its pharo version. Nevertheless, I think it would be good to use the latest available VM for a given image format to determine its pharo version. It should work in most cases. Thanks very much for the explanation, it makes sense now. My understanding is that the Pharo 7 VM is backward compatible with Pharo 6.1 (for now). Esteban's process is to release a new stable Pharo 7 VM, and then a month later upgrade the Pharo 6.1 VM as well. Of course, that will be superseded by the availability of pharo.version. Thanks again, Alistair

Aug. 22, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Christophe Demarey

Hi Alistair, > Le 22 aoÃ»t 2018 Ã 12:02, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > Hi Christophe, > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: >> >> ... >> >> As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. > > Part of the issue here is that Pharo 7 is still in development. My > understanding is that within the development cycle we assume that the > latest VM is being used (if I'm wrong, I'm sure someone will correct > me :-)). > > I don't use Pharo Launcher, so I'm not familiar with it, but it seems > to me that for the current development version (currently Pharo 7) the > launcher needs to ensure that it has the latest stable VM. Youâre right but the problem is that Pharo Launcher has no way to know what is the pharo version of an image before running it and evaluate a small expression. To achieve that, Pharo Launcher uses a VM that is, at least, compatible with the image format number. We do not have any guarantee that the expression evaluation of the VM will work fine for all images. For now, to detect the pharo version of Spur images, we use Pharo 61 VM. You can assume it will work well for 6. images. What if we use the 70 VM to determine pharo version of 6.* images? It will probably work better for Pharo 7 images (assuming we use the latest 70 VM) but then, no guarantee it will work for 61 images. The core of the problem is that we should not be forced to run an image to determine its pharo version. Nevertheless, I think it would be good to use the latest available VM for a given image format to determine its pharo version. It should work in most cases. Cheers, Christophe

Aug. 22, 2018

[Pharo 7.0-dev] Build #1192: Implement ZnNewLineWriterStream >> #flush

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1192 was: SUCCESS. The Pull Request #1709 was integrated: "Implement ZnNewLineWriterStream >> #flush" Pull request url: https://github.com/pharo-project/pharo/pull/1709 Issue Url: https://pharo.fogbugz.com/f/cases/22353 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 22, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Alistair Grant

Hi Christophe, On Wed, 22 Aug 2018 at 09:36, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > ... > > As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. Part of the issue here is that Pharo 7 is still in development. My understanding is that within the development cycle we assume that the latest VM is being used (if I'm wrong, I'm sure someone will correct me :-)). I don't use Pharo Launcher, so I'm not familiar with it, but it seems to me that for the current development version (currently Pharo 7) the launcher needs to ensure that it has the latest stable VM. Cheers, Alistair

Aug. 22, 2018

[Pharo 7.0-dev] Build #1191: 22360-add-pharo-version-next-to-the-image-file

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1191 was: SUCCESS. The Pull Request #1714 was integrated: "22360-add-pharo-version-next-to-the-image-file" Pull request url: https://github.com/pharo-project/pharo/pull/1714 Issue Url: https://pharo.fogbugz.com/f/cases/22360 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 22, 2018