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

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 2:10 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : >> > >> > >> > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> > >> > wrote: >> >> >> >> Hi, >> >> >> >> sorry for not sending before: work is hard :P >> >> yes, that should work, and no, I don't know a better way to define it. >> > >> > >> > No it won't work. See my message. >> > >> >> >> >> I think Eliot's idea is to form "libraries" of generic callbacks (for >> >> mars, for instance, I have CocoaCallback, child of Callback, who >> defines all >> >> my needed signatures, looks a lot at first instance, but if you see in >> >> detail, finally there are not so much variants) >> > >> > >> > Yes, the idea is to have a library of signature methods that marshal >> > specific C callback signatures to/from Smalltalk blocks. The pragma >> > specifies what ABI (application binary interface, or stack layout) the >> > signature is for so that the scheme is cross-platform. But I expect >> that >> > these signature methods could be the output of an ABI compiler, so that >> one >> > wouldn't have to write them by hand. The pragma doesn't need to >> include a >> > word-size since IA64 is a different ABI to IA32, and so the ABI subsumes >> > word size. >> > >> > HTH >> > >> >> >> Let me understand... >> If I have a signature (char x,double y, short z) IA-32, where is the >> spalien pointing to? >> > > At the first parameter immediately below the return address. > > >> - the original call stack (with proper ABI alignment, that is offsets >> 0,4,12, or 1-based indices 1,5,13) >> > > Right. > > >> - a serialized copy without alignment padding (offsets 0,1,9, or >> 1-based indices 1,2,10) >> > > No. > > >> In the former case, that means that the indices must be computed >> according to ABI (might be different in PPC for example). >> > > Right. Hence the pragma containing the name of the ABI to allow the > system to select the appropriate version. Note that the implementation > allows for passing a pointer to a struct containing marshalled register > arguments for RISC platforms, although this isn't used yet since it's not > needed on x86. > > >> And even if such code is generated with an ABI-aware interface >> compiler, is it really platform independent? >> > > The scheme is platform-independent, allowing platform-specific versions of > marshalling code to exist side-by-side. > > >> I'm quite sure the ABI have subtle variations, which are not even >> platform but compiler specific... >> > > No. That's the definition of an ABI. The ABI specifies the calling > convention for a particular platform, and compilers must conform to the ABI > for all external and system calls. > > >> For example of such niceties in win32, did you ever try returning a >> structure by value from a cdecl mingw-gcc compiled function to a cdecl >> visual studio compiled caller, not even speaking of different internal >> structure alignment padding (controlled with #pragma packed(4) or >> other compiler options...) >> > > That's different. Internal interfaces used by particular compilers are no > covered by the ABI but then they aren't used for inter-component interfaces > such as callbacks. If you look, for example, at the Intel x86 compiler > you'll see it'll use a register-based calling convention, multiple > entry-points for functions (an internal and an external one), etc. But > these non-standard interfaces are only used internally, typically between > functions within a single compilation unit. > > >> This apple page helps a lot, for example it tells how gcc returns a >> structure by value... >> >> https://developer.apple.com/library/mac/#documentation/developertools/Conce… > > > I know. But the bibles in these cases are documents such as "SYSTEM V > APPLICATION BINARY INTERFACE, Intel386? Architecture Processor > Supplement, Fourth Edition". You'll find a concise specification of the > calling convention of the ABI, and structure layout etc, in chapter 3. > Actually Nicolas, you're quite right. One needs to use the Apple document on those platforms that use SSE2. These mandate a 16-byte stack alignment to allow SSE instructions to function properly (many of them require 8-byte alignment). But there's a small difference between the two and the one set of VM code copes with linux, Mac and win32, including the pascal calling convention. > > cheers, > Eliot > >> >> >> Nicolas >> >> >> >> >> >> >> best, >> >> Esteban >> >> >> >> El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: >> >> >> >> > Esteban, >> >> > >> >> > Will this work? Even if so, is there a better way to define it? >> >> > >> >> > longVoidStarLongRetInt: callbackContext sp: spAlien >> >> > <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >> >> > ^callbackContext wordResult: >> >> > (block >> >> > value: (Alien newC:4) >> >> > value: (Alien forPointer: (spAlien >> unsignedLongAt: >> >> > 5)) >> >> > value: (Alien newC:4) >> >> > ) >> >> > >> >> > 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: Thursday, March 01, 2012 12:15 AM >> >> > To: Pharo-project(a)lists.gforge.inria.fr >> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> > >> >> > thanks!!!!! >> >> > >> >> > >> >> > >> >> > >> >> > ________________________________________ >> >> > From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> Lorenzano >> >> > [estebanlm(a)gmail.com] >> >> > Sent: Wednesday, February 29, 2012 10:18 PM >> >> > To: Pharo-project(a)lists.gforge.inria.fr >> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> > >> >> > you need to define a signature... not at home now, but wait 'til >> >> > tomorrow and I'll send an example >> >> > >> >> > best, >> >> > Esteban >> >> > >> >> > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: >> >> > >> >> >> What does "cannot find callback signature" mean from >> #signature:block:? >> >> >> I'm stuck. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ________________________________________ >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> Lorenzano >> >> >> [estebanlm(a)gmail.com] >> >> >> Sent: Wednesday, February 29, 2012 6:54 PM >> >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >> >> >> >> yeah... sorry about that >> >> >> is a bug on FFI... I managed to worked around it for HPDF, for a >> >> >> customer's project... but of course is not a good and definitive >> solution. >> >> >> >> >> >> best, >> >> >> Esteban >> >> >> >> >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >> >> >> >> >> >>> This is gonna take a while... I had structs flying around as >> void* >> >> >>> and was moderately happy. Nonetheless, your suggestion worked, >> provided I >> >> >>> add a lot getHandle asInteger and change the void* to long :( >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________________ >> >> >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of >> Esteban Lorenzano >> >> >>> [estebanlm(a)gmail.com] >> >> >>> Sent: Wednesday, February 29, 2012 6:23 PM >> >> >>> To: Pharo-project(a)lists.gforge.inria.fr >> >> >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >>> >> >> >>> I also found some problems using void* in linux... maybe you want >> to >> >> >>> use long (which has same size)... I "fixed" my problems that way. >> >> >>> >> >> >>> yes... maybe we need to look at FFI to see why void* has problems >> some >> >> >>> times, but well, that can help you atm (sorry for not having a >> better >> >> >>> answer) >> >> >>> >> >> >>> Esteban >> >> >>> >> >> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >> >> >>> >> >> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> >> >>>> wrote: >> >> >>>>> Another glitch: is there any problem passing things as void*? >> I'm >> >> >>>>> getting failure to coerce errors that did not arise before. >> >> >>>>> >> >> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got >> >> >>>> NativeBoost toy to play with. >> >> >>>> >> >> >>>> Please file the issue, describing the problem. so we can look >> over it >> >> >>>> and fix it. >> >> >>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ________________________________________ >> >> >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor >> Stasenko >> >> >>>>> [siguctua(a)gmail.com] >> >> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM >> >> >>>>> To: Pharo-project(a)lists.gforge.inria.fr >> >> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >>>>> >> >> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> >> >>>>> wrote: >> >> >>>>>> Does 1.3 by default not create field accessors? Why is that? I >> >> >>>>>> thought >> >> >>>>>> nothing was happening. >> >> >>>>>> >> >> >>>>> >> >> >>>>> Good question, i'd like to know the answer too. >> >> >>>>> It is related to MC final 'installation' phase, >> >> >>>>> where it initializing all classes. >> >> >>>>> >> >> >>>>> In NativeBoost i was also using >> >> >>>>> >> >> >>>>> noteCompilationOf: aSelector meta: isMeta >> >> >>>>> "A hook allowing some classes to react to recompilation of >> >> >>>>> certain selectors" >> >> >>>>> >> >> >>>>> but there was a big question, at which point this hook is >> triggered, >> >> >>>>> and looks like some changes in MC stop triggering it/triggering >> at >> >> >>>>> wrong time (not all methods get into a class/ class not >> initialized >> >> >>>>> etc), >> >> >>>>> which makes it not very useful. >> >> >>>>> >> >> >>>>> So i ended up creating a DNU handler on instance side, then on >> DNU i >> >> >>>>> check if i have field accessors and if not, >> >> >>>>> compile them on the fly. >> >> >>>>> >> >> >>>>> >> >> >>>>>> Bill >> >> >>>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Best regards, >> >> >>>>> Igor Stasenko. >> >> >>>>> >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> Best regards, >> >> >>>> Igor Stasenko. >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> >> > > > -- > best, > Eliot > > -- best, Eliot

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Nicolas Cellier

Le 1 mars 2012 23:10, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : >> > >> > >> > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> sorry for not sending before: work is hard :P >> >> yes, that should work, and no, I don't know a better way to define it. >> > >> > >> > No it won't work. Â See my message. >> > >> >> >> >> I think Eliot's idea is to form "libraries" of generic callbacks (for >> >> mars, for instance, I have CocoaCallback, child of Callback, who >> >> defines all >> >> my needed signatures, looks a lot at first instance, but if you see in >> >> detail, finally there are not so much variants) >> > >> > >> > Yes, the idea is to have a library of signature methods that marshal >> > specific C callback signatures to/from Smalltalk blocks. Â The pragma >> > specifies what ABI (application binary interface, or stack layout) the >> > signature is for so that the scheme is cross-platform. Â But I expect >> > that >> > these signature methods could be the output of an ABI compiler, so that >> > one >> > wouldn't have to write them by hand. Â The pragma doesn't need to include >> > a >> > word-size since IA64 is a different ABI to IA32, and so the ABI subsumes >> > word size. >> > >> > HTH >> > >> >> >> Let me understand... >> If I have a signature (char x,double y, short z) IA-32, where is the >> spalien pointing to? > > > At the first parameter immediately below the return address. > >> >> - the original call stack (with proper ABI alignment, that is offsets >> 0,4,12, or 1-based indices 1,5,13) > > > Right. > >> >> - a serialized copy without alignment padding (offsets 0,1,9, or >> 1-based indices 1,2,10) > > > No. > >> >> In the former case, that means that the indices must be computed >> according to ABI (might be different in PPC for example). > > > Right. Â Hence the pragma containing the name of the ABI to allow the system > to select the appropriate version. Â Note that the implementation allows for > passing a pointer to a struct containing marshalled register arguments for > RISC platforms, although this isn't used yet since it's not needed on x86. > >> >> And even if such code is generated with an ABI-aware interface >> compiler, is it really platform independent? > > > The scheme is platform-independent, allowing platform-specific versions of > marshalling code to exist side-by-side. > OK, thanks that's clear. >> >> I'm quite sure the ABI have subtle variations, which are not even >> platform but compiler specific... > > > No. Â That's the definition of an ABI. Â The ABI specifies the calling > convention for a particular platform, and compilers must conform to the ABI > for all external and system calls. > >> >> For example of such niceties in win32, did you ever try returning a >> structure by value from a cdecl mingw-gcc compiled function to a cdecl >> visual studio compiled caller, not even speaking of different internal >> structure alignment padding (controlled with #pragma packed(4) or >> other compiler options...) > > > That's different. Â Internal interfaces used by particular compilers are no > covered by the ABI but then they aren't used for inter-component interfaces > such as callbacks. Â If you look, for example, at the Intel x86 compiler > you'll see it'll use a register-based calling convention, multiple > entry-points for functions (an internal and an external one), etc. Â But > these non-standard interfaces are only used internally, typically between > functions within a single compilation unit. > OK, but in the structure by value case, I created functions exported as public DLL entry points, and that did not make them compiler-agnostic. Unless I did something wrong, VisualStudio and gcc seem to have both a different idea of cdecl (and stdcall too). >> >> This apple page helps a lot, for example it tells how gcc returns a >> structure by value... >> >> https://developer.apple.com/library/mac/#documentation/developertools/Conce… > > > I know. Â But the bibles in these cases are documents such as "SYSTEM V > APPLICATION BINARY INTERFACE,Â Intel386? Architecture Processor > Supplement,Â Fourth Edition". Â You'll find a concise specification of the > calling convention of the ABI, and structure layout etc, in chapter 3. > > cheers, > Eliot Yes, I'm pretty sure you know much more than me on the subject, I'm very reluctant in dealing with such low level unless I'm forced to ;) And a link to the bible can be found at bottom of apple page for the other guys having to put some grease on their hands ;) But from what I read, we should then have a MacOSX-IA-32 ABI and a SystemV-i386 ABI which are mostly the same with a few exceptions noted on top of apple's page, and structure returned by value are one such exception. My 2Â¢ advice would be to avoid such exception (for example write a wrapper that pass a pointer to the struct instead). Otherwise, one should be prepared to read technical specs and understand how to write his own marshaller. Nicolas >> >> >> >> Nicolas >> >> >> >> >> >> >> best, >> >> Esteban >> >> >> >> El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: >> >> >> >> > Esteban, >> >> > >> >> > Will this work? Â Even if so, is there a better way to define it? >> >> > >> >> > longVoidStarLongRetInt: callbackContext sp: spAlien >> >> > Â Â Â <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >> >> > Â Â Â ^callbackContext wordResult: >> >> > Â Â Â Â Â Â Â (block >> >> > Â Â Â Â Â Â Â Â Â Â Â value: (Alien newC:4) >> >> > Â Â Â Â Â Â Â Â Â Â Â value: (Alien forPointer: (spAlien >> >> > unsignedLongAt: >> >> > 5)) >> >> > Â Â Â Â Â Â Â Â Â Â Â value: (Alien newC:4) >> >> > Â Â Â Â Â Â Â ) >> >> > >> >> > 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: Thursday, March 01, 2012 12:15 AM >> >> > To: Pharo-project(a)lists.gforge.inria.fr >> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> > >> >> > thanks!!!!! >> >> > >> >> > >> >> > >> >> > >> >> > ________________________________________ >> >> > From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> >> > Lorenzano >> >> > [estebanlm(a)gmail.com] >> >> > Sent: Wednesday, February 29, 2012 10:18 PM >> >> > To: Pharo-project(a)lists.gforge.inria.fr >> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> > >> >> > you need to define a signature... not at home now, but wait 'til >> >> > tomorrow and I'll send an example >> >> > >> >> > best, >> >> > Esteban >> >> > >> >> > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: >> >> > >> >> >> What does "cannot find callback signature" mean from >> >> >> #signature:block:? >> >> >> Â I'm stuck. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ________________________________________ >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> >> >> Lorenzano >> >> >> [estebanlm(a)gmail.com] >> >> >> Sent: Wednesday, February 29, 2012 6:54 PM >> >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >> >> >> >> yeah... sorry about that >> >> >> is a bug on FFI... I managed to worked around it for HPDF, for a >> >> >> customer's project... but of course is not a good and definitive >> >> >> solution. >> >> >> >> >> >> best, >> >> >> Esteban >> >> >> >> >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >> >> >> >> >> >>> This is gonna take a while... Â I had structs flying around as >> >> >>> void* >> >> >>> and was moderately happy. Â Nonetheless, your suggestion worked, >> >> >>> provided I >> >> >>> add a lot getHandle asInteger and change the void* to long :( >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________________ >> >> >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> >> >>> Lorenzano >> >> >>> [estebanlm(a)gmail.com] >> >> >>> Sent: Wednesday, February 29, 2012 6:23 PM >> >> >>> To: Pharo-project(a)lists.gforge.inria.fr >> >> >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >>> >> >> >>> I also found some problems using void* in linux... maybe you want >> >> >>> to >> >> >>> use long (which has same size)... I "fixed" my problems that way. >> >> >>> >> >> >>> yes... maybe we need to look at FFI to see why void* has problems >> >> >>> some >> >> >>> times, but well, that can help you atm (sorry for not having a >> >> >>> better >> >> >>> answer) >> >> >>> >> >> >>> Esteban >> >> >>> >> >> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >> >> >>> >> >> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> >> >>>> wrote: >> >> >>>>> Another glitch: is there any problem passing things as void*? >> >> >>>>> Â I'm >> >> >>>>> getting failure to coerce errors that did not arise before. >> >> >>>>> >> >> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got >> >> >>>> NativeBoost toy to play with. >> >> >>>> >> >> >>>> Please file the issue, describing the problem. so we can look over >> >> >>>> it >> >> >>>> and fix it. >> >> >>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ________________________________________ >> >> >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor >> >> >>>>> Stasenko >> >> >>>>> [siguctua(a)gmail.com] >> >> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM >> >> >>>>> To: Pharo-project(a)lists.gforge.inria.fr >> >> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >>>>> >> >> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> >> >>>>> wrote: >> >> >>>>>> Does 1.3 by default not create field accessors? Â Why is that? Â I >> >> >>>>>> thought >> >> >>>>>> nothing was happening. >> >> >>>>>> >> >> >>>>> >> >> >>>>> Good question, i'd like to know the answer too. >> >> >>>>> It is related to MC final 'installation' phase, >> >> >>>>> where it initializing all classes. >> >> >>>>> >> >> >>>>> In NativeBoost i was also using >> >> >>>>> >> >> >>>>> noteCompilationOf: aSelector meta: isMeta >> >> >>>>> Â Â "A hook allowing some classes to react to recompilation of >> >> >>>>> certain selectors" >> >> >>>>> >> >> >>>>> but there was a big question, at which point this hook is >> >> >>>>> triggered, >> >> >>>>> and looks like some changes in MC stop triggering it/triggering >> >> >>>>> at >> >> >>>>> wrong time (not all methods get into a class/ class not >> >> >>>>> initialized >> >> >>>>> etc), >> >> >>>>> which makes it not very useful. >> >> >>>>> >> >> >>>>> So i ended up creating a DNU handler on instance side, then on >> >> >>>>> DNU i >> >> >>>>> check if i have field accessors and if not, >> >> >>>>> compile them on the fly. >> >> >>>>> >> >> >>>>> >> >> >>>>>> Bill >> >> >>>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Best regards, >> >> >>>>> Igor Stasenko. >> >> >>>>> >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> Best regards, >> >> >>>> Igor Stasenko. >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> > > > > -- > best, > Eliot >

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 1:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Eliot, > > That helps a bit; it's still unfamiliar territory. I am a little bothered > by #wordResult: and #floatResult. There are times when one is expected to > return 16 bit values (rare) and either a float or a double (common). Does > that flexibility exist? > Yes, the flexibility exists. But the mechanism needed to provide the flexibility is less than one might expect. For example, on x86 there are three fundamental return conventions, one for integral values, one for floating-point values, and one for structure values. See e.g. chapter 3 of the Sys V ABI for 386 (in my reply to Nicolas). Read it; it's good for the soul; makes one value Smalltalk's simplicity. Integral values are returned in %eax, %edx. edx is not used if the value fits in 32-bits. So the same sequence can be used to answer all integral values from 1 byte to 8 bytes, irrespective of sign. That said, I use two sequences, one for 32-bits or less and one for 33 to 64 bits. In your example of answering 16 bits one simply answers either the sign-extension of 16-bits (if signed) to 32-bits or the zero-extension of 16-bits to 32-bits (if unsigned). In any case, the result is answered in %eax, and it is up to the caller to access the result correctly. Float values are returned on the top of the floating point register stack (%st(0)). The same machine-code sequence can be used to answer single, double and extended precision floats, since on the fp stack, they are all represented in the same extended format. So on x86 the callback implementation supports 4 return mechanisms, retword, retword64, retdouble and retstruct. So far only two of these are fleshed out in Smalltalk code. But look at http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/vmCallback.h & http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/IA32ABI/ia32ab… you'll see the other two. cheers, Eliot > > Bill > > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.miranda(a)gmail.com] > *Sent:* Thursday, March 01, 2012 3:26 PM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Alien signature: first attempt > > > > On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Esteban, >> >> Will this work? Even if so, is there a better way to define it? >> > > No it won't work, because you don't understand what it does. > > >> >> longVoidStarLongRetInt: callbackContext sp: spAlien >> <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >> ^callbackContext wordResult: >> (block >> value: (Alien newC:4) >> value: (Alien forPointer: (spAlien unsignedLongAt: >> 5)) >> value: (Alien newC:4) >> ) >> > > The above takes only one parameter's value from the spAlien (the void * > value) and passes garbage for the other parameters. The spAlien is a > pointer to the incoming C callback stack frame, i.e. a pointer to the > callback's parameters. So spAlien unsignedLongAt: 5 gets the four-byte > pointer for the void * parameter, wraps it up in a convenient pointer Alien > (so the callback block can e.g. indirect through it to get at the data the > pointer is pointing to), and passes it as the second argument of the > callback block. But the two Alien newC: 4's are entirely bogus, passing > effectively uninitialized data for the first and third parameters of the > callback block. They're just empty Aliens, when in fact you want to pass > two longs to the block for the first and third parameters. > > So to pass values in you need something like: > > longVoidStarLongRetInt: callbackContext sp: spAlien > <signature: 'int (*) (long, void *, long)' abi: 'IA32'> > ^callbackContext wordResult: > (block > value: (spAlien signedLongAt: 1) > value: (Alien forPointer: (spAlien unsignedLongAt: > 5)) > value: (spAlien signedLongAt: 9) > ) > > You might also need to consider passing the result of the block back > out. If you only want to use it to answer integers then the above is fine. > But take a look at the intcharstarRetint:sp: signature: > > intcharstarRetint: callbackContext sp: spAlien > <signature: 'int (*)(int, char *)' abi: 'IA32'> > ^callbackContext wordResult: > ((block > value: (spAlien signedLongAt: 1) ~= 0 > value: (Alien forPointer: (spAlien unsignedLongAt: 5)) strcpyUTF8) > ifNil: [0] > ifNotNil: > [:result| > result isInteger > ifTrue: [result] > ifFalse: [result == true ifTrue: [1] ifFalse: [0]]]) > > Analogously it passes a signed integer as the first argument and a UTF8 > string derived from the second char * parameter. (The method should > probably be called intcharstarasUTF8Retint:sp: or some such; forgive me, > we're getting there). > > But on return it takes the result of the callback block and passes it to > the ifNil:ifNotNil: which > - maps a nil result form the block to 0 (ifNil: [0]) > - maps integers to integers (which will only deal correctly with integers > in the 32-bit range), and > - maps true to 1, mapping all other results to 0. > > Does what's going on now make more sense? > > HTH, > Eliot > > >> 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: Thursday, March 01, 2012 12:15 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> thanks!!!!! >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> Lorenzano [estebanlm(a)gmail.com] >> Sent: Wednesday, February 29, 2012 10:18 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> you need to define a signature... not at home now, but wait 'til tomorrow >> and I'll send an example >> >> best, >> Esteban >> >> El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: >> >> > What does "cannot find callback signature" mean from #signature:block:? >> I'm stuck. >> > >> > >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> Lorenzano [estebanlm(a)gmail.com] >> > Sent: Wednesday, February 29, 2012 6:54 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> > >> > yeah... sorry about that >> > is a bug on FFI... I managed to worked around it for HPDF, for a >> customer's project... but of course is not a good and definitive solution. >> > >> > best, >> > Esteban >> > >> > El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >> > >> >> This is gonna take a while... I had structs flying around as void* >> and was moderately happy. Nonetheless, your suggestion worked, provided I >> add a lot getHandle asInteger and change the void* to long :( >> >> >> >> >> >> >> >> >> >> ________________________________________ >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >> Lorenzano [estebanlm(a)gmail.com] >> >> Sent: Wednesday, February 29, 2012 6:23 PM >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >> >> I also found some problems using void* in linux... maybe you want to >> use long (which has same size)... I "fixed" my problems that way. >> >> >> >> yes... maybe we need to look at FFI to see why void* has problems some >> times, but well, that can help you atm (sorry for not having a better >> answer) >> >> >> >> Esteban >> >> >> >> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >> >> >> >>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> wrote: >> >>>> Another glitch: is there any problem passing things as void*? I'm >> getting failure to coerce errors that did not arise before. >> >>>> >> >>> No idea. As you may suspect, i stopped using FFI/Alien once i got >> >>> NativeBoost toy to play with. >> >>> >> >>> Please file the issue, describing the problem. so we can look over it >> >>> and fix it. >> >>> >> >>>> >> >>>> >> >>>> ________________________________________ >> >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [ >> siguctua(a)gmail.com] >> >>>> Sent: Wednesday, February 29, 2012 5:51 PM >> >>>> To: Pharo-project(a)lists.gforge.inria.fr >> >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >>>> >> >>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> wrote: >> >>>>> Does 1.3 by default not create field accessors? Why is that? I >> thought >> >>>>> nothing was happening. >> >>>>> >> >>>> >> >>>> Good question, i'd like to know the answer too. >> >>>> It is related to MC final 'installation' phase, >> >>>> where it initializing all classes. >> >>>> >> >>>> In NativeBoost i was also using >> >>>> >> >>>> noteCompilationOf: aSelector meta: isMeta >> >>>> "A hook allowing some classes to react to recompilation of >> certain selectors" >> >>>> >> >>>> but there was a big question, at which point this hook is triggered, >> >>>> and looks like some changes in MC stop triggering it/triggering at >> >>>> wrong time (not all methods get into a class/ class not initialized >> >>>> etc), >> >>>> which makes it not very useful. >> >>>> >> >>>> So i ended up creating a DNU handler on instance side, then on DNU i >> >>>> check if i have field accessors and if not, >> >>>> compile them on the fly. >> >>>> >> >>>> >> >>>>> Bill >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Best regards, >> >>>> Igor Stasenko. >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Best regards, >> >>> Igor Stasenko. >> >>> >> >> >> >> >> >> >> > >> > >> > >> >> >> >> >> > > > -- > best, > Eliot > > -- best, Eliot

March 1, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Marcus Denker

> > I think this attitude is what will continue to hold Pharo back from wider > adoption. I've found 1.4 to be unusable for daily development. And yet > there's no interest in fixing problems in 1.3. There is. But we need to be reasonable... we can not back-port everything. Even fixing bugs changes the system so that it leads to incompatibility and new problems. > > And lest you think I don't want to contribute, I'll point you to > > http://code.google.com/p/pharo/issues/detail?id=4549&can=1&q=test%20runner&… > > where I > a) submitted a bug report > b) included a video demonstrating the bug > c) included a patch fixing the bug > Yes, and I only understood the problem last week. Because I use a mouse, and it works with a mouse with right-click... it even works when your track-pad is configured with right click. It only does not work if not. > responses were > - "not a showstopper -> move it to 1.4" > - "for me the bug entry is not really relevant" > Then complain! There are 450 open reports in the database... we closed nearly 5000 issues. There will be mistakes. The thing is that we could have not released 1.3 until we fixed all bugs.... then we would never have released it. So we go through all reports and decide: what needs to be really really fixed? Yes, we make mistakes. I do not know how to not do mistakes, sorry. > seven months later it finally made its way in. > Because *I* pushed. Ben is using a mouse, so he just did not see the problem. In general, there are just not enough people to look at bugs... if nobody helps, it takes a looong time. > I can see saying, "move it to 1.4" if 1.4 is right around the corner. We could have blocked the release of 1.3 and then we would have not released 1.3 until now. (keep in mind there are 450 other open issues besides the one you are talking about). > > As long as 1.3 is the prime time release - i.e. the release suitable for > active development - you have to support it and care about the people using > it. This is not some backward compatibility thing. It's a daily usability > thing. You can't tell people, "yeah that is fixed, but only in 1.4, but 1.4 > isn't really ready for you to use yet." And if I submit a patch for 1.3, > then accept the damn patch for 1.3. Don't tell me "it'll go into 1.4" when I > can't even use 1.4 myself. That's how you alienate users and keep the > community tiny. We can not backport everything... especially as the amount of people looking at stuff is very small. yes, we should release more often... E.g. since I asked for help on 1.3 issues: http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 There was *no reaction at all*. Nothing. Zero. Sometimes I think we should just stop and do something else. This is clearly not working. Marcus -- Marcus Denker -- http://marcusdenker.de

March 1, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by patmaddox

> I do not think so, since I fixed a lot the system itself :S > > Sorry. (Maybe it's a good excuse to try Pharo 1.4 ^^ ) understood. thanks. I'll keep spending some time trying to get my stuff to run on 1.4. -- View this message in context: http://forum.world.st/Nautilus-version-4-0-4-tp4422530p4436637.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 1, 2012

Re: [Pharo-project] Monticello Version Info

by Camillo Bruni

well, you usually cache the mcz in your local directory cache (at least that's the default). and extracting the meta-data out of a local mcz is rather cheap since zip allows you to directly extract certain files. maybe we could add another entry to the mcz with just the stripped down version info in it. this way older monticello versions would still be able to load it the slow way, whereas an updated version could benefit from incremental loading? On 2012-03-01, at 23:11, Nicolas Cellier wrote: > I think the main reason is that you cannot load just the metadata, but > the whole mcz when you need to dig into the history... > That ain't cheap, and that happens when you merge more or less distant branches. > > Also, it's not unusual to upload directly version N+5 without the > whole N+1 to: N+4 ancestry... > In this case MC can still find a common ancestor. > > Nicolas > > Le 1 mars 2012 23:07, Dale Henrichs <dhenrich(a)vmware.com> a Ã©crit : >> For the majority of use cases I think that the immediate ancestor is the only one needed ... so you might be onto something here... >> >> Dale >> >> ----- Original Message ----- >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> | Sent: Thursday, March 1, 2012 1:53:48 PM >> | Subject: [Pharo-project] Monticello Version Info >> | >> | I am still having a look at the Monticello implementation. >> | Now coming from the git world, this seems very weird: >> | >> | Why does each Monticello version store the complete ancestor history? >> | >> | ------------------------------------------------------------------------ >> | >> | Wouldn't it simply be enough to keep pointers to the immediate >> | ancestors, and then lazily load and cache them? >> | >> | Where is the complete ancestry needed, besides diffing/merging? >> | >> | ------------------------------------------------------------------------ >> | >> | The current setup implies that something like >> | >> | MCCacheRepository default loadVersionFromFileNamed: >> | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' >> | >> | takes around 1.5 seconds to complete, whereas this could be done in a >> | fragment of a second for most cases... >> | >> >

March 1, 2012

[Pharo-project] [Announce] S8 in the Concrete Jungle

by Elvio Fernandez

Hi! Alejandro Reimondo (Ale) will make a presentation about S8 platform and U8 service on Tuesday March 6, 2012 to NYC Smallltalk Developerâs group. http://www.nycsmalltalk.org/2012/01/10/s8-release-candidate-smalltalk-on-js/ There is a lot of topics to talk about..., the topic of most interest (to us) is to explain what we are doing with S8. A breaf description of our regional point of view about OT and Smalltalk, and our proposal of a modern formulation of development using Smalltalk will be the starting point of the presentation. The S8 platform was implemented to let us(smalltalkers) be responsible of our execution environments (as it was in the early days of smalltalk). That impose a change of attitude and the formulation/idea must be supported by tools and evidence/experience of others in the same field. As a demostration on how we can do that with S8, Ale will mention the platforms we have implemented for using the U8 service (designed to make worldwide social development with smalltalk http://u8.smalltalking.net ). On technical side, to mention where a person can start application development and self-learning using U8, he will describe the frameworks we have implemented on top of S8 (we all know the importance of frameworks) and the process we are using for development/testing of frameworks. The presentation is also open to the topics of interest of the audience. And Ale will be happy to respond questions about how to use S8 in diferent contexts of development. Some of the technical points that will be of interest are: - how to use our FFI framework? (make API calls, use native libraries and implement callbacks using S8; 100% smalltalk code) - how to do server side development? (NodeJS framework) - how to use your code from other smalltalks? - how to use javascript libraries? and (more important) how to write interfaces to existing libraries fast and minimize errors / testing points? - how to develop for Android and phones? - how to use cloud services? - how to work using U8? How to contact experts and people to do development of frameworks using the U8 service? - why we minimized the toolset at this stage? and what powerfull features of smalltalk we support today. - what is not implemented yet? and how to contribute? - ... In all the presentations and coding events we made here (in Buenos Aires) the time has been short for going deep in groups, and the presentation was important to get in touch with people that has interest in global development as it is used to be in this decade. So, if you are near NY on March,6 join us. If you can't attend there next week, please contact us at info(a)smalltalking.net and consider we have open the Betatesting site to start contributing and using U8 from now and we are doing one betaworks meeting per week to let people put their hands on the frameworks, tools and S8 platform, in small groups. ...If you canÂ´t wait and want to start coding now/today, please visit the U8 page ( http://u8.smalltalking.net ) and register there to become a member of our community, to be in contact with people and companies interested in social development using Smalltalk. cheers, --------------- on behalf of Smalltalking Associationwww.smalltalking.net

March 1, 2012

Re: [Pharo-project] Monticello Version Info

by Nicolas Cellier

I think the main reason is that you cannot load just the metadata, but the whole mcz when you need to dig into the history... That ain't cheap, and that happens when you merge more or less distant branches. Also, it's not unusual to upload directly version N+5 without the whole N+1 to: N+4 ancestry... In this case MC can still find a common ancestor. Nicolas Le 1 mars 2012 23:07, Dale Henrichs <dhenrich(a)vmware.com> a Ã©crit : > For the majority of use cases I think that the immediate ancestor is the only one needed ... so you might be onto something here... > > Dale > > ----- Original Message ----- > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > | Sent: Thursday, March 1, 2012 1:53:48 PM > | Subject: [Pharo-project] Monticello Version Info > | > | I am still having a look at the Monticello implementation. > | Now coming from the git world, this seems very weird: > | > | Why does each Monticello version store the complete ancestor history? > | > | ------------------------------------------------------------------------ > | > | Wouldn't it simply be enough to keep pointers to the immediate > | ancestors, and then lazily load and cache them? > | > | Where is the complete ancestry needed, besides diffing/merging? > | > | ------------------------------------------------------------------------ > | > | The current setup implies that something like > | > | MCCacheRepository default loadVersionFromFileNamed: > | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' > | > | takes around 1.5 seconds to complete, whereas this could be done in a > | fragment of a second for most cases... > | >

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > > > > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > > wrote: > >> > >> Hi, > >> > >> sorry for not sending before: work is hard :P > >> yes, that should work, and no, I don't know a better way to define it. > > > > > > No it won't work. See my message. > > > >> > >> I think Eliot's idea is to form "libraries" of generic callbacks (for > >> mars, for instance, I have CocoaCallback, child of Callback, who > defines all > >> my needed signatures, looks a lot at first instance, but if you see in > >> detail, finally there are not so much variants) > > > > > > Yes, the idea is to have a library of signature methods that marshal > > specific C callback signatures to/from Smalltalk blocks. The pragma > > specifies what ABI (application binary interface, or stack layout) the > > signature is for so that the scheme is cross-platform. But I expect that > > these signature methods could be the output of an ABI compiler, so that > one > > wouldn't have to write them by hand. The pragma doesn't need to include > a > > word-size since IA64 is a different ABI to IA32, and so the ABI subsumes > > word size. > > > > HTH > > > > > Let me understand... > If I have a signature (char x,double y, short z) IA-32, where is the > spalien pointing to? > At the first parameter immediately below the return address. > - the original call stack (with proper ABI alignment, that is offsets > 0,4,12, or 1-based indices 1,5,13) > Right. > - a serialized copy without alignment padding (offsets 0,1,9, or > 1-based indices 1,2,10) > No. > In the former case, that means that the indices must be computed > according to ABI (might be different in PPC for example). > Right. Hence the pragma containing the name of the ABI to allow the system to select the appropriate version. Note that the implementation allows for passing a pointer to a struct containing marshalled register arguments for RISC platforms, although this isn't used yet since it's not needed on x86. > And even if such code is generated with an ABI-aware interface > compiler, is it really platform independent? > The scheme is platform-independent, allowing platform-specific versions of marshalling code to exist side-by-side. > I'm quite sure the ABI have subtle variations, which are not even > platform but compiler specific... > No. That's the definition of an ABI. The ABI specifies the calling convention for a particular platform, and compilers must conform to the ABI for all external and system calls. > For example of such niceties in win32, did you ever try returning a > structure by value from a cdecl mingw-gcc compiled function to a cdecl > visual studio compiled caller, not even speaking of different internal > structure alignment padding (controlled with #pragma packed(4) or > other compiler options...) > That's different. Internal interfaces used by particular compilers are no covered by the ABI but then they aren't used for inter-component interfaces such as callbacks. If you look, for example, at the Intel x86 compiler you'll see it'll use a register-based calling convention, multiple entry-points for functions (an internal and an external one), etc. But these non-standard interfaces are only used internally, typically between functions within a single compilation unit. > This apple page helps a lot, for example it tells how gcc returns a > structure by value... > > https://developer.apple.com/library/mac/#documentation/developertools/Conce… I know. But the bibles in these cases are documents such as "SYSTEM V APPLICATION BINARY INTERFACE, Intel386? Architecture Processor Supplement, Fourth Edition". You'll find a concise specification of the calling convention of the ABI, and structure layout etc, in chapter 3. cheers, Eliot > > > Nicolas > > >> > >> > >> best, > >> Esteban > >> > >> El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: > >> > >> > Esteban, > >> > > >> > Will this work? Even if so, is there a better way to define it? > >> > > >> > longVoidStarLongRetInt: callbackContext sp: spAlien > >> > <signature: 'int (*) (long, void *, long)' abi: 'IA32'> > >> > ^callbackContext wordResult: > >> > (block > >> > value: (Alien newC:4) > >> > value: (Alien forPointer: (spAlien > unsignedLongAt: > >> > 5)) > >> > value: (Alien newC:4) > >> > ) > >> > > >> > 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: Thursday, March 01, 2012 12:15 AM > >> > To: Pharo-project(a)lists.gforge.inria.fr > >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >> > > >> > thanks!!!!! > >> > > >> > > >> > > >> > > >> > ________________________________________ > >> > From: pharo-project-bounces(a)lists.gforge.inria.fr > >> > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> > [estebanlm(a)gmail.com] > >> > Sent: Wednesday, February 29, 2012 10:18 PM > >> > To: Pharo-project(a)lists.gforge.inria.fr > >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >> > > >> > you need to define a signature... not at home now, but wait 'til > >> > tomorrow and I'll send an example > >> > > >> > best, > >> > Esteban > >> > > >> > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: > >> > > >> >> What does "cannot find callback signature" mean from > #signature:block:? > >> >> I'm stuck. > >> >> > >> >> > >> >> > >> >> > >> >> ________________________________________ > >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> >> [estebanlm(a)gmail.com] > >> >> Sent: Wednesday, February 29, 2012 6:54 PM > >> >> To: Pharo-project(a)lists.gforge.inria.fr > >> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >> >> > >> >> yeah... sorry about that > >> >> is a bug on FFI... I managed to worked around it for HPDF, for a > >> >> customer's project... but of course is not a good and definitive > solution. > >> >> > >> >> best, > >> >> Esteban > >> >> > >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: > >> >> > >> >>> This is gonna take a while... I had structs flying around as void* > >> >>> and was moderately happy. Nonetheless, your suggestion worked, > provided I > >> >>> add a lot getHandle asInteger and change the void* to long :( > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________________ > >> >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> >>> [estebanlm(a)gmail.com] > >> >>> Sent: Wednesday, February 29, 2012 6:23 PM > >> >>> To: Pharo-project(a)lists.gforge.inria.fr > >> >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >> >>> > >> >>> I also found some problems using void* in linux... maybe you want to > >> >>> use long (which has same size)... I "fixed" my problems that way. > >> >>> > >> >>> yes... maybe we need to look at FFI to see why void* has problems > some > >> >>> times, but well, that can help you atm (sorry for not having a > better > >> >>> answer) > >> >>> > >> >>> Esteban > >> >>> > >> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: > >> >>> > >> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > >> >>>> wrote: > >> >>>>> Another glitch: is there any problem passing things as void*? I'm > >> >>>>> getting failure to coerce errors that did not arise before. > >> >>>>> > >> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got > >> >>>> NativeBoost toy to play with. > >> >>>> > >> >>>> Please file the issue, describing the problem. so we can look over > it > >> >>>> and fix it. > >> >>>> > >> >>>>> > >> >>>>> > >> >>>>> ________________________________________ > >> >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor > Stasenko > >> >>>>> [siguctua(a)gmail.com] > >> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM > >> >>>>> To: Pharo-project(a)lists.gforge.inria.fr > >> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >> >>>>> > >> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > >> >>>>> wrote: > >> >>>>>> Does 1.3 by default not create field accessors? Why is that? I > >> >>>>>> thought > >> >>>>>> nothing was happening. > >> >>>>>> > >> >>>>> > >> >>>>> Good question, i'd like to know the answer too. > >> >>>>> It is related to MC final 'installation' phase, > >> >>>>> where it initializing all classes. > >> >>>>> > >> >>>>> In NativeBoost i was also using > >> >>>>> > >> >>>>> noteCompilationOf: aSelector meta: isMeta > >> >>>>> "A hook allowing some classes to react to recompilation of > >> >>>>> certain selectors" > >> >>>>> > >> >>>>> but there was a big question, at which point this hook is > triggered, > >> >>>>> and looks like some changes in MC stop triggering it/triggering at > >> >>>>> wrong time (not all methods get into a class/ class not > initialized > >> >>>>> etc), > >> >>>>> which makes it not very useful. > >> >>>>> > >> >>>>> So i ended up creating a DNU handler on instance side, then on > DNU i > >> >>>>> check if i have field accessors and if not, > >> >>>>> compile them on the fly. > >> >>>>> > >> >>>>> > >> >>>>>> Bill > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> Best regards, > >> >>>>> Igor Stasenko. > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> Best regards, > >> >>>> Igor Stasenko. > >> >>>> > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > >> > > > > > > > > -- > > best, > > Eliot > > > > -- best, Eliot

March 1, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by patmaddox

> Hi, > > Just as another suggestion of something else to do to uselessly talk about > what one would > do if one could do... here is something that needs to be done: > > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 > > Someone need to looks at each issue and as questions. > > - can this problem be repeated in the current last version of 1.3? > - is this already fixed in 1.4? if yes > -- is it so grave that the fix needs to be backported? > - was it already a bug for the last 10 years and it did not hurt? > -- Hint, hint: likely not important for fixing in 1.3 > after it has been released. > (yet, it could be. And if the fix is easy and clearly > not breaking anything) > - is there already a bug report about this issue on the tracker? > (you have no idea how many reports are duplicated > entries...) > - What could be the reason for the problem? What could be a > possible fix? I think this attitude is what will continue to hold Pharo back from wider adoption. I've found 1.4 to be unusable for daily development. And yet there's no interest in fixing problems in 1.3. As long as 1.4 is totally experimental and not actually a productive environment, people who need to get stuff done won't contribute to it. That means that for the time being, it's the five of you who know what you're doing that will make Pharo better. It's all good to say, "complain less, patch more" (and I totally agree with it), but often times the person "complaining" is trying to figure out how to get going so they can solve their own problem! And lest you think I don't want to contribute, I'll point you to http://code.google.com/p/pharo/issues/detail?id=4549&can=1&q=test%20runner&… where I a) submitted a bug report b) included a video demonstrating the bug c) included a patch fixing the bug responses were - "not a showstopper -> move it to 1.4" - "for me the bug entry is not really relevant" seven months later it finally made its way in. I can see saying, "move it to 1.4" if 1.4 is right around the corner. But it's seven months later and there's no 1.4 release and I'm personally still very confused as to what versions of stuff people actually use. Presumably some people use 1.4 else it wouldn't be under "active development," but for actually getting stuff done, are people on 1.3? Or do people use 1.4 to get stuff done? Feel free to write me off, but I'm telling you this as someone who loves smalltalk and pharo and really wants to see it win and receive wider adoption. And I imagine that you guys do too, especially since more people using pharo = more people contributing to pharo. But right now the pharo ecosystem is so fragmented, and I feel like the development process is totally opaque, and exclusive to the few people who get together in lille for the sprints or whatever. I mean really, someone says they *can't run tests*, *submits a patch*, and gets a "fuck you" response? No wonder there's so little contribution from outside the core group of developers. As long as 1.3 is the prime time release - i.e. the release suitable for active development - you have to support it and care about the people using it. This is not some backward compatibility thing. It's a daily usability thing. You can't tell people, "yeah that is fixed, but only in 1.4, but 1.4 isn't really ready for you to use yet." And if I submit a patch for 1.3, then accept the damn patch for 1.3. Don't tell me "it'll go into 1.4" when I can't even use 1.4 myself. That's how you alienate users and keep the community tiny. Pat -- View this message in context: http://forum.world.st/Bug-Tracker-Issues-tagged-1-3-tp4416469p4436606.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 1, 2012