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

Re: [Pharo-project] Process questions about configurationOfâ¦.

by Mariano Martinez Peck

Hi Stef. I have answered what I think several times, but I will try to do one last shoot ;) I agree to what you say and I have some things to say and some questions: 1) For the implementation point of view, there must be an agreement between the jenkins and the ConfigurationOf. Several things have to be set down: WHICH VERSION to load, and for that version, which PACKAGES/GROUPS to load, and WHICH category tests to run. So...this can be easily done as conventions: a) for which version, we assume #stable (if we are building in pharo images before the current one). So say we are building in Pharo 1.3 then we always load #stable. So developers should maintain that method. If we are then building in Pharo 1.4, then I think we should use #bleedingEdge. Last option is to create a special symbol version for this special jenkins runner. b) for which package or group, each ConfigurationOf can just implement #defaultPackagesToLoadInPharo13: that answers an array with the packages/groups to load. Another posibility is to always load a specific group. Say we have a group called "CertifierGroup" and then we always load that group. c) we can just implement #testsCategoriesForPharo13 in each conf and that's all. That way, maintainers of ConfigurationOf only needs to keep #stable up to date, and just implement (for example) #defaultPackagesToLoadInPharo13 and #testsCategoriesForPharo13 2) Once the server has run and moved the conf to MetaRepoForPharo13, it is very cool because we can then after scan the repo MetaRepoForPharo13 and know that taking that conf, with that version and that amount of packages, then it should work ;) 3) What happens with tests? do we only accept 100% green tests as ok? In Fuel for example, we like to create tests before the real code. And moreover, we create tests to demonstrate things we don't support yet. So sometimes we have red tests even if there is no bug, but just a missing thing we will do in the near future. maybe we can have a treshlod ? say, 80% of green tests? 4) Answering to Guille, we don't care about overrides. I think each conf will be run in a clean pharo image as the jenkins does right now. Is it like this? 5) not as a first step, but as a future, the process of moving to MetaRepoForPharo13, could also move ALL mzc files of all the packages in order to be self-contained. But this is more complicated because then we need to use #repositoryOverrides: or something like that because even if we move mzc files our confs are pointing to another place... Or maybe we can change the confs on the fly...anyway, this is future ;) 6) once we have this repositories, we can have tools that scan those repos and let us load stuff from there. 7) Is this process propagated? Say I have ConfigurationOfGlorpDBX and I want to run this process. Such conf uses ConfigurationOfFFI. Will FFI be processed as well as glorpDBX or we only measure/analyzer the first one ? 8) Same as Guille? what happens with projects that do not have tests? There is no way to certify they work.... I would put them as broken directly ;) Sorry for the long mail. On Sat, Jan 7, 2012 at 12:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > What is the process we want? > What I would like is > > MetaRepoForPharo13Inbox were everybody can write > and a jenkins process that loads every published version > and try to load it (after we will run tests and check > rules). > depending on the result the configuration is promoted > into > MetaRepoForPharo13 > or > MetaRepoForPharo13Broken > > At the end of the month we will have one engineer working on jenkins and I > would like to ask him > to start to put in place this process. > > What do you think? > > Stef > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Schwab,Wilhelm K

Agreed, except for thinking that changing all of the module names is not a big deal :) An external library subclass is the way to go. I know this already exists in FFI, but the evolving chapter on Spock does not mention it - it should not only mention it, but recommend it, IMHO. Stef, does it make sense yet? ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Sunday, January 08, 2012 3:52 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Best way for FFI in Pharo On Sun, Jan 8, 2012 at 9:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: can you give an example that I understand "One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 " Bill: that already exists in FFI. Stef: what Bill says is that if you bind to a specific library you have to put its library name in each method that calls a ffi function. Example of DBX: apiErrorType: handle number: err "int odbx_error_type( odbx_t*, int )" <cdecl: long 'odbx_error_type' (ulong long) module: 'opendbx'> ^ self externalCallFailed ---- apiInitialize: handle backend: backend host: host port: port "long odbx_init(odbx_t**, char*, char*, char*)" <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> ^self externalCallFailed --- xxx --- Notice the "module: 'opendbx" So...if now the library is renamed or whatever, you have to change all methods. But I don't think this is a real big deal. There are much worst things. Finaly, I copy paste an answer from Andreas from a previous thread: The Right Way to do this is to have a subclass of ExternalLibrary and implement the class-side method #moduleName along the lines of: MyLibrary class>>moduleName "Answer the module name to use for this library" Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll']. Smalltalk platformName = 'unix' ifTrue:[ "check various locations and versions" #('/usr/lib/libMyLibrary.so' '/usr/lib/libMyLibrary.so.1' '/usr/lib/libMyLibrary.so.2' '/usr/share/libMyLibrary.so.1' '/usr/share/libMyLibrary.so.2' ) do:[:location| (FileDirectory fileExists: location) ifTrue:[^location]. ]. ^self error:'MyLibrary is not installed' ]. Tx On Jan 8, 2012, at 9:18 PM, Schwab,Wilhelm K wrote: > Stef, > > Absent the NB experience, +1 to the comments below. FFI has pretty much "just worked" for me. We need double arrays. Callbacks would be great. One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 It makes a LOT more sense to have a class per library, and that class knows the name to use. That's all the more true when one considers code such as ODBC that can run on multiple platforms with different names. #moduleName can test the OS and answer the correct name. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>] > Sent: Sunday, January 08, 2012 2:16 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] Best way for FFI in Pharo > > thanks for the feedback. > We will come back you soon :) > Because we should get FFI and NativeBoost fully working :). > > Stef > > On Jan 8, 2012, at 7:29 PM, ncalexan wrote: > >> >> fstephany wrote >>> >>> I'm also a bit lost between all the different options (plugins, >>> NativeBoost, FFI, Alien). >>> >> >> I also found this confusing, so let me tell my recent experience and my >> conclusion. >> >> I have written bindings to the SDL game programming library for use with >> Pharo. SDL is cross-platform, and I want to support Mac (most of all), >> Windows (one must), and Linux (if I must). As far as I can tell, Alien is >> not cross-platform and not maintained, so I have not spent time >> investigating it. >> >> Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package >> which parses the relevant C header files and then writes either an NB or FFI >> callout class tree. I need to define a few structures, make a class pool >> with some constants, and then define lots of callouts, many of which take >> references to structures (like 'foo(struct x*)'). >> >> I was able to make both work, more or less, on my Macbook Pro, using stock >> Pharo 1.3 images and Igor's NBCog.app. >> >> I found NB to be a nicer programmer experience but I found that the FFI just >> works. There are a lot of gratuitous differences, but: >> >> * NB requires a VM compiled with a separate plugin (that I built from source >> with no trouble -- Igor has done splendid work with CMakeVMMaker). >> * NB should be faster than the FFI at pretty much everything, but I can't >> say since I haven't measured. >> * NB has useful primitives for determining if your external objects are >> still valid and for determining the current operating system (I intend to >> use these even if I don't use NB). >> * NB has very few tests and examples and essentially no documentation. >> * NB has a simple conceptual model, but it is still not as simple as the FFI >> model. >> * NB uses variableByteClasses to great advantage -- this is very cool. >> >> * NB makes it easy to crash your image, since you are evaluating native code >> in image. >> * NB is still, to my eye, raw and untested on Mac. I had problems with >> stack alignments in bizarre places, and NB's interaction with garbage >> collection basically ended my attempts to use it. >> * NB is basically impossible to debug if you aren't very strong with x86 >> assembly (I'm not even strong with x86 assembly), and the stack >> manipulations rendered GDB pretty much useless for me. >> * NB does not integrate well with the Pharo tools -- I think the >> MethodTrailers are screwing up references, implementors, and source views, >> but I haven't investigated. >> * NB does not seem to support indirections very easily -- I struggled to >> understand how to interface to foreign C functions with specs like >> 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually >> gave up. >> >> I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings >> crash horribly for me, and although I was able to fix them, it I just don't >> hack enough x86 assembly to figure out all the tricks Igor is doing. The >> thought of making it all work on 3 platforms, and fix all the tool >> integration, was just too much for me. >> >> In conclusion, I prefer the FFI. It is old, cross platform, well tested, >> somewhat documented, and reliable. I think Igor has done some amazing work >> and I do not want to bash his project (and certainly not his code -- the >> man's a magician) but the fancy features are not necessary for my project. >> >> >> fstephany wrote >>> >>> Will this interface handle callbacks ? >>> >> >> I do not need callbacks so cannot speak to this issue. >> >> Yours, >> Nick Alexander >> >> -- >> View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

[Pharo-project] loading bytecodes into the image?

by Philippe Marschall

Hi Ok, I'm not pretending this isn't a stupid idea, I'm just curios. Suppose I want to build something that would allow me to load "compiled classes" (without sources) into the VM. How would you approach something like this? What things need special care (bindings, symbols, load order, â¦)? Cheers Philippe

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Mariano Martinez Peck

On Sun, Jan 8, 2012 at 9:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > can you give an example that I understand > "One thing I strongly recommend is to favor #moduleName over pragmas > listing the library - imagine changing 2000+ GSL calls if the library name > changes =:0 " > > Bill: that already exists in FFI. Stef: what Bill says is that if you bind to a specific library you have to put its library name in each method that calls a ffi function. Example of DBX: apiErrorType: handle number: err "int odbx_error_type( odbx_t*, int )" <cdecl: long 'odbx_error_type' (ulong long) module: 'opendbx'> ^ self externalCallFailed ---- apiInitialize: handle backend: backend host: host port: port "long odbx_init(odbx_t**, char*, char*, char*)" <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> ^self externalCallFailed --- xxx --- Notice the "module: 'opendbx" So...if now the library is renamed or whatever, you have to change all methods. But I don't think this is a real big deal. There are much worst things. Finaly, I copy paste an answer from Andreas from a previous thread: *The Right Way to do this is to have a subclass of ExternalLibrary and implement the class-side method #moduleName along the lines of: MyLibrary class>>moduleName "Answer the module name to use for this library" Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll']. Smalltalk platformName = 'unix' ifTrue:[ "check various locations and versions" #('/usr/lib/libMyLibrary.so' '/usr/lib/libMyLibrary.so.1' '/usr/lib/libMyLibrary.so.2' '/usr/share/libMyLibrary.so.1' '/usr/share/libMyLibrary.so.2'* *) do:[:location| (FileDirectory fileExists: location) ifTrue:[^location]. ]. ^self error:'MyLibrary is not installed' ]. * * * > Tx > > On Jan 8, 2012, at 9:18 PM, Schwab,Wilhelm K wrote: > > > Stef, > > > > Absent the NB experience, +1 to the comments below. FFI has pretty much > "just worked" for me. We need double arrays. Callbacks would be great. > One thing I strongly recommend is to favor #moduleName over pragmas > listing the library - imagine changing 2000+ GSL calls if the library name > changes =:0 It makes a LOT more sense to have a class per library, and > that class knows the name to use. That's all the more true when one > considers code such as ODBC that can run on multiple platforms with > different names. #moduleName can test the OS and answer the correct name. > > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane > Ducasse [stephane.ducasse(a)inria.fr] > > Sent: Sunday, January 08, 2012 2:16 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] Best way for FFI in Pharo > > > > thanks for the feedback. > > We will come back you soon :) > > Because we should get FFI and NativeBoost fully working :). > > > > Stef > > > > On Jan 8, 2012, at 7:29 PM, ncalexan wrote: > > > >> > >> fstephany wrote > >>> > >>> I'm also a bit lost between all the different options (plugins, > >>> NativeBoost, FFI, Alien). > >>> > >> > >> I also found this confusing, so let me tell my recent experience and my > >> conclusion. > >> > >> I have written bindings to the SDL game programming library for use with > >> Pharo. SDL is cross-platform, and I want to support Mac (most of all), > >> Windows (one must), and Linux (if I must). As far as I can tell, Alien > is > >> not cross-platform and not maintained, so I have not spent time > >> investigating it. > >> > >> Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs > package > >> which parses the relevant C header files and then writes either an NB > or FFI > >> callout class tree. I need to define a few structures, make a class > pool > >> with some constants, and then define lots of callouts, many of which > take > >> references to structures (like 'foo(struct x*)'). > >> > >> I was able to make both work, more or less, on my Macbook Pro, using > stock > >> Pharo 1.3 images and Igor's NBCog.app. > >> > >> I found NB to be a nicer programmer experience but I found that the FFI > just > >> works. There are a lot of gratuitous differences, but: > >> > >> * NB requires a VM compiled with a separate plugin (that I built from > source > >> with no trouble -- Igor has done splendid work with CMakeVMMaker). > >> * NB should be faster than the FFI at pretty much everything, but I > can't > >> say since I haven't measured. > >> * NB has useful primitives for determining if your external objects are > >> still valid and for determining the current operating system (I intend > to > >> use these even if I don't use NB). > >> * NB has very few tests and examples and essentially no documentation. > >> * NB has a simple conceptual model, but it is still not as simple as > the FFI > >> model. > >> * NB uses variableByteClasses to great advantage -- this is very cool. > >> > >> * NB makes it easy to crash your image, since you are evaluating native > code > >> in image. > >> * NB is still, to my eye, raw and untested on Mac. I had problems with > >> stack alignments in bizarre places, and NB's interaction with garbage > >> collection basically ended my attempts to use it. > >> * NB is basically impossible to debug if you aren't very strong with x86 > >> assembly (I'm not even strong with x86 assembly), and the stack > >> manipulations rendered GDB pretty much useless for me. > >> * NB does not integrate well with the Pharo tools -- I think the > >> MethodTrailers are screwing up references, implementors, and source > views, > >> but I haven't investigated. > >> * NB does not seem to support indirections very easily -- I struggled to > >> understand how to interface to foreign C functions with specs like > >> 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and > eventually > >> gave up. > >> > >> I wanted to help Igor with the NB project, but the NB-OpenGL Mac > bindings > >> crash horribly for me, and although I was able to fix them, it I just > don't > >> hack enough x86 assembly to figure out all the tricks Igor is doing. > The > >> thought of making it all work on 3 platforms, and fix all the tool > >> integration, was just too much for me. > >> > >> In conclusion, I prefer the FFI. It is old, cross platform, well > tested, > >> somewhat documented, and reliable. I think Igor has done some amazing > work > >> and I do not want to bash his project (and certainly not his code -- the > >> man's a magician) but the fancy features are not necessary for my > project. > >> > >> > >> fstephany wrote > >>> > >>> Will this interface handle callbacks ? > >>> > >> > >> I do not need callbacks so cannot speak to this issue. > >> > >> Yours, > >> Nick Alexander > >> > >> -- > >> View this message in context: > http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by StÃ©phane Ducasse

can you give an example that I understand "One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 " Tx On Jan 8, 2012, at 9:18 PM, Schwab,Wilhelm K wrote: > Stef, > > Absent the NB experience, +1 to the comments below. FFI has pretty much "just worked" for me. We need double arrays. Callbacks would be great. One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 It makes a LOT more sense to have a class per library, and that class knows the name to use. That's all the more true when one considers code such as ODBC that can run on multiple platforms with different names. #moduleName can test the OS and answer the correct name. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Sunday, January 08, 2012 2:16 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Best way for FFI in Pharo > > thanks for the feedback. > We will come back you soon :) > Because we should get FFI and NativeBoost fully working :). > > Stef > > On Jan 8, 2012, at 7:29 PM, ncalexan wrote: > >> >> fstephany wrote >>> >>> I'm also a bit lost between all the different options (plugins, >>> NativeBoost, FFI, Alien). >>> >> >> I also found this confusing, so let me tell my recent experience and my >> conclusion. >> >> I have written bindings to the SDL game programming library for use with >> Pharo. SDL is cross-platform, and I want to support Mac (most of all), >> Windows (one must), and Linux (if I must). As far as I can tell, Alien is >> not cross-platform and not maintained, so I have not spent time >> investigating it. >> >> Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package >> which parses the relevant C header files and then writes either an NB or FFI >> callout class tree. I need to define a few structures, make a class pool >> with some constants, and then define lots of callouts, many of which take >> references to structures (like 'foo(struct x*)'). >> >> I was able to make both work, more or less, on my Macbook Pro, using stock >> Pharo 1.3 images and Igor's NBCog.app. >> >> I found NB to be a nicer programmer experience but I found that the FFI just >> works. There are a lot of gratuitous differences, but: >> >> * NB requires a VM compiled with a separate plugin (that I built from source >> with no trouble -- Igor has done splendid work with CMakeVMMaker). >> * NB should be faster than the FFI at pretty much everything, but I can't >> say since I haven't measured. >> * NB has useful primitives for determining if your external objects are >> still valid and for determining the current operating system (I intend to >> use these even if I don't use NB). >> * NB has very few tests and examples and essentially no documentation. >> * NB has a simple conceptual model, but it is still not as simple as the FFI >> model. >> * NB uses variableByteClasses to great advantage -- this is very cool. >> >> * NB makes it easy to crash your image, since you are evaluating native code >> in image. >> * NB is still, to my eye, raw and untested on Mac. I had problems with >> stack alignments in bizarre places, and NB's interaction with garbage >> collection basically ended my attempts to use it. >> * NB is basically impossible to debug if you aren't very strong with x86 >> assembly (I'm not even strong with x86 assembly), and the stack >> manipulations rendered GDB pretty much useless for me. >> * NB does not integrate well with the Pharo tools -- I think the >> MethodTrailers are screwing up references, implementors, and source views, >> but I haven't investigated. >> * NB does not seem to support indirections very easily -- I struggled to >> understand how to interface to foreign C functions with specs like >> 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually >> gave up. >> >> I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings >> crash horribly for me, and although I was able to fix them, it I just don't >> hack enough x86 assembly to figure out all the tricks Igor is doing. The >> thought of making it all work on 3 platforms, and fix all the tool >> integration, was just too much for me. >> >> In conclusion, I prefer the FFI. It is old, cross platform, well tested, >> somewhat documented, and reliable. I think Igor has done some amazing work >> and I do not want to bash his project (and certainly not his code -- the >> man's a magician) but the fancy features are not necessary for my project. >> >> >> fstephany wrote >>> >>> Will this interface handle callbacks ? >>> >> >> I do not need callbacks so cannot speak to this issue. >> >> Yours, >> Nick Alexander >> >> -- >> View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > >

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Schwab,Wilhelm K

Stef, Absent the NB experience, +1 to the comments below. FFI has pretty much "just worked" for me. We need double arrays. Callbacks would be great. One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 It makes a LOT more sense to have a class per library, and that class knows the name to use. That's all the more true when one considers code such as ODBC that can run on multiple platforms with different names. #moduleName can test the OS and answer the correct name. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, January 08, 2012 2:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Best way for FFI in Pharo thanks for the feedback. We will come back you soon :) Because we should get FFI and NativeBoost fully working :). Stef On Jan 8, 2012, at 7:29 PM, ncalexan wrote: > > fstephany wrote >> >> I'm also a bit lost between all the different options (plugins, >> NativeBoost, FFI, Alien). >> > > I also found this confusing, so let me tell my recent experience and my > conclusion. > > I have written bindings to the SDL game programming library for use with > Pharo. SDL is cross-platform, and I want to support Mac (most of all), > Windows (one must), and Linux (if I must). As far as I can tell, Alien is > not cross-platform and not maintained, so I have not spent time > investigating it. > > Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package > which parses the relevant C header files and then writes either an NB or FFI > callout class tree. I need to define a few structures, make a class pool > with some constants, and then define lots of callouts, many of which take > references to structures (like 'foo(struct x*)'). > > I was able to make both work, more or less, on my Macbook Pro, using stock > Pharo 1.3 images and Igor's NBCog.app. > > I found NB to be a nicer programmer experience but I found that the FFI just > works. There are a lot of gratuitous differences, but: > > * NB requires a VM compiled with a separate plugin (that I built from source > with no trouble -- Igor has done splendid work with CMakeVMMaker). > * NB should be faster than the FFI at pretty much everything, but I can't > say since I haven't measured. > * NB has useful primitives for determining if your external objects are > still valid and for determining the current operating system (I intend to > use these even if I don't use NB). > * NB has very few tests and examples and essentially no documentation. > * NB has a simple conceptual model, but it is still not as simple as the FFI > model. > * NB uses variableByteClasses to great advantage -- this is very cool. > > * NB makes it easy to crash your image, since you are evaluating native code > in image. > * NB is still, to my eye, raw and untested on Mac. I had problems with > stack alignments in bizarre places, and NB's interaction with garbage > collection basically ended my attempts to use it. > * NB is basically impossible to debug if you aren't very strong with x86 > assembly (I'm not even strong with x86 assembly), and the stack > manipulations rendered GDB pretty much useless for me. > * NB does not integrate well with the Pharo tools -- I think the > MethodTrailers are screwing up references, implementors, and source views, > but I haven't investigated. > * NB does not seem to support indirections very easily -- I struggled to > understand how to interface to foreign C functions with specs like > 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually > gave up. > > I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings > crash horribly for me, and although I was able to fix them, it I just don't > hack enough x86 assembly to figure out all the tricks Igor is doing. The > thought of making it all work on 3 platforms, and fix all the tool > integration, was just too much for me. > > In conclusion, I prefer the FFI. It is old, cross platform, well tested, > somewhat documented, and reliable. I think Igor has done some amazing work > and I do not want to bash his project (and certainly not his code -- the > man's a magician) but the fancy features are not necessary for my project. > > > fstephany wrote >> >> Will this interface handle callbacks ? >> > > I do not need callbacks so cannot speak to this issue. > > Yours, > Nick Alexander > > -- > View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 8, 2012

[Pharo-project] [COTDC] 102 - ZLibReadStream

by sean＠clipperadams.com

101 classes done 795 classes remaining Continuing in Compression... Today: ZLibReadStream Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Jan. 8, 2012

[Pharo-project] Pharo and new Androids (was: happy new year plus cogdroid news)

by Dimitry Golubovsky

Hi, Guido Stepken wrote: > Google has unified development for handy and tablet 4.0. They have introduced scalable, animated tiles, reacting on events, coming from analysing contents of about 100 different protocols streaming > through the machine. Google even collects barometer and temperature information global, for own weather forecast, and A-GPS information for traffic jam maps. Well, every application on Android is event-driven (rather than polls for events itself). This of course applies to CogDroid. See [1] - how it was initially implemented in Andreas' classic VM port, and later the same design was done in Cog [2]. For scalable animated tiles I believe you mean the widget views which have been improved in Android 4. But having an application look as a widget is just a way to configure its main view. Currently the CogDroid main view is fullscreen. So, for events, I think more can be done in the way Android events are mapped to Smalltalk events. Currently only touch and keyboard events are processed, and they are treated by the image as regular Linux (polled) input events - just for the sake of the "Regular" GUI to work. Nothing prevents development of a different event handler behaving in desired way. Maybe some reflection must be done on incoming messages, and then recipients of those messages inside an image could be resolved symbolically. Do you have an example of an Android scalable tile application with sources? I might look which events it takes, and how can I map them into Smalltalk messages internally. For widget vs. fullscreen view: the code of VM itself has been separated into a Java class library, so it may be possible to write overriding classes for activity and view so it show up as a tile. Only nobody has tried this yet. Maybe I need to make some of widget functionality part of the library. > This new tile approach is even intended to be > introduced onto desktops, so i fear, former designs with pulldown menus will look old fashioned in about one year for customers, included Windows 7, Mac OS X. > This new tile design even can be found already in Samsung TV's. Yes, and I am belong to the number of people who want this. The Android-x86 project makes steps towards better adoption of Android on the Intel architecture (desktops and laptops). Unfortunately, the state of things is: Gingerbread works more or less (I use it for my Cogdroid testing) - but it is not very convenient for desktop use - at the userland level of course, Honeycomb works so-so (I was able to PXE-load it onto a PC, and browse Internet, but asynchronous downloads always get stuck and never complete, so I could not even install CogDroid on it). ICS is from barely working to not working at all - never worked for me. But eventually I think (open sourced part of) Android will make a good single-user client-oriented Linux distro (Ubuntu and likes are server distros, and there seems to be no other Linux distro aimed at an average smartphone user level than Android). > Like Jobs banned flash on iphone for power consumption disadvantages, Google has dropped the "monolithic" design approach and invented a "multi-vm-vm", where multiple bytecodes are executed > in parallel, but time slices are controlled by the underlying linux scheduler. This approach leads to very good uptimes of your handy or tablet. 1/2 Watt incl. Display at normal operation. Well, if you mean that most of the userland is event-driven, it is true, and as I wrote earlier, the only reason I need to keep sending periodic timer events to CogDroid is to make its regular Pharo desktop work as usual: blinking text cursors, scrollers when scroll buttons are held still, network operations which run long without any user input. If you need an application which only reacts to external events, and not doing anything in between (like most of mobile apps should behave), just put the background timer delay to maximum value, and Cog code will not run without external events at all. I'll try to make this configurable. > So, any "monolitic" vm will consume too much power. Pharo Smalltalk completely had to be redesigned to work on multi-vm-vm, where parts of smalltalk code can be time scheduled by the > underlying kernel. Apart from the fact, that about a hundred new protocols had to be implemented in pharo, i see NO chance in integrating pharo in the new operating system designs. I think we already have this covered in part - see my notes on disabling the background timer, and reflection on external messages to resolve them into Smalltalk classes to handle them. > This is state of development on vm's . And yes, jitter included. Thanks for your suggestions - very interesting direction of development. --------------------- [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003385.html [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-August/052848.html -- Dimitry Golubovsky Anywhere on the Web

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by StÃ©phane Ducasse

thanks for the feedback. We will come back you soon :) Because we should get FFI and NativeBoost fully working :). Stef On Jan 8, 2012, at 7:29 PM, ncalexan wrote: > > fstephany wrote >> >> I'm also a bit lost between all the different options (plugins, >> NativeBoost, FFI, Alien). >> > > I also found this confusing, so let me tell my recent experience and my > conclusion. > > I have written bindings to the SDL game programming library for use with > Pharo. SDL is cross-platform, and I want to support Mac (most of all), > Windows (one must), and Linux (if I must). As far as I can tell, Alien is > not cross-platform and not maintained, so I have not spent time > investigating it. > > Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package > which parses the relevant C header files and then writes either an NB or FFI > callout class tree. I need to define a few structures, make a class pool > with some constants, and then define lots of callouts, many of which take > references to structures (like 'foo(struct x*)'). > > I was able to make both work, more or less, on my Macbook Pro, using stock > Pharo 1.3 images and Igor's NBCog.app. > > I found NB to be a nicer programmer experience but I found that the FFI just > works. There are a lot of gratuitous differences, but: > > * NB requires a VM compiled with a separate plugin (that I built from source > with no trouble -- Igor has done splendid work with CMakeVMMaker). > * NB should be faster than the FFI at pretty much everything, but I can't > say since I haven't measured. > * NB has useful primitives for determining if your external objects are > still valid and for determining the current operating system (I intend to > use these even if I don't use NB). > * NB has very few tests and examples and essentially no documentation. > * NB has a simple conceptual model, but it is still not as simple as the FFI > model. > * NB uses variableByteClasses to great advantage -- this is very cool. > > * NB makes it easy to crash your image, since you are evaluating native code > in image. > * NB is still, to my eye, raw and untested on Mac. I had problems with > stack alignments in bizarre places, and NB's interaction with garbage > collection basically ended my attempts to use it. > * NB is basically impossible to debug if you aren't very strong with x86 > assembly (I'm not even strong with x86 assembly), and the stack > manipulations rendered GDB pretty much useless for me. > * NB does not integrate well with the Pharo tools -- I think the > MethodTrailers are screwing up references, implementors, and source views, > but I haven't investigated. > * NB does not seem to support indirections very easily -- I struggled to > understand how to interface to foreign C functions with specs like > 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually > gave up. > > I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings > crash horribly for me, and although I was able to fix them, it I just don't > hack enough x86 assembly to figure out all the tricks Igor is doing. The > thought of making it all work on 3 platforms, and fix all the tool > integration, was just too much for me. > > In conclusion, I prefer the FFI. It is old, cross platform, well tested, > somewhat documented, and reliable. I think Igor has done some amazing work > and I do not want to bash his project (and certainly not his code -- the > man's a magician) but the fancy features are not necessary for my project. > > > fstephany wrote >> >> Will this interface handle callbacks ? >> > > I do not need callbacks so cannot speak to this issue. > > Yours, > Nick Alexander > > -- > View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 8, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

> What I don't understand is why in Squeak it does work. >> > > Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper than > I should have, so I'll publish a few changes soon. > > Ok, you are right. Squeak #inboundPointersExcluding: is using #instVarsInclude: rather than #pointsTo. And that solves the problem in Pharo as well. But still, I would like to understand why we get those method contexts with #pointsTo. Thanks Levente for your help. If you find something let us know, I want to learn :) Thanks > > Levente > > >> Thanks in advance Levente! >> >> >> >> >> >> it will create at least one new MethodContext which is not included in >>> that list. >>> >>> >>> Levente >>> >>> >>> >>>> >>>> >>>> >>>> >>>> Levente >>>>> >>>>> >>>>> Thanks again. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Do you mean what I understand :)? that some tools compiled methods? >>>>>>> :) >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>> http://marianopeck.wordpress. >>>>>>>> **** >>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>> **** >>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012