April 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Erik Stel

Richard, Can you explain me what you mean by "sortBlock is supposed to act like #<="? Isn't it up to the developer to decide what the logic should be? I simply used #<= because #> might not have been implemented for all relevant classes, but would otherwise have chosen #> as a means to get the 'reversal' of #<=. Your solution is not resulting in the behaviour I would expect it. Adding elements which are compared equally, but still have a different value, do not get added in the same position. In the examples below I use Associations, since it compares on the key only (for #<= comparison). Consider a regular SortedCollection with default sortBlock (set explicitly): | aCollection | aCollection := SortedCollection sortBlock: [ :a :b | a <= b ]. {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection add: each ]. aCollection. "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" When I create a SortedCollection with your code's sortBlock reversed I get: | aCollection | aCollection := SortedCollection sortBlock: [ :a :b | b <= a ]. {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection add: each ]. aCollection. "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" The order of the result is the same in both situations. What I would expect is the result you get from the sortBlock I suggested: | aCollection | aCollection := SortedCollection sortBlock: [ :a :b | (a <= b) not ]. {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection add: each ]. aCollection. "a SortedCollection(#k->'Other' #k->'Or' #k->'Value' #k->'Some')" This last result is the reversal of the original result. (side note) IF in the above #addAll: was used instead of the repeated #add:, things might be different again. Since the #addAll: implementation would on some occasions (when size of receiver vs size of added elements is certain ratio) add the elements at the end and then perform a #reSort. With values being compared as equal, the order will be decided by the order they were added. So the result of #addAll: depends on the collection sizes. This might not be what a user would expect ;-). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 23, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Erik Stel

I already deleted my post (within 1 minute after posting 8-) seeing that I jumped the wagon too early. Sorry for that. Your message and proposed solution is fine. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 23, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

I know perfectly well what the problem is. I explained it in my message: the inherited #reversed method doesn't know the sortBlock exists. (So whether it is nil or not is not relevant.) I also know several ways to fix it, and provided tested source code for one of them in my message. Using (a <= b) not would be a bad idea as a sortBlock is supposed to act like #<=, not like #<. (That has always puzzled me: why take #< as the fundamental operation in Magnitude but #<= as the fundamental operation in sorting? But that is historic and standard practice.) On 23 April 2018 at 19:10, Erik Stel <erik.stel(a)gmail.com> wrote: > Richard, > > The 'problem' is that the result of the (original) #reverse is a > SortedCollection without a sortBlock. Meaning it defaults to comparing > values using #<=. When a new element is added to the reversed collection it > simply assumes all elements are already sorted and uses the (default) > sortBlock to add a new element. > > I think the solution should be to have #reverse add an explicit sortBlock > which consists of reversing the original sortBlock or defaulting to [ a: b: > | (a <= b) not ]. (Keep #<= as some classes might depend on only > implementing this) > > Cheers, > Erik > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 23, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Erik Stel

Richard, The 'problem' is that the result of the (original) #reverse is a SortedCollection without a sortBlock. Meaning it defaults to comparing values using #<=. When a new element is added to the reversed collection it simply assumes all elements are already sorted and uses the (default) sortBlock to add a new element. I think the solution should be to have #reverse add an explicit sortBlock which consists of reversing the original sortBlock or defaulting to [ a: b: | (a <= b) not ]. (Keep #<= as some classes might depend on only implementing this) Cheers, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 23, 2018

SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

Test case: #(1 2 4) asSortedCollection reverse add: 3; yourself <print it> The answer *should* be aSortedCollection(4 3 2 1) but *is* aSortedCollection(4 2 1 3). This works in Squeak. The problem is that SortedCollection does not define #reverse[d] but simply inherits it(them), and the inherited code pays no attention to the sortBlock. I propose adding the following two methods to SortedCollection: reverseInPlace |a z| a := firstIndex. z := lastIndex. [a < z] whileTrue: [array swap: a with: z. a := a + 1. z := z - 1]. sortBlock := sortBlock ifNil: [[:x :y | y <= x]] ifNotNil: [[:x :y | sortBlock value: y value: x]]. ^self reversed ^self copy reverseInPlace The ANSI method is #reverse, not #reversed, but Pharo defines #reverse to call #reversed, and OrderedCollection overrides #reversed, so SortedCollection *must* override #reversed. #reverseInPlace is the name Squeak uses for the other method. It also has a definition in SequenceableCollection, which is not but is equivalent to reverseInPlace |a z| a := 1. z := self size. [a < z] whileTrue: [self swap: a with: z. a := a + 1. z := z - 1].l ^self r

April 23, 2018

Re: [Pharo-users] What next for Pharo vm?

by Ronie Salgado

> > > I was thinking the vm is able to run more than one bytecode set. Why > couldnât our vm support both Pharo and Java bytecodes? Perhaps a simpler way is to make a translator from Java bytecodes -> Pharo (Sista) bytecodes. I believe that ikvm did something similar for .NET. The hardest part of this would actually be on parsing the .class files. Best regards, Ronie 2018-04-22 21:31 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > On 22/04/2018 11:03, henry wrote: > > I was thinking the vm is able to run more than one bytecode set. Why > > couldnât our vm support both Pharo and Java bytecodes? > > Smaltallk/X provides that Smalltalk/Java code duality. > > But I think if Pharo ever pursues that path the best thing would be to > make it run in a VM such as Truffle/GraalVM [1]. A longest path maybe, > but you'll be able to piggyback on an existing community of VM > developers, and be able to interact not only with Java but it other > languages as well. > > [1] https://www.graalvm.org/ > > Regards! > > -- > Esteban A. Maringolo > >

April 23, 2018

Re: [Pharo-users] Where do we go now ?

by Offray Vladimir Luna CÃ¡rdenas

On 20/04/18 02:14, Stephane Ducasse wrote: >> On this matter, when I named my project, "Grafoscopio" I thought in >> something evocative and unique, because of the Spanish words "grafo" >> (graph) and grafÃa[1][2] (graphy, related with writing like in >> "ortografÃa" "orthography". After naming it I discover there was a old >> device related with writing and visualization, also called >> Grafoscopio[3][4], but I got good search rankings because of the >> uniqueness of the word[5][6]. > Obviously and well done! > > I like when developers are talking about names: > They use a mac and not a computer, they were nike, lewis and not shoes > and pants.... > > May be we should rename Pharo: programming language. > And Voyage: Layer > And Athens, Cairo: Canvas > > And git: versioning system > > Hibernate? JavaFX?, Graddle?, Travis?, Bintray? > Do you want more > Docker? > > So guys can we focus our energy on positive things. > > Stef > > Thanks Stephan. I think most of the community is working on positive thinks (like you). Naming preferences and conventions shouldn't be a place for holy wars. And in fact I would like to learn more about Smalltalk Style, for example, how to use prefixes in classes without loosing the "branding" behind names and tools. Cheers, Offray

April 23, 2018

Re: [Pharo-users] What next for Pharo vm?

by Esteban A. Maringolo

On 22/04/2018 11:03, henry wrote: > I was thinking the vmÂ is able to run more than one bytecode set. Why > couldnât our vm support both Pharo and Java bytecodes? Smaltallk/X provides that Smalltalk/Java code duality. But I think if Pharo ever pursues that path the best thing would be to make it run in a VM such as Truffle/GraalVM [1]. A longest path maybe, but you'll be able to piggyback on an existing community of VM developers, and be able to interact not only with Java but it other languages as well. [1] https://www.graalvm.org/ Regards! -- Esteban A. Maringolo

April 23, 2018

Re: [Pharo-users] Escaping from FileStream

by Sven Van Caekenberghe

> On 22 Apr 2018, at 16:55, Hilaire <hilaire(a)drgeo.eu> wrote: > > For example when rewritting this methods, to read afterward PNG image I have error: image format no recognized. > > getFile: aFilename > " ^ FileStream readOnlyFileNamed: (self fullname: aFilename)" > ^ (self fullname: aFilename) asFileReference binaryReadStream Yes that is an open issue that I have not yet committed to pharo7 dev https://pharo.manuscript.com/f/cases/21611/Adapt-ImageReadWriter-hierarchy-… but I got it fixed in some image somewhere, it just needs cleanup and packaging. > Le 22/04/2018 Ã 16:46, Hilaire a Ã©crit : >> A migration guide will be more than welcome, because the API, and likely the logic, is different. >> >> Thanks >> >> Hilaire >> >> >> Le 21/04/2018 Ã 13:37, Sven Van Caekenberghe a Ã©crit : >>> Yes, relatively recent, weeks I guess, maybe a month, at least since half March. >>> >>> FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements. >>> >>> BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector. > > -- > Dr. Geo > http://drgeo.eu > > >

April 22, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 22 Apr 2018, at 16:46, Hilaire <hilaire(a)drgeo.eu> wrote: > > A migration guide will be more than welcome, because the API, and likely the logic, is different. It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start. >From a user perspective, the changes are not that big. If something is not clear, you can always ask. > Thanks > > Hilaire > > > Le 21/04/2018 Ã 13:37, Sven Van Caekenberghe a Ã©crit : >> Yes, relatively recent, weeks I guess, maybe a month, at least since half March. >> >> FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements. >> >> BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector. > > -- > Dr. Geo > http://drgeo.eu > > >

April 22, 2018