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 |
Hi Laura,
and welcome! On Wed, May 11, 2016 at 10:39 AM, Laura Perez Cerrato <[hidden email]> wrote:
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:
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 I'm curious about your project(s). Would you care to say something about what you're doing?
_,,,^..^,,,_ best, Eliot |
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:
|
Thanks a lot for the quick and helpful responses! I'll keep you updated if I find any other oddities. On 11 May 2016 15:54, "Clément Bera" <[hidden email]> wrote:
|
Hi Laura,
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)
|
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 > |
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 |
> 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! |
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! > > > |
> 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. |
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 :-) |
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 |
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 |
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 |
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 |
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. |
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 > |
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) |
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) > |
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 |
Free forum by Nabble | Edit this page |