On Mon, Jan 31, 2011 at 03:08:09PM +0100, Igor Stasenko wrote:

On 31 January 2011 14:43, David T. Lewis lewis@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.

Ah, I see what you mean now. I was referring only to 'Cog-ProcessorPlugins', which contains just the BochsIA32Plugin. But there are a number of other things of interest in package 'Cog'. Perhaps Eliot can offer some guidance here, I don't know how or where this package should be maintained. If the intent is to maintain all of category 'Cog' as a package, then putting it in the VMMaker project might make better sense.

Dave