- Pharo-dev - lists.pharo.org

[Pharo-project] Alien signature: first attempt

by Schwab,Wilhelm K

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. >>> >> >> >> > > >

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Igor Stasenko

On 1 March 2012 18:20, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 1 March 2012 02:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> >> Modify RFBSocket class >> #acceptFrom: to read: >> ^RFBSocketInstances add: (super acceptFrom: aSocket) > > > Congratulations! You have just turned Pharo from so-so to awesome. > With one line of code? No, you must be joking! :) -- Best regards, Igor Stasenko.

March 1, 2012

[Pharo-project] Just a thought... <Versions> with Monticello/Metacello load info

by Ben Coman

Just a small idea that popped up... In SystemBrowser when clicking <Versions>, in addition to showing the code author and timestamp, a nice enhancement might be to also show which mcz or ConfigurationOf the change was related to, as well as the date loaded into the current image. cheers, Ben

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Milan Mimica

On 1 March 2012 02:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Modify RFBSocket class >> #acceptFrom: to read: > ^RFBSocketInstances add: (super acceptFrom: aSocket) > Congratulations! You have just turned Pharo from so-so to awesome. -- Milan Mimica http://sparklet.sf.net

March 1, 2012