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

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

by Alexandre Bergel

Hi Chris, I haven't recently tried to install Mondrian on Squeak. If it does not work, no much should be missing I believe. There is nothing in Pharo which is a crucial requirement. If you wish to see Mondrian on Squeak, then I can help to make it work. > 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)? As Doru said, there is no relationship between Mondrian and OB. Mondrian was dependend on OB some times ago principally for the text input lower pane. But not anymore. If you have any question on how to use Mondrian, please ask. Cheers, Alexandre > > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 3, 2010

Re: [Pharo-project] Dynamic content in inspector??

by Schwab,Wilhelm K

Help.... This might be a problem in Pharo (RC1) in general or in its standard toolset, but I have a multi-line print string that when displayed in an inspector appears to try to edit the receiver and cause strangeness. Is that a known problem with a solution? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Saturday, April 03, 2010 1:59 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Dynamic content in inspector?? Hello all, With the understanding that I am doing non-trivial FFI work and could have completely fried my image already, I'm wondering if this is a common Squeak/Pharo newbie kind of amazement: I create and inspect a new instance of something that has a #printOn: method, and the contents of the inspector's workspace change with time. I have seen inspectors update to track objects in the past, but this behavior is unwanted. I thought of finalization, but that appears not to be happening (nor should it be with the object inspected). I will keep looking, but plausible explanations will be appreciated. Bill _______________________________________________ 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 Hilaire Fernandes

Laurent, I runned the same benchmark with Exupery, here is Exupery 202371541 bytecodes/sec; 5948654 sends/sec 201574803 bytecodes/sec; 5948654 sends/sec 201416207 bytecodes/sec; 5933632 sends/sec 202531645 bytecodes/sec; 5903814 sends/sec 201892744 bytecodes/sec; 5938631 sends/sec -O2 (compiled source code from the archive you provided) 87372013 bytecodes/sec; 4436220 sends/sec 86544962 bytecodes/sec; 4501376 sends/sec 86253369 bytecodes/sec; 4507132 sends/sec 86253369 bytecodes/sec; 4487049 sends/sec 87372013 bytecodes/sec; 4498503 sends/sec You better check with Bryce. Hilaire

April 3, 2010

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

by John M McIntosh

Well you were showing "C" last time around so I assumed you where doing everything by hand so to speak. Anyway the example shows how to get a memory address of a linker exposed global symbol without help from FFI/Alien/VM On 2010-04-03, at 11:54 AM, Schwab,Wilhelm K wrote: > John, > > Sorry, but you lost me. When I see interpreter proxies, I think of plugins, which I'm not doing. Are you asking me to check something? > > Bill -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

[Pharo-project] Dynamic content in inspector??

by Schwab,Wilhelm K

Hello all, With the understanding that I am doing non-trivial FFI work and could have completely fried my image already, I'm wondering if this is a common Squeak/Pharo newbie kind of amazement: I create and inspect a new instance of something that has a #printOn: method, and the contents of the inspector's workspace change with time. I have seen inspectors update to track objects in the past, but this behavior is unwanted. I thought of finalization, but that appears not to be happening (nor should it be with the object inspected). I will keep looking, but plausible explanations will be appreciated. Bill

April 3, 2010

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

by Schwab,Wilhelm K

John, Sorry, but you lost me. When I see interpreter proxies, I think of plugins, which I'm not doing. Are you asking me to check something? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Saturday, April 03, 2010 1:22 PM To: johnmci(a)smalltalkconsulting.com Cc: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] [squeak-dev] FFI - structure pointer On 2010-04-03, at 11:01 AM, John M McIntosh wrote: > entryPointNameLength > 256 ifTrue: [^interpreterProxy positive64BitIntegerFor: 0]. Tsk, should be > 255 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

Re: [Pharo-project] Linux VM microbenchmarks

by Hilaire Fernandes

laurent laffont a Ã©crit : > 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 ? I guess it means code was compiled optimized for this specific processor. Hilaire

April 3, 2010

Re: [Pharo-project] FFI - structure pointer

by Schwab,Wilhelm K

Andreas, I *think* I already took your second option. I created functions that do nothing but return the structure pointer, call them and pass the result onward - it seems to work. 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 1:16 PM 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 10:10 AM, Schwab,Wilhelm K wrote: > 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. Can you verify the correctness of both pointer as well as function signature? Depending on platform and/or entity in question you just *might* get an extra indirection. If you can't get the code to work as-is I would recommend compiling your own library that exports a symbol in the form you're using and then verify correctness of the bridge that way. Cheers, - Andreas > -----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] [squeak-dev] FFI - structure pointer

by John M McIntosh

On 2010-04-03, at 11:01 AM, John M McIntosh wrote: > entryPointNameLength > 256 ifTrue: [^interpreterProxy positive64BitIntegerFor: 0]. Tsk, should be > 255 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

Re: [Pharo-project] FFI - structure pointer

by Andreas Raab

On 4/3/2010 10:10 AM, Schwab,Wilhelm K wrote: > 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. Can you verify the correctness of both pointer as well as function signature? Depending on platform and/or entity in question you just *might* get an extra indirection. If you can't get the code to work as-is I would recommend compiling your own library that exports a symbol in the form you're using and then verify correctness of the bridge that way. Cheers, - Andreas > -----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

April 3, 2010