- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] remove unused variables

by Johan Fabry

This was changed somewhere in November by Marcus and Miguel, and it was intentional, as part of the work on annotations on the AST that enabled breakpoints. (Breakpoints use the same highlighting mechanism). > On Apr 21, 2016, at 18:52, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > The editor used to inform when there was an unused local variable and offered to remove it. > > Is it possible to get this behavior back, or is it a feature regression with the "new" (this changed some time ago) editor? > > Thanks, > Peter ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

April 22, 2016

remove unused variables

by Peter UhnÃ¡k

The editor used to inform when there was an unused local variable and offered to remove it. Is it possible to get this behavior back, or is it a feature regression with the "new" (this changed some time ago) editor? Thanks, Peter

April 21, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Eliot Miranda

On Thu, Apr 21, 2016 at 1:24 PM, stepharo <stepharo(a)free.fr> wrote: > Hi eliot > > do you imply that the logic at the level of the image changed in squeak. > Because Pharo50 is also running Spur on a CogSpur Vm? > The only logic that chanes at the image level is - no more compact classes, so indexIfCompact is missing - a primitive to answer allInstances instead of someInstance/nextInstance loop - a primitive to answer allObjects instead of a firstObject/nextObject loop - a special primitive version of identityHash in Behavior Above this layer everything looks the same. But some things work much better (many more identityHash values, faster allocation, etc). > Stef > > Le 21/4/16 16:48, Eliot Miranda a Ã©crit : > > Hi Bernhard, >> >> On Apr 20, 2016, at 9:56 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> Hi Eliot, >>> >>> Right, but in the latest Squeak5.1-trunk with the latest >>> CogSpur.r3663.app it takes only 3 milliseconds. I guess itâs just an >>> optimized implementation, there. (Canât look right now.) >>> >> Indeed ;-). In most Smalltalk implementations an object's header >> contains a direct reference (a pointer) to its class, but in Spur, an >> object's header contains a "class index" (as does the Dart VM). IIRC this >> is an approach first tried in a system at Xerox PARC, but what follows, I >> invented for 64-bit VW, to avoid having 64-bits of class reference in every >> object. >> >> The object header contains both a 22-bit classIndex, for up to 4 million >> classes, and a 22-bit identityHash field for 4 million hash values. The >> classIndex is used in all method caches, which has advantages for the GC, >> and means that when sending a message via an inline cache, the object's >> index is fetched, not its class. >> >> Classes are stored in a hidden two-level sparse array (array of arrays), >> the class table. If the object's class object is required (for the #class >> message or to do a full message lookup searching the inheritance hierarchy) >> the classIndex is used to index the class table. >> >> The classes known to the VM, Array, Message, Context, >> LargeNegativeInteger, LargePositiveInteger have known indices and occupy >> the first page of the class table. So the VM can allocate instances of >> these by simply writing a header containing the relevant classIndex. A >> conventional implementation would have to fetch the class from the >> specialObjectsArray and write it into the header (and in pre-Spur, there >> are 31 "compact class indices" of which a handful are used for a subset of >> the classes). >> >> But how does the VM find the classIndex of an arbitrary class? Searching >> the table would be very slow. So Spur arranges that a class's identityHash >> is also its index in the classTable. Classes have their own special >> identityHash primitive, see Behavior>>#identityHash. Whenever the VM tries >> to Instantiate a class, or whenever the class's identityHash primitive is >> run, if the class's identityHash is zero, the VM assigns an unused index in >> the class table as the identityHash and stores the class in the table. So >> a class's identityHash is its index in the class table. >> >> To Instantiate a class its identityHash is copied into the classIndex >> field of the new instance's header. To search for all instances of a >> class, the VM searches for objects whose classIndex is that class's >> identityHash. A consequence is that if a class doesn't yet have an >> identityHash (identityHash = 0) it can't have instances, and so there is no >> need to scan the heap. >> >> >> Note that you can't (easily) tell from the image. If you send >> identityHash to a class that will enter it into the table. There's a >> hidden hasIdentityHash primitive that can be used, and if you're curious I >> can post code to get at it. Note that this implies all the metaclasses are >> in the table because they have as their single instance a normal named >> class, but Metaclasses holds onto its instance via thisClass and so can >> also avoid traversing the heap. >> >> Some things to try: >> >> {Array. ByteString. Character. Context. LargeNegativeInteger. >> LargePositiveInteger. Message. SmallFloat64. BoxedFloat64. SmallInteger} >> collect: #identityHash >> >> and in a pre-Spur system >> >> Smalltalk compactClassesArray select: [:c| Smalltalk specialObjectsArray >> includes: c] thenCollect: [:c| {c. c indexIfCompact] >> >> Hope this explains what's going on under the covers. >> >> Cheers, >>> Bernhard >>> >>> Am 20.04.2016 um 17:43 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> Hi Bernhard, >>>> >>>> >>>> On Apr 20, 2016, at 5:26 AM, Bernhard Pieber <bernhard(a)pieber.com> >>>>> wrote: >>>>> >>>>> Dear Pharoers, >>>>> >>>>> I found something strange: >>>>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >>>>> >>>> Because it does an allInstances for Class and all its subclasses, and >>>> allInstances visits every object in the heap, so this does thousands of >>>> scans of the heap. >>>> >>>> >>>> I did this on a new Pharo 5 image >>>>> curl get.pharo.org/alpha+vmLatest | bash >>>>> >>>>> Can somebody confirm this on their machine? What might be the reason? >>>>> >>>>> Cheers, >>>>> Bernhard >>>>> >>>> >>> >> > > -- _,,,^..^,,,_ best, Eliot

April 21, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by stepharo

Hi eliot do you imply that the logic at the level of the image changed in squeak. Because Pharo50 is also running Spur on a CogSpur Vm? Stef Le 21/4/16 16:48, Eliot Miranda a Ã©crit : > Hi Bernhard, > >> On Apr 20, 2016, at 9:56 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> Hi Eliot, >> >> Right, but in the latest Squeak5.1-trunk with the latest CogSpur.r3663.app it takes only 3 milliseconds. I guess itâs just an optimized implementation, there. (Canât look right now.) > Indeed ;-). In most Smalltalk implementations an object's header contains a direct reference (a pointer) to its class, but in Spur, an object's header contains a "class index" (as does the Dart VM). IIRC this is an approach first tried in a system at Xerox PARC, but what follows, I invented for 64-bit VW, to avoid having 64-bits of class reference in every object. > > The object header contains both a 22-bit classIndex, for up to 4 million classes, and a 22-bit identityHash field for 4 million hash values. The classIndex is used in all method caches, which has advantages for the GC, and means that when sending a message via an inline cache, the object's index is fetched, not its class. > > Classes are stored in a hidden two-level sparse array (array of arrays), the class table. If the object's class object is required (for the #class message or to do a full message lookup searching the inheritance hierarchy) the classIndex is used to index the class table. > > The classes known to the VM, Array, Message, Context, LargeNegativeInteger, LargePositiveInteger have known indices and occupy the first page of the class table. So the VM can allocate instances of these by simply writing a header containing the relevant classIndex. A conventional implementation would have to fetch the class from the specialObjectsArray and write it into the header (and in pre-Spur, there are 31 "compact class indices" of which a handful are used for a subset of the classes). > > But how does the VM find the classIndex of an arbitrary class? Searching the table would be very slow. So Spur arranges that a class's identityHash is also its index in the classTable. Classes have their own special identityHash primitive, see Behavior>>#identityHash. Whenever the VM tries to Instantiate a class, or whenever the class's identityHash primitive is run, if the class's identityHash is zero, the VM assigns an unused index in the class table as the identityHash and stores the class in the table. So a class's identityHash is its index in the class table. > > To Instantiate a class its identityHash is copied into the classIndex field of the new instance's header. To search for all instances of a class, the VM searches for objects whose classIndex is that class's identityHash. A consequence is that if a class doesn't yet have an identityHash (identityHash = 0) it can't have instances, and so there is no need to scan the heap. > > > Note that you can't (easily) tell from the image. If you send identityHash to a class that will enter it into the table. There's a hidden hasIdentityHash primitive that can be used, and if you're curious I can post code to get at it. Note that this implies all the metaclasses are in the table because they have as their single instance a normal named class, but Metaclasses holds onto its instance via thisClass and so can also avoid traversing the heap. > > Some things to try: > > {Array. ByteString. Character. Context. LargeNegativeInteger. LargePositiveInteger. Message. SmallFloat64. BoxedFloat64. SmallInteger} collect: #identityHash > > and in a pre-Spur system > > Smalltalk compactClassesArray select: [:c| Smalltalk specialObjectsArray includes: c] thenCollect: [:c| {c. c indexIfCompact] > > Hope this explains what's going on under the covers. > >> Cheers, >> Bernhard >> >>> Am 20.04.2016 um 17:43 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Hi Bernhard, >>> >>> >>>> On Apr 20, 2016, at 5:26 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> Dear Pharoers, >>>> >>>> I found something strange: >>>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >>> Because it does an allInstances for Class and all its subclasses, and allInstances visits every object in the heap, so this does thousands of scans of the heap. >>> >>> >>>> I did this on a new Pharo 5 image >>>> curl get.pharo.org/alpha+vmLatest | bash >>>> >>>> Can somebody confirm this on their machine? What might be the reason? >>>> >>>> Cheers, >>>> Bernhard >> >

April 21, 2016

Re: [Pharo-dev] Some GT tool for this?

by Mariano Martinez Peck

Hi Andrei, I cannot seem to find this feature anymore in 5.0. Do you know how can I reach to "History" I cannot find it as a filter... Thanks in advance, On Fri, Jan 1, 2016 at 12:50 PM, stepharo <stepharo(a)free.fr> wrote: > Andrei / Mariano > > could you package them as extension of MC and we can integrate them in > Pharo. > > Stef > > > Le 11/12/15 20:01, Andrei Chis a Ã©crit : > > You can add the two methods below. Then when you open Spotter on a package > you can also search through it's history. > This will trigger an update if the history is not present, but Spotter > will still respond quite fast. > > You can also dive in a MCVersionInfo to see its ancestors. > > RPackage>>spotterHistoryFor: aStep > <spotterOrder: 100> > aStep listProcessor > title: 'History'; > allCandidates: [ |ancestry| > ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = > self name]) ancestry. > ancestry withBreadthFirstAncestors select: [:each | each isKindOf: > MCVersionInfo] ]; > candidatesLimit: 50; > itemName: [ :each | each name, ' - ', each message ]; > filter: GTFilterSubstrings > > MCVersionInfo>>spotterPreviewCodeIn: aComposite > <spotterPreview: 10> > aComposite text > title: 'Summary'; > display: [ > self summaryHeader, String cr, > 'Message:', String cr, self message ]; > entity: self. > Cheers, > Andrei > > > > On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Mariano, >> >> for this in Squeak I added a simple menu pick to the Monticello >> Browser's package list menu called "search history" which opens up a >> workspace containing the entire history as a flat string. I then just >> search using ctrl-f. You can find it in a current squeak trunk image. >> >> _,,,^..^,,,_ (phone) >> >> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> How many times have you tried to search a string as a comment of a commit >> in all the history? Myself: many many times. I know we need much better >> tools for that, store the history in a another way, provide a nicer API, >> etc etc. And I know there were topics about that. >> >> However, I would deeply appreciate a very short term solution for ease >> that. The model side is as simple as this: >> >> | packageName ancestry anscestors substring | >> packageName := 'MyPackageXX'. >> substring := 'whatever I want to search'. >> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName >> = packageName] ) ancestry. >> anscestors := ancestry withBreadthFirstAncestors select: [:each | each >> isKindOf: MCVersionInfo]. >> anscestors select: [ :each | each message includesSubstring: substring ] >> >> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? >> >> Cheers, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > -- Mariano http://marianopeck.wordpress.com

April 21, 2016

Re: [Pharo-dev] Smalltalk ui icons foo -> Smalltalk ui icons iconNamed: #foo

by stepharo

Sure :) Write Le 21/4/16 18:11, Yuriy Tymchuk a Ã©crit : > Is it ok to do that next week? Iâm a bit busy at the moment (actually writing about this stuff). > > Uko > >> On 21 Apr 2016, at 14:13, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> With the changes made by esteban all the tools should be accessing icons using iconNamed: >> Yes Yuriy it would be good to have a nice QA rule >> >> Smalltalk ui icons foo -> Smalltalk ui icons iconNamed: #foo >> >> The DNU trick should be deprecated in Pharo 60. >> Could you update your tools and we will do it for all the non externally managed ones? >> >> Stef >> >> > >

April 21, 2016

Re: [Pharo-dev] Smalltalk ui icons foo -> Smalltalk ui icons iconNamed: #foo

by Yuriy Tymchuk

Is it ok to do that next week? Iâm a bit busy at the moment (actually writing about this stuff). Uko > On 21 Apr 2016, at 14:13, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > With the changes made by esteban all the tools should be accessing icons using iconNamed: > Yes Yuriy it would be good to have a nice QA rule > > Smalltalk ui icons foo -> Smalltalk ui icons iconNamed: #foo > > The DNU trick should be deprecated in Pharo 60. > Could you update your tools and we will do it for all the non externally managed ones? > > Stef > >

April 21, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Eliot Miranda

Hi Bernhard, > On Apr 20, 2016, at 9:56 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Hi Eliot, > > Right, but in the latest Squeak5.1-trunk with the latest CogSpur.r3663.app it takes only 3 milliseconds. I guess itâs just an optimized implementation, there. (Canât look right now.) Indeed ;-). In most Smalltalk implementations an object's header contains a direct reference (a pointer) to its class, but in Spur, an object's header contains a "class index" (as does the Dart VM). IIRC this is an approach first tried in a system at Xerox PARC, but what follows, I invented for 64-bit VW, to avoid having 64-bits of class reference in every object. The object header contains both a 22-bit classIndex, for up to 4 million classes, and a 22-bit identityHash field for 4 million hash values. The classIndex is used in all method caches, which has advantages for the GC, and means that when sending a message via an inline cache, the object's index is fetched, not its class. Classes are stored in a hidden two-level sparse array (array of arrays), the class table. If the object's class object is required (for the #class message or to do a full message lookup searching the inheritance hierarchy) the classIndex is used to index the class table. The classes known to the VM, Array, Message, Context, LargeNegativeInteger, LargePositiveInteger have known indices and occupy the first page of the class table. So the VM can allocate instances of these by simply writing a header containing the relevant classIndex. A conventional implementation would have to fetch the class from the specialObjectsArray and write it into the header (and in pre-Spur, there are 31 "compact class indices" of which a handful are used for a subset of the classes). But how does the VM find the classIndex of an arbitrary class? Searching the table would be very slow. So Spur arranges that a class's identityHash is also its index in the classTable. Classes have their own special identityHash primitive, see Behavior>>#identityHash. Whenever the VM tries to Instantiate a class, or whenever the class's identityHash primitive is run, if the class's identityHash is zero, the VM assigns an unused index in the class table as the identityHash and stores the class in the table. So a class's identityHash is its index in the class table. To Instantiate a class its identityHash is copied into the classIndex field of the new instance's header. To search for all instances of a class, the VM searches for objects whose classIndex is that class's identityHash. A consequence is that if a class doesn't yet have an identityHash (identityHash = 0) it can't have instances, and so there is no need to scan the heap. Note that you can't (easily) tell from the image. If you send identityHash to a class that will enter it into the table. There's a hidden hasIdentityHash primitive that can be used, and if you're curious I can post code to get at it. Note that this implies all the metaclasses are in the table because they have as their single instance a normal named class, but Metaclasses holds onto its instance via thisClass and so can also avoid traversing the heap. Some things to try: {Array. ByteString. Character. Context. LargeNegativeInteger. LargePositiveInteger. Message. SmallFloat64. BoxedFloat64. SmallInteger} collect: #identityHash and in a pre-Spur system Smalltalk compactClassesArray select: [:c| Smalltalk specialObjectsArray includes: c] thenCollect: [:c| {c. c indexIfCompact] Hope this explains what's going on under the covers. > Cheers, > Bernhard > >> Am 20.04.2016 um 17:43 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Hi Bernhard, >> >> >>> On Apr 20, 2016, at 5:26 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> Dear Pharoers, >>> >>> I found something strange: >>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >> >> Because it does an allInstances for Class and all its subclasses, and allInstances visits every object in the heap, so this does thousands of scans of the heap. >> >> >>> I did this on a new Pharo 5 image >>> curl get.pharo.org/alpha+vmLatest | bash >>> >>> Can somebody confirm this on their machine? What might be the reason? >>> >>> Cheers, >>> Bernhard > >

April 21, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Denis Kudriashov

2016-04-21 15:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > I think we not need special LoggerUI app. We can just inspect > SystemLogger instance to look at all recorded objects. And in perspective > of my suggestions it will mean that we just explore particular ObjectLog. > And we can extend GTInspector for this. > > > > Take a look at Beacon. The GTInspector extensions are provided out of the > box. Yes, I know. That's why I mention it. And I expect it will become much better in future. That's why I would not spend time to create special inspector for logs.

April 21, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Denis Kudriashov

2016-04-21 14:57 GMT+02:00 stepharo <stepharo(a)free.fr>: > > - name SystemLogger for collection based log. > > SystemLogger makes me think that it is singleton which is used by system > and I should not use it for my own application. > I would call it like ObjectLog or NativeLog (following my first sentence > about Log). > > It was the same as SystemAnnouncer. SystemAnnouncer is what we really use. We subscribe our tools on it. But SystemLogger is completely different case. Nobody is supposed to use it because users work with Log.

April 21, 2016