- Pharo-dev - lists.pharo.org

[Pharo-project] #and:and:and: deprecated on 1.1, why?

by nullPointer

that methods is marked like "deprecated": 'Use self deprecated: 'Use and: instead'. ' But curiosly the method #and:and:and:and: appears normal, without deprecation. That behavior is correct? Thanks -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2230786.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2010

Re: [Pharo-project] FFI Documentation

by Igor Stasenko

2010/5/25 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I too am waiting to find something about NB that we should not like.Â No > offense to Sig, there has to be _something_ wrong with it, right? :) > Right. :) Wrong, is lack of Unix and mac support. It should be written. Examples is missing too. > A draft list of stuff we should check: > > (1)Â many examples of calls with int, float/double, pointers, structs, etc. > (2) mac, Linux, Windows > (3) callbacks > > Bonus: > (4) calls on separate OS threads so the image can defend itself against > something that does not return in a "reasonable" time, with reasonable being > up to either the programmer or the end user (which the programmer can > hopefully enforce if the image is not locked). > > Bill > > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Denis > Kudriashov > Sent: Tuesday, May 25, 2010 1:08 PM > To: Pharo-project > Subject: Re: [Pharo-project] FFI Documentation > > Hi. Igor > > Can you compare NB callout functionality with FFI and Alien functionality. > Can NB replace FFI, Alien? > > What absent in NB callout? > > You implement callbacks with NB. FFI not support it. > For me NB foreign interface seems more attractive than something else. > > > 2010/5/21 Igor Stasenko <siguctua(a)gmail.com> >> >> Very nice topic coverage. I hope, eventually NB will also have >> something like this :) >> >> But it having a little different pros/cons table: >> >> NB Pros: >> Â Â Â Â Â Â Â * as well as for plugin, you can create new >> functionality that doesn't exist in any library >> Â Â Â Â Â Â Â * no need to recompile plugin/VM when you making a changes >> Â Â Â Â Â Â Â * all your code is distributed with the Smalltalk code, >> but there can be >> complications with platforms >> Â Â Â Â Â Â Â * fast - faster than any FFI implementation written in >> C, and as fast as plugin primitive or even faster >> >> Â Â Â Cons: >> Â Â Â Â Â Â Â * ?unsafe? - you have to provide a safety layers >> Â Â Â Â Â Â Â (But hey, you have to deal with same sorts of stuff, >> when writing plugin. No magician workers there) >> >> Â Â Â Â Â Â Â * harder to write >> Yes, its harder than plain smalltalk - true. >> But i can't say, that writing an assembler is harder than writing a >> plugin's slang code. >> If you writing a plugin, you should have an expertise, in VM internals >> and how to build VM , etc etc >> and if you writing an native code, you should have an expertise in >> assembler as well as VM internals. >> >> So, they are different, and definitely much harder comparing to plain >> smalltalk code, >> but which one is easier is hard to tell. >> >> On 20 May 2010 22:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > thanks sean >> > this is cool to see such kind of documentation emerging. >> > >> > Stef >> > >> > On May 20, 2010, at 9:16 PM, Sean P. DeNigris wrote: >> > >> >> >> >> I want to get this info into the help system and/or collaborative book, >> >> as >> >> similar questions pop up regularly on the lists. >> >> >> >> I compiled every piece of info I could find. Â The focus in on FFI, with >> >> stubs for other strategies. Â Please read this *very* rough outline for >> >> missing info and inaccuracies: >> >> >> >> FFI >> >> >> >> What is FFI and what is it used for? Â Calling functions in libraries >> >> outside >> >> of the image... >> >> >> >> FFI, the Squeak Foreign Function Interface, is used to call functions >> >> located in shared libraries that are not part of the Squeak VM nor its >> >> plugins. It also provides means to read and write memory structures >> >> that are >> >> associated with the use of those shared libraries. A typical use is to >> >> directly invoke operating system APIs. As such, applications that use >> >> FFI >> >> can only be used on the platform(s) that support the particular API >> >> being >> >> used. C conventions are used throughout, though the external function >> >> could >> >> have been written by any language capable of generating object code >> >> that >> >> follows C conventions. Â FFI is probably the easiest way to do the >> >> things it >> >> does. FFI is pretty fast too. Croquet uses FFI calls to OpenGL for all >> >> it's >> >> drawing routines.[1] >> >> >> >> How does FFI work? >> >> Technically what happens is: >> >> * you define what the interface is - the parameters, types etc. >> >> * when you make the call, the FFI logic assembles the data from the >> >> Squeak >> >> Objects into the proper structures according to the routine calling >> >> conventions for your architecture, and of course manages the return >> >> values. >> >> So no magic but perhaps just a little assembler in the plugin to >> >> properly >> >> deal with all the registers and condition flags. >> >> >> >> How do I use it? >> >> >> >> 1. make a method (whose structure is similar to a named primitive >> >> method) >> >> >> >> Example: >> >> system: aString "name (by convention is apiXxx: e.g. apiSystem:)" >> >> >> >> Â Â Â <apicall: long 'system' (char*) module: 'libSystem.dylib'> "first >> >> line >> >> should be the external function specification" >> >> Â Â Â ^self externalCallFailed. >> >> >> >> Let's take it piece by piece: >> >> >> >> Â Â Â system: aString >> >> Â Â Â Â Â Â Â Method name - by convention named 'apiXxx' >> >> >> >> Â Â Â <apicall: long 'system' (char*) module: 'libSystem.dylib'> >> >> Â Â Â Â Â Â Â Function specification >> >> Â Â Â Â Â Â Â Â Â Â Â - should be the first line >> >> Â Â Â Â Â Â Â Â Â Â Â - enclosed in angle brackets: < > containing: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1. Calling Convention, either apicall: >> >> (Pascal convention) or cdecl: (C >> >> convention) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Mac - use either one >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Unix - use cdecl >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Windows - use apical >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 2. Return Type (see types) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 3. External Function Name (literal >> >> string) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4. Argument Types (a literal array) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 5. Module - "module: " + [filename of the >> >> external library (literal >> >> string)] (see below). >> >> >> >> Â Â Â self externalCallFailed. >> >> Â Â Â Â Â Â Â Failure handler >> >> Â Â Â Â Â Â Â Â Â Â Â - normal smalltalk code >> >> Â Â Â Â Â Â Â Â Â Â Â - executed if the linking to or calling the >> >> external function fails >> >> Â Â Â Â Â Â Â Â Â Â Â - API calls don't know how to communicate failure >> >> like Squeak primitives >> >> do, so: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - it does not tell you whether the >> >> external function succeeded >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - the most common code is simply '^self >> >> externalCallFailed.' >> >> >> >> Argument Types >> >> Â Â Â - must be names of ExternalTypes, either: >> >> Â Â Â Â Â Â Â - atomic types (see ExternalType >> >> class>>initializeFFIConstants and >> >> ExternalType class>>initializeAtomicTypes): >> >> Â Â Â Â Â Â Â Â Â Â Â void >> >> Â Â Â Â Â Â Â Â Â Â Â bool >> >> Â Â Â Â Â Â Â Â Â Â Â byte (unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â sbyte (signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ushort (16-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â short (16-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ulong (32-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â long (32-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ulonglong (64-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â longlong (64-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â char (unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â schar (signed) >> >> Â Â Â Â Â Â Â Â Â Â Â float (single-precision float) >> >> Â Â Â Â Â Â Â Â Â Â Â double (double-precision float) >> >> >> >> Structure Types [4] >> >> Â Â Â - subclass of ExternalStructure >> >> Â Â Â Â Â Â Â - class>>fields that returns an array of field >> >> descriptions (see below) >> >> Â Â Â Â Â Â Â Â Â Â Â - Example: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fields >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^#((red Â 'byte')(green >> >> 'byte')(blue Â 'byte')) >> >> Â Â Â Â Â Â Â - class>>initialize which includes "self defineFields" >> >> (which must be >> >> called before using the class) >> >> Â Â Â - refer to as MyExternalStructure* (to indicate that the argument >> >> or return >> >> is a pointer to that structure) >> >> >> >> Field description [4] >> >> Â Â Â - 2-element array (or three but that does something else, I'm not >> >> sure >> >> what): >> >> Â Â Â Â Â Â Â - first element is the field name >> >> Â Â Â Â Â Â Â - second is the type >> >> >> >> Mac Memory Allocation Issues [4] (not sure about this) >> >> >> >> If you allocate external structures, those with memory outside the >> >> Squeak >> >> process space, you may need to increase the amount of memory that is >> >> reserved outside the object heap for such use. The Mac OS (9 and >> >> previous) >> >> needs this, other platforms may be able to dynamically get more memory >> >> from >> >> the OS. To see how much memory is currently reserved printIt 'Smalltalk >> >> extraVMMemory'. To change it, execute 'Smalltalk extraVMMemory: >> >> someNumberofBytes' Then save your image and quit. When you next start >> >> up, >> >> the amount of memory you requested will be reserved. (JMM) Note the OSX >> >> versions of the VM ignore extraVMMemory because the memory model for >> >> OS-X/unix applications is quite different. >> >> >> >> Module Name >> >> - depends on the platform >> >> Â Â Â - Mac >> >> Â Â Â Â Â Â Â - pre Snow Leopard: flexible, can eliminate leading lib >> >> or extension e.g. >> >> 'libc.dylib' becomes 'libc', 'c.dylib', or 'c' >> >> Â Â Â Â Â Â Â - Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â - file name must be exact including extension >> >> (unless Info.plist is >> >> altered as in 'Library Location' below) >> >> Â Â Â Â Â Â Â - With pre-mach-o VMs >> >> Â Â Â Â Â Â Â Â Â Â Â - For Classic applications, use 'InterfaceLib' >> >> Â Â Â Â Â Â Â Â Â Â Â - For Carbon libs, use 'CarbonLib' >> >> >> >> Module Location - where the external library file lives >> >> Â Â Â - depends on the platform >> >> Â Â Â Â Â Â Â - Mac >> >> Â Â Â Â Â Â Â Â Â Â Â - pre Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - checks VM path and common library paths >> >> Â Â Â Â Â Â Â Â Â Â Â - Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - only looks in VM bundle's Resources >> >> file, you must either [5]: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - store all external libraries >> >> there >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - ln -s path/to/library >> >> path/to/VM/Resources/library_name >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Change the VM's Info.plist >> >> "SqueakPluginsBuiltInOrLocalOnly" key from >> >> "true" to "false." >> >> Caveats >> >> Â Â Â - security >> >> Â Â Â Â Â Â Â - malicious users could call arbitrary functions in the >> >> OS e.g. Â "format >> >> c:" from "system.dll" [7] >> >> Â Â Â Â Â Â Â - VMs do not protect against buffer overflow from bad >> >> parameters [8]: >> >> Â Â Â Â Â Â Â Â Â Â Â "this would require an attacker to execute >> >> arbitrary Smalltalk >> >> Â Â Â Â Â Â Â Â Â Â Â code on your server. Of course if they can do >> >> that they own you >> >> Â Â Â Â Â Â Â Â Â Â Â anyway, especially if you allow FFi or use the >> >> OSProcess plugin" - John >> >> McIntosh >> >> >> >> * difficulty >> >> Â Â Â - if you make a mistake you'll not drop into the debugger but >> >> Squeak will >> >> just crash [2] >> >> Â Â Â - If you crash Squeak when it is running the garbage collector, >> >> then you >> >> know your FFI code is leaking bits into object memory [2] >> >> >> >> What do I need to use FFI with Squeak? >> >> >> >> You need the FFI plugin, which is included with most VM's as of Squeak >> >> 3.6 >> >> or so. >> >> >> >> You can also build the plugin yourself. See VMMaker. >> >> >> >> References: >> >> [1] http://wiki.squeak.org/squeak/1414 >> >> [2] http://wiki.squeak.org/squeak/2424 >> >> [3] http://wiki.squeak.org/squeak/5716 >> >> [4] http://wiki.squeak.org/squeak/2426 >> >> [5] >> >> >> >> http://forum.world.st/squeak-dev-Alien-Squeak-FFI-issues-on-Snow-Leopard-td… >> >> [6] http://wiki.squeak.org/squeak/5846 >> >> [7] http://forum.world.st/FFI-Callbacks-td54056.html#a54073 >> >> [8] http://forum.world.st/Security-td99624.html#a99635: >> >> >> >> Other choices: >> >> In the fall of 2008, Alien the FFI interface (written by Cadence Design >> >> Systems, Inc.) was put into squeaksource: >> >> http://www.squeaksource.com/Alien.html. This API allows the primitive >> >> to >> >> call back to Smalltalk Code, and return error code information, and >> >> apparently is much faster due to a less complex call sequence. >> >> Â Â Â * if you need callbacks >> >> Â Â Â * mac-only? >> >> >> >> Plugins - write external code and dynamically link it to the VM >> >> Â Â Â Pros: >> >> Â Â Â Â Â Â Â * safest - users are limited to using the functionality >> >> you provide and >> >> can not call other external functions e.g. system rm / >> >> Â Â Â Â Â Â Â * fast - faster than FFI >> >> Â Â Â Â Â Â Â * you can create new functionality that doesn't exist in >> >> any library >> >> Â Â Â Cons: >> >> Â Â Â Â Â Â Â * harder to write >> >> Â Â Â Â Â Â Â * plugin must be distributed with the Smalltalk code - >> >> there can be >> >> complications with platforms >> >> >> >> Primitive method - invokes behavior in the VM or a plugin [3] >> >> >> >> Questions: >> >> * why would you want to build the FFI plugin yourself? >> >> * api prefix or no for method names? >> >> * not sure about pre Snow Leopard library search >> >> * OSProcess - how does this fit into the bigger picture? >> >> * "^self externalCallFailed." or "self externalCallFailed." i.e. return >> >> self >> >> or return the result, or doesn't matter? >> >> * why would a field description have three elements? >> >> * Mac Memory Allocation Issues? >> >> -- >> >> View this message in context: >> >> http://forum.world.st/FFI-Documentation-tp2225148p2225148.html >> >> 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 >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 25, 2010

Re: [Pharo-project] FFI Documentation

by Igor Stasenko

2010/5/25 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. Igor > > Can you compare NB callout functionality with FFI and Alien functionality. > Can NB replace FFI, Alien? > Yes, it can. > What absent in NB callout? > I don't know. Its hard to imagine what can't be done in it, since you having a direct access to native code generation. > You implement callbacks with NB. FFI not support it. > For me NB foreign interface seems more attractive than something else. > > > 2010/5/21 Igor Stasenko <siguctua(a)gmail.com> >> >> Very nice topic coverage. I hope, eventually NB will also have >> something like this :) >> >> But it having a little different pros/cons table: >> >> NB Pros: >> Â Â Â Â Â Â Â * as well as for plugin, you can create new >> functionality that doesn't exist in any library >> Â Â Â Â Â Â Â * no need to recompile plugin/VM when you making a changes >> Â Â Â Â Â Â Â * all your code is distributed with the Smalltalk code, >> but there can be >> complications with platforms >> Â Â Â Â Â Â Â * fast - faster than any FFI implementation written in >> C, and as fast as plugin primitive or even faster >> >> Â Â Â Cons: >> Â Â Â Â Â Â Â * ?unsafe? - you have to provide a safety layers >> Â Â Â Â Â Â Â (But hey, you have to deal with same sorts of stuff, >> when writing plugin. No magician workers there) >> >> Â Â Â Â Â Â Â * harder to write >> Yes, its harder than plain smalltalk - true. >> But i can't say, that writing an assembler is harder than writing a >> plugin's slang code. >> If you writing a plugin, you should have an expertise, in VM internals >> and how to build VM , etc etc >> and if you writing an native code, you should have an expertise in >> assembler as well as VM internals. >> >> So, they are different, and definitely much harder comparing to plain >> smalltalk code, >> but which one is easier is hard to tell. >> >> On 20 May 2010 22:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > thanks sean >> > this is cool to see such kind of documentation emerging. >> > >> > Stef >> > >> > On May 20, 2010, at 9:16 PM, Sean P. DeNigris wrote: >> > >> >> >> >> I want to get this info into the help system and/or collaborative book, >> >> as >> >> similar questions pop up regularly on the lists. >> >> >> >> I compiled every piece of info I could find. Â The focus in on FFI, with >> >> stubs for other strategies. Â Please read this *very* rough outline for >> >> missing info and inaccuracies: >> >> >> >> FFI >> >> >> >> What is FFI and what is it used for? Â Calling functions in libraries >> >> outside >> >> of the image... >> >> >> >> FFI, the Squeak Foreign Function Interface, is used to call functions >> >> located in shared libraries that are not part of the Squeak VM nor its >> >> plugins. It also provides means to read and write memory structures >> >> that are >> >> associated with the use of those shared libraries. A typical use is to >> >> directly invoke operating system APIs. As such, applications that use >> >> FFI >> >> can only be used on the platform(s) that support the particular API >> >> being >> >> used. C conventions are used throughout, though the external function >> >> could >> >> have been written by any language capable of generating object code >> >> that >> >> follows C conventions. Â FFI is probably the easiest way to do the >> >> things it >> >> does. FFI is pretty fast too. Croquet uses FFI calls to OpenGL for all >> >> it's >> >> drawing routines.[1] >> >> >> >> How does FFI work? >> >> Technically what happens is: >> >> * you define what the interface is - the parameters, types etc. >> >> * when you make the call, the FFI logic assembles the data from the >> >> Squeak >> >> Objects into the proper structures according to the routine calling >> >> conventions for your architecture, and of course manages the return >> >> values. >> >> So no magic but perhaps just a little assembler in the plugin to >> >> properly >> >> deal with all the registers and condition flags. >> >> >> >> How do I use it? >> >> >> >> 1. make a method (whose structure is similar to a named primitive >> >> method) >> >> >> >> Example: >> >> system: aString "name (by convention is apiXxx: e.g. apiSystem:)" >> >> >> >> Â Â Â <apicall: long 'system' (char*) module: 'libSystem.dylib'> "first >> >> line >> >> should be the external function specification" >> >> Â Â Â ^self externalCallFailed. >> >> >> >> Let's take it piece by piece: >> >> >> >> Â Â Â system: aString >> >> Â Â Â Â Â Â Â Method name - by convention named 'apiXxx' >> >> >> >> Â Â Â <apicall: long 'system' (char*) module: 'libSystem.dylib'> >> >> Â Â Â Â Â Â Â Function specification >> >> Â Â Â Â Â Â Â Â Â Â Â - should be the first line >> >> Â Â Â Â Â Â Â Â Â Â Â - enclosed in angle brackets: < > containing: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1. Calling Convention, either apicall: >> >> (Pascal convention) or cdecl: (C >> >> convention) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Mac - use either one >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Unix - use cdecl >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Windows - use apical >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 2. Return Type (see types) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 3. External Function Name (literal >> >> string) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4. Argument Types (a literal array) >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 5. Module - "module: " + [filename of the >> >> external library (literal >> >> string)] (see below). >> >> >> >> Â Â Â self externalCallFailed. >> >> Â Â Â Â Â Â Â Failure handler >> >> Â Â Â Â Â Â Â Â Â Â Â - normal smalltalk code >> >> Â Â Â Â Â Â Â Â Â Â Â - executed if the linking to or calling the >> >> external function fails >> >> Â Â Â Â Â Â Â Â Â Â Â - API calls don't know how to communicate failure >> >> like Squeak primitives >> >> do, so: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - it does not tell you whether the >> >> external function succeeded >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - the most common code is simply '^self >> >> externalCallFailed.' >> >> >> >> Argument Types >> >> Â Â Â - must be names of ExternalTypes, either: >> >> Â Â Â Â Â Â Â - atomic types (see ExternalType >> >> class>>initializeFFIConstants and >> >> ExternalType class>>initializeAtomicTypes): >> >> Â Â Â Â Â Â Â Â Â Â Â void >> >> Â Â Â Â Â Â Â Â Â Â Â bool >> >> Â Â Â Â Â Â Â Â Â Â Â byte (unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â sbyte (signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ushort (16-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â short (16-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ulong (32-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â long (32-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â ulonglong (64-bit unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â longlong (64-bit signed) >> >> Â Â Â Â Â Â Â Â Â Â Â char (unsigned) >> >> Â Â Â Â Â Â Â Â Â Â Â schar (signed) >> >> Â Â Â Â Â Â Â Â Â Â Â float (single-precision float) >> >> Â Â Â Â Â Â Â Â Â Â Â double (double-precision float) >> >> >> >> Structure Types [4] >> >> Â Â Â - subclass of ExternalStructure >> >> Â Â Â Â Â Â Â - class>>fields that returns an array of field >> >> descriptions (see below) >> >> Â Â Â Â Â Â Â Â Â Â Â - Example: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fields >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^#((red Â 'byte')(green >> >> 'byte')(blue Â 'byte')) >> >> Â Â Â Â Â Â Â - class>>initialize which includes "self defineFields" >> >> (which must be >> >> called before using the class) >> >> Â Â Â - refer to as MyExternalStructure* (to indicate that the argument >> >> or return >> >> is a pointer to that structure) >> >> >> >> Field description [4] >> >> Â Â Â - 2-element array (or three but that does something else, I'm not >> >> sure >> >> what): >> >> Â Â Â Â Â Â Â - first element is the field name >> >> Â Â Â Â Â Â Â - second is the type >> >> >> >> Mac Memory Allocation Issues [4] (not sure about this) >> >> >> >> If you allocate external structures, those with memory outside the >> >> Squeak >> >> process space, you may need to increase the amount of memory that is >> >> reserved outside the object heap for such use. The Mac OS (9 and >> >> previous) >> >> needs this, other platforms may be able to dynamically get more memory >> >> from >> >> the OS. To see how much memory is currently reserved printIt 'Smalltalk >> >> extraVMMemory'. To change it, execute 'Smalltalk extraVMMemory: >> >> someNumberofBytes' Then save your image and quit. When you next start >> >> up, >> >> the amount of memory you requested will be reserved. (JMM) Note the OSX >> >> versions of the VM ignore extraVMMemory because the memory model for >> >> OS-X/unix applications is quite different. >> >> >> >> Module Name >> >> - depends on the platform >> >> Â Â Â - Mac >> >> Â Â Â Â Â Â Â - pre Snow Leopard: flexible, can eliminate leading lib >> >> or extension e.g. >> >> 'libc.dylib' becomes 'libc', 'c.dylib', or 'c' >> >> Â Â Â Â Â Â Â - Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â - file name must be exact including extension >> >> (unless Info.plist is >> >> altered as in 'Library Location' below) >> >> Â Â Â Â Â Â Â - With pre-mach-o VMs >> >> Â Â Â Â Â Â Â Â Â Â Â - For Classic applications, use 'InterfaceLib' >> >> Â Â Â Â Â Â Â Â Â Â Â - For Carbon libs, use 'CarbonLib' >> >> >> >> Module Location - where the external library file lives >> >> Â Â Â - depends on the platform >> >> Â Â Â Â Â Â Â - Mac >> >> Â Â Â Â Â Â Â Â Â Â Â - pre Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - checks VM path and common library paths >> >> Â Â Â Â Â Â Â Â Â Â Â - Snow Leopard >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - only looks in VM bundle's Resources >> >> file, you must either [5]: >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - store all external libraries >> >> there >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - ln -s path/to/library >> >> path/to/VM/Resources/library_name >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Change the VM's Info.plist >> >> "SqueakPluginsBuiltInOrLocalOnly" key from >> >> "true" to "false." >> >> Caveats >> >> Â Â Â - security >> >> Â Â Â Â Â Â Â - malicious users could call arbitrary functions in the >> >> OS e.g. Â "format >> >> c:" from "system.dll" [7] >> >> Â Â Â Â Â Â Â - VMs do not protect against buffer overflow from bad >> >> parameters [8]: >> >> Â Â Â Â Â Â Â Â Â Â Â "this would require an attacker to execute >> >> arbitrary Smalltalk >> >> Â Â Â Â Â Â Â Â Â Â Â code on your server. Of course if they can do >> >> that they own you >> >> Â Â Â Â Â Â Â Â Â Â Â anyway, especially if you allow FFi or use the >> >> OSProcess plugin" - John >> >> McIntosh >> >> >> >> * difficulty >> >> Â Â Â - if you make a mistake you'll not drop into the debugger but >> >> Squeak will >> >> just crash [2] >> >> Â Â Â - If you crash Squeak when it is running the garbage collector, >> >> then you >> >> know your FFI code is leaking bits into object memory [2] >> >> >> >> What do I need to use FFI with Squeak? >> >> >> >> You need the FFI plugin, which is included with most VM's as of Squeak >> >> 3.6 >> >> or so. >> >> >> >> You can also build the plugin yourself. See VMMaker. >> >> >> >> References: >> >> [1] http://wiki.squeak.org/squeak/1414 >> >> [2] http://wiki.squeak.org/squeak/2424 >> >> [3] http://wiki.squeak.org/squeak/5716 >> >> [4] http://wiki.squeak.org/squeak/2426 >> >> [5] >> >> >> >> http://forum.world.st/squeak-dev-Alien-Squeak-FFI-issues-on-Snow-Leopard-td… >> >> [6] http://wiki.squeak.org/squeak/5846 >> >> [7] http://forum.world.st/FFI-Callbacks-td54056.html#a54073 >> >> [8] http://forum.world.st/Security-td99624.html#a99635: >> >> >> >> Other choices: >> >> In the fall of 2008, Alien the FFI interface (written by Cadence Design >> >> Systems, Inc.) was put into squeaksource: >> >> http://www.squeaksource.com/Alien.html. This API allows the primitive >> >> to >> >> call back to Smalltalk Code, and return error code information, and >> >> apparently is much faster due to a less complex call sequence. >> >> Â Â Â * if you need callbacks >> >> Â Â Â * mac-only? >> >> >> >> Plugins - write external code and dynamically link it to the VM >> >> Â Â Â Pros: >> >> Â Â Â Â Â Â Â * safest - users are limited to using the functionality >> >> you provide and >> >> can not call other external functions e.g. system rm / >> >> Â Â Â Â Â Â Â * fast - faster than FFI >> >> Â Â Â Â Â Â Â * you can create new functionality that doesn't exist in >> >> any library >> >> Â Â Â Cons: >> >> Â Â Â Â Â Â Â * harder to write >> >> Â Â Â Â Â Â Â * plugin must be distributed with the Smalltalk code - >> >> there can be >> >> complications with platforms >> >> >> >> Primitive method - invokes behavior in the VM or a plugin [3] >> >> >> >> Questions: >> >> * why would you want to build the FFI plugin yourself? >> >> * api prefix or no for method names? >> >> * not sure about pre Snow Leopard library search >> >> * OSProcess - how does this fit into the bigger picture? >> >> * "^self externalCallFailed." or "self externalCallFailed." i.e. return >> >> self >> >> or return the result, or doesn't matter? >> >> * why would a field description have three elements? >> >> * Mac Memory Allocation Issues? >> >> -- >> >> View this message in context: >> >> http://forum.world.st/FFI-Documentation-tp2225148p2225148.html >> >> 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 >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 25, 2010

Re: [Pharo-project] Issue 670: Should clean Morph menu

by Carla F. Griggio

Well, I haven't tried all those actions, but if it helps in any way, the ones I usually use are: grab delete copy text submorphs inspect show actions debug-> inspect morph inspect model browse morph class browse model class I don't see what the layout options do. I don't know much about layouts, so maybe this doesn't make sense, but... shouldn't the options for table layout be available only if the morph I'm dealing with has a table layout? On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > **EXCELLENT** > truly excellent > Yes we try to sort that and get some cleaning. > > > grab > > copy to paste buffer > > collapse > > delete > > copy text > > go behind > > add halo > > duplicate > > embed into-> > > PasteUpMorph > > SystemWindow > > resize > > change color... > > drop shadow-> > > show shadow > > shadow color... > > shadow offset... > > layout-> > > no layout > > proportional layout > > table layout > > change layout inset... > > child layout-> > > disable layout in tables > > horizontal resizing-> > > rigid > > shrink wrap > > space fill > > vertical resizing-> > > rigid > > shrink wrap > > space fill > > table layout-> > > reverse table cells > > clip to cell size > > rubber band cells > > change cell inset... > > change min cell size... > > change max cell size... > > list direction-> > > ... > > wrap direction-> > > ... > > cell positioning-> > > ... > > list centering-> > > ... > > wrap centering-> > > ... > > list spacing-> > > ... > > cell spacing-> > > ... > > provide clipping > > submorphs > ?? > > > inspect > > explore > > > browse hierarchy > ?? > > > save morph in file > > attach to resource > ?? > > > show actions > > debug-> > > inspect morph > > inspect owner chain > > inspect model > > explore morph > > browse morph class > > browse model class > > explore view hierarchy > > call #tempCommand > ?? > > define #tempCommand > ?? > > > open editing > > edit label... > > > > Cheers, > > Guille > > _______________________________________________ > > 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 >

May 25, 2010

Re: [Pharo-project] [update 1.1] #11371

by StÃ©phane Ducasse

not really :) we prefer to keep it but that the user cannot use it by accident. Stef On May 25, 2010, at 11:07 PM, Guillermo Polito wrote: > Should that method be deprecated in the current Dev Image so no one makes a mistake? I don't know how the current "branches" are mantained to allow something like that... :/ > > 2010/5/25 Carla F. Griggio <carla.griggio(a)gmail.com> > :O > So I guess that's why it actually didn't update anything... :P > > > On Tue, May 25, 2010 at 5:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > The reason why we have turned it off is because updating Pharo images repeatedly caused problems (in contrast to PharoCore). People then reported issues. Unless this feature is working properly, we shouldn't enable it again. One possible cause of the problems are overrides by external packages in core code. But I think nobody has analyzed the problem in depth so far. > > Cheers, > Adrian > > > On May 25, 2010, at 21:48 , Carla F. Griggio wrote: > > > That annoyed me too. Shouldn't that option be checked by default? > > > > On Tuesday, May 25, 2010, laurent laffont <laurent.laffont(a)gmail.com> wrote: > >> World Menu -> System -> Software Update > >> Cheers,Laurent Laffont > >> > >> http://pharocasts.blogspot.com/ > >> http://magaloma.blogspot.com/ > >> > >> > >> 2010/5/25 Guillermo Polito <guillermopolito(a)gmail.com> > >> > >> > >> I'm sorry but i can't find how to update my 1.1 image. Can I update my image with this changes? Can someone enlight me? :) > >> > >> Guille, the newbie > >> > >> > >> > >> On Mon, May 24, 2010 at 5:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> 11371 > >> ----- > >> - Issue 1281: Button in TestRunner to fileout the test results. Thanks Laurent. > >> - Issue 2468: Better method trailer method creation. Part One. Thanks Igor. > >> - Issue 2406: MovieMorph should be removed from the core. Thanks Alain. > >> - Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks Laurent > >> - Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks Guillermo. > >> > >> 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 > > > _______________________________________________ > 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

May 25, 2010

Re: [Pharo-project] [update 1.1] #11371

by Guillermo Polito

Should that method be deprecated in the current Dev Image so no one makes a mistake? I don't know how the current "branches" are mantained to allow something like that... :/ 2010/5/25 Carla F. Griggio <carla.griggio(a)gmail.com> > :O > So I guess that's why it actually didn't update anything... :P > > > On Tue, May 25, 2010 at 5:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> The reason why we have turned it off is because updating Pharo images >> repeatedly caused problems (in contrast to PharoCore). People then reported >> issues. Unless this feature is working properly, we shouldn't enable it >> again. One possible cause of the problems are overrides by external packages >> in core code. But I think nobody has analyzed the problem in depth so far. >> >> Cheers, >> Adrian >> >> >> On May 25, 2010, at 21:48 , Carla F. Griggio wrote: >> >> > That annoyed me too. Shouldn't that option be checked by default? >> > >> > On Tuesday, May 25, 2010, laurent laffont <laurent.laffont(a)gmail.com> >> wrote: >> >> World Menu -> System -> Software Update >> >> Cheers,Laurent Laffont >> >> >> >> http://pharocasts.blogspot.com/ >> >> http://magaloma.blogspot.com/ >> >> >> >> >> >> 2010/5/25 Guillermo Polito <guillermopolito(a)gmail.com> >> >> >> >> >> >> I'm sorry but i can't find how to update my 1.1 image. Can I update my >> image with this changes? Can someone enlight me? :) >> >> >> >> Guille, the newbie >> >> >> >> >> >> >> >> On Mon, May 24, 2010 at 5:16 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> 11371 >> >> ----- >> >> - Issue 1281: Button in TestRunner to fileout the test results. Thanks >> Laurent. >> >> - Issue 2468: Better method trailer method creation. Part One. Thanks >> Igor. >> >> - Issue 2406: MovieMorph should be removed from the core. Thanks Alain. >> >> - Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks >> Laurent >> >> - Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks >> Guillermo. >> >> >> >> 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 >> >> >> _______________________________________________ >> 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 >

May 25, 2010

Re: [Pharo-project] ConnectionQueue defect in 1.0

by StÃ©phane Ducasse

bill can you open a new bug entry. There are too much activities so that we could remember all the information passing around :) Stef On May 25, 2010, at 8:58 PM, Schwab,Wilhelm K wrote: > Hello all, > > Please see attached - CAREFULLY :) It turns out that NetworkSmokeTest will fail in your images, for want of #nextMany: and other additions I have made to streams. I will try to get them packaged for release, but if nothing else, please take a careful look at ConnectionQueue, which appears to be broken in 1.x, and hopefully fixed by the attached. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Monday, May 24, 2010 6:33 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] ConnectionQueue defect in 1.0 > > Hello all, > > Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas? > > Billx > > <SocketWoes.1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 25, 2010

Re: [Pharo-project] [update 1.1] #11371

by Carla F. Griggio

:O So I guess that's why it actually didn't update anything... :P On Tue, May 25, 2010 at 5:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > The reason why we have turned it off is because updating Pharo images > repeatedly caused problems (in contrast to PharoCore). People then reported > issues. Unless this feature is working properly, we shouldn't enable it > again. One possible cause of the problems are overrides by external packages > in core code. But I think nobody has analyzed the problem in depth so far. > > Cheers, > Adrian > > > On May 25, 2010, at 21:48 , Carla F. Griggio wrote: > > > That annoyed me too. Shouldn't that option be checked by default? > > > > On Tuesday, May 25, 2010, laurent laffont <laurent.laffont(a)gmail.com> > wrote: > >> World Menu -> System -> Software Update > >> Cheers,Laurent Laffont > >> > >> http://pharocasts.blogspot.com/ > >> http://magaloma.blogspot.com/ > >> > >> > >> 2010/5/25 Guillermo Polito <guillermopolito(a)gmail.com> > >> > >> > >> I'm sorry but i can't find how to update my 1.1 image. Can I update my > image with this changes? Can someone enlight me? :) > >> > >> Guille, the newbie > >> > >> > >> > >> On Mon, May 24, 2010 at 5:16 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> 11371 > >> ----- > >> - Issue 1281: Button in TestRunner to fileout the test results. Thanks > Laurent. > >> - Issue 2468: Better method trailer method creation. Part One. Thanks > Igor. > >> - Issue 2406: MovieMorph should be removed from the core. Thanks Alain. > >> - Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks > Laurent > >> - Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks > Guillermo. > >> > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 25, 2010

Re: [Pharo-project] Issue 670: Should clean Morph menu

by StÃ©phane Ducasse

**EXCELLENT** truly excellent Yes we try to sort that and get some cleaning. > grab > copy to paste buffer > collapse > delete > copy text > go behind > add halo > duplicate > embed into-> > PasteUpMorph > SystemWindow > resize > change color... > drop shadow-> > show shadow > shadow color... > shadow offset... > layout-> > no layout > proportional layout > table layout > change layout inset... > child layout-> > disable layout in tables > horizontal resizing-> > rigid > shrink wrap > space fill > vertical resizing-> > rigid > shrink wrap > space fill > table layout-> > reverse table cells > clip to cell size > rubber band cells > change cell inset... > change min cell size... > change max cell size... > list direction-> > ... > wrap direction-> > ... > cell positioning-> > ... > list centering-> > ... > wrap centering-> > ... > list spacing-> > ... > cell spacing-> > ... > provide clipping > submorphs ?? > inspect > explore > browse hierarchy ?? > save morph in file > attach to resource ?? > show actions > debug-> > inspect morph > inspect owner chain > inspect model > explore morph > browse morph class > browse model class > explore view hierarchy > call #tempCommand ?? > define #tempCommand ?? > open editing > edit label... > > Cheers, > Guille > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 25, 2010

Re: [Pharo-project] Timeline PBE 2

by StÃ©phane Ducasse

As alex says we do not have a specific target when we will have enough good chapters we will bundle them together Stef On May 25, 2010, at 6:33 PM, Torsten Bergmann wrote: > Hi, > > what is the plan for an offical PBE2 book? > Will it align with the Pharo 1.1. release? > > Thx > T. > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 25, 2010