FFI in 1.1
Locked
 
|
>I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev
>image. +1 >That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
The question is what we call core.
I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien are infrastructure. If you look at my answer to German on "Re: [Pharo-project] Really Important message (tm)" April 16 You can see that with a fast loading package mechanism then we could really introduce in "Pharo-Core" (= what we have now) infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but to Pharo from my point of view Mini Mini + FFI + Tools + IDE + Compiler ....= PharoCore Pharo + Sounds + Morphic examples + archiview.... = Pharo Note that the belonging of one package to group is not automatically clear. This is why metacello is key and a metacelloRepository. Steg >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev >> image. > > +1 > >> That's only my opinion. > > Maybe Stef should tell us more about why he thinks it should be included. > > Bye > T. > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > [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 |
|
|
Stef, I like how you're thinking, but your list raises one question in
my mind: how do you propose to load anything into "Mini" without a Compiler? Sorry if that's a stupid question, but I need to know :-p -- Cheers, Peter. On 20 apr 2010, at 08.59, Stéphane Ducasse <[hidden email]> wrote: > The question is what we call core. > I think that core should contain less and less but pharo should > contain infrastructure and FFI or Alien > are infrastructure. > > > If you look at my answer to German on "Re: [Pharo-project] Really > Important message (tm)" > April 16 > You can see that with a fast loading package mechanism then we could > really introduce in "Pharo-Core" (= what we have now) > infrastructure package to produce Pharo and works on making a real > core. FFI does not belong to this core=mini but > to Pharo from my point of view > > Mini > Mini + FFI + Tools + IDE + Compiler ....= PharoCore > Pharo + Sounds + Morphic examples + archiview.... = Pharo > > Note that the belonging of one package to group is not automatically > clear. > This is why metacello is key and a metacelloRepository. > > Steg > >>> I wouldn't include neither FFI or Alien FFI in neither PharoCore >>> or PharoDev >>> image. >> >> +1 >> >>> That's only my opinion. >> >> Maybe Stef should tell us more about why he thinks it should be >> included. >> >> Bye >> T. >> >> -- >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> [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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
Well I asked for it...
(a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev >> image. > > +1 > >> That's only my opinion. > > Maybe Stef should tell us more about why he thinks it should be included. > > Bye > T. > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 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 |
smime.p7s (3K) |
|
In reply to this post by Peter Hugosson-Miller
On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: > Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into "Mini" without a Compiler? Sorry if that's a stupid question, but I need to know :-p > In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
John M McIntosh wrote:
> Well I asked for it... > > (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. > > (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . > > (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. > Forget curl, I want to recreate the Cocoa class libs in squeak/pharo for WebKit... And then create etoy extensions that can handle them. ;-). Lawson _______________________________________________ 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 20 apr 2010, at 09.13, Stéphane Ducasse <[hidden email]>
wrote: > > On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: > >> Stef, I like how you're thinking, but your list raises one question >> in my mind: how do you propose to load anything into "Mini" without >> a Compiler? Sorry if that's a stupid question, but I need to know :-p >> > In my coolest dream: socket + object serializer like in some > versions of S# of dan simmons. Aha! Très très cool! :-D > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
But ok we need time for that....
and I do not have any right now. Stef On Apr 20, 2010, at 9:21 AM, Peter Hugosson-Miller wrote: > On 20 apr 2010, at 09.13, Stéphane Ducasse <[hidden email]> wrote: > >> >> On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: >> >>> Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into "Mini" without a Compiler? Sorry if that's a stupid question, but I need to know :-p >>> >> In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. > > Aha! Très très cool! :-D > >> Stef >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Cheers, > Peter > _______________________________________________ > 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 LawsonEnglish
On Tue, Apr 20, 2010 at 9:14 AM, Lawson English <[hidden email]> wrote:
Cocoa ? So it will run only on Mac OS X ? Laurent Laffont And then create etoy extensions that can handle them. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
laurent laffont wrote:
> > On Tue, Apr 20, 2010 at 9:14 AM, Lawson English <[hidden email] > <mailto:[hidden email]>> wrote: > > John M McIntosh wrote: > > Well I asked for it... > (a) you can get graphic cut/copy/paste of complex data on the > macintosh and windows. > > (b) I'd rather have people learn FFI & Alien so they can build > their own api to Rome, Pango, & Curl instead of waiting on > about 4 people in the world to get around to building and > distributing *official* plugins . > > (c) When your curl, rome, etc FFI call freaks and toasts your > image why you can do debugging, versus relying on a handful of > people in the world to grind thru some compiler, gnu debug > session to figure out why that register move results in a > fatal Virtual memory page fault. > > > Forget curl, I want to recreate the Cocoa class libs in > squeak/pharo for WebKit... > > > Cocoa ? So it will run only on Mac OS X ? > means (I hope) that the documented Cocoa classes for webkit should be a perfect template for wrapping the C-based webkit calls with squeak classes. Depends on how much has changed of course. Lawson _______________________________________________ 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 Tue, Apr 20, 2010 at 8:59 AM, Stéphane Ducasse <[hidden email]> wrote: The question is what we call core. Pharo + Sounds + Morphic examples + archiview.... = Pharo I know what you are thinking ;) But I even wouldn't put FFI neither in PharoCore or Pharo. If you want FFI, load it by yourself or in the metacello configuration of YOUR app. Cheers Mariano Note that the belonging of one package to group is not automatically clear. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I think that the remarks of john is really important.
If we would have a good C interaction then we can minimize also the dependencies on C plugin and the like. Stef > > > On Tue, Apr 20, 2010 at 8:59 AM, Stéphane Ducasse <[hidden email]> wrote: > The question is what we call core. > I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien > are infrastructure. > > > If you look at my answer to German on "Re: [Pharo-project] Really Important message (tm)" > April 16 > You can see that with a fast loading package mechanism then we could really introduce in "Pharo-Core" (= what we have now) > infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but > to Pharo from my point of view > > Mini > Mini + FFI + Tools + IDE + Compiler ....= PharoCore > Pharo + Sounds + Morphic examples + archiview.... = Pharo > > > > I know what you are thinking ;) > But I even wouldn't put FFI neither in PharoCore or Pharo. > > If you want FFI, load it by yourself or in the metacello configuration of YOUR app. > > Cheers > > Mariano > > Note that the belonging of one package to group is not automatically clear. > This is why metacello is key and a metacelloRepository. > > Steg > > >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev > >> image. > > > > +1 > > > >> That's only my opinion. > > > > Maybe Stef should tell us more about why he thinks it should be included. > > > > Bye > > T. > > > > -- > > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > Pharo-project mailing list > > [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 > > _______________________________________________ > 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 johnmci
Hi All,
2010/4/20 John M McIntosh <[hidden email]> Well I asked for it... I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself.
I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework.
Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call.
This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code)
2¢ Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 21.04.2010, at 00:09, Eliot Miranda wrote:
> Hi All, > > 2010/4/20 John M McIntosh <[hidden email]> >> Well I asked for it... >> >> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... - Bert - _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
2010/4/20 John M McIntosh <[hidden email]>:
> Well I asked for it... > > (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. > > (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . > > (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. > +++100 > > On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: > >>> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev >>> image. >> >> +1 >> >>> That's only my opinion. >> >> Maybe Stef should tell us more about why he thinks it should be included. >> >> Bye >> T. >> >> -- >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: squeaker68882 > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Bert Freudenberg
On 4/20/2010 3:37 PM, Bert Freudenberg wrote:
> > On 21.04.2010, at 00:09, Eliot Miranda wrote: >> Hi All, >> >> 2010/4/20 John M McIntosh<[hidden email]> >>> Well I asked for it... >>> >>> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. > > Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... Where is ExtendedClipboardPlugin? I've never seen it. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: > Hi All, > > 2010/4/20 John M McIntosh <[hidden email]> > Well I asked for it... > > (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. > > (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . > > I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. > > I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. Sounds good. I do not get anything but trying to learn. :) > (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. > > Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. > > This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) well when will we get more Cog improvements in the vm? > > 2¢ > > Eliot > > > On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: > > >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev > >> image. > > > > +1 > > > >> That's only my opinion. > > > > Maybe Stef should tell us more about why he thinks it should be included. > > > > Bye > > T. > > > > -- > > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: squeaker68882 > 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 > > _______________________________________________ > 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 Apr 21, 2010, at 9:06 AM, Stéphane Ducasse wrote: > > On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: > >> Hi All, >> >> 2010/4/20 John M McIntosh <[hidden email]> >> Well I asked for it... >> >> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. >> >> (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . >> >> I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. > > Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making > the VM knowledge more spread in the community. >> >> I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. > > Sounds good. I do not get anything but trying to learn. :) > >> (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. >> >> Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. >> >> This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) > > well when will we get more Cog improvements in the vm? >> >> 2¢ >> >> Eliot >> >> >> On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: >> >>>> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev >>>> image. >>> >>> +1 >>> >>>> That's only my opinion. >>> >>> Maybe Stef should tell us more about why he thinks it should be included. >>> >>> Bye >>> T. >>> >>> -- >>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> =========================================================================== >> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >> 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 >> >> _______________________________________________ >> 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 _______________________________________________ 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 |