Cog VMMaker dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Cog VMMaker dependencies

Igor Stasenko

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.


--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Cog VMMaker dependencies

David T. Lewis
 
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?

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 ;)

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Cog VMMaker dependencies

Igor Stasenko
 
On 31 January 2011 14:43, David T. Lewis <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Cog VMMaker dependencies

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

>  
> On 31 January 2011 14:43, David T. Lewis <[hidden email]> 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