- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3821 in pharo: makeStrong/makeWeak contains a bug

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com CC: siguc...(a)gmail.com, ryd...(a)gmail.com Labels: Milestone-1.3 New issue 3821 by stephane...(a)gmail.com: makeStrong/makeWeak contains a bug http://code.google.com/p/pharo/issues/detail?id=3821 makeStrong/makeWeak contains a bug, because it is using #becomeForward: but doesn't takes into account that subscription stored in a set , which is hash-based , so after become, the item will be at wrong position. So, we need to implement announcer>>replace: subscription with: newOne then a) we don't have to use become b) it will be thread safe, because you can protect replacement in subscription registry with monitor As an alternative, we can use Set instead of IdentitySet, and implement #hash and #== for subscriptions which don't changing when you switch between weak/strong. Then we can keep using #becomeForward: -- Best regards, Igor Stasenko AKA sig.

March 16, 2011

Re: [Pharo-project] Lumiere on Linux?

by StÃ©phane Ducasse

igor first a canvas because lot of people can help for using it and this will support parallelisation of actions. Stef > from this message i learn that i have to kick my ass and continue > working on NativeBoost, > including its OpenGL bindings. > > Too bad, there is not much people who can do low level assembly + VM > hacking + openGL hacking > and interested in pushing NB forward and/or collaborating with me :( > > On 16 March 2011 00:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Hi Alex, i'm sad to hear that AlienOpenGL is not working for you, i'm >> currently not mainting it. IMO opinion the Croquet OpengL and Igor's >> native boost OpenGL are far better choices for interfacing with >> OpenGL. >> Lumiere is conceptually designed to work with any of the above, but >> currently tied to AlienOpenGL. Wouldn't take much to plug the other >> two, and you would get the high level abstractions over OpenGL that >> Lumiere offers. >> >> Regarding the boost, it highly depends on the 3D application being >> built. http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node… >> Anyway, Croquet OpenGL does the computation on Smalltalk, (but i think >> FloatArray is using a plugin).With Lumiere i left the matrix >> calculations to OpenGL, but you get less functionality. >> >> The boost comes not from the matrix calculations but because of the >> efficient rendering engine (parallel pipelines) implemented in low >> level language, as opposed doing everything in Smalltalk. >> Again, this depends on the 3D application being built. >> >> Regarding the tool that you mentioned, how do you simulate 3D, in the >> 2D Morphic framework? I'm finding hard to understand how can you >> achieve a Morphic cube. >> >> Saludos, >> Fernando >> >> On Tue, Mar 15, 2011 at 7:29 PM, Alexandre Bergel >> <alexandre.bergel(a)me.com> wrote: >>>> Great. What about the usual "native code" speed boost? Are you writing a plugin, or is it all Smalltalk code? >>> >>> It is all Smalltalk code. We are not against native libraries, however we could not make it run. And so, after several months of intensive tries. So, in order to make some progress, we coded a 3d engine in Smalltalk. Actually, this is not difficult (for basic functionalities such as light, cubes, camera -- no texture and complex light rendering). I did a 2d engine for Mondrian. So having a 3d engine should not be that hard (actually it is not). The nice advantage, that it should work on the ipad, iphone, web, ... >>> >>> Other things, I would be surprise to have a significant boost by using OpenGL for rendering objects if all the matrix computations are realized in Smalltalk. Anyone can comment on it? >>> >>> Cheers, >>> Alexandre >>> > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 16, 2011

Re: [Pharo-project] Cog/FFI Return Values

by StÃ©phane Ducasse

ken it would be good to enter a bug entry on the cog vm bug tracker. Stef On Mar 15, 2011, at 11:19 PM, Ken Treis wrote: > For kicks, I tried running the GemStone tools in a Cog VM. It *almost* works. Apparently this sort of call: > >> apiGciPerform: anOopType a: aString a: anArray a: anInteger >> >> <apicall: OopType64 'GciPerform' (OopType64 char* ulong long) > >> ^self externalCallFailed > > ... works differently now. In the old (non-Cog) VM, it return an instance of OopType64. In Cog, it returns a SmallInteger. > > The function itself returns a uint64_t, so apparently the OopType64 class (a subclass of ExternalStructure) is being used to trick the FFI into automatically wrapping the return value in the way we want. > > 1. Is this trick no longer supported/legit (assuming it ever was)? > 2. Is there a better way to accomplish the same thing, or do we just have to do the wrapping ourselves now? > > I'm pretty new to the FFI, so forgive me if the premise is wrong. All I know is that it doesn't work the way it used to. :) > > -- > Ken Treis > Miriam Technologies, Inc. > >

March 16, 2011

Re: [Pharo-project] Lumiere on Linux?

by Igor Stasenko

from this message i learn that i have to kick my ass and continue working on NativeBoost, including its OpenGL bindings. Too bad, there is not much people who can do low level assembly + VM hacking + openGL hacking and interested in pushing NB forward and/or collaborating with me :( On 16 March 2011 00:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi Alex, Â i'm sad to hear that AlienOpenGL is not working for you, i'm > currently not mainting it. IMO opinion the Croquet OpengL and Igor's > native boost OpenGL are far better choices for interfacing with > OpenGL. > Lumiere is conceptually designed to work with any of the above, but > currently tied to AlienOpenGL. Wouldn't take much to plug the other > two, and you would get the high level abstractions over OpenGL that > Lumiere offers. > > Regarding the boost, it highly depends on the 3D application being > built. http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node… > Anyway, Croquet OpenGL does the computation on Smalltalk, (but i think > FloatArray is using a plugin).With Lumiere i left the matrix > calculations to OpenGL, but you get less functionality. > > The boost comes not from the matrix calculations but Â because of the > efficient rendering engine (parallel pipelines) implemented in low > level language, as opposed doing everything in Smalltalk. > Again, this depends on the 3D application being built. > > Regarding the tool that you mentioned, Â how do you simulate 3D, in the > 2D Morphic framework? I'm finding hard to understand how can you > achieve a Morphic cube. > > Saludos, > Fernando > > On Tue, Mar 15, 2011 at 7:29 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >>> Great. Â What about the usual "native code" speed boost? Â Are you writing a plugin, or is it all Smalltalk code? >> >> It is all Smalltalk code. We are not against native libraries, however we could not make it run. And so, after several months of intensive tries. So, in order to make some progress, we coded a 3d engine in Smalltalk. Actually, this is not difficult (for basic functionalities such as light, cubes, camera -- no texture and complex light rendering). I did a 2d engine for Mondrian. So having a 3d engine should not be that hard (actually it is not). The nice advantage, that it should work on the ipad, iphone, web, ... >> >> Other things, I would be surprise to have a significant boost by using OpenGL for rendering objects if all the matrix computations are realized in Smalltalk. Anyone can comment on it? >> >> Cheers, >> Alexandre >> -- Best regards, Igor Stasenko AKA sig.

March 16, 2011

Re: [Pharo-project] Lumiere on Linux?

by Fernando Olivero

Hi Alex, i'm sad to hear that AlienOpenGL is not working for you, i'm currently not mainting it. IMO opinion the Croquet OpengL and Igor's native boost OpenGL are far better choices for interfacing with OpenGL. Lumiere is conceptually designed to work with any of the above, but currently tied to AlienOpenGL. Wouldn't take much to plug the other two, and you would get the high level abstractions over OpenGL that Lumiere offers. Regarding the boost, it highly depends on the 3D application being built. http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node… Anyway, Croquet OpenGL does the computation on Smalltalk, (but i think FloatArray is using a plugin).With Lumiere i left the matrix calculations to OpenGL, but you get less functionality. The boost comes not from the matrix calculations but because of the efficient rendering engine (parallel pipelines) implemented in low level language, as opposed doing everything in Smalltalk. Again, this depends on the 3D application being built. Regarding the tool that you mentioned, how do you simulate 3D, in the 2D Morphic framework? I'm finding hard to understand how can you achieve a Morphic cube. Saludos, Fernando On Tue, Mar 15, 2011 at 7:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Great. Â What about the usual "native code" speed boost? Â Are you writing a plugin, or is it all Smalltalk code? > > It is all Smalltalk code. We are not against native libraries, however we could not make it run. And so, after several months of intensive tries. So, in order to make some progress, we coded a 3d engine in Smalltalk. Actually, this is not difficult (for basic functionalities such as light, cubes, camera -- no texture and complex light rendering). I did a 2d engine for Mondrian. So having a 3d engine should not be that hard (actually it is not). The nice advantage, that it should work on the ipad, iphone, web, ... > > Other things, I would be surprise to have a significant boost by using OpenGL for rendering objects if all the matrix computations are realized in Smalltalk. Anyone can comment on it? > > Cheers, > Alexandre > >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Ricardo Jacas [ricardo.jacas(a)gmail.com] >> Sent: Tuesday, March 15, 2011 11:07 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Lumiere on Linux? >> >> Hi guys, as Alex said we are currently working on a quite simple 3d >> library entirely based on Morph. >> Right know there is only cubes and "3d lines" to play as we please, i >> will add some screenshots as soon as i have some spare time :) >> >> 2011/3/13 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Using libGL.so.1 gives similar results :( >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lemuus [lemuus(a)gmail.com] >>> Sent: Saturday, March 12, 2011 9:48 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Lumiere on Linux? >>> >>> I think that the correct choice is libGL.so,but I'm just guessing. >>> >>> On Sat, Mar 12, 2011 at 9:43 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> I tried the 1.2 one-click with Lumiere. Â Following the collaboractive book, >>> >>> Gofer it >>> Â Â Â squeaksource: 'Lumiere'; >>> Â Â Â package: 'ConfigurationOfLumiere'; >>> Â Â Â load. >>> Â Â Â ( Smalltalk globals classNamed:'ConfigurationOfLumiere' ) perform: #loadDefault. >>> >>> led to a warning about DisplayList(??), but seemed to work otherwise. Â Trying an example such as #testRenderingSphere gave an error trying open OpenGL.framework, which I had trouble finding on Linux. Â Changing AlienOpenGLLibrary>>libraryName to answer 'libglut.so.3' gets it to the point of a segment fault, shown below. Â Is glut the correct choice, or do I need to get or specify some other library? >>> >>> Bill >>> >>> >>> >>> >>> Segmentation fault >>> >>> Smalltalk stack dump: >>> 0xbfd1714c I AlienOpenGLLibrary>glMatrixMode: 2033044028: a(n) AlienOpenGLLibrary >>> 0xbfd17170 M [] in AlienOpenGLLibraryExamples>testRenderingSphere 2033042940: a(n) AlienOpenGLLibraryExamples >>> 0xbfd17190 M BlockClosure>ensure: 2033043980: a(n) BlockClosure >>> 0xbfd171b4 M AlienOpenGLLibraryExamples>testRenderingSphere 2033042940: a(n) AlienOpenGLLibraryExamples >>> 0xbfd171d4 I AlienOpenGLLibraryExamples class>run: 2024758496: a(n) AlienOpenGLLibraryExamples class >>> 0xbfd171f0 M AlienOpenGLLibraryExamples class>? 2024758496: a(n) AlienOpenGLLibraryExamples class >>> 0xbfd17228 I Compiler>evaluate:in:to:notifying:ifFail:logged: 2032491124: a(n) Compiler >>> 0xbfd17268 I [] in OBTextMorphEditorWithShout(SmalltalkEditor)>evaluateSelection 2025101912: a(n) OBTextMorphEditorWithShout >>> 0xbfd17284 M BlockClosure>on:do: 2032491080: a(n) BlockClosure >>> 0xbfd172b8 I OBTextMorphEditorWithShout(SmalltalkEditor)>evaluateSelection 2025101912: a(n) OBTextMorphEditorWithShout >>> 0xbfd172d0 M [] in OBPluggableTextMorphWithShout(PluggableTextMorph)>doIt 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd172f8 I [] in OBPluggableTextMorphWithShout(PluggableTextMorph)>handleEdit: 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd17318 I OBTextMorphWithShout(TextMorph)>handleEdit: 2024964024: a(n) OBTextMorphWithShout >>> 0xbfd17340 I OBPluggableTextMorphWithShout(PluggableTextMorph)>handleEdit: 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd1735c M OBPluggableTextMorphWithShout(PluggableTextMorph)>doIt 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd17378 M OBDefinitionPanel(OBTextPanel)>perform:orSendTo: 2024940940: a(n) OBDefinitionPanel >>> 0xbfd173a8 I [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd173c8 M BlockClosure>ensure: 2032477540: a(n) BlockClosure >>> 0xbfd173f0 I CursorWithMask(Cursor)>showWhile: 2002515888: a(n) CursorWithMask >>> 0xbfd17418 I ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd1743c I ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd17458 M ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd17474 M MouseButtonEvent>sentTo: 2032130572: a(n) MouseButtonEvent >>> 0xbfd17490 M ToggleMenuItemMorph(Morph)>handleEvent: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd174c0 M MorphicEventDispatcher>dispatchDefault:with: 2032130556: a(n) MorphicEventDispatcher >>> 0xbfd174e0 M MorphicEventDispatcher>dispatchEvent:with: 2032130556: a(n) MorphicEventDispatcher >>> 0xbfd17500 M ToggleMenuItemMorph(Morph)>processEvent:using: 2031928172: a(n) ToggleMenuItemMorph >>> 0xbfd17534 M MorphicEventDispatcher>dispatchDefault:with: 2032130556: a(n) MorphicEventDispatcher >>> 0xbfd17554 M MorphicEventDispatcher>dispatchEvent:with: 2032130556: a(n) MorphicEventDispatcher >>> 0xbfd17574 M MenuMorph(Morph)>processEvent:using: 2031927856: a(n) MenuMorph >>> 0xbfd17594 M MenuMorph(Morph)>processEvent: 2031927856: a(n) MenuMorph >>> 0xbfd175b0 M MenuMorph>handleFocusEvent: 2031927856: a(n) MenuMorph >>> 0xbfd175d8 M [] in HandMorph>sendFocusEvent:to:clear: 2002449320: a(n) HandMorph >>> 0xbfd175f4 M [] in PasteUpMorph>becomeActiveDuring: 2003523448: a(n) PasteUpMorph >>> 0xbfd17610 M BlockClosure>on:do: 2032130460: a(n) BlockClosure >>> 0xbfd1763c M PasteUpMorph>becomeActiveDuring: 2003523448: a(n) PasteUpMorph >>> 0xbfd17660 M HandMorph>sendFocusEvent:to:clear: 2002449320: a(n) HandMorph >>> 0xbfd17688 M HandMorph>sendEvent:focus:clear: 2002449320: a(n) HandMorph >>> 0xbfd176ac M HandMorph>sendMouseEvent: 2002449320: a(n) HandMorph >>> 0xbfd176d0 M HandMorph>handleEvent: 2002449320: a(n) HandMorph >>> 0xbfd176fc M HandMorph>processEvents 2002449320: a(n) HandMorph >>> 0xbfd17714 M [] in WorldState>doOneCycleNowFor: 2004924588: a(n) WorldState >>> 0xbfd17738 M Array(SequenceableCollection)>do: 2001081712: a(n) Array >>> 0xbfd17754 M WorldState>handsDo: 2004924588: a(n) WorldState >>> 0xbfd17770 M WorldState>doOneCycleNowFor: 2004924588: a(n) WorldState >>> 0xbfd1778c M WorldState>doOneCycleFor: 2004924588: a(n) WorldState >>> 0xbfd101bc M WorldState>doOneSubCycleFor: 2004924588: a(n) WorldState >>> 0xbfd101d8 M PasteUpMorph>doOneSubCycle 2003523448: a(n) PasteUpMorph >>> 0xbfd10200 I MenuMorph>invokeModalAt:in:allowKeyboard: 2031927856: a(n) MenuMorph >>> 0xbfd1022c I MenuMorph>invokeModal: 2031927856: a(n) MenuMorph >>> 0xbfd10250 I MenuMorph>invokeModal 2031927856: a(n) MenuMorph >>> 0xbfd10274 I OBPluggableTextMorphWithShout(PluggableTextMorph)>yellowButtonActivity: 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd10298 I OBTextMorphWithShout(TextMorphForEditView)>mouseDown: 2024964024: a(n) OBTextMorphWithShout >>> 0xbfd102b4 M OBTextMorphWithShout(Morph)>handleMouseDown: 2024964024: a(n) OBTextMorphWithShout >>> 0xbfd102d0 M MouseButtonEvent>sentTo: 2031927788: a(n) MouseButtonEvent >>> 0xbfd102ec M OBTextMorphWithShout(Morph)>handleEvent: 2024964024: a(n) OBTextMorphWithShout >>> 0xbfd10328 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10348 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10368 M OBTextMorphWithShout(Morph)>processEvent:using: 2024964024: a(n) OBTextMorphWithShout >>> 0xbfd103a8 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd103c8 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd103e8 M TransformMorph(Morph)>processEvent:using: 2024963800: a(n) TransformMorph >>> 0xbfd10428 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10448 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10468 M OBPluggableTextMorphWithShout(Morph)>processEvent:using: 2024962936: a(n) OBPluggableTextMorphWithShout >>> 0xbfd104a8 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd104c8 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd104e8 M OBGroupingMorph(Morph)>processEvent:using: 2024957608: a(n) OBGroupingMorph >>> 0xbfd10528 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10548 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd10568 M OBSystemWindow(Morph)>processEvent:using: 2024944124: a(n) OBSystemWindow >>> 0xbfd105a8 M MorphicEventDispatcher>dispatchMouseDown:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd105c8 M MorphicEventDispatcher>dispatchEvent:with: 2031927596: a(n) MorphicEventDispatcher >>> 0xbfd105e8 M PasteUpMorph(Morph)>processEvent:using: 2003523448: a(n) PasteUpMorph >>> 0xbfd10610 M PasteUpMorph>processEvent:using: 2003523448: a(n) PasteUpMorph >>> 0xbfd10630 M PasteUpMorph(Morph)>processEvent: 2003523448: a(n) PasteUpMorph >>> 0xbfd10650 M HandMorph>sendEvent:focus:clear: 2002449320: a(n) HandMorph >>> 0xbfd10674 M HandMorph>sendMouseEvent: 2002449320: a(n) HandMorph >>> 0xbfd10698 M HandMorph>handleEvent: 2002449320: a(n) HandMorph >>> 0xbfd106c4 M HandMorph>processEvents 2002449320: a(n) HandMorph >>> 0xbfd106dc M [] in WorldState>doOneCycleNowFor: 2004924588: a(n) WorldState >>> 0xbfd10700 M Array(SequenceableCollection)>do: 2001081712: a(n) Array >>> 0xbfd1071c M WorldState>handsDo: 2004924588: a(n) WorldState >>> 0xbfd10738 M WorldState>doOneCycleNowFor: 2004924588: a(n) WorldState >>> 0xbfd10754 M WorldState>doOneCycleFor: 2004924588: a(n) WorldState >>> 0xbfd10770 M PasteUpMorph>doOneCycle 2003523448: a(n) PasteUpMorph >>> 0xbfd10790 I [] in Project class>spawnNewProcess 2004397340: a(n) Project class >>> 2025126836 s [] in BlockClosure>newProcess >>> >>> Most recent primitives >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> at:put: >>> basicNew >>> new: >>> at:put: >>> at:put: >>> value:value: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> basicNew >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> basicNew: >>> at:put: >>> at:put: >>> basicNew: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> species >>> new: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> species >>> new: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> basicNew: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> basicNew: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> new >>> value:value: >>> value:value: >>> basicNew >>> size >>> basicNew >>> byteAt:put: >>> byteAt:put: >>> bitXor: >>> size >>> species >>> basicNew: >>> replaceFrom:to:with:startingAt: >>> basicNew: >>> replaceFrom:to:with:startingAt: >>> replaceFrom:to:with:startingAt: >>> basicNew: >>> basicNew >>> at:put: >>> species >>> basicNew: >>> replaceFrom:to:with:startingAt: >>> replaceFrom:to:with:startingAt: >>> size >>> at:put: >>> species >>> basicNew: >>> replaceFrom:to:with:startingAt: >>> size >>> size >>> size >>> perform:withArguments: >>> perform:withArguments: >>> species >>> basicNew >>> new: >>> value: >>> perform:withArguments: >>> at:put: >>> perform:withArguments: >>> species >>> new: >>> species >>> new: >>> species >>> new: >>> replaceFrom:to:with:startingAt: >>> newMethod:header: >>> at:put: >>> at:put: >>> at:put: >>> objectAt:put: >>> objectAt:put: >>> objectAt:put: >>> objectAt:put: >>> basicNew >>> size >>> objectAt: >>> basicNew >>> objectAt: >>> at:put: >>> at:put: >>> at:put: >>> at:put: >>> value >>> objectAt: >>> size >>> objectAt: >>> objectAt: >>> objectAt: >>> objectAt: >>> objectAt: >>> objectAt:put: >>> objectAt: >>> objectAt:put: >>> withArgs:executeMethod: >>> basicNew >>> perform: >>> basicNew >>> @ >>> basicNew >>> primCreateRenderer:x:y:w:h: >>> millisecondClockValue >>> signal >>> primSignal:atMilliseconds: >>> millisecondClockValue >>> wait >>> primGetNextEvent: >>> millisecondClockValue >>> wait >>> signal >>> millisecondClockValue >>> primSignal:atMilliseconds: >>> millisecondClockValue >>> wait >>> signal >>> wait >>> at:put: >>> primRender:getProperty: >>> basicNew >>> primLoadLibrary: >>> basicNew: >>> sizeFieldPut: >>> unsignedLongAt:put: >>> basicNew >>> new: >>> value >>> value >>> basicNew: >>> sizeFieldPut: >>> unsignedLongAt:put: >>> basicNew >>> at:put: >>> primFindSymbol: >>> basicNew: >>> sizeFieldPut: >>> addressFieldPut: >>> primFFICallResult:with: >>> Aborted >>> >>> >>> >>> >>> >> >> >> >> -- >> lets reign all together >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

March 15, 2011

Re: [Pharo-project] PBenchmark as a general framework for benchmarking in Smalltalk (commit access)

by Miguel CobÃ¡

Cool idea! Thanks. Cheers El mar, 15-03-2011 a las 23:37 +0100, Stefan Marr escribiÃ³: > Hi: > > Small update, I just created > http://www.squeaksource.com/SMark.html > > SMark is the attempt to build a common benchmarking framework for Smalltalk. > It inspired from the metaphor used for unit testing in SUnit, and thus, a benchmark is implemented by adding #benchMyBenchmark to a subclass of SBenchmarkSuite. > > The code is originally based on PBenchmark the benchmark framework used for the PinocchioVM and RoarBenchmark a framework used for performance regression testing of the RoarVM. Other sources of inspiration are for instance the Caliper microbenchmarking framework for Java. (http://code.google.com/p/caliper/) > > The name choice of SMark is deliberately confusable with smark (as defined by the urban dictionary: Noun. A person who is being scamed but is in on the prank. Someone who knows they are being tricked. Its origin is from the term "mark" and is the shortened form of the phrase "smart mark".) freely following the old wisdom: "Lies, Damn Lies, and --Statistics-- Benchmarks" > > > Current status is still pretty early, I am spec'ing out the behavior and data structures I imaging with tests. And I haven't actually renamed anything to new names yet. > > The next update here will be once there is something actually usable. > However, the project is world-writeable, so feel free to have a look. > > Best regards > Stefan > > > On 13 Mar 2011, at 23:30, Stefan Marr wrote: > > > Hi: > > > > For the others, I am currently adapting the benchmarking infrastructure used for Pinocchio to be a bit more general, and enable me to integrate our RoarVM benchmarking tools. > > The goal is to have a framework that allows all kind of benchmarking, written like unit tests. > > One other idea Henrik was interested in is to be able to easily compare the benchmark results of different versions of method-implementations, to see whether optimizations were successful. > > > > > > Camillo, even so I don't have a working version yet, I was trying to commit my refactoring (perhaps for review). > > However, the PinocchioVM project seems to be 'global readonly'. > > > > Would it be better to make it a stand-alone project? > > When we go with that step, as already mentioned, I would like to rename it. > > > > PBenchmark is a name that might prevent adoption. Not that I would like to go into politics here, but perhaps we can consider a new name. > > > > Since the general idea is to write benchmarks like unit tests, how about 'SMark'/'SBench' instead of 'SUnit'? > > > > Best regards > > Stefan > > > > > > PS: > > > > One thing, we might want to use as a source of inspiration in the future is: > > http://code.google.com/p/caliper/ > > > > Thats a microbenchmark framework for Java, also using the unit-testing metaphor. > > There @Param is also neat (http://code.google.com/p/caliper/source/browse/trunk/examples/src/main/java…) and allows to encode input sizes for which the benchmarks should be executed. > > That is something I am not to interested in, but in case the framework finds adoption that might be something to keep in mind. > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 15, 2011

Re: [Pharo-project] PBenchmark as a general framework for benchmarking in Smalltalk (commit access)

by Stefan Marr

Hi: Small update, I just created http://www.squeaksource.com/SMark.html SMark is the attempt to build a common benchmarking framework for Smalltalk. It inspired from the metaphor used for unit testing in SUnit, and thus, a benchmark is implemented by adding #benchMyBenchmark to a subclass of SBenchmarkSuite. The code is originally based on PBenchmark the benchmark framework used for the PinocchioVM and RoarBenchmark a framework used for performance regression testing of the RoarVM. Other sources of inspiration are for instance the Caliper microbenchmarking framework for Java. (http://code.google.com/p/caliper/) The name choice of SMark is deliberately confusable with smark (as defined by the urban dictionary: Noun. A person who is being scamed but is in on the prank. Someone who knows they are being tricked. Its origin is from the term "mark" and is the shortened form of the phrase "smart mark".) freely following the old wisdom: "Lies, Damn Lies, and --Statistics-- Benchmarks" Current status is still pretty early, I am spec'ing out the behavior and data structures I imaging with tests. And I haven't actually renamed anything to new names yet. The next update here will be once there is something actually usable. However, the project is world-writeable, so feel free to have a look. Best regards Stefan On 13 Mar 2011, at 23:30, Stefan Marr wrote: > Hi: > > For the others, I am currently adapting the benchmarking infrastructure used for Pinocchio to be a bit more general, and enable me to integrate our RoarVM benchmarking tools. > The goal is to have a framework that allows all kind of benchmarking, written like unit tests. > One other idea Henrik was interested in is to be able to easily compare the benchmark results of different versions of method-implementations, to see whether optimizations were successful. > > > Camillo, even so I don't have a working version yet, I was trying to commit my refactoring (perhaps for review). > However, the PinocchioVM project seems to be 'global readonly'. > > Would it be better to make it a stand-alone project? > When we go with that step, as already mentioned, I would like to rename it. > > PBenchmark is a name that might prevent adoption. Not that I would like to go into politics here, but perhaps we can consider a new name. > > Since the general idea is to write benchmarks like unit tests, how about 'SMark'/'SBench' instead of 'SUnit'? > > Best regards > Stefan > > > PS: > > One thing, we might want to use as a source of inspiration in the future is: > http://code.google.com/p/caliper/ > > Thats a microbenchmark framework for Java, also using the unit-testing metaphor. > There @Param is also neat (http://code.google.com/p/caliper/source/browse/trunk/examples/src/main/java…) and allows to encode input sizes for which the benchmarks should be executed. > That is something I am not to interested in, but in case the framework finds adoption that might be something to keep in mind. > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 15, 2011

Re: [Pharo-project] Cog/FFI Return Values

by Eliot Miranda

Hi Ken, On Tue, Mar 15, 2011 at 3:19 PM, Ken Treis <ken(a)miriamtech.com> wrote: > For kicks, I tried running the GemStone tools in a Cog VM. It *almost* > works. Apparently this sort of call: > > > apiGciPerform: anOopType a: aString a: anArray a: anInteger > > > > <apicall: OopType64 'GciPerform' (OopType64 char* ulong long) > > > ^self externalCallFailed > > ... works differently now. In the old (non-Cog) VM, it return an instance > of OopType64. In Cog, it returns a SmallInteger. > > The function itself returns a uint64_t, so apparently the OopType64 class > (a subclass of ExternalStructure) is being used to trick the FFI into > automatically wrapping the return value in the way we want. > > 1. Is this trick no longer supported/legit (assuming it ever was)? > I expect that if the standard FFI plugin answers an instance of OopType64 then you've found a bug in the ReentrantFFIPlugin. If you're brave you'll have a look at both plugins and try and verify that that's the case. But I have to say that the FFI plugins are not simple. > 2. Is there a better way to accomplish the same thing, or do we just have > to do the wrapping ourselves now? > Difficult to answer without answering 1. I'm guessing that 2. is a non-issue and that the real answer is to fix the bug in ReentrantFFIPlugin. For that I'd like to enlist your help. You have the patient on the table as it were and I don't have the time to attempt to reproduce the example and fix it now. > > I'm pretty new to the FFI, so forgive me if the premise is wrong. All I > know is that it doesn't work the way it used to. :) > The premise is right. The ReentrantFFIPlugin is supposed to be a plug-and-play replacement for the old FFIPlugin (at least in Cog; a little more work may be necessary to get it to work in the standard VM). let me know how you get on. best, Eliot > > -- > Ken Treis > Miriam Technologies, Inc. > > >

March 15, 2011

[Pharo-project] [Vm-dev] OSS sound plugin.

by Lemuus

Hi, is it possible to include the vm-sound-OSS sound plugin in the cog build on Hudson?. This is the only plugin that seems to work on linux. Thanks. Daniel Galdames G.

March 15, 2011

[Pharo-project] Cog/FFI Return Values

by Ken Treis

For kicks, I tried running the GemStone tools in a Cog VM. It *almost* works. Apparently this sort of call: > apiGciPerform: anOopType a: aString a: anArray a: anInteger > > <apicall: OopType64 'GciPerform' (OopType64 char* ulong long) > > ^self externalCallFailed ... works differently now. In the old (non-Cog) VM, it return an instance of OopType64. In Cog, it returns a SmallInteger. The function itself returns a uint64_t, so apparently the OopType64 class (a subclass of ExternalStructure) is being used to trick the FFI into automatically wrapping the return value in the way we want. 1. Is this trick no longer supported/legit (assuming it ever was)? 2. Is there a better way to accomplish the same thing, or do we just have to do the wrapping ourselves now? I'm pretty new to the FFI, so forgive me if the premise is wrong. All I know is that it doesn't work the way it used to. :) -- Ken Treis Miriam Technologies, Inc.

March 15, 2011