Loading FFI is broken
Locked
12
12
 
|
(Installer monticello mc: (MCHttpRepository new location:
'http://source.squeak.org/FFI')) install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's not important to this post" fails with an MNU: ExternalFunction class >> callingConventionFor:. As far as I can see what's happening is this: * during the loading of the mcz ExternalFunction is defined, * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: X11Display* ''XOpenDisplay'' (char*) module:''X11''>) * Parser >> externalFunctionDeclaration checks whether ExternalFunction is defined. * It is, so tries to evaluate `descriptorClass callingConvention: here` and boom, because ExternalFunction class >> callingConventionFor: _has not been loaded yet_. I've seen this kind of issue with Helvetia code: sometimes you simply have to load class-side methods first. Thoughts? Lukas worked around the issue with his Helvetia code by directly patching Monticello, and ripping out its "try to do atomic loading" mechanism. frank |
|
|
On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar <[hidden email]> wrote: (Installer monticello mc: (MCHttpRepository new location: I thought we'd modified Monticello to load new methods first. Did this not get added to trunk?
best, Eliot
|
|
|
On 26 February 2013 18:36, Eliot Miranda <[hidden email]> wrote:
> > > On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar <[hidden email]> > wrote: >> >> (Installer monticello mc: (MCHttpRepository new location: >> 'http://source.squeak.org/FFI')) >> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's >> not important to this post" >> >> fails with an MNU: ExternalFunction class >> callingConventionFor:. >> >> As far as I can see what's happening is this: >> * during the loading of the mcz ExternalFunction is defined, >> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >> * Parser >> externalFunctionDeclaration checks whether >> ExternalFunction is defined. >> * It is, so tries to evaluate `descriptorClass callingConvention: >> here` and boom, because ExternalFunction class >> >> callingConventionFor: _has not been loaded yet_. > > > I thought we'd modified Monticello to load new methods first. Did this not > get added to trunk? Apparently not. It still happens with an up-to-date Squeak 4.5. frank >> I've seen this kind of issue with Helvetia code: sometimes you simply >> have to load class-side methods first. >> >> Thoughts? Lukas worked around the issue with his Helvetia code by >> directly patching Monticello, and ripping out its "try to do atomic >> loading" mechanism. >> >> frank >> > > > > -- > best, > Eliot > > > |
|
|
Installer new merge: #ffi.
Worked for me.. On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar <[hidden email]> wrote: > On 26 February 2013 18:36, Eliot Miranda <[hidden email]> wrote: >> >> >> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar <[hidden email]> >> wrote: >>> >>> (Installer monticello mc: (MCHttpRepository new location: >>> 'http://source.squeak.org/FFI')) >>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's >>> not important to this post" >>> >>> fails with an MNU: ExternalFunction class >> callingConventionFor:. >>> >>> As far as I can see what's happening is this: >>> * during the loading of the mcz ExternalFunction is defined, >>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >>> * Parser >> externalFunctionDeclaration checks whether >>> ExternalFunction is defined. >>> * It is, so tries to evaluate `descriptorClass callingConvention: >>> here` and boom, because ExternalFunction class >> >>> callingConventionFor: _has not been loaded yet_. >> >> >> I thought we'd modified Monticello to load new methods first. Did this not >> get added to trunk? > > Apparently not. It still happens with an up-to-date Squeak 4.5. > > frank > >>> I've seen this kind of issue with Helvetia code: sometimes you simply >>> have to load class-side methods first. >>> >>> Thoughts? Lukas worked around the issue with his Helvetia code by >>> directly patching Monticello, and ripping out its "try to do atomic >>> loading" mechanism. >>> >>> frank >>> >> >> >> >> -- >> best, >> Eliot >> >> >> > |
|
|
That pulls in the latest packages, right?
So that does work. But why does the reported version fail to load? That's a problem still. (While this lets me get on with what I wanted to do - add #interleaving: to Xtreams - this is still a problem. But thanks for the workaround, Chris!) frank On 12 November 2013 20:55, Chris Muller <[hidden email]> wrote: > Installer new merge: #ffi. > > Worked for me.. > > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar <[hidden email]> wrote: >> On 26 February 2013 18:36, Eliot Miranda <[hidden email]> wrote: >>> >>> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar <[hidden email]> >>> wrote: >>>> >>>> (Installer monticello mc: (MCHttpRepository new location: >>>> 'http://source.squeak.org/FFI')) >>>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's >>>> not important to this post" >>>> >>>> fails with an MNU: ExternalFunction class >> callingConventionFor:. >>>> >>>> As far as I can see what's happening is this: >>>> * during the loading of the mcz ExternalFunction is defined, >>>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >>>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >>>> * Parser >> externalFunctionDeclaration checks whether >>>> ExternalFunction is defined. >>>> * It is, so tries to evaluate `descriptorClass callingConvention: >>>> here` and boom, because ExternalFunction class >> >>>> callingConventionFor: _has not been loaded yet_. >>> >>> >>> I thought we'd modified Monticello to load new methods first. Did this not >>> get added to trunk? >> >> Apparently not. It still happens with an up-to-date Squeak 4.5. >> >> frank >> >>>> I've seen this kind of issue with Helvetia code: sometimes you simply >>>> have to load class-side methods first. >>>> >>>> Thoughts? Lukas worked around the issue with his Helvetia code by >>>> directly patching Monticello, and ripping out its "try to do atomic >>>> loading" mechanism. >>>> >>>> frank >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >> > |
|
|
I didn't see you loading FFI-Pools in advance. The issue you encountered may not have had anything to do with -eem.24. FYI -- FFI also has a "head" release on SqueakMap which documents how to load it.
On Tue, Nov 12, 2013 at 4:50 PM, Frank Shearar <[hidden email]> wrote: That pulls in the latest packages, right? |
|
|
That's the source of the problem: FFI-Kernel uses FFIConstants, which
is declared/defined in FFI-Pools. Insert standard Frank rant of something called "Kernel" depending on other stuff. (Possibly insert standard Chris rant of a package containing a single class? :) ) frank On 12 November 2013 23:20, Chris Muller <[hidden email]> wrote: > I didn't see you loading FFI-Pools in advance. The issue you encountered > may not have had anything to do with -eem.24. > > FYI -- FFI also has a "head" release on SqueakMap which documents how to > load it. > > > On Tue, Nov 12, 2013 at 4:50 PM, Frank Shearar <[hidden email]> > wrote: >> >> That pulls in the latest packages, right? >> >> So that does work. But why does the reported version fail to load? >> That's a problem still. >> >> (While this lets me get on with what I wanted to do - add >> #interleaving: to Xtreams - this is still a problem. But thanks for >> the workaround, Chris!) >> >> frank >> >> On 12 November 2013 20:55, Chris Muller <[hidden email]> wrote: >> > Installer new merge: #ffi. >> > >> > Worked for me.. >> > >> > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar <[hidden email]> >> > wrote: >> >> On 26 February 2013 18:36, Eliot Miranda <[hidden email]> >> >> wrote: >> >>> >> >>> >> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar >> >>> <[hidden email]> >> >>> wrote: >> >>>> >> >>>> (Installer monticello mc: (MCHttpRepository new location: >> >>>> 'http://source.squeak.org/FFI')) >> >>>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's >> >>>> not important to this post" >> >>>> >> >>>> fails with an MNU: ExternalFunction class >> callingConventionFor:. >> >>>> >> >>>> As far as I can see what's happening is this: >> >>>> * during the loading of the mcz ExternalFunction is defined, >> >>>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >> >>>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >> >>>> * Parser >> externalFunctionDeclaration checks whether >> >>>> ExternalFunction is defined. >> >>>> * It is, so tries to evaluate `descriptorClass callingConvention: >> >>>> here` and boom, because ExternalFunction class >> >> >>>> callingConventionFor: _has not been loaded yet_. >> >>> >> >>> >> >>> I thought we'd modified Monticello to load new methods first. Did >> >>> this not >> >>> get added to trunk? >> >> >> >> Apparently not. It still happens with an up-to-date Squeak 4.5. >> >> >> >> frank >> >> >> >>>> I've seen this kind of issue with Helvetia code: sometimes you simply >> >>>> have to load class-side methods first. >> >>>> >> >>>> Thoughts? Lukas worked around the issue with his Helvetia code by >> >>>> directly patching Monticello, and ripping out its "try to do atomic >> >>>> loading" mechanism. >> >>>> >> >>>> frank >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> best, >> >>> Eliot >> >>> >> >>> >> >>> >> >> >> > > > |
|
|
On Thu, Nov 14, 2013 at 09:59:19AM +0000, Frank Shearar wrote:
> That's the source of the problem: FFI-Kernel uses FFIConstants, which > is declared/defined in FFI-Pools. > > Insert standard Frank rant of something called "Kernel" depending on > other stuff. (Possibly insert standard Chris rant of a package > containing a single class? :) ) > The external package VMMaker uses FFIConstants for the FFI plugin. This should work properly when FFI-Kernel is not loaded in the image, so the separation is there for a good reason (unless the rant refers only to the use of the term "kernel" in which case I have no opinion). Dave |
|
|
In reply to this post by Frank Shearar-3
Hi Frank,
On Thu, Nov 14, 2013 at 1:59 AM, Frank Shearar <[hidden email]> wrote: That's the source of the problem: FFI-Kernel uses FFIConstants, which The problem here is that the VM depends on FFIConstants also, and the VM shouldn't depend on the rest of FFI. So FFIConstants does need to be on its own, but could perhaps be called something different.
best, Eliot
|
|
|
I know module-heads like to say it's all about modularity and not size
but I think it being about size is unavoidable. (And, when I say "size" I'm talking only talking about disk and memory but also coherence which is a valuable thing). Because otherwise "so what" if FFI includes the constants and VMMaker depends on it solely for that portion of it? How many methods making up FFI are we talking about? There are plenty of _other_ methods in the image which are not being used by VMMaker, what about them? Acknowledged or not, at some point we're forced to assume a balance between number of extra methods and number of extra packages. The hand-made-micro-packages approach puts these two metrics at inverse of each other, trading domain complexity for package complexity. This is why want Spoon to make micro-packaging less important. Let the machine imprint a truly "optimal", application-specific, image that no amount of human-wrangling could ever come close. Just MHO. PS -- Frank I agree with you that "Kernel" should imply the inner singularity EXCEPT when talking about "Constants" or "Exceptions", because a kernel implies a functional engine like physics where constants is even lower level, like constants of the universe.. On Thu, Nov 14, 2013 at 10:42 AM, Eliot Miranda <[hidden email]> wrote: > Hi Frank, > > > On Thu, Nov 14, 2013 at 1:59 AM, Frank Shearar <[hidden email]> > wrote: >> >> That's the source of the problem: FFI-Kernel uses FFIConstants, which >> is declared/defined in FFI-Pools. >> >> Insert standard Frank rant of something called "Kernel" depending on >> other stuff. (Possibly insert standard Chris rant of a package >> containing a single class? :) ) > > > The problem here is that the VM depends on FFIConstants also, and the VM > shouldn't depend on the rest of FFI. So FFIConstants does need to be on its > own, but could perhaps be called something different. > >> >> >> frank >> >> On 12 November 2013 23:20, Chris Muller <[hidden email]> wrote: >> > I didn't see you loading FFI-Pools in advance. The issue you >> > encountered >> > may not have had anything to do with -eem.24. >> > >> > FYI -- FFI also has a "head" release on SqueakMap which documents how to >> > load it. >> > >> > >> > On Tue, Nov 12, 2013 at 4:50 PM, Frank Shearar <[hidden email]> >> > wrote: >> >> >> >> That pulls in the latest packages, right? >> >> >> >> So that does work. But why does the reported version fail to load? >> >> That's a problem still. >> >> >> >> (While this lets me get on with what I wanted to do - add >> >> #interleaving: to Xtreams - this is still a problem. But thanks for >> >> the workaround, Chris!) >> >> >> >> frank >> >> >> >> On 12 November 2013 20:55, Chris Muller <[hidden email]> wrote: >> >> > Installer new merge: #ffi. >> >> > >> >> > Worked for me.. >> >> > >> >> > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar >> >> > <[hidden email]> >> >> > wrote: >> >> >> On 26 February 2013 18:36, Eliot Miranda <[hidden email]> >> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar >> >> >>> <[hidden email]> >> >> >>> wrote: >> >> >>>> >> >> >>>> (Installer monticello mc: (MCHttpRepository new location: >> >> >>>> 'http://source.squeak.org/FFI')) >> >> >>>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but >> >> >>>> that's >> >> >>>> not important to this post" >> >> >>>> >> >> >>>> fails with an MNU: ExternalFunction class >> >> >> >>>> callingConventionFor:. >> >> >>>> >> >> >>>> As far as I can see what's happening is this: >> >> >>>> * during the loading of the mcz ExternalFunction is defined, >> >> >>>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >> >> >>>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >> >> >>>> * Parser >> externalFunctionDeclaration checks whether >> >> >>>> ExternalFunction is defined. >> >> >>>> * It is, so tries to evaluate `descriptorClass callingConvention: >> >> >>>> here` and boom, because ExternalFunction class >> >> >> >>>> callingConventionFor: _has not been loaded yet_. >> >> >>> >> >> >>> >> >> >>> I thought we'd modified Monticello to load new methods first. Did >> >> >>> this not >> >> >>> get added to trunk? >> >> >> >> >> >> Apparently not. It still happens with an up-to-date Squeak 4.5. >> >> >> >> >> >> frank >> >> >> >> >> >>>> I've seen this kind of issue with Helvetia code: sometimes you >> >> >>>> simply >> >> >>>> have to load class-side methods first. >> >> >>>> >> >> >>>> Thoughts? Lukas worked around the issue with his Helvetia code by >> >> >>>> directly patching Monticello, and ripping out its "try to do >> >> >>>> atomic >> >> >>>> loading" mechanism. >> >> >>>> >> >> >>>> frank >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> best, >> >> >>> Eliot >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> > >> > >> > > > > -- > best, > Eliot > > > |
|
|
In reply to this post by Eliot Miranda-2
On 14 November 2013 16:42, Eliot Miranda <[hidden email]> wrote:
> Hi Frank, > > > On Thu, Nov 14, 2013 at 1:59 AM, Frank Shearar <[hidden email]> > wrote: >> >> That's the source of the problem: FFI-Kernel uses FFIConstants, which >> is declared/defined in FFI-Pools. >> >> Insert standard Frank rant of something called "Kernel" depending on >> other stuff. (Possibly insert standard Chris rant of a package >> containing a single class? :) ) > > > The problem here is that the VM depends on FFIConstants also, and the VM > shouldn't depend on the rest of FFI. So FFIConstants does need to be on its > own, but could perhaps be called something different. You know, I would be quite happy if we folded FFI into the base image. Seriously. For once I'd argue for _including_ something. I would gladly trade Morphic for FFI. OK, I'll chalk this up to That's How It Is, and move on. If you install from SqueakMap (as you should, and as I should have) you get the right load order. frank >> frank >> >> On 12 November 2013 23:20, Chris Muller <[hidden email]> wrote: >> > I didn't see you loading FFI-Pools in advance. The issue you >> > encountered >> > may not have had anything to do with -eem.24. >> > >> > FYI -- FFI also has a "head" release on SqueakMap which documents how to >> > load it. >> > >> > >> > On Tue, Nov 12, 2013 at 4:50 PM, Frank Shearar <[hidden email]> >> > wrote: >> >> >> >> That pulls in the latest packages, right? >> >> >> >> So that does work. But why does the reported version fail to load? >> >> That's a problem still. >> >> >> >> (While this lets me get on with what I wanted to do - add >> >> #interleaving: to Xtreams - this is still a problem. But thanks for >> >> the workaround, Chris!) >> >> >> >> frank >> >> >> >> On 12 November 2013 20:55, Chris Muller <[hidden email]> wrote: >> >> > Installer new merge: #ffi. >> >> > >> >> > Worked for me.. >> >> > >> >> > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar >> >> > <[hidden email]> >> >> > wrote: >> >> >> On 26 February 2013 18:36, Eliot Miranda <[hidden email]> >> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar >> >> >>> <[hidden email]> >> >> >>> wrote: >> >> >>>> >> >> >>>> (Installer monticello mc: (MCHttpRepository new location: >> >> >>>> 'http://source.squeak.org/FFI')) >> >> >>>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but >> >> >>>> that's >> >> >>>> not important to this post" >> >> >>>> >> >> >>>> fails with an MNU: ExternalFunction class >> >> >> >>>> callingConventionFor:. >> >> >>>> >> >> >>>> As far as I can see what's happening is this: >> >> >>>> * during the loading of the mcz ExternalFunction is defined, >> >> >>>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: >> >> >>>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) >> >> >>>> * Parser >> externalFunctionDeclaration checks whether >> >> >>>> ExternalFunction is defined. >> >> >>>> * It is, so tries to evaluate `descriptorClass callingConvention: >> >> >>>> here` and boom, because ExternalFunction class >> >> >> >>>> callingConventionFor: _has not been loaded yet_. >> >> >>> >> >> >>> >> >> >>> I thought we'd modified Monticello to load new methods first. Did >> >> >>> this not >> >> >>> get added to trunk? >> >> >> >> >> >> Apparently not. It still happens with an up-to-date Squeak 4.5. >> >> >> >> >> >> frank >> >> >> >> >> >>>> I've seen this kind of issue with Helvetia code: sometimes you >> >> >>>> simply >> >> >>>> have to load class-side methods first. >> >> >>>> >> >> >>>> Thoughts? Lukas worked around the issue with his Helvetia code by >> >> >>>> directly patching Monticello, and ripping out its "try to do >> >> >>>> atomic >> >> >>>> loading" mechanism. >> >> >>>> >> >> >>>> frank >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> best, >> >> >>> Eliot >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> > >> > >> > > > > -- > best, > Eliot |
|
|
FFI used to BE part of the base image, and was specifically taken out on purpose. The purpose, as I remember it, was because it acted like a security hole for squeak as a squeaklet on the web (when you browse a page on a website that invokes Squeak, and then being able to, via FFI, invoke anything you want on the remote machine). So, for any image still working in that mode (such as the etoys derivative), it is important to leave out. But, with the shiny new CI servers, couldn't we have an artifact built with FFI loaded? Or, even neater, include FFI in the trunk, but have a switch/pragma in the image that says 'Don't ever load FFI' for those that don't want it, but want everything else loaded? So, for people that LIKE FFI, it is just part of Trunk; for those that have to avoid it, it isn't loaded; for the rest, they get whatever was setup when they got their image. (I'd be in the first group most of the time)
-cbc On Thu, Nov 14, 2013 at 2:30 PM, Frank Shearar <[hidden email]> wrote:
|
|
|
A few things to be aware of:
- Both Eliot Miranda and Igor Stasenko have done considerable work on FFI interfaces. I cannot explain the details, but be aware that there may be more than one kind of FFI that people will want to use, and it seems quite likely that the classic FFI may in future be replaced by a different implementation. - None of the available FFI interfaces will work for a VM compiled in 64-bit mode, nor can they be used to interface to existing 64-bit libraries. I am sure that the problems will be addressed in one or more of the FFI implementations, but this may take some time (to give an idea of the time scale, see http://bugs.squeak.org/view.php?id=7237). - Like any other reloadable package in Squeak, the classic Squeak FFI can be maintained as an external package. It requires a little more work to keep it healthy, because someone has to remember to test it once in a while. But there is no reason that this can not or should not be done. Dave On Thu, Nov 14, 2013 at 03:38:49PM -0800, Chris Cunningham wrote: > FFI used to BE part of the base image, and was specifically taken out on > purpose. The purpose, as I remember it, was because it acted like a > security hole for squeak as a squeaklet on the web (when you browse a page > on a website that invokes Squeak, and then being able to, via FFI, invoke > anything you want on the remote machine). So, for any image still working > in that mode (such as the etoys derivative), it is important to leave out. > > But, with the shiny new CI servers, couldn't we have an artifact built with > FFI loaded? > > Or, even neater, include FFI in the trunk, but have a switch/pragma in the > image that says 'Don't ever load FFI' for those that don't want it, but > want everything else loaded? So, for people that LIKE FFI, it is just part > of Trunk; for those that have to avoid it, it isn't loaded; for the rest, > they get whatever was setup when they got their image. (I'd be in the > first group most of the time) > > -cbc > > > On Thu, Nov 14, 2013 at 2:30 PM, Frank Shearar <[hidden email]>wrote: > > > On 14 November 2013 16:42, Eliot Miranda <[hidden email]> wrote: > > > Hi Frank, > > > > > > > > > On Thu, Nov 14, 2013 at 1:59 AM, Frank Shearar <[hidden email]> > > > wrote: > > >> > > >> That's the source of the problem: FFI-Kernel uses FFIConstants, which > > >> is declared/defined in FFI-Pools. > > >> > > >> Insert standard Frank rant of something called "Kernel" depending on > > >> other stuff. (Possibly insert standard Chris rant of a package > > >> containing a single class? :) ) > > > > > > > > > The problem here is that the VM depends on FFIConstants also, and the VM > > > shouldn't depend on the rest of FFI. So FFIConstants does need to be on > > its > > > own, but could perhaps be called something different. > > > > You know, I would be quite happy if we folded FFI into the base image. > > Seriously. For once I'd argue for _including_ something. I would > > gladly trade Morphic for FFI. > > > > OK, I'll chalk this up to That's How It Is, and move on. If you > > install from SqueakMap (as you should, and as I should have) you get > > the right load order. > > > > frank > > > > >> frank > > >> > > >> On 12 November 2013 23:20, Chris Muller <[hidden email]> wrote: > > >> > I didn't see you loading FFI-Pools in advance. The issue you > > >> > encountered > > >> > may not have had anything to do with -eem.24. > > >> > > > >> > FYI -- FFI also has a "head" release on SqueakMap which documents how > > to > > >> > load it. > > >> > > > >> > > > >> > On Tue, Nov 12, 2013 at 4:50 PM, Frank Shearar < > > [hidden email]> > > >> > wrote: > > >> >> > > >> >> That pulls in the latest packages, right? > > >> >> > > >> >> So that does work. But why does the reported version fail to load? > > >> >> That's a problem still. > > >> >> > > >> >> (While this lets me get on with what I wanted to do - add > > >> >> #interleaving: to Xtreams - this is still a problem. But thanks for > > >> >> the workaround, Chris!) > > >> >> > > >> >> frank > > >> >> > > >> >> On 12 November 2013 20:55, Chris Muller <[hidden email]> wrote: > > >> >> > Installer new merge: #ffi. > > >> >> > > > >> >> > Worked for me.. > > >> >> > > > >> >> > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar > > >> >> > <[hidden email]> > > >> >> > wrote: > > >> >> >> On 26 February 2013 18:36, Eliot Miranda <[hidden email] > > > > > >> >> >> wrote: > > >> >> >>> > > >> >> >>> > > >> >> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar > > >> >> >>> <[hidden email]> > > >> >> >>> wrote: > > >> >> >>>> > > >> >> >>>> (Installer monticello mc: (MCHttpRepository new location: > > >> >> >>>> 'http://source.squeak.org/FFI')) > > >> >> >>>> install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but > > >> >> >>>> that's > > >> >> >>>> not important to this post" > > >> >> >>>> > > >> >> >>>> fails with an MNU: ExternalFunction class >> > > >> >> >>>> callingConventionFor:. > > >> >> >>>> > > >> >> >>>> As far as I can see what's happening is this: > > >> >> >>>> * during the loading of the mcz ExternalFunction is defined, > > >> >> >>>> * a method is parsed (#XOpenDisplay, which has a pragma <cdecl: > > >> >> >>>> X11Display* ''XOpenDisplay'' (char*) module:''X11''>) > > >> >> >>>> * Parser >> externalFunctionDeclaration checks whether > > >> >> >>>> ExternalFunction is defined. > > >> >> >>>> * It is, so tries to evaluate `descriptorClass > > callingConvention: > > >> >> >>>> here` and boom, because ExternalFunction class >> > > >> >> >>>> callingConventionFor: _has not been loaded yet_. > > >> >> >>> > > >> >> >>> > > >> >> >>> I thought we'd modified Monticello to load new methods first. > > Did > > >> >> >>> this not > > >> >> >>> get added to trunk? > > >> >> >> > > >> >> >> Apparently not. It still happens with an up-to-date Squeak 4.5. > > >> >> >> > > >> >> >> frank > > >> >> >> > > >> >> >>>> I've seen this kind of issue with Helvetia code: sometimes you > > >> >> >>>> simply > > >> >> >>>> have to load class-side methods first. > > >> >> >>>> > > >> >> >>>> Thoughts? Lukas worked around the issue with his Helvetia code > > by > > >> >> >>>> directly patching Monticello, and ripping out its "try to do > > >> >> >>>> atomic > > >> >> >>>> loading" mechanism. > > >> >> >>>> > > >> >> >>>> frank > > >> >> >>>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> -- > > >> >> >>> best, > > >> >> >>> Eliot > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >> > > >> >> > > > >> > > > >> > > > >> > > > > > > > > > > > > -- > > > best, > > > Eliot > > > > > |
|
|
Hi David,
forgive me for chipping in somewhat tangentally. But the vision thang can be important sometimes. On Thu, Nov 14, 2013 at 3:59 PM, David T. Lewis <[hidden email]> wrote: A few things to be aware of: +1. At least Spur will change the facilities available as does NativeBoost. Ideally we'll develop some kind of synthesis. SPur provides pinning. NativeBoost provides the ability to generate marshalling code from within the image which means not having to rely on the VM for marshalling, which should hopefully mean correctness on platforms with really complex marshalling rules such as x86-64/IA64.
Further, Igor's discovery that any C signature can be compiled as a Smalltalk literal array changes how one should parse C declarations. It's a magnificently simple hack.
struct { int foo; float bar; } (*f)(double bletch); => #(#struct #'{' #int #foo #';' #float #bar #';' #'}' #(#* #f) #(#double #bletch) #';') => #(struct { int foo; float bar; } (*f)(double bletch);)
- None of the available FFI interfaces will work for a VM compiled in That will be addressed when a 64-bit Spur is implemented.
- Like any other reloadable package in Squeak, the classic Squeak FFI +1. Dave best, Eliot
|
|
|
In reply to this post by Frank Shearar-3
On 14.11.2013, at 14:30, Frank Shearar <[hidden email]> wrote:
> You know, I would be quite happy if we folded FFI into the base image. > Seriously. For once I'd argue for _including_ something. -1 We should make it as simple to install as possible, but the temptation to use it for system-critical functions would just be too large if it is "always there", I'm afraid. - Bert - |
|
|
Hi,
On 19.11.2013, at 00:43, Bert Freudenberg <[hidden email]> wrote: > On 14.11.2013, at 14:30, Frank Shearar <[hidden email]> wrote: > >> You know, I would be quite happy if we folded FFI into the base image. >> Seriously. For once I'd argue for _including_ something. > > -1 > > We should make it as simple to install as possible, but the temptation to use it for system-critical functions would just be too large if it is "always there", I'm afraid. Controversial Proposal: Drop all plugins, do _only_ FFI. Just my 2ct Best -Tobias |
signature.asc (1K) |
|
On Tue, 19 Nov 2013, Tobias Pape wrote:
> Hi, > > > On 19.11.2013, at 00:43, Bert Freudenberg <[hidden email]> wrote: > >> On 14.11.2013, at 14:30, Frank Shearar <[hidden email]> wrote: >> >>> You know, I would be quite happy if we folded FFI into the base image. >>> Seriously. For once I'd argue for _including_ something. >> >> -1 >> >> We should make it as simple to install as possible, but the temptation to use it for system-critical functions would just be too large if it is "always there", I'm afraid. > > Controversial Proposal: > > Drop all plugins, do _only_ FFI. > > Just my 2ct Show me how you can replace the SocketPlugin with FFI, and I'll consider it. ;) Levente > > Best > -Tobias > |
|
|
In reply to this post by Bert Freudenberg
On 18 November 2013 23:43, Bert Freudenberg <[hidden email]> wrote:
> On 14.11.2013, at 14:30, Frank Shearar <[hidden email]> wrote: > >> You know, I would be quite happy if we folded FFI into the base image. >> Seriously. For once I'd argue for _including_ something. > > -1 > > We should make it as simple to install as possible, but the temptation to use it for system-critical functions would just be too large if it is "always there", I'm afraid. Agreed. I only half-suggested it, because there are many frivolous things included in the base image, while something actually really useful for connecting with the larger world is deliberately kept out of the base image. frank > - Bert - > > > |
|
|
In reply to this post by Tobias Pape
On Tue, Nov 19, 2013 at 10:27:59AM +0100, Tobias Pape wrote:
> > Controversial Proposal: > > Drop all plugins, do _only_ FFI. > Try converting one of the existing plugins to FFI and let us know if you still think it is a good idea. I remember when somebody on the Pharo list suggested reimplementing the OSProcessPlugin in FFI. I told them it was a really great idea, and they should give it a try. That settled the matter quite quickly ;-) As an aside, it is a complete mystery to me why people are willing to work so hard to avoid writing a VM plugin. VM plugins are reliable, portable, and debuggable. They work across a range of processors. They work on 64-bit platforms. So why would someone prefer to switch to a calling interface that basically only works on 32-bit Intel processors and that may require low level knowledge of calling conventions, word alignment, and platform-specific data types? I really don't get it. But don't listen to me. If anyone thinks that plugins should be implemented with FFI, I will tell them that it is a really great idea, and they should give it a try and let us know how it works out ;-) Dave |
|
|
In reply to this post by Tobias Pape
On 19.11.2013, at 03:27, Tobias Pape <[hidden email]> wrote:
> > Hi, > > >> On 19.11.2013, at 00:43, Bert Freudenberg <[hidden email]> wrote: >> >>> On 14.11.2013, at 14:30, Frank Shearar <[hidden email]> wrote: >>> >>> You know, I would be quite happy if we folded FFI into the base image. >>> Seriously. For once I'd argue for _including_ something. >> >> -1 >> >> We should make it as simple to install as possible, but the temptation to use it for system-critical functions would just be too large if it is "always there", I'm afraid. > > Controversial Proposal: > > Drop all plugins, do _only_ FFI. Suppose we add a new VM platform, like a VM running on JavaScript in the browser. Do you really want to re-implement all the C libraries utilized via FFI? Or rather a handful of primitives in your language of choice? - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |