January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Understanding Object Structures

by Eliot Miranda

Hi Thierry, On Jan 16, 2015, at 8:10 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-01-16 16:55 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi All, >> >> On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> > Hi Marcel, >> > >> > On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <marcel.taeumel(a)student.hpi.uni-potsdam.de> wrote: >> > >> >> Ah, okay. I was curious about the performance of iterating over an array vs. >> >> the linked list: >> >> >> >> a := Array new: 1000. >> >> l := LinkedList new. >> >> >> >> 1000 timesRepeat: [l add: (StackLink with: nil)]. >> >> >> >> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'" >> >> >> >> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'" >> >> >> >> I expected the opposite! :-O Why is that so? >> > >> > Look at the implementations of do:. >> > >> > In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element. >> > >> > In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element. >> >> This is interesting. (Marcel, Chris, forgive me; I'm presuming; please don't take this personally). Marcel above appears to lack an intuition about the structure of Array vs LinkedList. And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers. >> >> As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head. Those pictures are key to my approach to design and optimization. >> >> I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures. >> >> I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments. >> >> Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment. > > > >> >> A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration. >> >> Either approach would make an interesting project, yes? > > I would prefer something conceptually simpler and worthwhile: the ability to embed a morph as a character in the text (would do the two approaches easily). And a bit of marshalling/text representation to make a completely textual representation possible. Yes that's a *much* better idea and one we could realize v quickly. > > I used to have that for hypermedia (i.e. a drawing editor with text frame objects, and text frames able to display GUI components... in ParcPlace Smalltalk) > > Now I dream a bit of having something like TiddlyWiki in Pharo ;) > > Thierry >

Jan. 16, 2015

Re: [Pharo-dev] Understanding Object Structures

by Thierry Goubier

2015-01-16 16:55 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi All, > > On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi Marcel, > > > > On Jan 16, 2015, at 5:54 AM, Marcel Taeumel < > marcel.taeumel(a)student.hpi.uni-potsdam.de> wrote: > > > >> Ah, okay. I was curious about the performance of iterating over an > array vs. > >> the linked list: > >> > >> a := Array new: 1000. > >> l := LinkedList new. > >> > >> 1000 timesRepeat: [l add: (StackLink with: nil)]. > >> > >> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'" > >> > >> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'" > >> > >> I expected the opposite! :-O Why is that so? > > > > Look at the implementations of do:. > > > > In the Array case we iterate over the indices using SmallIntegers (fast > arithmetic with no allocation) and dereference each element using the > Object>>at: primitive, which (apart from type and bounds checking) is > simple indexed memory access. So one read per element. > > > > In the LinkedList case each list element is fetched from the previous > element and each value fetched from the element, so two reads per element. > > This is interesting. (Marcel, Chris, forgive me; I'm presuming; please > don't take this personally). Marcel above appears to lack an intuition > about the structure of Array vs LinkedList. And in developing a hash > algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to > lack an I tuition about Floats being boxed, assuming they were value types, > not containers. > > As a VM implementer I carry around a clear picture (literally, I am a > visual thinker) of objects in my head. Those pictures are key to my > approach to design and optimization. > > I presume that for someone approaching the system given only a textual > description of object structures, through class comments and method source > it is difficult to develop a good picture or mental model. For me, I read > the blue book first, which is replete with pictures. > > I know that historically visual inspector frameworks such as Jun have been > able to auto-generate pictorial representations of specific object graphs. > I wonder how useful it would be to provide support for designers to include > pictorial representations in class comments. > > Again I presume that the text model would have to support inclusion of > simple bitmaps (to avoid having to include a full drawing framework in the > system) and that the designer would construct a sample graph, generate a > diagram using a visual inspector framework using eg Jun, render it to a > bitmap and include it in the class comment. > > > A more elaborate system could of course include the sample graph and > render it dynamically, that would allow exploration. > > Either approach would make an interesting project, yes? > I would prefer something conceptually simpler and worthwhile: the ability to embed a morph as a character in the text (would do the two approaches easily). And a bit of marshalling/text representation to make a completely textual representation possible. I used to have that for hypermedia (i.e. a drawing editor with text frame objects, and text frames able to display GUI components... in ParcPlace Smalltalk) Now I dream a bit of having something like TiddlyWiki in Pharo ;) Thierry

Jan. 16, 2015

Understanding Object Structures

by Eliot Miranda

Hi All, On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Marcel, > > On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <marcel.taeumel(a)student.hpi.uni-potsdam.de> wrote: > >> Ah, okay. I was curious about the performance of iterating over an array vs. >> the linked list: >> >> a := Array new: 1000. >> l := LinkedList new. >> >> 1000 timesRepeat: [l add: (StackLink with: nil)]. >> >> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'" >> >> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'" >> >> I expected the opposite! :-O Why is that so? > > Look at the implementations of do:. > > In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element. > > In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element. This is interesting. (Marcel, Chris, forgive me; I'm presuming; please don't take this personally). Marcel above appears to lack an intuition about the structure of Array vs LinkedList. And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers. As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head. Those pictures are key to my approach to design and optimization. I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures. I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments. Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment. A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration. Either approach would make an interesting project, yes? >> Best, >> Marcel >> >> >> >> -- >> View this message in context: http://forum.world.st/The-Trunk-Collections-mt-593-mcz-tp4799750p4799893.ht… >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>

Jan. 16, 2015

Re: [Pharo-dev] review request

by Ben Coman

I know everyone is busy and working in their own domains not having the time to review a lot of other people's issues. However I am on my own, not part of a team where I can walk over and tap someone on the shoulder to ask for review of an issue I've resolved. It is a bit discouraging not to be able to proceed for lack of review. I'd be glad for any feedback including "its crap, do it a different way". So consider this a virtual should tap. I have... * refactored the two calls to #forMilliseconds: out to a single call * replaced call to #wait with #waitOr: * added #waitOr: Here is the diff... WorldState >> interCyclePause: milliSecs | currentTime wait | self serverMode ifFalse: [ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ currentTime := Time millisecondClockValue. wait := lastCycleTime + milliSecs - currentTime. + "wait is the time remaining until milliSecs has passed + since lastCycle. If wait is zero or less, no need to Delay" + "If wait is greater than milliSeconds then bypass Delay, + by setting wait to zero." - (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ - (Delay forMilliseconds: wait) wait ] ] ] + wait > milliSecs ifTrue: [ wait := 0 ] ] ] "btw, wait>milliSecs can only occur when clock rolls over. Eliminate after integrating issue 14353 ?" - ifTrue: [ (Delay forMilliseconds: 50) wait ]. + ifTrue: [ wait := 50 ]. + wait > 0 ifTrue: [ + (Delay forMilliseconds: wait) waitOr: [ + self inform: 'WorldState>>interCyclePause failed.' ] ]. lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. "--------------------------" +Delay >> waitOr: anErrorBlock + self schedule. + [ beingWaitedOn + ifTrue: [ delaySemaphore wait ] + ifFalse:[ anErrorBlock value ] + ] ifCurtailed:[self unschedule]. +"Only the high priority timer event loop (TEL) signals /delaySempahore/. If the + TEL is not running, a delay will block forever (for example the UI will lock up). + /beingWaitedOn/ is only set to true from the TEL (via + DelayScheduler>>scheduleDelay: and Delay>>timingPriorityWaitedOn:) so test + this to determine if TEL is running. Avoid waiting when the TEL is not running." "--------------------------" This is for issue 14669 "Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped" that is required to facilitate integration of issue 14353 "Delay refactoring (part 2) - change from milliseconds to microseconds. cheers -ben https://pharo.fogbugz.com/default.asp?14669 https://pharo.fogbugz.com/default.asp?14353

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Damien Pollet

On 16 January 2015 at 16:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> How do you do that? > > double click on the valueâ¦ (it is a secret feature for now ;-) hhhaaahhhh :) it worked via writing an accessor method too -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Marcus Denker

> On 16 Jan 2015, at 12:20, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > On 16 January 2015 at 14:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> change âivâ to value (e.g. 5). > > How do you do that? double click on the valueâ¦ (it is a secret feature for now ;-) > When I try iv := 5 in the inspector, it looks like it's changing a > local variable instead of the slot (as if the bottom field of the > inspector was a workspace) > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Marcus Denker

> On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > For me it's ok like it is now. > > > I updated the GTDebuggers to use slots. > For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot). > > <Screen Shot 2015-01-16 at 4.06.03 PM.png> > Wow! And just like that, the byte code debugger is actually very useful to see what happens for real with Slotsâ¦. very useful especially when you emit you own byte code for a Slot. > Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. > The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account. > Yes, that would be nice. Marcus

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Damien Pollet

On 16 January 2015 at 14:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > change âivâ to value (e.g. 5). How do you do that? When I try iv := 5 in the inspector, it looks like it's changing a local variable instead of the slot (as if the bottom field of the inspector was a workspace) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Andrei Chis

For me it's ok like it is now. I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot). [image: Inline image 1] Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account. Cheers, Andrei On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > Hi Marcus, > > > > So now ' self class allSlots ' should be used also in the debugger to > get the instance variables of an object? > > > > Yes, at least for nowâ¦ I am not yet that happy with the namingâ¦ it is hard > to get consistent *and* be resably compatibleâ¦. > > So the idea is that the old API for (instVarAt:, instVarNamesâ¦) continues > to work *but* this shows (and manipulates) > what is really there. VM level instance variables. > > Slots are first class instance variables that > a) might redefine what happens of read/write > â> all reflective read and write needs to go > through the slots. > b) they often correspond 1:1 to a low level ivar, but they donât > have to (e.g. the TestSlot in the example has no underlying ivar) > â> we need to ask for all Slots, not just all > instVarNames. > > For the namingâ¦ in some way Slots are just âFirst Class Instance > Variablesâ that map to VM level Fields. > Sometimes I feel it would be nice to use just these two for naming: Fields > (VM Level) and Instance Variables (Image level, aka Slots). > > But then, there is backward compatibility to be taken into accountâ¦ we > canât really change instVarAt:â¦ but we could of course keep > those for legacy and use the âlong formâ for the âreifiedâ instance > variables: instanceVariableNamed:, #instanceVariableNames, and so onâ¦ > > To make it really consistent and just use âField and Ivar", there would be > a lot to be changed: names of byte codes, for example. > So maybe having it like it is now is good? âField and Ivarâ are one > concept, while the high-level one is âSlotâ. > > I am not sure myselfâ¦ I have to admit. > > Marcus > > >

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Marcus Denker

> On 16 Jan 2015, at 11:44, Ben Coman <btc(a)openInWorld.com> wrote: > > do you mean...? > https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayou… <https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayou…> > No, Tims refers to the mails I sendâ¦ describing the reflective reading and writing if Slots. My probkem is that I could now dig that out and postpone other things. But I will not. i will write a tutorial later, but not now. (I am already behind at least 3 things that people are waiting for that have higher priorityâ¦) Marcus

Jan. 16, 2015