[Vm-dev] Cog VMMaker dependencies

[Igor Stasenko]

On 31 January 2011 14:43, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Mon, Jan 31, 2011 at 02:02:30PM +0100, Igor Stasenko wrote:
>>
>> Hello
>>
>> i am trying to put everything together and load all VMMaker stuff into
>> clean image, and found that it depends on
>> ???BochsIA32Alien class, defined in Cog package.
>> But this package have no public repository and can be found only in
>> vmmaker image which saved by Eliot in SVN repo :(
>>
>> Guys, do you mind if i copy this package to VMMaker repository on
>> squeaksource, so then we could have an official place where to
>> download it.
>> Because clearly, we need to make sure that VMMaker could be loaded
>> into fresh image from scratch, and in order to do that, we need some
>> persistent public place where we can download all packages from.
>
> Funny, I was looking at exactly the same thing yesterday. The Alien
> project on SqueakSource provides the NewsqueakIA32ABIPlugin and puts
> it in package 'Alien-VMMaker-Plugins'. This is also present in the
> oscog image but recategorized to 'VMMaker-Plugins-Alien', which
> also contains the new IA32ABIPlugin distributed with Cog. The
> BochsIA32Plugin plugin is in 'Cog-ProcessorPlugins'.
>
> The IA32ABIPlugin and BochsIA32Plugin are not yet usable in the
> standard VMMaker package (though I hope to correct this after the
> current round of VM builds). NewsqueakIA32ABIPlugin builds cleanly
> on Linux, though I have no idea if the resulting plugin does anything
> useful.
>
> I'm assuming that BochsIA32Plugin is at least loosely related to the
> current Alien development in Cog, so my personal preference would be
> to store IA32ABIPlugin and BochsIA32Plugin in the SqS/Alien project.
> The project seems to be actively maintained, and it already serves
> as the source for NewsqueakIA32ABIPlugin (I have it linked to VMMaker
> through the configure map). Would that approach be workable?
>

It would be good if VMMaker or plugins above to be not depend on Alien.
Alien is an image-side package, which having no use when building VM,
except some constants (i think).
So, what should be done is to split Alien to Alien + Alien-pool, in
same way as it done with FFI,
to decouple VMMaker from FFI image-side code.

> As an aside, I do think it is a good thing for plugins that are
> actively maintained to live in their own projects. Once they land
> in VMMaker, they tend to become homeless children ;)
>

Yes, things are messy..
the problem now is, that Cog's VMMaker now depends on Cog package,
while Cog package in own turn depends on VMMaker
(SmartSyntaxInterpreterPlugin etc).
A classic circular dependency between packages :))

So, what is the right place for putting a Cog package?
In VMMaker or in Alien repository?

So, certainly, some classes should change their home package to avoid
circular dependency,
and to have a good load order, like we had in old VMMaker:

- FFI & Sound pools
- VMMaker
- rest of stuff


P.S. by exploring the Cog package contents, i don't feel that it
belongs to Alien repository.
Btw, few weeks ago i hacked BochsIA32Alien class to remove
dependencies from Alien and Boch plugins both.
So, it can generate the code in simulator, but of course can't execute
it nor disassemble it.



> Dave
>

-- 
Best regards,
Igor Stasenko AKA sig.