September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Denis Kudriashov

2017-09-15 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Fri, Sep 15, 2017 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-09-15 11:31 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Actually, in latest bootstrapped images, images are shipped with sources >>> instead of changes. So, as before you had a changes file per image, now you >>> have a sources file per image. So there is no really an extra overhead... >>> >> >> Cool. But changes mechanism is still in image? At what point changes are >> created? >> > > Yes, as soon as you start coding, new code will go to the changes file as > usual. > > >> >> And did we plan to remove old changes in Pharo 7? ( Epices is working >> fine now) >> > > Epicea is good for logs, but the changes file also stores versions and > source code. As soon as we don't have a new solution to store method's > source code, the changes file will be there. > Ah, right. I should know it :) > > >> >> >>> >>> On Thu, Sep 14, 2017 at 8:57 PM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2017-09-14 15:10 GMT+02:00 stephan <stephan(a)stack.nl>: >>>> >>>>> On 14-09-17 14:52, Peter UhnÃ¡k wrote: >>>>> >>>>>> That's not related to Pharo Launcher. Pharo 7 sources (for alpha >>>>>> images) are now shipped with the image, not the VM. >>>>>> >>>>> >>>>> That's an issue. I have hundreds of images, and definitely don't need >>>>> so many different sources. >>>> >>>> >>>> You can share sources for as many images as you want as soon these >>>> images are based on the same bootstrapped image build. >>>> >>>> -- Pavel >>>> >>>> >>>> >>>>> >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> 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 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > 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 <+33%206%2052%2070%2066%2013> >

Sept. 15, 2017

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Pavel Krivanek

2017-09-15 13:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-09-15 11:31 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Actually, in latest bootstrapped images, images are shipped with sources >> instead of changes. So, as before you had a changes file per image, now you >> have a sources file per image. So there is no really an extra overhead... >> > > Cool. But changes mechanism is still in image? At what point changes are > created? > > And did we plan to remove old changes in Pharo 7? ( Epices is working fine > now) > when the image is is bootstrapped, it does have no sources nor changes file. But as soon as you start to load packages into it using compiler, all loaded sources are placed in the changes file. When everything is loaded, we condense changes to the sources file so you have all sources in the changes file and empty sources ready for changes done by the image user. -- Pavel >> On Thu, Sep 14, 2017 at 8:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> >>> >>> 2017-09-14 15:10 GMT+02:00 stephan <stephan(a)stack.nl>: >>> >>>> On 14-09-17 14:52, Peter UhnÃ¡k wrote: >>>> >>>>> That's not related to Pharo Launcher. Pharo 7 sources (for alpha >>>>> images) are now shipped with the image, not the VM. >>>>> >>>> >>>> That's an issue. I have hundreds of images, and definitely don't need >>>> so many different sources. >>> >>> >>> You can share sources for as many images as you want as soon these >>> images are based on the same bootstrapped image build. >>> >>> -- Pavel >>> >>> >>> >>>> >>>> >>>> Stephan >>>> >>>> >>>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> 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 <+33%206%2052%2070%2066%2013> >> > >

Sept. 15, 2017

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Guillermo Polito

On Fri, Sep 15, 2017 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-09-15 11:31 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Actually, in latest bootstrapped images, images are shipped with sources >> instead of changes. So, as before you had a changes file per image, now you >> have a sources file per image. So there is no really an extra overhead... >> > > Cool. But changes mechanism is still in image? At what point changes are > created? > Yes, as soon as you start coding, new code will go to the changes file as usual. > > And did we plan to remove old changes in Pharo 7? ( Epices is working fine > now) > Epicea is good for logs, but the changes file also stores versions and source code. As soon as we don't have a new solution to store method's source code, the changes file will be there. > > >> >> On Thu, Sep 14, 2017 at 8:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> >>> >>> 2017-09-14 15:10 GMT+02:00 stephan <stephan(a)stack.nl>: >>> >>>> On 14-09-17 14:52, Peter UhnÃ¡k wrote: >>>> >>>>> That's not related to Pharo Launcher. Pharo 7 sources (for alpha >>>>> images) are now shipped with the image, not the VM. >>>>> >>>> >>>> That's an issue. I have hundreds of images, and definitely don't need >>>> so many different sources. >>> >>> >>> You can share sources for as many images as you want as soon these >>> images are based on the same bootstrapped image build. >>> >>> -- Pavel >>> >>> >>> >>>> >>>> >>>> Stephan >>>> >>>> >>>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> 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 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer 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

Sept. 15, 2017

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Denis Kudriashov

2017-09-15 11:31 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Actually, in latest bootstrapped images, images are shipped with sources > instead of changes. So, as before you had a changes file per image, now you > have a sources file per image. So there is no really an extra overhead... > Cool. But changes mechanism is still in image? At what point changes are created? And did we plan to remove old changes in Pharo 7? ( Epices is working fine now) > > On Thu, Sep 14, 2017 at 8:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> >> >> 2017-09-14 15:10 GMT+02:00 stephan <stephan(a)stack.nl>: >> >>> On 14-09-17 14:52, Peter UhnÃ¡k wrote: >>> >>>> That's not related to Pharo Launcher. Pharo 7 sources (for alpha >>>> images) are now shipped with the image, not the VM. >>>> >>> >>> That's an issue. I have hundreds of images, and definitely don't need so >>> many different sources. >> >> >> You can share sources for as many images as you want as soon these images >> are based on the same bootstrapped image build. >> >> -- Pavel >> >> >> >>> >>> >>> Stephan >>> >>> >>> >> > > > -- > > > > Guille Polito > > > Research Engineer > > 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 <+33%206%2052%2070%2066%2013> >

Sept. 15, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Tim Mackinnon

Me too - I have started heavily caching things on Gitlab and Dropbox. Iâm surprised they canât find an issue - something seems wrong. Tim > On 15 Sep 2017, at 10:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > Also this applies not just to files.pharo.org <http://files.pharo.org/>, but also to Inria Jenkins (I just had a build timeout after 10 minutes by trying to download Moose image ). > > So in the meantime there's no workaround for this? > > Peter > > On Fri, Sep 15, 2017 at 11:38 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Sadly not. > > The admins can not find a reason for why it is slow. > > I think we should evaluate to use S3 instead again. > >> On 15 Sep 2017, at 11:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> Has there been any progress on this? >> >> Thanks, >> Peter >> >> On Thu, Aug 31, 2017 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> > On 31 Aug 2017, at 16:56, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> > >> > Peter UhnÃ¡k wrote >> >> over the past week+ downloading the latest Pharo 6 version has been >> >> extremely slow -- 5+ minutes to download the zip. >> > >> > I don't know if this is related, but Launcher just took several minutes to >> > "Fetch source files for Pharo 6.0" when I tried to launch an imageâ¦ >> > >> > >> >> I know have opened a ticket to see if the admins know of any Inria related networking >> issues. >> >> Marcus >> > >

Sept. 15, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Peter UhnÃ¡k

Also this applies not just to files.pharo.org, but also to Inria Jenkins (I just had a build timeout after 10 minutes by trying to download Moose image ). So in the meantime there's no workaround for this? Peter On Fri, Sep 15, 2017 at 11:38 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Sadly not. > > The admins can not find a reason for why it is slow. > > I think we should evaluate to use S3 instead again. > > On 15 Sep 2017, at 11:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Has there been any progress on this? > > Thanks, > Peter > > On Thu, Aug 31, 2017 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> > On 31 Aug 2017, at 16:56, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> > >> > Peter UhnÃ¡k wrote >> >> over the past week+ downloading the latest Pharo 6 version has been >> >> extremely slow -- 5+ minutes to download the zip. >> > >> > I don't know if this is related, but Launcher just took several minutes >> to >> > "Fetch source files for Pharo 6.0" when I tried to launch an imageâ¦ >> > >> > >> >> I know have opened a ticket to see if the admins know of any Inria >> related networking >> issues. >> >> Marcus >> > > >

Sept. 15, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Marcus Denker

Sadly not. The admins can not find a reason for why it is slow. I think we should evaluate to use S3 instead again. > On 15 Sep 2017, at 11:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Has there been any progress on this? > > Thanks, > Peter > > On Thu, Aug 31, 2017 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On 31 Aug 2017, at 16:56, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > > Peter UhnÃ¡k wrote > >> over the past week+ downloading the latest Pharo 6 version has been > >> extremely slow -- 5+ minutes to download the zip. > > > > I don't know if this is related, but Launcher just took several minutes to > > "Fetch source files for Pharo 6.0" when I tried to launch an imageâ¦ > > > > > > I know have opened a ticket to see if the admins know of any Inria related networking > issues. > > Marcus >

Sept. 15, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Peter UhnÃ¡k

Has there been any progress on this? Thanks, Peter On Thu, Aug 31, 2017 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 31 Aug 2017, at 16:56, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > Peter UhnÃ¡k wrote > >> over the past week+ downloading the latest Pharo 6 version has been > >> extremely slow -- 5+ minutes to download the zip. > > > > I don't know if this is related, but Launcher just took several minutes > to > > "Fetch source files for Pharo 6.0" when I tried to launch an imageâ¦ > > > > > > I know have opened a ticket to see if the admins know of any Inria related > networking > issues. > > Marcus >

Sept. 15, 2017

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Guillermo Polito

Actually, in latest bootstrapped images, images are shipped with sources instead of changes. So, as before you had a changes file per image, now you have a sources file per image. So there is no really an extra overhead... On Thu, Sep 14, 2017 at 8:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-09-14 15:10 GMT+02:00 stephan <stephan(a)stack.nl>: > >> On 14-09-17 14:52, Peter UhnÃ¡k wrote: >> >>> That's not related to Pharo Launcher. Pharo 7 sources (for alpha images) >>> are now shipped with the image, not the VM. >>> >> >> That's an issue. I have hundreds of images, and definitely don't need so >> many different sources. > > > You can share sources for as many images as you want as soon these images > are based on the same bootstrapped image build. > > -- Pavel > > > >> >> >> Stephan >> >> >> > -- Guille Polito Research Engineer 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

Sept. 15, 2017

Re: [Pharo-dev] Are assignment to block variables is prohibited?

by Marcus Denker

> On 14 Sep 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-09-14 21:43 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > Yes. But there is a setting for the compiler to load/compile code with errors. > > > 2017-09-14 20:46 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > Hi > > I know that method arg are read only and you cannot assign to them. > Now what is the status of block arguments? > Because some old code of plotmorph is breaking. > > Stef > > > > But using catalog, I can load plotmorph, even without enabling this setting. OCStoreIntoReadOnlyVariableError checks if you are compiling interactively or not. signal compilationContext interactive ifFalse: [ ^ self crTrace ]. ^ super signal This way old code load fine, but you are not allowed to create such code while codingâ¦ and you have to fix code when recompiling a method interactively that has an assignment to an argument. Marcus

Sept. 15, 2017