On 14 November 2013 16:42, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Frank,
>
>
> On Thu, Nov 14, 2013 at 1:59 AM, Frank Shearar <frank.shearar at gmail.com>
> 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 <ma.chris.m at gmail.com> 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 <frank.shearar at gmail.com>
>> > 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 <asqueaker at gmail.com> wrote:
>> >> > Installer new merge: #ffi.
>> >> >
>> >> > Worked for me..
>> >> >
>> >> > On Tue, Nov 12, 2013 at 2:45 PM, Frank Shearar
>> >> > <frank.shearar at gmail.com>
>> >> > wrote:
>> >> >> On 26 February 2013 18:36, Eliot Miranda <eliot.miranda at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>>
>> >> >>> On Tue, Feb 26, 2013 at 1:51 AM, Frank Shearar
>> >> >>> <frank.shearar at gmail.com>
>> >> >>> 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