- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #753: 21638-Implementing-FT2Plugin-with-FFI-calls-in-the-image-side

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

There is a new Pharo build available! The status of the build #753 was: SUCCESS. The Pull Request #1142 was integrated: "21638-Implementing-FT2Plugin-with-FFI-calls-in-the-image-side" Pull request url: https://github.com/pharo-project/pharo/pull/1142 Issue Url: https://pharo.fogbugz.com/f/cases/21638 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Alistair Grant

Hi Nicolas, On 4 April 2018 at 12:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2018-04-04 12:18 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Hi Sven, >> >> On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: >> > Somehow, somewhere there was a change to the implementation of the >> > primitive called by some streams' #atEnd. >> >> That's a proposed change by me, but it hasn't been integrated yet. So >> the discussion below should apply to the current stable vm (from August >> last year). >> >> >> > IIRC, someone said it is implemented as 'remaining size being zero' >> > and some virtual unix files like /dev/random are zero sized. >> >> Currently, for files other than sdio (stdout, stderr, stdin) it is >> effectively defined as: >> >> atEnd := stream position >= stream size >> >> >> And, as you say, plenty of virtual unix files report size 0. >> >> >> >> > Now, all kinds of changes are being done image size to work around this. >> >> I would phrase this slightly differently :-) >> >> Some code does the right thing, while other code doesn't. E.g.: >> >> MultiByteFileStream>>upToEnd is good, while >> FileStream>>contents is incorrect >> >> >> > I am a strong believer in simple, real (i.e. infinite) streams, but I >> > am not sure we are doing the right thing here. >> > >> > Point is, I am not sure #next returning nil is official and universal. >> > >> > Consider the comments: >> > >> > Stream>>#next >> > "Answer the next object accessible by the receiver." >> > >> > ReadStream>>#next >> > "Primitive. Answer the next object in the Stream represented by the >> > receiver. Fail if the collection of this stream is not an Array or a >> > String. >> > Fail if the stream is positioned at its end, or if the position is out >> > of >> > bounds in the collection. Optional. See Object documentation >> > whatIsAPrimitive." >> > >> > Note how there is no talk about returning nil ! >> > >> > I think we should discuss about this first. >> > >> > Was the low level change really correct and the right thing to do ? >> >> The primitive change proposed doesn't affect this discussion. It will >> mean that #atEnd returns false (correctly) sometimes, while currently it >> returns true (incorrectly). The end result is still incorrect, e.g. >> #contents returns an empty string for /proc/cpuinfo. >> >> You're correct about no mention of nil, but we have: >> >> FileStream>>next >> >> (position >= readLimit and: [self atEnd]) >> ifTrue: [^nil] >> ifFalse: [^collection at: (position := position + 1)] >> >> >> which has been around for a long time (I suspect, before Pharo existed). >> >> Having said that, I think that raising an exception is a better >> solution, but it is a much, much bigger change than the one I proposed >> in https://github.com/pharo-project/pharo/pull/1180. >> >> >> Cheers, >> Alistair >> > > Hi, > yes, if you are after universal behavior englobing Unix streams, the > Exception might be the best way. > Because on special stream you can't allways say in advance, you have to try. > That's the solution adopted by authors of Xtreams. > But there is a runtime penalty associated to it. > > The penalty once was so high that my proposal to generalize EndOfStream > usage was rejected a few years ago by AndreaRaab. > http://forum.world.st/EndOfStream-unused-td68806.html Thanks for this, I'll definitely take a look. Do you have a sense of how Denis' suggestion of using an EndOfStream object would compare? It would keep the same coding style, but avoid the problems with nil. Thanks, Alistair > I have regularly benched Xtreams, but stopped a few years ago. > Maybe i can excavate and pass on newer VM. > > In the mean time, i had experimented a programmable end of stream behavior > (via a block, or any other valuable) > http://www.squeaksource.com/XTream.htm > so as to reconcile performance and universality, but it was a source of > complexification at implementation side. > > Nicolas > >> >> >> > Note also that a Guille introduced something new, #closed which is >> > related to the difference between having no more elements (maybe right now, >> > like an open network stream) and never ever being able to produce more data. >> > >> > Sven >> > >> > >> > >> >

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Nicolas Cellier

2018-04-04 12:18 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Sven, > > On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: > > Somehow, somewhere there was a change to the implementation of the > > primitive called by some streams' #atEnd. > > That's a proposed change by me, but it hasn't been integrated yet. So > the discussion below should apply to the current stable vm (from August > last year). > > > > IIRC, someone said it is implemented as 'remaining size being zero' > > and some virtual unix files like /dev/random are zero sized. > > Currently, for files other than sdio (stdout, stderr, stdin) it is > effectively defined as: > > atEnd := stream position >= stream size > > > And, as you say, plenty of virtual unix files report size 0. > > > > > Now, all kinds of changes are being done image size to work around this. > > I would phrase this slightly differently :-) > > Some code does the right thing, while other code doesn't. E.g.: > > MultiByteFileStream>>upToEnd is good, while > FileStream>>contents is incorrect > > > > I am a strong believer in simple, real (i.e. infinite) streams, but I > > am not sure we are doing the right thing here. > > > > Point is, I am not sure #next returning nil is official and universal. > > > > Consider the comments: > > > > Stream>>#next > > "Answer the next object accessible by the receiver." > > > > ReadStream>>#next > > "Primitive. Answer the next object in the Stream represented by the > > receiver. Fail if the collection of this stream is not an Array or a > String. > > Fail if the stream is positioned at its end, or if the position is out > of > > bounds in the collection. Optional. See Object documentation > > whatIsAPrimitive." > > > > Note how there is no talk about returning nil ! > > > > I think we should discuss about this first. > > > > Was the low level change really correct and the right thing to do ? > > The primitive change proposed doesn't affect this discussion. It will > mean that #atEnd returns false (correctly) sometimes, while currently it > returns true (incorrectly). The end result is still incorrect, e.g. > #contents returns an empty string for /proc/cpuinfo. > > You're correct about no mention of nil, but we have: > > FileStream>>next > > (position >= readLimit and: [self atEnd]) > ifTrue: [^nil] > ifFalse: [^collection at: (position := position + 1)] > > > which has been around for a long time (I suspect, before Pharo existed). > > Having said that, I think that raising an exception is a better > solution, but it is a much, much bigger change than the one I proposed > in https://github.com/pharo-project/pharo/pull/1180. > > > Cheers, > Alistair > > Hi, yes, if you are after universal behavior englobing Unix streams, the Exception might be the best way. Because on special stream you can't allways say in advance, you have to try. That's the solution adopted by authors of Xtreams. But there is a runtime penalty associated to it. The penalty once was so high that my proposal to generalize EndOfStream usage was rejected a few years ago by AndreaRaab. http://forum.world.st/EndOfStream-unused-td68806.html I have regularly benched Xtreams, but stopped a few years ago. Maybe i can excavate and pass on newer VM. In the mean time, i had experimented a programmable end of stream behavior (via a block, or any other valuable) http://www.squeaksource.com/XTream.htm so as to reconcile performance and universality, but it was a source of complexification at implementation side. Nicolas > > > Note also that a Guille introduced something new, #closed which is > related to the difference between having no more elements (maybe right now, > like an open network stream) and never ever being able to produce more data. > > > > Sven > > > > > > > >

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Alistair Grant

Hi Sven, On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: > Somehow, somewhere there was a change to the implementation of the > primitive called by some streams' #atEnd. That's a proposed change by me, but it hasn't been integrated yet. So the discussion below should apply to the current stable vm (from August last year). > IIRC, someone said it is implemented as 'remaining size being zero' > and some virtual unix files like /dev/random are zero sized. Currently, for files other than sdio (stdout, stderr, stdin) it is effectively defined as: atEnd := stream position >= stream size And, as you say, plenty of virtual unix files report size 0. > Now, all kinds of changes are being done image size to work around this. I would phrase this slightly differently :-) Some code does the right thing, while other code doesn't. E.g.: MultiByteFileStream>>upToEnd is good, while FileStream>>contents is incorrect > I am a strong believer in simple, real (i.e. infinite) streams, but I > am not sure we are doing the right thing here. > > Point is, I am not sure #next returning nil is official and universal. > > Consider the comments: > > Stream>>#next > "Answer the next object accessible by the receiver." > > ReadStream>>#next > "Primitive. Answer the next object in the Stream represented by the > receiver. Fail if the collection of this stream is not an Array or a String. > Fail if the stream is positioned at its end, or if the position is out of > bounds in the collection. Optional. See Object documentation > whatIsAPrimitive." > > Note how there is no talk about returning nil ! > > I think we should discuss about this first. > > Was the low level change really correct and the right thing to do ? The primitive change proposed doesn't affect this discussion. It will mean that #atEnd returns false (correctly) sometimes, while currently it returns true (incorrectly). The end result is still incorrect, e.g. #contents returns an empty string for /proc/cpuinfo. You're correct about no mention of nil, but we have: FileStream>>next (position >= readLimit and: [self atEnd]) ifTrue: [^nil] ifFalse: [^collection at: (position := position + 1)] which has been around for a long time (I suspect, before Pharo existed). Having said that, I think that raising an exception is a better solution, but it is a much, much bigger change than the one I proposed in https://github.com/pharo-project/pharo/pull/1180. Cheers, Alistair > Note also that a Guille introduced something new, #closed which is related to the difference between having no more elements (maybe right now, like an open network stream) and never ever being able to produce more data. > > Sven > > >

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Denis Kudriashov

Hi. #next returning nil is definitely looks bad because we will always have case when nil value will not means the end: #(1 nil 2) readSteam next; next; atEnd But I understand that in many cases analysing #next for nil is much more suitable than #atEnd. I am sure that it can be always avoided but it can be not easy to do. Alternatively we can reify real EndOfStream object which will be used as result of reading operation when stream is at end. It can provide nice API like #ifEndOfStream:. which will reflect intention in much cleaner way than ifNil: checks. 2018-04-04 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 4 Apr 2018, at 11:38, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > Hi Sven, > > See also discussion at https://github.com/OpenSmalltalk/opensmalltalk- > vm/pull/232 > > Thanks Nicolas, I had already seen parts of it. > > Now, I still want image level changes to be based on clear semantic > definitions of the abstract stream API, we're not just talking about file > or unix streams, the general Smalltalk concept. > > For reading, they are IMHO, > > #next > #readInto:startingAt:count: > #peek > #atEnd > #upToEnd (can be derived but still the semantics are important in relation > to #atEnd) > > For writing, we have > > #nextPut: > #next:putAll:startingAt: > #flush > > For both, we have > > #atEnd > #close > #closed (new) > > So, I know, #next returning nil exists, but is it universally/officially > defined as such ? Where is that documented ? > > Positioning, sizing are not universal, IMHO, but should be clearly defined > as well. > > > 2018-04-04 11:32 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Somehow, somewhere there was a change to the implementation of the > primitive called by some streams' #atEnd. > > > > IIRC, someone said it is implemented as 'remaining size being zero' and > some virtual unix files like /dev/random are zero sized. > > > > Now, all kinds of changes are being done image size to work around this. > > > > I am a strong believer in simple, real (i.e. infinite) streams, but I am > not sure we are doing the right thing here. > > > > Point is, I am not sure #next returning nil is official and universal. > > > > Consider the comments: > > > > Stream>>#next > > "Answer the next object accessible by the receiver." > > > > ReadStream>>#next > > "Primitive. Answer the next object in the Stream represented by the > > receiver. Fail if the collection of this stream is not an Array or a > String. > > Fail if the stream is positioned at its end, or if the position is out > of > > bounds in the collection. Optional. See Object documentation > > whatIsAPrimitive." > > > > Note how there is no talk about returning nil ! > > > > I think we should discuss about this first. > > > > Was the low level change really correct and the right thing to do ? > > > > Note also that a Guille introduced something new, #closed which is > related to the difference between having no more elements (maybe right now, > like an open network stream) and never ever being able to produce more data. > > > > Sven > > > > > > > > > > >

April 4, 2018

[Pharo 7.0-dev] Build #752: 21672-Package-deprecation-based-on-deprecated-manifest-class

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

There is a new Pharo build available! The status of the build #752 was: SUCCESS. The Pull Request #1178 was integrated: "21672-Package-deprecation-based-on-deprecated-manifest-class" Pull request url: https://github.com/pharo-project/pharo/pull/1178 Issue Url: https://pharo.fogbugz.com/f/cases/21672 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

> On 4 Apr 2018, at 11:38, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Sven, > See also discussion at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232 Thanks Nicolas, I had already seen parts of it. Now, I still want image level changes to be based on clear semantic definitions of the abstract stream API, we're not just talking about file or unix streams, the general Smalltalk concept. For reading, they are IMHO, #next #readInto:startingAt:count: #peek #atEnd #upToEnd (can be derived but still the semantics are important in relation to #atEnd) For writing, we have #nextPut: #next:putAll:startingAt: #flush For both, we have #atEnd #close #closed (new) So, I know, #next returning nil exists, but is it universally/officially defined as such ? Where is that documented ? Positioning, sizing are not universal, IMHO, but should be clearly defined as well. > 2018-04-04 11:32 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Somehow, somewhere there was a change to the implementation of the primitive called by some streams' #atEnd. > > IIRC, someone said it is implemented as 'remaining size being zero' and some virtual unix files like /dev/random are zero sized. > > Now, all kinds of changes are being done image size to work around this. > > I am a strong believer in simple, real (i.e. infinite) streams, but I am not sure we are doing the right thing here. > > Point is, I am not sure #next returning nil is official and universal. > > Consider the comments: > > Stream>>#next > "Answer the next object accessible by the receiver." > > ReadStream>>#next > "Primitive. Answer the next object in the Stream represented by the > receiver. Fail if the collection of this stream is not an Array or a String. > Fail if the stream is positioned at its end, or if the position is out of > bounds in the collection. Optional. See Object documentation > whatIsAPrimitive." > > Note how there is no talk about returning nil ! > > I think we should discuss about this first. > > Was the low level change really correct and the right thing to do ? > > Note also that a Guille introduced something new, #closed which is related to the difference between having no more elements (maybe right now, like an open network stream) and never ever being able to produce more data. > > Sven > > > >

April 4, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Nicolas Cellier

Hi Sven, See also discussion at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232 2018-04-04 11:32 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Somehow, somewhere there was a change to the implementation of the > primitive called by some streams' #atEnd. > > IIRC, someone said it is implemented as 'remaining size being zero' and > some virtual unix files like /dev/random are zero sized. > > Now, all kinds of changes are being done image size to work around this. > > I am a strong believer in simple, real (i.e. infinite) streams, but I am > not sure we are doing the right thing here. > > Point is, I am not sure #next returning nil is official and universal. > > Consider the comments: > > Stream>>#next > "Answer the next object accessible by the receiver." > > ReadStream>>#next > "Primitive. Answer the next object in the Stream represented by the > receiver. Fail if the collection of this stream is not an Array or a > String. > Fail if the stream is positioned at its end, or if the position is out of > bounds in the collection. Optional. See Object documentation > whatIsAPrimitive." > > Note how there is no talk about returning nil ! > > I think we should discuss about this first. > > Was the low level change really correct and the right thing to do ? > > Note also that a Guille introduced something new, #closed which is related > to the difference between having no more elements (maybe right now, like an > open network stream) and never ever being able to produce more data. > > Sven > > > >

April 4, 2018

Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

Somehow, somewhere there was a change to the implementation of the primitive called by some streams' #atEnd. IIRC, someone said it is implemented as 'remaining size being zero' and some virtual unix files like /dev/random are zero sized. Now, all kinds of changes are being done image size to work around this. I am a strong believer in simple, real (i.e. infinite) streams, but I am not sure we are doing the right thing here. Point is, I am not sure #next returning nil is official and universal. Consider the comments: Stream>>#next "Answer the next object accessible by the receiver." ReadStream>>#next "Primitive. Answer the next object in the Stream represented by the receiver. Fail if the collection of this stream is not an Array or a String. Fail if the stream is positioned at its end, or if the position is out of bounds in the collection. Optional. See Object documentation whatIsAPrimitive." Note how there is no talk about returning nil ! I think we should discuss about this first. Was the low level change really correct and the right thing to do ? Note also that a Guille introduced something new, #closed which is related to the difference between having no more elements (maybe right now, like an open network stream) and never ever being able to produce more data. Sven

April 4, 2018

CFP - IWST 2018 - International Workshop on Smalltalk Technologies

by Anne Etien

CFP - IWST 2018 - International Workshop on Smalltalk Technologies [Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST 2018 â International Workshop on Smalltalk Technologies http://esug.org/wiki/pier/Conferences/2018/International-Workshop-IWST_18 <http://www.esug.org/wiki/pier/Conferences/2017/International-Workshop-IWST_…> Cagliari, Italy; Between September 10th and 14th, 2018 ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: June 15th, 2018 Notification deadline: July 20th, 2018 Workshop : between September 10th and 14th, 2018 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm <http://www.acm.org/sigs/sigplan/authorInformation.htm>. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst18 <https://easychair.org/conferences/?conf=iwst18> ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille, France) Loic Lagadec (Ensta Bretagne, France)

April 4, 2018