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