April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Linux VM microbenchmarks

by laurent laffont

2010/4/3 John M McIntosh <johnmci(a)smalltalkconsulting.com> > > On 2010-04-03, at 9:27 AM, laurent laffont wrote: > > Hi, > > Thanks to people who send the results of tinyBenchmarks for various CPU, > here's the report. > > What I want to know is whether these results are crap or "normal". It seems > that all people succeed in compiling the VM with the source provided. So it > may be a candidate for Pharo 1.0 ? > > The procedure to build the VM was: > > wget > http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz > tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz > cd Squeak-3.11.3.2135-pharo-src/ > mkdir build && cd build > ../unix/cmake/configure --CFLAGS="-O2" > make > > The results: > > Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz > 64 bits > =============================================== > 432 M bytecodes/sec; 13 M sends/sec > > > Optimal on a Intel(r) Core(TM)2 duo CPU @ 2.33Ghz is > 587 M bytecodes/sec; 14.7 M sends/sec > Is "Optimal" means special CFLAGS, GCC version / Intel compiler, or source code changes ? I understand you cannot tell how you optimize the VM. But with the VM source I provide, maybe you can tell that compiling it with your "secret weapons" you obtain near optimal results ? Laurent Laffont > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 3, 2010

Re: [Pharo-project] Linux VM microbenchmarks

by John M McIntosh

On 2010-04-03, at 9:27 AM, laurent laffont wrote: > Hi, > > Thanks to people who send the results of tinyBenchmarks for various CPU, here's the report. > > What I want to know is whether these results are crap or "normal". It seems that all people succeed in compiling the VM with the source provided. So it may be a candidate for Pharo 1.0 ? > > The procedure to build the VM was: > > wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz > tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz > cd Squeak-3.11.3.2135-pharo-src/ > mkdir build && cd build > ../unix/cmake/configure --CFLAGS="-O2" > make > > The results: > > Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz > 64 bits > =============================================== > 432 M bytecodes/sec; 13 M sends/sec > Optimal on a Intel(r) Core(TM)2 duo CPU @ 2.33Ghz is 587 M bytecodes/sec; 14.7 M sends/sec -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10517-rc4dev10.04.1

by Tudor Girba

Hi, Moose loads and runs perfectly in RC4. Cheers, Doru On 3 Apr 2010, at 19:00, laurent laffont wrote: > With my VM on Archlinux 32 bits: > > 9176 run, 9156 passes, 20 expected failures, 0 failures, 0 errors, 0 > unexpected passes. > > Stan, could you try using this VM ? To build it: > > wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz > tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz > cd Squeak-3.11.3.2135-pharo-src/ > mkdir build && cd build > ../unix/cmake/configure --CFLAGS="-O2" > make > > then ./squeak /path/to.image > > Laurent Laffont > > > On Sat, Apr 3, 2010 at 6:23 PM, Stan Shepherd <stan.shepherd414(a)gmail.com > > wrote: > > hi Mariano, I get (Ubuntu 9.04) > 9176 run, 9152 passes, 20 expected failures, 4 failures, 0 errors, 0 > unexpected passes > > [1] : 'MCInitializationTest>>#testWorkingCopy' > [2] : 'MCSnapshotTest>>#testInstanceReuse' > [3] : 'TestIndenting>>#testCR2' > [4] : 'TestIndenting>>#testNewLineLeaveSpacesOnOldLine' > > ...Stan > -- > View this message in context: http://n4.nabble.com/BetaTesting-ANN-Pharo-1-0-10517-rc4dev10-04-1-tp174923… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 3, 2010

Re: [Pharo-project] [squeak-dev] FFI - structure pointer

by John M McIntosh

On 2010-04-03, at 6:36 AM, Schwab,Wilhelm K wrote: > Andreas, John, anybody, > > I need to find the address of a "function" (it is in fact a global structure pointer somewhere in memory) and pass it to another function. Well some sample code from the objective C bridge. This doesn't use any "C" code or the FFI/Alien logic since it was targeted towards the iPhone and FFI and Alien aren't supported. This creates a byteArray that contains the (length) bytes from a known global structure identified by linker name. However the primitiveGetAddressFromEntryPointString returns a memory address as a large positive integer. "Pass in the name in a String, indicate the length of the data element" fetchByteArrayConstantCalled: aString withLength: length | address | address := self findAddressForString: aString. address = 0 ifTrue: [^self error: 'Address of constant not found']. ^self fetchByteArrayFrom: address length: length. findAddressForString: aNameString "ObjectiveCBridge findAddressForString: 'CGRectZero'" | externalAddress | externalAddress := self primitiveGetAddressFromEntryPointString: aNameString. ^externalAddress primitiveGetAddressFromEntryPointString: aString <primitive: 'primitiveGetAddressFromEntryPointString' module: 'ObjectiveCPlugin'> self primitiveFailed "The plugin code is below, first we need to move the name from a smalltalk string to a C String. To do this we construct a strlcpy using a fake call to str:l:cpy: then we invoke dl:sym: which is really dlSym(-2,entryPointName) This gives back the address of the data. Remember to create a 64bit positive number out of it since we could be on a 64bit system primitiveGetAddressFromEntryPointString: aEntryPointName | entryPointNameLength fn entryPointName | self primitive: 'primitiveGetAddressFromEntryPointString' parameters: #(String). self var: 'entryPointName' declareC: 'char entryPointName[256]'. self var: 'fn' declareC: 'void * fn'. entryPointNameLength := interpreterProxy slotSizeOf: aEntryPointName cPtrAsOop. entryPointNameLength > 256 ifTrue: [^interpreterProxy positive64BitIntegerFor: 0]. self str: entryPointName l: aEntryPointName cpy: entryPointNameLength+1. fn := self dl: -2 sym: entryPointName. ^interpreterProxy positive64BitIntegerFor: (self cCoerce: fn to: 'usqInt') "Given an address lets fetch N bytes from it, the ByteArray is create by the primitive " fetchByteArrayFrom: anAddress length: length ^self nsInvocationGetStructureType: anAddress length: length nsInvocationGetStructureType: bufferAddressOop length: length ^self primitiveNSInvocationGetStructureType: bufferAddressOop length: length primitiveNSInvocationGetStructureType: bufferAddressOop length: length <primitive: 'primitiveNSInvocationGetStructureType' module: 'ObjectiveCPlugin'> self primitiveFailed "64bits again for 64 bit systems, Use the fake construct of me:m:cpy: to do the memcpy" primitiveNSInvocationGetStructureType: bufferAddressOop length: length | bufferPointer newByteArray | self primitive: 'primitiveNSInvocationGetStructureType' parameters: #(Oop SmallInteger). self var: 'bufferPointer' declareC: 'char ** bufferPointer'. self var: 'buffer' declareC: 'char * buffer'. bufferPointer := self cCoerce: (interpreterProxy positive64BitValueOf: bufferAddressOop) to: 'void *'. interpreterProxy failed ifTrue: [^nil]. newByteArray := interpreterProxy instantiateClass: interpreterProxy classByteArray indexableSize: length. self me: (interpreterProxy arrayValueOf: newByteArray) m: bufferPointer cpy: length. "void * memcpy(void *restrict s1, const void *restrict s2, size_t n)" ^newByteArray -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

Re: [Pharo-project] CollabActive book :)

by Tudor Girba

Hi, I created the user with editor rights. I will send the password separately. For admins, here is how you create new users: 1. Go to: http://book.pharo-project.org/system/management/ 2. In the Users section add the user you want (the first input box) 3. In the dialog, make sure you add the groups you want to the user. Right now there are 2 groups: admin and editor. The editor is allowed to work on the content, the admin has additional rights in the system area. Cheers, Doru On 3 Apr 2010, at 16:49, StÃ©phane Ducasse wrote: > I tried to find how to add a new user but I failed. I will ask doru ;( > > Stef > > On Apr 3, 2010, at 2:38 PM, laurent laffont wrote: > >> So if you want to be an editor you are more than welcome! >> Just ask >> >> I ask :) >> >> Laurent Laffont. >> >> >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 3, 2010

Re: [Pharo-project] [Moose-dev] Re: Mondrian: present and future

by Tudor Girba

Hi Chris, The core of Mondrian has no relationship with OB. The rendering of Mondrian only depends on Canvas. By default, when you say "view open" a window with a canvas is created and the canvas is passed to Mondrian. Cheers, Doru On 3 Apr 2010, at 19:11, Chris Muller wrote: > HI Alexandre, what is the current status of Mondrian on Squeak? I've > always been intrigued by Mondrian, what would be the best approach for > getting it going on Squeak? > > I am mostly interested using Mondrians rendering and input-event > handling inside my own widgets, not OB or other windowing tools. How > hard would it be to extricate just the Form-drawing and > input-capability of the Mondrian core from the OB window widgetry that > seems to be included in the package (at least, the last time I > looked)? > > - Chris > > On Thu, Apr 1, 2010 at 3:15 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: >> Hi All, >> >> Just to give some news about Mondrian. Together with colleagues >> from Bern, >> Lille and Santiago, I have been working on this visualization >> engine for >> quite some times. Although it contains some important bugs (e.g., >> popupView) >> it is fairly stable and usable. The current version is 2.0-beta.7. >> >> Mondrian is slowly maturing. A short summary of the discussion I >> had with >> Doru and StÃ©phane today. >> Some of the features I would like to see in for Version 3.0 are: >> - scalable spring layout (also known as force based layout): this >> is a very >> simple and nice layout that produces amazing results >> - add layers: embedding a rendering or a part of it in a layer. >> Layers >> could then be iteratively activated and desactivared. The idea is >> to enable >> the construction of scripts in a very iterative and incremental way. >> - having a small core embeddable in your application >> - making Mondrian load graphiz scripts >> - having a better help system (Ã la ProfStef) >> - dedicated chapter for Pharo By Example Volume 2 >> - exporting as PDF >> - anti-aliasing >> >> This probably will not happen today or tomorrow, but I just feel >> necessary >> to share this roadmap with you. Some other features are wanted. >> Using Rome >> is one. Open GL is another. There are plenty of rooms for a very cool >> visualization engine. >> >> Probably during the holiday period I will consolidate the current >> version by >> fixing remaining bugs and produce 2.0. >> >> Bug tracker: http://code.google.com/p/moose-technology/ >> Web page: http://www.moosetechnology.org/tools/mondrian >> >> Let's render our dream! >> >> Cheers, >> Alexandre >> >> NB: sorry for this cross mailing list post. >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

April 3, 2010

Re: [Pharo-project] [Moose-dev] Mondrian: present and future

by Chris Muller

HI Alexandre, what is the current status of Mondrian on Squeak? I've always been intrigued by Mondrian, what would be the best approach for getting it going on Squeak? I am mostly interested using Mondrians rendering and input-event handling inside my own widgets, not OB or other windowing tools. How hard would it be to extricate just the Form-drawing and input-capability of the Mondrian core from the OB window widgetry that seems to be included in the package (at least, the last time I looked)? - Chris On Thu, Apr 1, 2010 at 3:15 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi All, > > Just to give some news about Mondrian. Together with colleagues from Bern, > Lille and Santiago, I have been working on this visualization engine for > quite some times. Although it contains some important bugs (e.g., popupView) > it is fairly stable and usable. The current version is 2.0-beta.7. > > Mondrian is slowly maturing. A short summary of the discussion I had with > Doru and StÃ©phane today. > Some of the features I would like to see in for Version 3.0 are: > Â - scalable spring layout (also known as force based layout): this is a very > simple and nice layout that produces amazing results > Â - add layers: embedding a rendering or a part of it in a layer. Layers > could then be iteratively activated and desactivared. The idea is to enable > the construction of scripts in a very iterative and incremental way. > Â - having a small core embeddable in your application > Â - making Mondrian load graphiz scripts > Â - having a better help system (Ã la ProfStef) > Â - dedicated chapter for Pharo By Example Volume 2 > Â - exporting as PDF > Â - anti-aliasing > > This probably will not happen today or tomorrow, but I just feel necessary > to share this roadmap with you. Some other features are wanted. Using Rome > is one. Open GL is another. There are plenty of rooms for a very cool > visualization engine. > > Probably during the holiday period I will consolidate the current version by > fixing remaining bugs and produce 2.0. > > Bug tracker: http://code.google.com/p/moose-technology/ > Web page: http://www.moosetechnology.org/tools/mondrian > > Let's render our dream! > > Cheers, > Alexandre > > NB: sorry for this cross mailing list post. > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

April 3, 2010

Re: [Pharo-project] FFI - structure pointer

by Schwab,Wilhelm K

Andreas, #getProcAddress: is a Smalltalk message, so it does not have a return type. It does return an ExternalData because it it ultimately calls <cdecl: void* 'FindSymbol' ( long char* ) > I had to create FindSymbol as a simply wrapper around dlsym() because the vm dies a quick death over (what I believe to be) linking hassles similar to recent problems in skype. Of course, I am referring the Linux vm or I would be calling GetProcAddress(). One thing that I considered is that the aspects of the ExternalData might be incorrect. The handle is an external address and type is an ExternalType that prints itself as void*. With many variations, if the call was made, the vm crashed. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab Sent: Saturday, April 03, 2010 11:54 AM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI - structure pointer On 4/3/2010 6:36 AM, Schwab,Wilhelm K wrote: > Andreas, John, anybody, > > I need to find the address of a "function" (it is in fact a global structure pointer somewhere in memory) and pass it to another function. > > Suppose the structure is called Type and the function allocate_one(). > I call the function something like > > allocateOne:type size:anInt > <cdecl: SomeOtherStruct* 'allocate_one' ( Type* long )> > > > but I am having an awful time getting the pointer to Type. Given that > dlsym() will return a pointer to it, how can I represent that in > Smalltalk? I have tried variations on > > "Indirectly call dlsym()" > address := Library default getProcAddress:'name_of_global_struct'. > > "try to create Type* from the resulting address" > type := Type fromHandle:address. > type := Type fromHandle:address getHandle. > type := ExternalData fromHandle:address type:Type externalType asPointerType. > > Something := Library default allocateOne:type size:2. > > and it either complains about bad arguments during the call or segment faults. Any ideas or similar examples? The return type of getProcAddress: is likely wrong. It should be declared to return void* which will cause it to return an ExternalData. With an ExternalData your second variant "Type fromHandle: data getHandle" will work. Cheers, - Andreas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 3, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10517-rc4dev10.04.1

by laurent laffont

With my VM on Archlinux 32 bits: 9176 run, 9156 passes, 20 expected failures, 0 failures, 0 errors, 0 unexpected passes. Stan, could you try using this VM ? To build it: wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz cd Squeak-3.11.3.2135-pharo-src/ mkdir build && cd build ../unix/cmake/configure --CFLAGS="-O2" make then ./squeak /path/to.image Laurent Laffont On Sat, Apr 3, 2010 at 6:23 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > hi Mariano, I get (Ubuntu 9.04) > 9176 run, 9152 passes, 20 expected failures, 4 failures, 0 errors, 0 > unexpected passes > > [1] : 'MCInitializationTest>>#testWorkingCopy' > [2] : 'MCSnapshotTest>>#testInstanceReuse' > [3] : 'TestIndenting>>#testCR2' > [4] : 'TestIndenting>>#testNewLineLeaveSpacesOnOldLine' > > ...Stan > -- > View this message in context: > http://n4.nabble.com/BetaTesting-ANN-Pharo-1-0-10517-rc4dev10-04-1-tp174923… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 3, 2010

Re: [Pharo-project] [OB] CodeCritics questions

by Lukas Renggli

See: http://www.lukas-renggli.ch/blog/ob-rb-3 As well: http://www.lukas-renggli.ch/blog/ob-rb-2 and http://www.lukas-renggli.ch/blog/ob-rb-1 On 3 April 2010 18:32, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi, > Â For Code Critics in OB users, if you select Refactor -> Code critics, > the lint checks starts automatically.... > > -But it seems to start in background on all image? (the toolbar says > "on Smalltalk") instead of the selected class category in the OB. It > is probably a bug? > -There is a percentage indicator but I don't know if refers to the > currently selected lint category or all lints plus transformations... > -It would be cool to start the lints on demand in a selected category? > What do you think? > > Cheers, > > HernÃ¡n > > -- > You received this message because you are subscribed to the Google Groups "OmniBrowser Development" group. > To post to this group, send email to omnibrowser-dev(a)googlegroups.com. > To unsubscribe from this group, send email to omnibrowser-dev+unsubscribe(a)googlegroups.com. > For more options, visit this group at http://groups.google.com/group/omnibrowser-dev?hl=en. > > -- Lukas Renggli www.lukas-renggli.ch

April 3, 2010