- Pharo-users - lists.pharo.org

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

by Guillermo Polito

Hi, I think the more proper API to use is CodeImporter evaluateFileNamed: '/path/to/my/file.st'. Check CodeImporter class side for more options (streams, strings...). CodeImporter is there for already 3/4 years I think. The idea is that filing in is not a file responsibility. Guille On Mon, Apr 23, 2018 at 10:35 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > That's a plan! > > I realized from my code I was already using a mix of the new and old > world. It will be nice to get rid of the antic one to reduce the confusion > when manipulating file. > > Thanks > > Le 22/04/2018 Ã 20:12, Sven Van Caekenberghe a Ã©crit : > >> 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. >> > > -- > Dr. Geo > http://drgeo.eu > > > > -- 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

April 24, 2018

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

by Hilaire

That's a plan! I realized from my code I was already using a mix of the new and old world. It will be nice to get rid of the antic one to reduce the confusion when manipulating file. Thanks Le 22/04/2018 Ã 20:12, Sven Van Caekenberghe a Ã©critÂ : > 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. -- Dr. Geo http://drgeo.eu

April 23, 2018

Re: [Pharo-users] treemap of memory use for an object?

by phil＠highoctane.be

I do.not know about variable sizes but I've made a treemap of database table size grouped by some grouping. I'll fetch the code and post it when home. Phil On Mon, Apr 23, 2018, 19:42 PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > Hi, > > With Roassal is it possible to make a treemap ( > https://en.wikipedia.org/wiki/Treemapping) of the memory use of an object > and its instVars? > > > I have a leak and am not sure where and its not one or two objects > AFAIK.... > > > Thanks > > > Paul > >

April 23, 2018

treemap of memory use for an object?

by PAUL DEBRUICKER

Hi, With Roassal is it possible to make a treemap (https://en.wikipedia.org/wiki/Treemapping) of the memory use of an object and its instVars? I have a leak and am not sure where and its not one or two objects AFAIK.... Thanks Paul

April 23, 2018

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