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

Strange deprecation of SystemVersion

by Stephane Ducasse

Hi I do not really understand why fromShortVErsionString: and friends have been deprecated (that part I can understand) but why do they depend on an extension packaged in tests. Stef

March 30, 2018

[Pharo 7.0-dev] Build #742: 21653-ShiftClassInstaller-gives-error-when-changing-superclass-to-new-one-with-variables

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

There is a new Pharo build available! The status of the build #742 was: SUCCESS. The Pull Request #1163 was integrated: "21653-ShiftClassInstaller-gives-error-when-changing-superclass-to-new-one-with-variables" Pull request url: https://github.com/pharo-project/pharo/pull/1163 Issue Url: https://pharo.fogbugz.com/f/cases/21653 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 30, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

Thanks, Guille! I can confirm that my load once again initializes properly. -Martin On 03/29/2018 12:48 AM, Guillermo Polito wrote: > PR:Â https://github.com/pharo-project/pharo/pull/1161 > > I added a test to avoid this problem in the future. > > Guille >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Denis Kudriashov

Hi Nicolas 2018-03-29 17:44 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > There are two different questions: > - expressiveness > - efficiency > > Real efficiency of transfer (without any intermediate copy) is only > guaranteed in very rare cases > (if the target collection of write stream is same species as source > collection of read stream, and there are no transform in any of the > intermediate wrapper streams, then a direct bulk transfer of the form > targetCollection replaceFrom:to:with: sourceCollection startingAt: is > possible) > I'm not at all convinced that we should focus too much on such > optimization. > > The fact that we have at least two choices, let the readStream drive the > operation, or let the writeStream do it, is a smell. > It sounds like we could provide the two: > aReadStream writeContentsTo: aWriteStream. > aWriteStream readContentsFrom: aReadStream. > ... and then let the programmer decide (maybe there is a more optimal > path). > ... or provide a way to negotiate the transfer (size of chunked buffers, > etc...) > I like this idea. > > Unless there is a more symetrical solution. > It's a long time since I did not check Xtreams, but wasn't there a reified > Buffer that could/would be the effective actor of such transfer? > Xtreams provides nice API to "pipe" multiple streams. But as I remember the Buffer was internal detail hidden from your. Idea was to reuse internal stream arrays to minimize garbage (or something like this). > > > Nicolas > > > 2018-03-29 15:02 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> >>> >>> > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > >>> > >>> > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> > ZnUtils class>>#streamFrom:to: ? >>> > >>> > Yes, it gives feature which I want. But it's too Java style. >>> > What you think to move it to stream itself? And with what message name? >>> >>> This was written in a specific context, to be efficient. I don't know if >>> it is general enough for broad use. Yes it could be more OO to not make it >>> a utility method, but on the other hand, where would you put it ? >> >> >> In read streams we already have: >> >> >> readInto: aCollection startingAt: startIndex count: n >> >> >> So I would put new method in ReadStream (#readIntoStream: ?). >> >> >>> I am hesitant to make the Stream API bigger ;-) >>> >> >> We already have this method in Utils class. So it is here but in strange >> hidden place. >> >> >>> > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > > >>> > > Hi. >>> > > >>> > > Do we have simple method to write data between streams? >>> > > >>> > > I want something like: >>> > > >>> > > writeStream nextPutAllFrom: readStream >>> > > >>> > > I always used loop for this. But maybe we have something suitable. >>> Otherwise lets introduce it. >>> > > >>> > > Best regards, >>> > > Denis >>> > >>> > >>> > >>> >>> >>> >> >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Sven Van Caekenberghe

> On 29 Mar 2018, at 15:02, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > > > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > ZnUtils class>>#streamFrom:to: ? > > > > Yes, it gives feature which I want. But it's too Java style. > > What you think to move it to stream itself? And with what message name? > > This was written in a specific context, to be efficient. I don't know if it is general enough for broad use. Yes it could be more OO to not make it a utility method, but on the other hand, where would you put it ? > > In read streams we already have: > > readInto: aCollection startingAt: startIndex count: n > > So I would put new method in ReadStream (#readIntoStream: ?). > > I am hesitant to make the Stream API bigger ;-) > > We already have this method in Utils class. So it is here but in strange hidden place. Not all streams inherit from ReadStream, far from it. So if you add it there, you add it to 'the stream API' that every other stream-like class has to implement. Hence it is a burden, for limited gain. I also do not specifically like Util classes, but this is a more special case. The operation belongs to both parties involved. You could define a StreamCopier to do the job. The way it is implemented now, it does not extend the stream API, that is worth something too. Anyway, we are just discussing ideas. > > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > > > Hi. > > > > > > Do we have simple method to write data between streams? > > > > > > I want something like: > > > > > > writeStream nextPutAllFrom: readStream > > > > > > I always used loop for this. But maybe we have something suitable. Otherwise lets introduce it. > > > > > > Best regards, > > > Denis > > > > > >

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Stephane Ducasse

Thanks a lot Guille. I love you attitude and your systematic tests On Thu, Mar 29, 2018 at 10:10 AM, Max Leske <maxleske(a)gmail.com> wrote: > Great! Thanks Guille! > > > > On 29 March 2018 at 09:49:37, Guillermo Polito (guillermopolito(a)gmail.com) > wrote: > > PR: https://github.com/pharo-project/pharo/pull/1161 > > I added a test to avoid this problem in the future. > > Guille > > On Thu, Mar 29, 2018 at 9:36 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Issue: https://pharo.manuscript.com/f/cases/21658/Monticello >> -initializers-are-not-enabled-by-default >> >> On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> I'm checking it. >>> >>> It may be a side effect of: https://github.com/pharo-proje >>> ct/pharo/pull/1130 >>> >>> Short story long: >>> - building Pharo we need to ensure that class initializations are >>> executed in a particular order, so some metacello configurations are >>> disabling monticello initializers during baselines >>> - I introduced/refactored a couple of new baselines because I'm playing >>> with creating smaller images. >>> - I discovered (and tried to patch probably not entirely right) a >>> bug that makes baseline postloads being executed more than once >>> - but all tests were green :D >>> >>> So I'll introduce a new test to verify that monticello initializers are >>> enabled by default and check what the problem is. >>> Keep you updated. >>> >>> >>> On Thu, Mar 29, 2018 at 9:18 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> I can confirm that class side #initialization is broken. Don't know >>>> since when though. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> >>>> On 29 March 2018 at 08:28:00, Martin McClure (martin(a)hand2mouse.com) >>>> wrote: >>>> >>>> Good to know. In my case, however, I'm always loading code into a fresh >>>> image where these classes don't previously exist, so I would think that >>>> #initialize would always be sent. >>>> >>>> >>>> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote: >>>> > class side #initialize is only send by MC if the incoming source code >>>> is different, has changed. I always add a date in a comment to be sure. >>>> > >>>> >> On 29 Mar 2018, at 04:47, Martin McClure <martin(a)hand2mouse.com> >>>> wrote: >>>> >> >>>> >> On 03/28/2018 04:35 PM, Martin McClure wrote: >>>> >>> I have a project that loads via Metacello in builds up through build >>>> >>> 738. In 739 the load fails with DNU. >>>> >>> >>>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It >>>> >>> fails because it sends a message to a pool variable, which is nil. >>>> >>> However, it should not be nil because it should have been >>>> initialized by >>>> >>> a class-side #initialize method in a prerequisite package. >>>> >>> >>>> >>> Again, this worked up through build 738. Any idea what changed in >>>> 739 >>>> >>> that would cause this, and is this change intentional? >>>> >> Odd, I don't see any code changes that would be likely to have >>>> caused this. >>>> >> >>>> >> Is the expected behavior of Metacello to send #initialize to classes >>>> in >>>> >> prerequisite packages before running a #postLoadDoIt in a package? >>>> I'd >>>> >> think so, but am starting to wonder if this is perhaps unordered and >>>> >> I've just been lucky... >>>> >> >>>> >> -Martin >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> 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 <+33%206%2052%2070%2066%2013> >>> >> >> >> >> -- >> >> >> >> 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 <+33%206%2052%2070%2066%2013> >> > > > > -- > > > > 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 <+33%206%2052%2070%2066%2013> > >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Stephane Ducasse

Hi nicolas I like your proposal. Stef On Thu, Mar 29, 2018 at 5:44 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > There are two different questions: > - expressiveness > - efficiency > > Real efficiency of transfer (without any intermediate copy) is only > guaranteed in very rare cases > (if the target collection of write stream is same species as source > collection of read stream, and there are no transform in any of the > intermediate wrapper streams, then a direct bulk transfer of the form > targetCollection replaceFrom:to:with: sourceCollection startingAt: is > possible) > I'm not at all convinced that we should focus too much on such optimization. > > The fact that we have at least two choices, let the readStream drive the > operation, or let the writeStream do it, is a smell. > It sounds like we could provide the two: > aReadStream writeContentsTo: aWriteStream. > aWriteStream readContentsFrom: aReadStream. > ... and then let the programmer decide (maybe there is a more optimal path). > ... or provide a way to negotiate the transfer (size of chunked buffers, > etc...) > > Unless there is a more symetrical solution. > It's a long time since I did not check Xtreams, but wasn't there a reified > Buffer that could/would be the effective actor of such transfer? > > Nicolas > > > 2018-03-29 15:02 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>> >>> > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> >>> > wrote: >>> > >>> > >>> > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> > ZnUtils class>>#streamFrom:to: ? >>> > >>> > Yes, it gives feature which I want. But it's too Java style. >>> > What you think to move it to stream itself? And with what message name? >>> >>> This was written in a specific context, to be efficient. I don't know if >>> it is general enough for broad use. Yes it could be more OO to not make it a >>> utility method, but on the other hand, where would you put it ? >> >> >> In read streams we already have: >> >> >> readInto: aCollection startingAt: startIndex count: n >> >> >> So I would put new method in ReadStream (#readIntoStream: ?). >> >>> >>> I am hesitant to make the Stream API bigger ;-) >> >> >> We already have this method in Utils class. So it is here but in strange >> hidden place. >> >>> >>> > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> >>> > > wrote: >>> > > >>> > > Hi. >>> > > >>> > > Do we have simple method to write data between streams? >>> > > >>> > > I want something like: >>> > > >>> > > writeStream nextPutAllFrom: readStream >>> > > >>> > > I always used loop for this. But maybe we have something suitable. >>> > > Otherwise lets introduce it. >>> > > >>> > > Best regards, >>> > > Denis >>> > >>> > >>> > >>> >>> >> >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Stephane Ducasse

I agree we should not have Utils class. On Thu, Mar 29, 2018 at 3:02 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >> > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > >> > >> > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > ZnUtils class>>#streamFrom:to: ? >> > >> > Yes, it gives feature which I want. But it's too Java style. >> > What you think to move it to stream itself? And with what message name? >> >> This was written in a specific context, to be efficient. I don't know if >> it is general enough for broad use. Yes it could be more OO to not make it a >> utility method, but on the other hand, where would you put it ? > > > In read streams we already have: > > > readInto: aCollection startingAt: startIndex count: n > > > So I would put new method in ReadStream (#readIntoStream: ?). > >> >> I am hesitant to make the Stream API bigger ;-) > > > We already have this method in Utils class. So it is here but in strange > hidden place. > >> >> > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> >> > > wrote: >> > > >> > > Hi. >> > > >> > > Do we have simple method to write data between streams? >> > > >> > > I want something like: >> > > >> > > writeStream nextPutAllFrom: readStream >> > > >> > > I always used loop for this. But maybe we have something suitable. >> > > Otherwise lets introduce it. >> > > >> > > Best regards, >> > > Denis >> > >> > >> > >> >> >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Nicolas Cellier

There are two different questions: - expressiveness - efficiency Real efficiency of transfer (without any intermediate copy) is only guaranteed in very rare cases (if the target collection of write stream is same species as source collection of read stream, and there are no transform in any of the intermediate wrapper streams, then a direct bulk transfer of the form targetCollection replaceFrom:to:with: sourceCollection startingAt: is possible) I'm not at all convinced that we should focus too much on such optimization. The fact that we have at least two choices, let the readStream drive the operation, or let the writeStream do it, is a smell. It sounds like we could provide the two: aReadStream writeContentsTo: aWriteStream. aWriteStream readContentsFrom: aReadStream. ... and then let the programmer decide (maybe there is a more optimal path). ... or provide a way to negotiate the transfer (size of chunked buffers, etc...) Unless there is a more symetrical solution. It's a long time since I did not check Xtreams, but wasn't there a reified Buffer that could/would be the effective actor of such transfer? Nicolas 2018-03-29 15:02 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> >> > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > >> > >> > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > ZnUtils class>>#streamFrom:to: ? >> > >> > Yes, it gives feature which I want. But it's too Java style. >> > What you think to move it to stream itself? And with what message name? >> >> This was written in a specific context, to be efficient. I don't know if >> it is general enough for broad use. Yes it could be more OO to not make it >> a utility method, but on the other hand, where would you put it ? > > > In read streams we already have: > > > readInto: aCollection startingAt: startIndex count: n > > > So I would put new method in ReadStream (#readIntoStream: ?). > > >> I am hesitant to make the Stream API bigger ;-) >> > > We already have this method in Utils class. So it is here but in strange > hidden place. > > >> > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > > >> > > Hi. >> > > >> > > Do we have simple method to write data between streams? >> > > >> > > I want something like: >> > > >> > > writeStream nextPutAllFrom: readStream >> > > >> > > I always used loop for this. But maybe we have something suitable. >> Otherwise lets introduce it. >> > > >> > > Best regards, >> > > Denis >> > >> > >> > >> >> >> >

March 29, 2018

[Pharo 7.0-dev] Build #741: 21621 improvements to tree scrolling

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

There is a new Pharo build available! The status of the build #741 was: SUCCESS. The Pull Request #1133 was integrated: "21621 improvements to tree scrolling" Pull request url: https://github.com/pharo-project/pharo/pull/1133 Issue Url: https://pharo.fogbugz.com/f/cases/21621 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 29, 2018