September 2019 - Pharo-users

Re: [Pharo-users] ..LCK

by James Foster

The lock file is tested to see if the stone is running and if you delete it then the system should be willing to start a new stone. Please reboot your machine, try the âstartstoneâ command again, and then post the output of to the gemstone mailing list. > On Sep 10, 2019, at 2:24 AM, ian <ian(a)icjohnson.com> wrote: > > Hi All, > > I am not able to start my stone as I inadvertantly deleted the ..LCK file. :) > > Is there a way to fix this? > > Thanks, > >

Sept. 10, 2019

Re: [Pharo-users] Stream >> <<

by Sven Van Caekenberghe

Development happens in Pharo 8 first, with possible back ports if really necessary. The last relevant change was the following: https://github.com/pharo-project/pharo/pull/2698 > On 10 Sep 2019, at 14:54, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I think it's fair to say that #<< *is* a bug. > There does not seem to be any coherent description of what it means. > It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or* > something else, in some confusing ways. > CommandLineHandler #nextPutAll: (sent somewhere else) > Integer left shift (someone has been smoking too much C++) > NonInteractiveTranscript #show: = locked #print: > SocketStream #putOn: (which may itself act like > #nextPut:, #nextPutAll:, #print, > put elements sans separators, or > something else) > Stream #putOn: (see above) > WriteStream either #nextPutAll: or #putOn: > Transcript #show: = locked #print: > ThreadSafeTranscript #show: = locked #print: > VTermOutputDriver #putOn: > VTermOutputDriver2 #asString then #nextPutAll: > ZnEncodedWriteStream #nextPutAll: > ZnHtmlOutputStream #asString then #nextPutAll: > SequenceableCollection class #streamContents: > > As was once said about PL/I, #<< fills a much-needed gap. > When I see #print:, or #nextPut:, or #nextPutAll:, I know > what to expect. When I see #putOn:, I have in general no > idea what will happen. And when I see << it is worse. > > One point of << is to imitate C++'s composition of outputs. > That might work, too, if only there were some agreement > about what #nextPutAll: returns. There is not. It might > return the receiver. It might return some other stream > related to the receiver. It might even return the collection > argument. So when you see > a << b << c > in general you not only do not have a clue what (a) is going > to do with (b) but you have no idea what object the message > << c will be sent to. > > Now let's see if we can puzzle out what > Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] > does. > The output will be going to a WriteStream. > aWriteStream << anInteger > is not, but is like, aWriteStream print: anInteger. > So we add $1 and $0. > aWriteStream << aString > reduces to aWriteStream nextPutAll: aString. > So we add $1 and $0. > aWriteStream on anArray << anotherArray > reduces to aWriteStream nextPutAll: anotherArray. > So we add 10 and '10'. > Thus the result we get is > #($1 $0 $1 $0 10 '10'). > What result we should *expect* from this muddle I cannot say. > > If, on the other hand, you wrote explicitly > Array streamContents: [:stream | > stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')] > you would have an easy time figuring out what to expect. > > By the way, there is no standard definition of #show:, but in > other Smalltalk systems it's usually a variant of #nextPutAll:, > not a variant of #print:. There's no denying that locked output > is useful to have, but #show: is not perhaps the best name for it. >

Sept. 10, 2019

Re: [Pharo-users] Stream >> <<

by Richard O'Keefe

I think it's fair to say that #<< *is* a bug. There does not seem to be any coherent description of what it means. It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or* something else, in some confusing ways. CommandLineHandler #nextPutAll: (sent somewhere else) Integer left shift (someone has been smoking too much C++) NonInteractiveTranscript #show: = locked #print: SocketStream #putOn: (which may itself act like #nextPut:, #nextPutAll:, #print, put elements sans separators, or something else) Stream #putOn: (see above) WriteStream either #nextPutAll: or #putOn: Transcript #show: = locked #print: ThreadSafeTranscript #show: = locked #print: VTermOutputDriver #putOn: VTermOutputDriver2 #asString then #nextPutAll: ZnEncodedWriteStream #nextPutAll: ZnHtmlOutputStream #asString then #nextPutAll: SequenceableCollection class #streamContents: As was once said about PL/I, #<< fills a much-needed gap. When I see #print:, or #nextPut:, or #nextPutAll:, I know what to expect. When I see #putOn:, I have in general no idea what will happen. And when I see << it is worse. One point of << is to imitate C++'s composition of outputs. That might work, too, if only there were some agreement about what #nextPutAll: returns. There is not. It might return the receiver. It might return some other stream related to the receiver. It might even return the collection argument. So when you see a << b << c in general you not only do not have a clue what (a) is going to do with (b) but you have no idea what object the message << c will be sent to. Now let's see if we can puzzle out what Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] does. The output will be going to a WriteStream. aWriteStream << anInteger is not, but is like, aWriteStream print: anInteger. So we add $1 and $0. aWriteStream << aString reduces to aWriteStream nextPutAll: aString. So we add $1 and $0. aWriteStream on anArray << anotherArray reduces to aWriteStream nextPutAll: anotherArray. So we add 10 and '10'. Thus the result we get is #($1 $0 $1 $0 10 '10'). What result we should *expect* from this muddle I cannot say. If, on the other hand, you wrote explicitly Array streamContents: [:stream | stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')] you would have an easy time figuring out what to expect. By the way, there is no standard definition of #show:, but in other Smalltalk systems it's usually a variant of #nextPutAll:, not a variant of #print:. There's no denying that locked output is useful to have, but #show: is not perhaps the best name for it.

Sept. 10, 2019

Re: [Pharo-users] Stream >> <<

by Noury Bouraqadi

Herby, It's a feature. ;-) << sends putOn: message to the non-collection args. Integer>>#putOn: aStream aStream isBinary ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] ifFalse: [ self asString putOn: aStream ] String>>#putOn: aStream aStream nextPutAll: self > On 10 Sep 2019, at 11:27, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hello! > > In Pharo 7.0.4, > > Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] > > >>> #($1 $0 $1 $0 10 '10') > > Bug or feature? > > Herby >

Sept. 10, 2019

Re: [Pharo-users] Lazy Streams - was: Re: Set >> collect:thenDo:

by Steffen MÃ¤rcker

Hi, I really think we should have an efficient way to chain operations on collections and alike. In my personal opinion, this should be backed by transducers, as they decouple the operations from the type the data source and sink. Hence they are applicable to different collection types, streams and so on. Also, transducers allow for straight-forward parallization of operations that are concurrency-safe. However, the transducers port is not complete yet. I think I'll finish it in October/November, but definitely this year. Maybe this could be a starting point to discuss how to move forward? One related question: Is there a somewhat comprehensive benchmark yielding a baseline of Pharo's collection/streams/iteration performance? I'd really like to compare the existing implemenation to the alternative approaches. Best regards, Steffen Am .09.2019, 11:30 Uhr, schrieb Kasper Ãsterbye <kasper.osterbye(a)gmail.com>: > On 10 September 2019 at 00.56.28, Richard O'Keefe (raoknz(a)gmail.com) > wrote: > > Does that sound like a way forward? > I could convert my implementation of this interface to > Pharo if people would like me to. > > Hi Richard, > > It seems like what you propose (in sofar as I understand it) is already > present in at least three other libraries which have not yet made it to > the > core of Pharo: > > The Iterator framework Julien is working on: > https://github.com/juliendelplanque/Iterators > > The XStreams framework: https://code.google.com/archive/p/xtreams/ > <https://code.google.com/archive/p/xtreams/> > > The transducers: https://github.com/Pharophile/Transducers > <https://github.com/Pharophile/Transducers> > > I was not aware of the virtual collections from Strongtalk. > > I am aware you know them (as you commented on the Iterators Julien > proposed). > > I have been working with the LINQ stream/iterator framework in C#, and > found that to be a rather sound library, lazy evaluation. The streams in > Java are also nice, and are actually very good at exploiting multi cores. > > It is sad there is no lazy streams in the core of Pharo, and I would find > it intersting to participate in a project to build one. > > Best, > > Kasper

Sept. 10, 2019

Lazy Streams - was: Re: Set >> collect:thenDo:

by Kasper Ãsterbye

On 10 September 2019 at 00.56.28, Richard O'Keefe (raoknz(a)gmail.com) wrote: Does that sound like a way forward? I could convert my implementation of this interface to Pharo if people would like me to. Hi Richard, It seems like what you propose (in sofar as I understand it) is already present in at least three other libraries which have not yet made it to the core of Pharo: The Iterator framework Julien is working on: https://github.com/juliendelplanque/Iterators The XStreams framework: https://code.google.com/archive/p/xtreams/ <https://code.google.com/archive/p/xtreams/> The transducers: https://github.com/Pharophile/Transducers <https://github.com/Pharophile/Transducers> I was not aware of the virtual collections from Strongtalk. I am aware you know them (as you commented on the Iterators Julien proposed). I have been working with the LINQ stream/iterator framework in C#, and found that to be a rather sound library, lazy evaluation. The streams in Java are also nice, and are actually very good at exploiting multi cores. It is sad there is no lazy streams in the core of Pharo, and I would find it intersting to participate in a project to build one. Best, Kasper

Sept. 10, 2019

Stream >> <<

by Herby VojÄÃk

Hello! In Pharo 7.0.4, Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] >>> #($1 $0 $1 $0 10 '10') Bug or feature? Herby

Sept. 10, 2019

..LCK

by ian

Hi All, I am not able to start my stone as I inadvertantly deleted the ..LCK file. :) Is there a way to fix this? Thanks,

Sept. 10, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Richard O'Keefe

An automatic refactoring rule that converts (a collect: b) do: c to (a collect: b thenDo: c) would change the semantics of the code in all of Squeak, Pharo, and Smalltalk/X, whichever definition of #collect:thenDo: is taken, and in Squeak would make the code slower, not faster. Using a different name *would* reduce confusion. However, there is an alternative. My library copied the #virtual{Collect,Select,Reject}: interface from Strongtalk. As the comment puts it, The idea is to do #select:, #reject:, #collect:, and some other collection->collection operations lazily. As long as you just use #do: &c, the operations will be referred back to the original collection, so that there is less need for fusion methods like #select:thenCollect:. ... You can do (((( coll virtualSelect: [..]) virtualCollect: [...]) virtualSelect: [..]) virtualCollect: [...]) asCollection and only *one* new collection is actually built. So (aCollection virtualCollect: transformBlock) do: actionBlock *does* build an intermediate object (with two instance variables) but *doesn't* build a whole intermediate collection. And that combination *could* be fused by an automatic rule without breaking anything. Does that sound like a way forward? I could convert my implementation of this interface to Pharo if people would like me to. On Tue, 10 Sep 2019 at 01:51, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I think this thread indicates that the selector #collect:thenDo: may > indeed cause some missunderstanding given standard semantics of #collect:. > Is there any reason not to use a different one, such as #map:thenDo:, to > make the difference clearer? > > A nice side effect could be a new automatic refactoring rule that > consolidates chained #collect: and #do: sends into a faster > #collect:thenDo: send without breaking existing code. > > Am .09.2019, 07:46 Uhr, schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > > (1) If you want (aSet collect: collectBlock) do: doBlock > > you can write exactly that. Nothing stops you, and it will > > be as clear and reliable as any use of Set>>collect:, which > > is to say NOT VERY CLEAR OR RELIABLE AT ALL. > > > > (2) #collect:then{Do:Select:Reject:} had no other purpose than > > to avoid creating an intermediate and otherwise useless > > collection. If you are not trying to involve an intermediate > > set then it just plain wrong to use #collect:thenDo:. > > > > (3) Oddly enough, the reason that #collect:thenDo: exists in my > > library is that I copied it from Squeak, at a time when it had > > the same definition as Pharo and ST/X. Had I known of the change > > in Squeak I would have bitterly opposed it. The comment in the > > current Squeak code, that it is for readability, is 100% the > > reverse of the truth. Using the version with parentheses is WAY > > clearer than using the portmanteau method. Sigh. I see they > > broke #collect:thenSelect: in the same way. > > > > (4) Let me offer you another member of the #collect:then* family. > > > > Collection > > collect: collectBlock thenInject: initial into: injectBlock > > |r| > > r := initial. > > self do: [:each | > > r := injectBlock value: r value: (collectBlock value: each)]. > > ^r > > > > #(now is the hour for us to say goodbye) asSet > > collect: [:each | each size] > > thenInject: 0 into: [:acc :each | acc + each] > > => 29 > > (#(now is the hour for us to say goodbye) asSet > > collect: [:each | each size]) > > inject: 0 into: [:acc :each | acc + each] > > => 16 > > > > That is, it would be WRONG to implement #collect:thenInject:into: > > as #collect: followed by #inject:into:. The point is NOT to > > coalesce things that the receiver might (in general, incorrectly) > > regard as equal. > > > > (5) The bottom line is that if #collect:thenDo: and its relatives did > > not have their present semantics in Pharo (and ST/X), they would > > need to be reinvented, with names that were not as clear. > > > > (1) Just to repeat for emphasis, if you *want* (_ collect: _) do: _ > > then that is exactly what you should write. There is no > > excuse for using #collect:thenDo: in that case. It is NOT > > clearer to do so. And you should imagine me jumping up and > > down screaming that sending #collect: to a set is a bad code > > smell which demands very explicit documentation as to why you > > (for example) want a Set to answer a Set but an IdentitySet > > to also answer a Set, not the expected IdentitySet. (I have > > been bitten by that more than once.) > > > > > > > > On Mon, 9 Sep 2019 at 01:33, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > > >> On 8. 9. 2019 14:28, Peter Kenny wrote: > >> > Two comments: > >> > First, the method comment for Collection>>collect:thenDo: is "Utility > >> method > >> > to improve readability", which is exactly the same as for > >> > collect:thenSelect: and collect:thenReject:. This suggests that the > >> > *intention* of the method is not to introduce new behaviour, but > >> simply > >> to > >> > provide a shorthand for the version with parentheses. For other kinds > >> of > >> > >> I had that same impression. > >> > >> > collection this is true; just the deduping makes Set different. If we > >> want > >> > >> I would be more defensive here and say that generic collection should > >> have (collect:)do: implementation and only sequenceable collections have > >> the optimized one (if it indeed is the case that it is a shotrhand for > >> parenthesized one). > >> > >> > the different behaviour, this should be indicated by method name and > >> > comment. > >> > Second, if we remove asSet from the second snippet, the output is > >> exactly > >> > the same. It will be the same as long as the original collection has > >> no > >> > duplicates. Somehow the effect is to ignore the asSet. It just smells > >> wrong. > >> > > >> > Peter Kenny > >> > >> Herby > >> > >> > Kasper Osterbye wrote > >> >> The first version: > >> >> > >> >> (#(1 2 3) asSet collect: #odd) > >> >> do: [ :each | Transcript show: each; cr ] > >> >> > >> >> is rather straight forward I believe, as collect: and do: has been > >> around > >> >> forever (relatively speaking). > >> >> > >> >> > >> >> #(1 2 3) asSet collect: #odd > >> >> thenDo: [ :each | Transcript show: each; cr ] > >> >> > >> >> > >> >> On 8 September 2019 at 09.13.36, Richard Sargent ( > >> > > >> >> richard.sargent@ > >> > > >> >> ) wrote: > >> >> > >> >> I am skeptical of one that relies on a specific implementation > >> rather > >> >> than > >> >> a specific definition. > >> >> > >> >> I share your feeling. I am not sure where such a definition would > >> come > >> >> from. In Squeak it is defined as: > >> >> > >> >> collect: collectBlock thenDo: doBlock > >> >> > >> >> ^ (self collect: collectBlock) do: doBlock > >> >> > >> >> In pharo as: > >> >> > >> >> collect: collectBlock thenDo: doBlock > >> >> > >> >> ^ self do: [ :each | doBlock value: (collectBlock value: each)] > >> >> > >> >> I might have called the method collect:eachDo:, but we each have > >> slightly > >> >> different styles. What I like about the pharo version is that is a > >> >> shorthand for something which is not achieved by mere parentheses. > >> >> > >> >> Best, > >> >> > >> >> Kasper > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > >> > >> > >> > > > >

Sept. 9, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Richard O'Keefe

Digging a bit further, the change from the pointless implementation to the current implementation was made between Pharo 2.0 and Pharo 3.0 and the current definition was introduced into ST/X some time between 2010 and 2012, which is about the same time as Pharo. {collect,select,reject}:thenDo: were added to my library on 2004.09.14, exactly a day after the version now in Squeak. Which leads me to believe that I picked the method up from a previous version of Squeak and that some of the Squeak version history has been lost. By the way, it's not just Sets where the current Squeak definition is a pain in the posterior. Consider the following example. |o| o := OrderedCollection new. #[3 1 4 1 5 9] collect: [:byte | byte asFloat] thenDo: [:float | o addLast: float]. Transcript print: o; cr. This works fine in Pharo, in Smalltalk/X, and in my library. It raises an exception in Squeak. Or try #[3 1 4 1 5 9] collect: [:byte | byte odd ifTrue: [byte printString] ifFalse: [byte]] thenSelect: [:each | each isNumber] In Pharo and my library, it straightforwardly answers #[4]. In Squeak, it raises an exception. So that's sets where the current Squeak definition can give you trouble, and ByteArrays, and we are not done yet! Pretty much anything other than an Array or an OrderedCollection is going to get you in trouble in Squeak. Just think of the fun you can have with SortedCollection. Ooh, the list goes on and on. So, the Squeak definition * does not improve readability. In fact, it REDUCES readability because the human reader stops to ask "why is this portmanteau method used rather than the obvious code" and several minutes later discovers that there is NO reason. * is useless with most collection classes. * does nothing to improve performance but just adds overhead. Are we done yet? On Tue, 10 Sep 2019 at 01:27, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Sep 09, 2019 at 05:46:48PM +1200, Richard O'Keefe wrote: > > > > (3) Oddly enough, the reason that #collect:thenDo: exists in my > > library is that I copied it from Squeak, at a time when it had > > the same definition as Pharo and ST/X. Had I known of the change > > in Squeak I would have bitterly opposed it. The comment in the > > current Squeak code, that it is for readability, is 100% the > > reverse of the truth. Using the version with parentheses is WAY > > clearer than using the portmanteau method. Sigh. I see they > > broke #collect:thenSelect: in the same way. > > > > In Squeak, collect:thenDo: is implemented only in Collection. > The method stamp is dgd 9/13/2004 23:42, which hardly qualifies as > a recent change. And the method stamp for collect:thenSelect: is > sma 5/12/2000. > > Dave > > >

Sept. 9, 2019