Status of Alien FFI
Locked
123
123
 
|
I'm unable to load Alien-Core into the latest Pharo (I'm on 10451),
mostly because the package overrides some methods in Scanner/Parser and those overrides are out of sync with the current Pharo base. Is anyone working on bringing these into sync? I would be glad to take a stab at it but I'm hardly the best qualified person to do that. If there's a better mailing list for Alien issues/discussion, please let me know. Thanks, -- Ken Treis Miriam Technologies, Inc. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi ken
fernando is the guy that fixed alien so he will probably reply to you Stef On Sep 14, 2009, at 11:36 PM, Ken Treis wrote: > I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), > mostly because the package overrides some methods in Scanner/Parser > and those overrides are out of sync with the current Pharo base. Is > anyone working on bringing these into sync? I would be glad to take a > stab at it but I'm hardly the best qualified person to do that. > > If there's a better mailing list for Alien issues/discussion, please > let me know. > > Thanks, > > -- > Ken Treis > Miriam Technologies, Inc. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
The problem is that Pharo no longer considers the following primitive
call syntactically correct: <primitive: 'primCalloc' error: errorCode module: 'IA32ABI'> It does work if we omit the errorCode: <primitive: 'primCalloc' module: 'IA32ABI'> Was this change in the parser intended?? On 15 Sep 2009, at 00:15, Stéphane Ducasse wrote: > Hi ken > > > fernando is the guy that fixed alien so he will probably reply to you > > Stef > On Sep 14, 2009, at 11:36 PM, Ken Treis wrote: > >> I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), >> mostly because the package overrides some methods in Scanner/Parser >> and those overrides are out of sync with the current Pharo base. Is >> anyone working on bringing these into sync? I would be glad to take a >> stab at it but I'm hardly the best qualified person to do that. >> >> If there's a better mailing list for Alien issues/discussion, please >> let me know. >> >> Thanks, >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Yes because the intent was that the primitive would return a failure
error code versus prim failed, guess why? On 9/15/09, Johan Brichau <[hidden email]> wrote: > The problem is that Pharo no longer considers the following primitive > call syntactically correct: > <primitive: 'primCalloc' error: errorCode module: 'IA32ABI'> > > It does work if we omit the errorCode: > <primitive: 'primCalloc' module: 'IA32ABI'> > > > Was this change in the parser intended?? > > > On 15 Sep 2009, at 00:15, Stéphane Ducasse wrote: > >> Hi ken >> >> >> fernando is the guy that fixed alien so he will probably reply to you >> >> Stef >> On Sep 14, 2009, at 11:36 PM, Ken Treis wrote: >> >>> I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), >>> mostly because the package overrides some methods in Scanner/Parser >>> and those overrides are out of sync with the current Pharo base. Is >>> anyone working on bringing these into sync? I would be glad to take a >>> stab at it but I'm hardly the best qualified person to do that. >>> >>> If there's a better mailing list for Alien issues/discussion, please >>> let me know. >>> >>> Thanks, >>> >>> -- >>> Ken Treis >>> Miriam Technologies, Inc. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
My first reply was wrong. It seems that Alien's Parser extensions are
not loaded before the primitive methods, which is why it does not accept them. I'll try to fix this on the train to work. On 16 Sep 2009, at 07:20, John McIntosh wrote: > Yes because the intent was that the primitive would return a failure > error code versus prim failed, guess why? > > On 9/15/09, Johan Brichau <[hidden email]> wrote: >> The problem is that Pharo no longer considers the following primitive >> call syntactically correct: >> <primitive: 'primCalloc' error: errorCode module: 'IA32ABI'> >> >> It does work if we omit the errorCode: >> <primitive: 'primCalloc' module: 'IA32ABI'> >> >> >> Was this change in the parser intended?? >> >> >> On 15 Sep 2009, at 00:15, Stéphane Ducasse wrote: >> >>> Hi ken >>> >>> >>> fernando is the guy that fixed alien so he will probably reply to >>> you >>> >>> Stef >>> On Sep 14, 2009, at 11:36 PM, Ken Treis wrote: >>> >>>> I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), >>>> mostly because the package overrides some methods in Scanner/Parser >>>> and those overrides are out of sync with the current Pharo base. Is >>>> anyone working on bringing these into sync? I would be glad to >>>> take a >>>> stab at it but I'm hardly the best qualified person to do that. >>>> >>>> If there's a better mailing list for Alien issues/discussion, >>>> please >>>> let me know. >>>> >>>> Thanks, >>>> >>>> -- >>>> Ken Treis >>>> Miriam Technologies, Inc. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ---------------------------- >> Johan Brichau >> [hidden email] >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
It's fixed (except the AlienLoader -- read on).
The only problem was loading order. I separated the extensions to the Parser (necessary to load the primitive methods) into a separate package Alien-Prereqs. If you load Alien-Prereqs before Alien-Core, it will work. I'm now trying to adapt the AlienLoader package to do the same but I'm not familiar with Flair/Gofer. If someone can tell me how to ensure package loading order? I tried the following but it does not make sure the Prereqs is installed first (I only added the line with 'Alien- Prereqs'). config project: 'Alien' dependsOn: [ config package: 'Alien-Prereqs' from: 'http://www.squeaksource.com/Alien' . config package: 'Alien-Core' from: 'http://www.squeaksource.com/ Alien'. config package: 'Alien-CoreTest' from: 'http://www.squeaksource.com/Alien' . config package: 'Alien-Examples' from: 'http://www.squeaksource.com/Alien' ]. On 14 Sep 2009, at 23:36, Ken Treis wrote: > I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), > mostly because the package overrides some methods in Scanner/Parser > and those overrides are out of sync with the current Pharo base. Is > anyone working on bringing these into sync? I would be glad to take a > stab at it but I'm hardly the best qualified person to do that. > > If there's a better mailing list for Alien issues/discussion, please > let me know. > > Thanks, > > -- > Ken Treis > Miriam Technologies, Inc. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Status of Alien FFI
|
|
On Wed, Sep 16, 2009 at 10:06 AM, Johan Brichau <[hidden email]> wrote: It's fixed (except the AlienLoader -- read on). Is it possible to make 'Alien-Core' depend on 'Alien-Prereqs' (i.e. a nested dependency)? If it were then the correct loading order would be achieved -- Cheers, Peter _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 16 Sep 2009, at 10:33, Peter Hugosson-Miller wrote: > Is it possible to make 'Alien-Core' depend on 'Alien-Prereqs' (i.e. > a nested dependency)? If it were then the correct loading order > would be achieved Probably that is the easiest solution. I'm just a bit lost in what is the preferred way of expressing package dependencies and loading process. I see Monticello's package dependencies but I also see specifically created load scripts and things like Flair and Gofer. I'm rediscovering development in Pharo-Squeak (I have been mostly working in Visualworks the last 5 years). So perhaps I'm asking a silly question that does not make sense? ;-) ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Status of Alien FFI
|
|
On Wed, Sep 16, 2009 at 11:33 AM, Johan Brichau <[hidden email]> wrote:
Heh, it makes sense to me, since I come from VisualAge, where dependencies can be nested as deep as you like. I'm quite new to PharO though, so that's why I asked the question. Hopefully someone knows the answer. -- Cheers, Peter _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau
> Probably that is the easiest solution.
> Most of the time we did not rely on the dependencies because I'm not sure that the order can be specified. I think that in the future we will use metacello to resolve this ordering. > I'm just a bit lost in what is the preferred way of expressing package > dependencies and loading process. I see Monticello's package > dependencies but I also see specifically created load scripts and > things like Flair and Gofer. Flair was a parallel track to get a kind of metacello system. It will disappear. Gofer is a simple interface to replace Installer and metacello will use it to load and script loading of packages. > I'm rediscovering development in Pharo-Squeak (I have been mostly > working in Visualworks the last 5 years). So perhaps I'm asking a > silly question that does not make sense? ;-) No the problem is that we are also inventing new ways of managing our artefacts. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau
On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote: I separated the extensions to the Parser (necessary to load the Given that Alien requires modifications to the core parser, and that the Alien-modified parser is backwards-compatible with the base parser... is there any chance we can get the Alien modifications into the base? Without that, Pharo software updates that touch parser code will end up reverting the code in Alien-Prereqs, right? -- Ken Treis Miriam Technologies, Inc.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi ken
it is correct that alien touches the parser? The declarations are not pragmas compliant. Of course your suggestion makes sense. When marcus is back in europe I will check the status of the new handwritten parser because it would be good to use it. Stef On Sep 16, 2009, at 5:36 PM, Ken Treis wrote: > On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote: > >> I separated the extensions to the Parser (necessary to load the >> primitive methods) into a separate package Alien-Prereqs. >> If you load Alien-Prereqs before Alien-Core, it will work. > > > Thanks Johan, that's good news here. I appreciate it. > > Given that Alien requires modifications to the core parser, and that > the Alien-modified parser is backwards-compatible with the base > parser... is there any chance we can get the Alien modifications > into the base? Without that, Pharo software updates that touch > parser code will end up reverting the code in Alien-Prereqs, right? > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Sep 16, 2009, at 11:14 AM, Stéphane Ducasse wrote: it is correct that alien touches the parser? Of course your suggestion makes sense. * AlienLibrary shouldn't do its cleanup at shutdown, it should do it at image startup instead. That way a simple image save won't invalidate all of my external references. * I'm creating a partial Alien library for GemStone so that I can use the CairoGraphics package in both Pharo and GLASS. But on x86-64, there there's a size difference between a pointer/long and an integer. It'd be nice to have some more explicit APIs on Alien, so I could say "Alien newCInteger" or "Alien newCLong" and have the platform return me the proper size Alien. Even without the platform size differences, it seems awkward to use "Alien newC: 4" everywhere I want an integer, "Alien newC: 8" where I want a double, etc. * Similarly, I'd like an API on AlienLibrary that distinguishes between integers and longs. In the CairoGraphics package I've added some methods to this effect: CRLibrary int: 'cairo_surface_write_to_png'
with: handle
with: string address or patternHandle := CRLibrary
pointer: 'cairo_pop_group'
with: handle. I like the way it reads. And even though on IA32 they both use the same 4-byte primitive, on x86-64 I could have pointers return an 8-byte Alien and ints return a 4-byte primitive. * Same story with the basic data accessors like (un)signedLongAt: -- I'd want to add something like (un)signedIntAt et. al. Yes, I realize that some of this is overkill for IA32 only, but on the other hand I think a couple of these intention-revealing changes would make Alien client code prettier. Sorry to be so wordy. I'd be glad to do all of the Smalltalk-level coding on this -- much of it is done already in my image -- but I thought I'd better ask the maintainer(s) first and this list is the best forum I've found for Alien issues. -- Ken Treis Miriam Technologies, Inc.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I will let eliot comment on that because I'm alien newbie.
We cleaned it so that people can use it but > >> it is correct that alien touches the parser? >> The declarations are not pragmas compliant. > > Yes -- there's a hack in there that allows an error code variable to > be passed in the <primitive> pragma where otherwise the parser would > expect a literal. > >> Of course your suggestion makes sense. >> When marcus is back in europe I will check the status of the >> new handwritten parser because it would be good to use it. > > > Thanks Stef. I've got some other ideas for Alien; is this list the > best place to discuss those? Specifically: > > * AlienLibrary shouldn't do its cleanup at shutdown, it should do it > at image startup instead. That way a simple image save won't > invalidate all of my external references. > > * I'm creating a partial Alien library for GemStone so that I can > use the CairoGraphics package in both Pharo and GLASS. what is the cairoPackage? For pharo 1.1 I would like to see Rome cleaned and loadable/integrated in pharo. > But on x86-64, there there's a size difference between a pointer/ > long and an integer. It'd be nice to have some more explicit APIs on > Alien, so I could say "Alien newCInteger" or "Alien newCLong" and > have the platform return me the proper size Alien. Even without the > platform size differences, it seems awkward to use "Alien newC: 4" > everywhere I want an integer, "Alien newC: 8" where I want a double, > etc. > > * Similarly, I'd like an API on AlienLibrary that distinguishes > between integers and longs. In the CairoGraphics package I've added > some methods to this effect: > > CRLibrary > int: 'cairo_surface_write_to_png' with: handle with: string > address > > or > > patternHandle := CRLibrary pointer: 'cairo_pop_group' with: > handle. > > I like the way it reads. And even though on IA32 they both use the > same 4-byte primitive, on x86-64 I could have pointers return an 8- > byte Alien and ints return a 4-byte primitive. > > * Same story with the basic data accessors like (un)signedLongAt: -- > I'd want to add something like (un)signedIntAt et. al. > > Yes, I realize that some of this is overkill for IA32 only, but on > the other hand I think a couple of these intention-revealing changes > would make Alien client code prettier. > > Sorry to be so wordy. I'd be glad to do all of the Smalltalk-level > coding on this -- much of it is done already in my image -- but I > thought I'd better ask the maintainer(s) first and this list is the > best forum I've found for Alien issues. > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
Ken Treis wrote:
> > * I'm creating a partial Alien library for GemStone so that I can use > the CairoGraphics package in both Pharo and GLASS. But on x86-64, > there there's a size difference between a pointer/long and an integer. > It'd be nice to have some more explicit APIs on Alien, so I could say > "Alien newCInteger" or "Alien newCLong" and have the platform return > me the proper size Alien. Even without the platform size differences, > it seems awkward to use "Alien newC: 4" everywhere I want an integer, > "Alien newC: 8" where I want a double, etc. > > * Similarly, I'd like an API on AlienLibrary that distinguishes > between integers and longs. In the CairoGraphics package I've added > some methods to this effect: One minor point is that whether integers and longs are different depends on the platforms data model. Under MS Win64, integers and long integers are both 32bit, while on most unixes integers are 32bit while long ints are 64bit. (LLP64 and LP64 models respectively) I don't know if this is important though. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Sep 16, 2009, at 11:54 AM, Stéphane Ducasse wrote: what is the cairoPackage? It's a port of Travis Griggs' package from VisualWorks -- a fairly direct mapping of Cairo objects into Smalltalk. I posted it on SqueakSource just a couple of days ago: I have been using it for our VisualWorks web apps for quite a while and wanted to bring it with me. Plus I really need portability between Pharo and GLASS. Not that I couldn't do that with Rome, but this seemed like an easier path for me. -- Ken Treis Miriam Technologies, Inc.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Douglas Brebner
On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote: > One minor point is that whether integers and longs are different > depends > on the platforms data model. Under MS Win64, integers and long > integers > are both 32bit, while on most unixes integers are 32bit while long > ints > are 64bit. (LLP64 and LP64 models respectively) > > I don't know if this is important though. Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64), and my main objective at present is to get this working for an application I'm committed to build, so I was ignoring those sorts of cross-platform details. Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do. -- Ken Treis Miriam Technologies, Inc. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Status of Alien FFI
|
|
On Wed, Sep 16, 2009 at 6:17 PM, Ken Treis <[hidden email]> wrote:
+1. Please take into consideration to make Alien cross platform!!! Just as FFI is.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
ok what is its license?
Stef > what is the cairoPackage? >> For pharo 1.1 I would like to see Rome cleaned and loadable/ >> integrated >> in pharo. > > It's a port of Travis Griggs' package from VisualWorks -- a fairly > direct mapping of Cairo objects into Smalltalk. I posted it on > SqueakSource just a couple of days ago: > > http://www.squeaksource.com/CairoGraphics.html > > I have been using it for our VisualWorks web apps for quite a while > and wanted to bring it with me. Plus I really need portability > between Pharo and GLASS. Not that I couldn't do that with Rome, but > this seemed like an easier path for me. > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
Ken Treis wrote:
> On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote: > > >> One minor point is that whether integers and longs are different >> depends >> on the platforms data model. Under MS Win64, integers and long >> integers >> are both 32bit, while on most unixes integers are 32bit while long >> ints >> are 64bit. (LLP64 and LP64 models respectively) >> >> I don't know if this is important though. >> > > Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64), > and my main objective at present is to get this working for an > application I'm committed to build, so I was ignoring those sorts of > cross-platform details. > > Perhaps there would need to be new primitives for the basic size of > each relevant C type? I'm anxious to hear what Eliot might have to say > about this since he's got about 2000x more experience with this than I > do. > > There's actually four 64bit data models, though I believe that pretty much every mainstream 64 bit platform is LP64 except MS Windows. Though no doubt someone is waiting to prove me wrong :) BTW, I just read about an embedded processor with 32 bit pointers, 32 bit integers but 40 bit(!) longs. Now that's nasty. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |