Simulating the Cog V3 VM

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

Simulating the Cog V3 VM

Laura Perez Cerrato
 
Hello, everyone,

I've been trying to simulate the Cog V3 VM using the snippets provided
in the VMMaker image with no success. The VM seems to start up fine
until it tries to perform a full GC, which raises a debugger with the
following message: 'MessageNotUnderstood:
InLineLiteralsManager>>backEnd'

The image built using the provided scripts shows a lot of messages
related with undelcared variables and some of the snippets in the
different workspaces include unimplemented messages (e.g.
#removeUnneededBuiltins, present in the Slang test workspace, lacks
implementors in this image). I suspect something could've gone wrong
during the automatic package loading process. However, I seem to have
all the necessary changesets installed (telling from a quick
inspection of the repository using Monticello).

I'm not familiar with the inner workings of the VM and have been
working on this only very recently, so my apologies if I seem to be
asking something obvious.

Thanks in advance,

-Laura Perez Cerrato
Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Eliot Miranda-2
 
Hi Laura,

    and welcome!

On Wed, May 11, 2016 at 10:39 AM, Laura Perez Cerrato <[hidden email]> wrote:

Hello, everyone,

I've been trying to simulate the Cog V3 VM using the snippets provided
in the VMMaker image with no success. The VM seems to start up fine
until it tries to perform a full GC, which raises a debugger with the
following message: 'MessageNotUnderstood:
InLineLiteralsManager>>backEnd'

It was a bug.  Thanks for finding it!  It's fixed in VMMaker.oscog-eem.1858
Author: eem
Time: 11 May 2016, 11:29:11.609577 am
UUID: 4b71a017-2e37-4c2f-bab6-9010e95cb2ea
Ancestors: VMMaker.oscog-tpr.1857

Fix slip in closedPICRefersToUnmarkedObject:
 

The image built using the provided scripts shows a lot of messages
related with undelcared variables and some of the snippets in the
different workspaces include unimplemented messages (e.g.
#removeUnneededBuiltins, present in the Slang test workspace, lacks
implementors in this image). I suspect something could've gone wrong
during the automatic package loading process. However, I seem to have
all the necessary changesets installed (telling from a quick
inspection of the repository using Monticello).

Thanks, I'll try and clean these up.  Please keep reporting any anomalies you find.
 
I'm not familiar with the inner workings of the VM and have been
working on this only very recently, so my apologies if I seem to be
asking something obvious.

I'm curious about your project(s).  Would you care to say something about what you're doing?
 

Thanks in advance,

-Laura Perez Cerrato


_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Clément Béra
In reply to this post by Laura Perez Cerrato
 
Hi,

The VM developers mostly develop using the Spur memory manager, so it could be one of us broke the V3 simulator. Sorry about that. Have you reached the point in the simulator where the display screen was shown ?

In general, I run first the StackVM simulator, then the Cog VM simulator, then in-image compilation to have a stable system.

Why are you using V3 ? Is it required for what you are trying to do ? Spur is generally better unless you need to use V3 for some reason.

For the specific error you have, it seems it's a dispatch problem. All the JIT classes are merged into a single C file during Slang translation. For simulation, there are methods to automatically dispatch between the different objects. I think the method missing shuould look like:
InLineLiteralsManager >> backEnd
    <doNotGenerate>
    ^ cogit backEnd
Or something like that.

Regards,

On Wed, May 11, 2016 at 7:39 PM, Laura Perez Cerrato <[hidden email]> wrote:

Hello, everyone,

I've been trying to simulate the Cog V3 VM using the snippets provided
in the VMMaker image with no success. The VM seems to start up fine
until it tries to perform a full GC, which raises a debugger with the
following message: 'MessageNotUnderstood:
InLineLiteralsManager>>backEnd'

The image built using the provided scripts shows a lot of messages
related with undelcared variables and some of the snippets in the
different workspaces include unimplemented messages (e.g.
#removeUnneededBuiltins, present in the Slang test workspace, lacks
implementors in this image). I suspect something could've gone wrong
during the automatic package loading process. However, I seem to have
all the necessary changesets installed (telling from a quick
inspection of the repository using Monticello).

I'm not familiar with the inner workings of the VM and have been
working on this only very recently, so my apologies if I seem to be
asking something obvious.

Thanks in advance,

-Laura Perez Cerrato

Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Laura Perez Cerrato
 

Thanks a lot for the quick and helpful responses! I'll keep you updated if I find any other oddities.
I'm currently trying to add 8-bit depth support to the JPEGReadWriter plugin in order to be able to write 8-bit deep images to disk. I'm using the Cog VM since I'm running Cuis (it provides some very helpful image processing related packages), which is based on a non-Spur Squeak image.

On 11 May 2016 15:54, "Clément Bera" <[hidden email]> wrote:
 
Hi,

The VM developers mostly develop using the Spur memory manager, so it could be one of us broke the V3 simulator. Sorry about that. Have you reached the point in the simulator where the display screen was shown ?

In general, I run first the StackVM simulator, then the Cog VM simulator, then in-image compilation to have a stable system.

Why are you using V3 ? Is it required for what you are trying to do ? Spur is generally better unless you need to use V3 for some reason.

For the specific error you have, it seems it's a dispatch problem. All the JIT classes are merged into a single C file during Slang translation. For simulation, there are methods to automatically dispatch between the different objects. I think the method missing shuould look like:
InLineLiteralsManager >> backEnd
    <doNotGenerate>
    ^ cogit backEnd
Or something like that.

Regards,

On Wed, May 11, 2016 at 7:39 PM, Laura Perez Cerrato <[hidden email]> wrote:

Hello, everyone,

I've been trying to simulate the Cog V3 VM using the snippets provided
in the VMMaker image with no success. The VM seems to start up fine
until it tries to perform a full GC, which raises a debugger with the
following message: 'MessageNotUnderstood:
InLineLiteralsManager>>backEnd'

The image built using the provided scripts shows a lot of messages
related with undelcared variables and some of the snippets in the
different workspaces include unimplemented messages (e.g.
#removeUnneededBuiltins, present in the Slang test workspace, lacks
implementors in this image). I suspect something could've gone wrong
during the automatic package loading process. However, I seem to have
all the necessary changesets installed (telling from a quick
inspection of the repository using Monticello).

I'm not familiar with the inner workings of the VM and have been
working on this only very recently, so my apologies if I seem to be
asking something obvious.

Thanks in advance,

-Laura Perez Cerrato


Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Eliot Miranda-2
 
Hi Laura,

On May 11, 2016, at 12:27 PM, Laura Perez Cerrato <[hidden email]> wrote:

Thanks a lot for the quick and helpful responses! I'll keep you updated if I find any other oddities.
I'm currently trying to add 8-bit depth support to the JPEGReadWriter plugin in order to be able to write 8-bit deep images to disk. I'm using the Cog VM since I'm running Cuis (it provides some very helpful image processing related packages), which is based on a non-Spur Squeak image.

Cool.  It may be possible to test your modifications without the full simulator.  The system is designed for one to be able to Instantiate a plugin and use it in objects in the current image by using an InterpreterProxy instance to interface the plugin code with ordinary Smalltalk objects.  But I've never done this so I can't help.  Perhaps someone with experience of dong this can provide help.  Or does anyone know of any documentation on thus approach?

_,,,^..^,,,_ (phone)

On 11 May 2016 15:54, "Clément Bera" <[hidden email]> wrote:
 
Hi,

The VM developers mostly develop using the Spur memory manager, so it could be one of us broke the V3 simulator. Sorry about that. Have you reached the point in the simulator where the display screen was shown ?

In general, I run first the StackVM simulator, then the Cog VM simulator, then in-image compilation to have a stable system.

Why are you using V3 ? Is it required for what you are trying to do ? Spur is generally better unless you need to use V3 for some reason.

For the specific error you have, it seems it's a dispatch problem. All the JIT classes are merged into a single C file during Slang translation. For simulation, there are methods to automatically dispatch between the different objects. I think the method missing shuould look like:
InLineLiteralsManager >> backEnd
    <doNotGenerate>
    ^ cogit backEnd
Or something like that.

Regards,

On Wed, May 11, 2016 at 7:39 PM, Laura Perez Cerrato <[hidden email]> wrote:

Hello, everyone,

I've been trying to simulate the Cog V3 VM using the snippets provided
in the VMMaker image with no success. The VM seems to start up fine
until it tries to perform a full GC, which raises a debugger with the
following message: 'MessageNotUnderstood:
InLineLiteralsManager>>backEnd'

The image built using the provided scripts shows a lot of messages
related with undelcared variables and some of the snippets in the
different workspaces include unimplemented messages (e.g.
#removeUnneededBuiltins, present in the Slang test workspace, lacks
implementors in this image). I suspect something could've gone wrong
during the automatic package loading process. However, I seem to have
all the necessary changesets installed (telling from a quick
inspection of the repository using Monticello).

I'm not familiar with the inner workings of the VM and have been
working on this only very recently, so my apologies if I seem to be
asking something obvious.

Thanks in advance,

-Laura Perez Cerrato


Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

David T. Lewis
In reply to this post by Laura Perez Cerrato
 
Hello and welcome!

Dave

>
> Hello, everyone,
>
> I've been trying to simulate the Cog V3 VM using the snippets provided
> in the VMMaker image with no success. The VM seems to start up fine
> until it tries to perform a full GC, which raises a debugger with the
> following message: 'MessageNotUnderstood:
> InLineLiteralsManager>>backEnd'
>
> The image built using the provided scripts shows a lot of messages
> related with undelcared variables and some of the snippets in the
> different workspaces include unimplemented messages (e.g.
> #removeUnneededBuiltins, present in the Slang test workspace, lacks
> implementors in this image). I suspect something could've gone wrong
> during the automatic package loading process. However, I seem to have
> all the necessary changesets installed (telling from a quick
> inspection of the repository using Monticello).
>
> I'm not familiar with the inner workings of the VM and have been
> working on this only very recently, so my apologies if I seem to be
> asking something obvious.
>
> Thanks in advance,
>
> -Laura Perez Cerrato
>


Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Phil B
In reply to this post by Clément Béra
 
Clément,

On Wed, 2016-05-11 at 20:54 +0200, Clément Bera wrote:
> Why are you using V3 ? Is it required for what you are trying to do ?
> Spur is generally better unless you need to use V3 for some reason.

Chiming in since it seemed apropos: it's not by choice... not everyone
has images that have been migrated to Spur (speaking as another Cuis
user, but there are likely other images out there in the same
situation)  So until/unless there is a semi-automatic means of
migrating images as VM changes necessitate it, there will be a small
population of users being left behind on older VMs each time there is a
new image format.

This has been a pain point since the initial releases of Cog: not
everyone is running off of the main Squeak (or even Pharo) images so
every time there is a migration that involves 'just fire up a VMMaker
image and...' and the described steps don't pretty much 'just work',
there are going to be people stuck until they can figure out the
process to migrate.

This isn't necessarily a problem for the VM developers as one possible
position could be 'the VM only supports the latest official Squeak (and
Pharo?) images'.  I don't think that's the position VM folks are taking
so I'd just ask that VM developers keep in mind the reason some of us
are using older VMs is that we're a bit stranded until we can sort out
how to bridge the gap. (we're not VM developers so it is slow going for
us)

It's great to have a fish in the form of a migrated Squeak image.  What
seems to be missing is the fishing lesson that shows us how it was done
rather than having to somewhat reverse engineer the process each time.

Thanks,
Phil
Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

timrowledge


> On 11-05-2016, at 2:24 PM, Phil (list) <[hidden email]> wrote:
>
> Chiming in since it seemed apropos: it's not by choice... not everyone
> has images that have been migrated to Spur (speaking as another Cuis
> user, but there are likely other images out there in the same
> situation)  So until/unless there is a semi-automatic means of
> migrating images as VM changes necessitate it, there will be a small
> population of users being left behind on older VMs each time there is a
> new image format.

Well, there is such a mechanism but it tends to get left behind. The SystemTracer is the all-purpose Scout tool for getting children out of horse’s hooves and converting images. It would be entirely possible to make a version to convert a V3 image to Spur;  it’s the way I would have done it originally if I’d been responsible for it. It’s… eek, 20 years since I last did a big junta with it but you’d amazed at the possibilities.

I’m absolutely not volunteering to do it. It’s a big enough job to do right that somebody would have to pay...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Spell checkers at maximum!  Fire!


Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

Levente Uzonyi
 
Spur support has been added to SystemTracer a while ago.
http://www.squeaksource.com/SystemTracing.html

Levente

On Wed, 11 May 2016, tim Rowledge wrote:

>
>
>> On 11-05-2016, at 2:24 PM, Phil (list) <[hidden email]> wrote:
>>
>> Chiming in since it seemed apropos: it's not by choice... not everyone
>> has images that have been migrated to Spur (speaking as another Cuis
>> user, but there are likely other images out there in the same
>> situation)  So until/unless there is a semi-automatic means of
>> migrating images as VM changes necessitate it, there will be a small
>> population of users being left behind on older VMs each time there is a
>> new image format.
>
> Well, there is such a mechanism but it tends to get left behind. The SystemTracer is the all-purpose Scout tool for getting children out of horse’s hooves and converting images. It would be entirely possible to make a version to convert a V3 image to Spur;  it’s the way I would have done it originally if I’d been responsible for it. It’s… eek, 20 years since I last did a big junta with it but you’d amazed at the possibilities.
>
> I’m absolutely not volunteering to do it. It’s a big enough job to do right that somebody would have to pay...
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Spell checkers at maximum!  Fire!
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

timrowledge


> On 11-05-2016, at 4:17 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Spur support has been added to SystemTracer a while ago.
> http://www.squeaksource.com/SystemTracing.html

Excellent; looks like other-Tim got to it and seems to have made something working. So, why isn’t that the solution to migrating Cuis?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Customer: A primitive life form at the bottom of the food chain.


Reply | Threaded
Open this post in threaded view
|

VM support for older image formats (was: Simulating the Cog V3 VM)

David T. Lewis
In reply to this post by Phil B
 
On Wed, May 11, 2016 at 05:24:28PM -0400, Phil (list) wrote:

>  
> Cl??ment,
>
> On Wed, 2016-05-11 at 20:54 +0200, Cl??ment Bera wrote:
> > Why are you using V3 ? Is it required for what you are trying to do ?
> > Spur is generally better unless you need to use V3 for some reason.
>
> Chiming in since it seemed apropos: it's not by choice... not everyone
> has images that have been migrated to Spur (speaking as another Cuis
> user, but there are likely other images out there in the same
> situation) ??So until/unless there is a semi-automatic means of
> migrating images as VM changes necessitate it, there will be a small
> population of users being left behind on older VMs each time there is a
> new image format.
>
> This has been a pain point since the initial releases of Cog: not
> everyone is running off of the main Squeak (or even Pharo) images so
> every time there is a migration that involves 'just fire up a VMMaker
> image and...' and the described steps don't pretty much 'just work',
> there are going to be people stuck until they can figure out the
> process to migrate.
>
> This isn't necessarily a problem for the VM developers as one possible
> position could be 'the VM only supports the latest official Squeak (and
> Pharo?) images'. ??I don't think that's the position VM folks are taking
> so I'd just ask that VM developers keep in mind the reason some of us
> are using older VMs is that we're a bit stranded until we can sort out
> how to bridge the gap. (we're not VM developers so it is slow going for
> us)
>
> It's great to have a fish in the form of a migrated Squeak image. ??What
> seems to be missing is the fishing lesson that shows us how it was done
> rather than having to somewhat reverse engineer the process each time.
>

Even the very earliest Squeak images can be run on SqueakJS:

  http://try.squeak.org/

The traditional interpreter VM works well for images going back to
about Squeak 3.2, and up to but not including Spur images. Official
(but now outdated) releases are on squeakvm.org, and on Linux (not so
sure of other platforms), it is straightforward to compile an up to
date version yourself (*):

  http://wiki.squeak.org/squeak/6354

The Cog VMs run recent V3 images, as long as they are closure enabled.
That goes back a number of years now.

Dave

(*) If you try this, I would appreciate feedback as to whether you
encounter any problems. I think that it is a 10 minute recipe for a
first time VM builder, but I have never had any feedback to confirm
or deny that claim. If it works or does not work for you, please
speak up :-)

Reply | Threaded
Open this post in threaded view
|

Re: Simulating the Cog V3 VM

David T. Lewis
In reply to this post by timrowledge
 
On Wed, May 11, 2016 at 04:46:32PM -0700, tim Rowledge wrote:
>
>
> > On 11-05-2016, at 4:17 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> > Spur support has been added to SystemTracer a while ago.
> > http://www.squeaksource.com/SystemTracing.html
>
> Excellent; looks like other-Tim got to it and seems to have made something working. So, why isn???t that the solution to migrating Cuis?
>

Because it is not just a matter of converting the existing object memory,
there are also changes in the image.

Regarding SystemTracer, this is a nice light-weight approach to doing
the conversion, but Eliot's bootstrap process that uses the simulation
machinery in VMMaker has a lot of advantages too.

In addition to Eliot's documentation of the image bootstrap process, you
can also get a rough idea of the image-side differences by looking at
the four packages in this repository from your up to date trunk Spur
image:

  MCHttpRepository
        location: 'http://www.squeaksource.com/TrunkUpdateStreamV3'
        user: ''
        password: ''

This overstates the differences needed for bootstrapping a V3 image
to Spur, but it does give a sense of where the differences lie.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats (was: Simulating the Cog V3 VM)

Phil B
In reply to this post by David T. Lewis
 
Dave,

On Wed, 2016-05-11 at 19:50 -0400, David T. Lewis wrote:

> Even the very earliest Squeak images can be run on SqueakJS:
>
>   http://try.squeak.org/
>
> The traditional interpreter VM works well for images going back to
> about Squeak 3.2, and up to but not including Spur images. Official
> (but now outdated) releases are on squeakvm.org, and on Linux (not so
> sure of other platforms), it is straightforward to compile an up to
> date version yourself (*):
>
>   http://wiki.squeak.org/squeak/6354
>

Your efforts to keep the ability to build the older VMs alive is
greatly appreciated!  I've actually fired up some early 2.x and 3.x
images within the last month as they still have both historical and
reference value.

> The Cog VMs run recent V3 images, as long as they are closure
> enabled.
> That goes back a number of years now.
>

Yep, and that's why we (Cuis) are still on Stack and Cog V3 VMs.  We
will be until the changes necessary to forward migrate to Spur are
worked out.  We'll get there eventually, but as none of us have heavy
VM expertise so it takes a while.

> Dave
>
> (*) If you try this, I would appreciate feedback as to whether you
> encounter any problems. I think that it is a 10 minute recipe for a
> first time VM builder, but I have never had any feedback to confirm
> or deny that claim. If it works or does not work for you, please
> speak up :-)
>

I can confirm that your docs worked perfectly for a 32-bit build on
Debian 8.  (~10 minutes if you include waiting time for downloading and
building inside of a VM... <60 seconds of my time :-)

Thanks,
Phil
Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats (was: Simulating the Cog V3 VM)

David T. Lewis
 
On Wed, May 11, 2016 at 10:44:06PM -0400, Phil (list) wrote:

>  
> On Wed, 2016-05-11 at 19:50 -0400, David T. Lewis wrote:
> >
> > (*) If you try this, I would appreciate feedback as to whether you
> > encounter any problems. I think that it is a 10 minute recipe for a
> > first time VM builder, but I have never had any feedback to confirm
> > or deny that claim. If it works or does not work for you, please
> > speak up :-)
> >
>
> I can confirm that your docs worked perfectly for a 32-bit build on
> Debian 8. ??(~10 minutes if you include waiting time for downloading and
> building inside of a VM... <60 seconds of my time :-)
>

Phil,

Thanks for the feedback, much appreciated.

By "32-bit build" I assume you mean that you compiled it on 32-bit
Debian, not that you were intentially trying to build a 32-bit VM,
is that right?

Thanks,

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats (was: Simulating the Cog V3 VM)

Eliot Miranda-2
In reply to this post by Phil B

Phil, Juan, and other Cuis users,

    please accept my apology.  I have meant to help you port Cuis to Spur for many months now and I always forget through pressure of work.  I can imagine if must be frustrating but please keep nagging me.  My immediate task in a 64-bit port of the Newspeak system at Cadence.  Perhaps once that's done I'll have time to attend to the Cuis Spur bootstrap.  Again I do apologize.

_,,,^..^,,,_ (phone)

> On May 11, 2016, at 7:44 PM, Phil (list) <[hidden email]> wrote:
>
>
> Dave,
>
>> On Wed, 2016-05-11 at 19:50 -0400, David T. Lewis wrote:
>> Even the very earliest Squeak images can be run on SqueakJS:
>>
>>   http://try.squeak.org/
>>
>> The traditional interpreter VM works well for images going back to
>> about Squeak 3.2, and up to but not including Spur images. Official
>> (but now outdated) releases are on squeakvm.org, and on Linux (not so
>> sure of other platforms), it is straightforward to compile an up to
>> date version yourself (*):
>>
>>   http://wiki.squeak.org/squeak/6354
>
> Your efforts to keep the ability to build the older VMs alive is
> greatly appreciated!  I've actually fired up some early 2.x and 3.x
> images within the last month as they still have both historical and
> reference value.
>
>> The Cog VMs run recent V3 images, as long as they are closure
>> enabled.
>> That goes back a number of years now.
>
> Yep, and that's why we (Cuis) are still on Stack and Cog V3 VMs.  We
> will be until the changes necessary to forward migrate to Spur are
> worked out.  We'll get there eventually, but as none of us have heavy
> VM expertise so it takes a while.
>
>> Dave
>>
>> (*) If you try this, I would appreciate feedback as to whether you
>> encounter any problems. I think that it is a 10 minute recipe for a
>> first time VM builder, but I have never had any feedback to confirm
>> or deny that claim. If it works or does not work for you, please
>> speak up :-)
>
> I can confirm that your docs worked perfectly for a 32-bit build on
> Debian 8.  (~10 minutes if you include waiting time for downloading and
> building inside of a VM... <60 seconds of my time :-)
>
> Thanks,
> Phil
Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats (was: Simulating the Cog V3 VM)

Phil B
 
On Wed, 2016-05-11 at 19:59 -0700, Eliot Miranda wrote:

>  
> Phil, Juan, and other Cuis users,
>
>     please accept my apology.  I have meant to help you port Cuis to
> Spur for many months now and I always forget through pressure of
> work.  I can imagine if must be frustrating but please keep nagging
> me.  My immediate task in a 64-bit port of the Newspeak system at
> Cadence.  Perhaps once that's done I'll have time to attend to the
> Cuis Spur bootstrap.  Again I do apologize.
>
> _,,,^..^,,,_ (phone)
>

No worries as we understand your day job takes priority.  I bring it up
to hopefully ensure we don't slip to a point where both we haven't
figured it out and you only have a vague recollection of how to do it.
Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats (was: Simulating the Cog V3 VM)

Phil B
In reply to this post by David T. Lewis
 
Dave,

On Wed, 2016-05-11 at 22:57 -0400, David T. Lewis wrote:
> Phil,
>
> Thanks for the feedback, much appreciated.
>
> By "32-bit build" I assume you mean that you compiled it on 32-bit
> Debian, not that you were intentially trying to build a 32-bit VM,
> is that right?
>

That is correct.  I've got enough different things to build and have
generally found it easier to just set up architecture specific VMs (as
in KVM/VMware, not Squeak) for what I want to target (i.e. 32-bit x86,
64-bit x86, 32-bit ARM)  So I built it inside a 32-bit x86 KVM image.

> Thanks,
>
> Dave
>  
Reply | Threaded
Open this post in threaded view
|

re: Simulating the Cog V3 VM

Craig Latta
In reply to this post by Eliot Miranda-2
 

Hi--

     Eliot writes:

> The system is designed for one to be able to Instantiate a plugin and
> use it in objects in the current image by using an InterpreterProxy
> instance to interface the plugin code with ordinary Smalltalk
> objects.  But I've never done this so I can't help.  Perhaps
> someone with experience of dong this can provide help.

     I've done this, for network access used by remote messaging between
two simulators on different machines (or a simulator and a normal
system). I originally took the LargeIntegerPlugin simulator support as
my example, but have worked with this technique extensively since then.
Laura, I'd be happy to help if you'd like.


     thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

re: Simulating the Cog V3 VM

Laura Perez Cerrato
 
Craig,
Thanks for the offering! If you could point me in the right direction
in order to take this approach I'd greatly appreciate it. Is there any
documentation available on the subject?

-Laura Perez Cerrato


On 12 May 2016 at 10:23, Craig Latta <[hidden email]> wrote:

>
>
> Hi--
>
>      Eliot writes:
>
>> The system is designed for one to be able to Instantiate a plugin and
>> use it in objects in the current image by using an InterpreterProxy
>> instance to interface the plugin code with ordinary Smalltalk
>> objects.  But I've never done this so I can't help.  Perhaps
>> someone with experience of dong this can provide help.
>
>      I've done this, for network access used by remote messaging between
> two simulators on different machines (or a simulator and a normal
> system). I originally took the LargeIntegerPlugin simulator support as
> my example, but have worked with this technique extensively since then.
> Laura, I'd be happy to help if you'd like.
>
>
>      thanks,
>
> -C
>
> --
> Craig Latta
> Black Page Digital
> Amsterdam
> [hidden email]
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>
Reply | Threaded
Open this post in threaded view
|

Re: VM support for older image formats

Juan Vuletich-3
In reply to this post by Eliot Miranda-2
 
On 11/05/2016 11:59 p.m., Eliot Miranda wrote:
>
> Phil, Juan, and other Cuis users,
>
>      please accept my apology.  I have meant to help you port Cuis to Spur for many months now and I always forget through pressure of work.  I can imagine if must be frustrating but please keep nagging me.  My immediate task in a 64-bit port of the Newspeak system at Cadence.  Perhaps once that's done I'll have time to attend to the Cuis Spur bootstrap.  Again I do apologize.
>
> _,,,^..^,,,_ (phone)
>

I think I can speak not only for the Cuis community, but also for
Squeak's and Pharo's. We are all grateful for the work you have been
doing for all of us for many years. I also want to thank Cadence and
Qwaq / 3DICC for supporting your work.

We Cuis users want to run on Spur as much as you want us to be able to
do so. With your help and support, I'm sure we'll do it rather soon.

Thanks,
Juan Vuletich

>> On May 11, 2016, at 7:44 PM, Phil (list)<[hidden email]>  wrote:
>>
>>
>> Dave,
>>
>>> On Wed, 2016-05-11 at 19:50 -0400, David T. Lewis wrote:
>>> Even the very earliest Squeak images can be run on SqueakJS:
>>>
>>>    http://try.squeak.org/
>>>
>>> The traditional interpreter VM works well for images going back to
>>> about Squeak 3.2, and up to but not including Spur images. Official
>>> (but now outdated) releases are on squeakvm.org, and on Linux (not so
>>> sure of other platforms), it is straightforward to compile an up to
>>> date version yourself (*):
>>>
>>>    http://wiki.squeak.org/squeak/6354
>> Your efforts to keep the ability to build the older VMs alive is
>> greatly appreciated!  I've actually fired up some early 2.x and 3.x
>> images within the last month as they still have both historical and
>> reference value.
>>
>>> The Cog VMs run recent V3 images, as long as they are closure
>>> enabled.
>>> That goes back a number of years now.
>> Yep, and that's why we (Cuis) are still on Stack and Cog V3 VMs.  We
>> will be until the changes necessary to forward migrate to Spur are
>> worked out.  We'll get there eventually, but as none of us have heavy
>> VM expertise so it takes a while.
>>
>>> Dave
>>>
>>> (*) If you try this, I would appreciate feedback as to whether you
>>> encounter any problems. I think that it is a 10 minute recipe for a
>>> first time VM builder, but I have never had any feedback to confirm
>>> or deny that claim. If it works or does not work for you, please
>>> speak up :-)
>> I can confirm that your docs worked perfectly for a 32-bit build on
>> Debian 8.  (~10 minutes if you include waiting time for downloading and
>> building inside of a VM...<60 seconds of my time :-)
>>
>> Thanks,
>> Phil


12