Hi: Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image. Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base. I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here. Would be great if those people could send me their change sets so that I can try getting everything working again. As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes. Which is enough to make it notice that a primitive fails, and to pop up the error dialog. However, it is a Pharo 1.2 image. Later images trigger some bug, I havenât identified yet. They execute code, but donât manage to bring up the display. Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here: https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot More to come soon. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Awesome. I'll try your code. And a 1.2 to see a screen :-) One more step to VM understanding here! Phil On Wednesday, February 12, 2014, Stefan Marr <smalltalk@stefan-marr.de> wrote:
Hi:
Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image.
Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base. I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here.
Would be great if those people could send me their change sets so that I can try getting everything working again.
As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes. Which is enough to make it notice that a primitive fails, and to pop up the error dialog. However, it is a Pharo 1.2 image. Later images trigger some bug, I haven't identified yet. They execute code, but don't manage to bring up the display.
Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here: https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot
More to come soon. Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Hi Stefan! On Wed, Feb 12, 2014 at 12:35 PM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
Hi:
Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image.
Fab! This is great. Over the last years, people have been tinkering with the simulator from
time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base.
How can anyone do anything significant with the VM without getting the simulator to work? [ ;-) ] You know about the first attempt at making a 64-bit VM for HP don't you? A nightmare tale :-).
I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here.
Would be great if those people could send me their change sets so that I can try getting everything working again.
As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes. Which is enough to make it notice that a primitive fails, and to pop up the error dialog. However, it is a Pharo 1.2 image. Later images trigger some bug, I haven't identified yet. They execute code, but don't manage to bring up the display.
Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here: https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot
Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
More to come soon. Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- best, Eliot
On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Stefan!
On Wed, Feb 12, 2014 at 12:35 PM, Stefan Marr <smalltalk@stefan-marr.de> wrote: Hi:
Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image.
Fab! This is great.
Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base.
How can anyone do anything significant with the VM without getting the simulator to work? [ ;-) ] You know about the first attempt at making a 64-bit VM for HP don't you? A nightmare tale :-).
I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here.
Would be great if those people could send me their change sets so that I can try getting everything working again.
As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes. Which is enough to make it notice that a primitive fails, and to pop up the error dialog. However, it is a Pharo 1.2 image. Later images trigger some bug, I havenât identified yet. They execute code, but donât manage to bring up the display.
Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here: https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot
Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
give me some days⦠I have in my todo list to create a jenkins job to upload the mcz to source.squeak.org (you asked for it more or less in december, but I didnât had the time until now, sorry). Esteban
More to come soon. Best regards Stefan
<simulator.jpeg> -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- best, Eliot
Hi Eliot: On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hmm. Whatâs the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
I think the bigger question is whether you actually want to adopt those things. If you skim over the diffs on Github [1], you will probably find that most of the changes are necessary to adopt Pharo-specific API changes. Not sure what the best way forward would be to avoid having the two Squeak and Pharo flavors diverge even more. I am open to suggestions, donât have a good idea how to properly âmodularizeâ these differences myself⦠Best regards Stefan [1] https://github.com/pharo-project/pharo-vm/pull/18 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Stefan Marr
Hi Eliot:
On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
I think the bigger question is whether you actually want to adopt those things.
That the vm says in sync should be a core requirement for our communities. I realize that there is a split. There are some really great advancements going on in pharo-vm including new build methods and configurations. All of that has value if pharo can stay in sync with COG developments. It doesn't make sense to require Pharo developers to redo Eliot's work or to eliminate Pharo VM advancements from the Squeak / Newspeak community. The VM is the one place where we can continue to work together for the benefit of all three communities. We should not, if at all possible, diverge, lest we lose some excellent contributions from some really terrific people, in one or another community. All the best, Ron Teitelbaum
If you skim over the diffs on Github [1], you will probably find that most of the changes are necessary to adopt Pharo-specific API changes. Not sure what the best way forward would be to avoid having the two Squeak and Pharo flavors diverge even more.
I am open to suggestions, don't have a good idea how to properly 'modularize' these differences myself.
Best regards Stefan
[1] https://github.com/pharo-project/pharo-vm/pull/18
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Hi Ron: On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that? Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits] primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:â' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table]. primitiveGetAttribute - attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr. CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm. ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue: And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Stefan, Some changes I did. I am adding you to a dropbox folder where I've put my sim image. You can put yours in there as well. There is also the issue of FileSystem :-) Phil On Thu, Feb 13, 2014 at 11:01 AM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
Hi Ron:
On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that?
Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].
primitiveGetAttribute
- attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr.
CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm.
ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue:
And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Hi Phil: On 13 Feb 2014, at 11:31, phil@highoctane.be wrote:
Some changes I did. There is also the issue of FileSystem :-)
Thanks, I checked these changes, and they are already covered. Including FileSystem :) Well, the image should be reproducible. But Iâll try to set up a CI job soon. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Stefan Marr Hi Ron:
On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that?
I think the answer is one at a time. With some collaboration and negotiation. Refactoring is fine as long as it provides some value. It doesn't have to be a change in function, a change in clarity suffices in my opinion. The benefit needs to be worth the pain of change. Where we can agree on the benefit the three communities should adopt it. Where we disagree, each community should take on the pain of supporting their version and we diverge. I'm confident that Eliot can manage to sync up what makes sense. Hopefully he can also push back on what doesn't and you can sync up on his changes or concerns. With the good intention as a core goal on all sides, proper action follows. All of this gets easier if we collaborate up front instead of trying to sync after the fact. All the best, Ron Teitelbaum
Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].
primitiveGetAttribute
- attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr.
CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm.
ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue:
And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Hi Folks, (below) Quoting Stefan Marr <smalltalk@stefan-marr.de>:
Hi Ron:
On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that?
Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:â' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].
primitiveGetAttribute
- attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr.
CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm.
ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue:
And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
All these can be handled without much trouble in a new package "VMMaker compatibility for Pharo" or such. Cheers, Juan Vuletich
Sorry for top posting. Juan is right. The kind of differences we are discussing here are related to user interface and file system differences in the various images, and this can be handled with a compatibility package for Pharo. It also can be done by merging into VMMaker (oscog branch), although this tends to get messy as Pharo diverges further from Squeak. I would defer to Eliot as to which approach he would prefer, since it most directly affects the oscog branch for now. But FWIW, I think that Juan's suggestion is the most straightforward and easiest to maintain over time. Dave
Hi Folks,
(below)
Quoting Stefan Marr <smalltalk@stefan-marr.de>:
Hi Ron:
On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that?
Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:âÂÂ' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].
primitiveGetAttribute
- attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr.
CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm.
ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue:
And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
All these can be handled without much trouble in a new package "VMMaker compatibility for Pharo" or such.
Cheers, Juan Vuletich
On Thu, Feb 13, 2014 at 2:01 AM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
Hi Ron:
On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron@USMedRec.com> wrote:
I think the bigger question is whether you actually want to adopt those things.
That the vm stays in sync should be a core requirement for our communities.
I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that?
I would implement isPharo/isSqueak/isNewspeak in VMClass. These can answer e.g. the value of a class variable. hence, below...
Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].
primitiveUpdateGZipCrc32 self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: (self isPharo ifTrue: [CRC] ifFalse: [GZipWriteStream]) crcTable].
primitiveGetAttribute
- attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr.
This is just my code base being a little out of date. Smalltalk vm getSystemAttribute: works in Squeak. I'll update my code.
CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm.
This needs to be isPharo.
ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue:
Ditto, until Squeak changes?
And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.
But fab that the simulator is receiving attention on Pharo (and Tty's work with events is great too). Now if there could be an automatic job to export whatever git state is the current official Pharo VM to a Monticello VMMaker package I'll be very much happier. Also for this discussion should we continue to cross-post or is vm-dev an adequate forum? Answers from Pharoites please... I have to admit that I'm a bit troubled by how often subjects that are clearly vm-centric are raised on pharo-dev. To Pharoites perceive vm-dev as a squeak thing? If so, may I suggest pharo-vm-dev? If not, can the Pharo community make an effort to direct vm discussion towards vm-dev in future?
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- best, Eliot
Ron, Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue. The key advantage is that the Smalltalk VM is written in itself. Now, what do I experience is that it is hard to embark on VM work. Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle. The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0. I am not in the league of the VM maintainers obviously. But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down. We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter). All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front). A real Pharo image is overkill for this as a ton of plugins get involved etc. The core system should be the same for Pharo/Squeak/... : VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation and of course the Slang things (VMMaker-Support and VMMaker-Translation to C). What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed. Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you? Phil On Thu, Feb 13, 2014 at 10:38 AM, Ron Teitelbaum <ron@usmedrec.com> wrote:
Stefan Marr
Hi Eliot:
On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
I think the bigger question is whether you actually want to adopt those things.
That the vm says in sync should be a core requirement for our communities. I realize that there is a split. There are some really great advancements going on in pharo-vm including new build methods and configurations. All of that has value if pharo can stay in sync with COG developments. It doesn't make sense to require Pharo developers to redo Eliot's work or to eliminate Pharo VM advancements from the Squeak / Newspeak community. The VM is the one place where we can continue to work together for the benefit of all three communities. We should not, if at all possible, diverge, lest we lose some excellent contributions from some really terrific people, in one or another community.
All the best, Ron Teitelbaum
If you skim over the diffs on Github [1], you will probably find that most of the changes are necessary to adopt Pharo-specific API changes. Not sure what the best way forward would be to avoid having the two Squeak and Pharo flavors diverge even more.
I am open to suggestions, don't have a good idea how to properly 'modularize' these differences myself.
Best regards Stefan
[1] https://github.com/pharo-project/pharo-vm/pull/18
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of phil@highoctane.be Ron, Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue. The key advantage is that the Smalltalk VM is written in itself. Now, what do I experience is that it is hard to embark on VM work. Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle. The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0. I understand. I'm suggestion that our shared goal should be to bring the communities together for the VM. We can all benefit from the contributions on all sides. It would seem to me that the COG simulator would work for Pharo if we can get closer in sync but you are correct: It will take time, collaboration and resources. All the best, Ron Teitelbaum [snip] The core system should be the same for Pharo/Squeak/... : VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation and of course the Slang things (VMMaker-Support and VMMaker-Translation to C). What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed. Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you? Phil On Thu, Feb 13, 2014 at 10:38 AM, Ron Teitelbaum <ron@usmedrec.com> wrote:
Stefan Marr
Hi Eliot:
On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?
I think the bigger question is whether you actually want to adopt those things.
That the vm says in sync should be a core requirement for our communities. I realize that there is a split. There are some really great advancements going on in pharo-vm including new build methods and configurations. All of that has value if pharo can stay in sync with COG developments. It doesn't make sense to require Pharo developers to redo Eliot's work or to eliminate Pharo VM advancements from the Squeak / Newspeak community. The VM is the one place where we can continue to work together for the benefit of all three communities. We should not, if at all possible, diverge, lest we lose some excellent contributions from some really terrific people, in one or another community. All the best, Ron Teitelbaum
If you skim over the diffs on Github [1], you will probably find that most of the changes are necessary to adopt Pharo-specific API changes. Not sure what the best way forward would be to avoid having the two Squeak and Pharo flavors diverge even more.
I am open to suggestions, don't have a good idea how to properly 'modularize' these differences myself.
Best regards Stefan
[1] https://github.com/pharo-project/pharo-vm/pull/18
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
phil@highoctane.be wrote:
Ron,
Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue.
The key advantage is that the Smalltalk VM is written in itself.
Now, what do I experience is that it is hard to embark on VM work.
Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle.
The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.
I am not in the league of the VM maintainers obviously.
But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down.
We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter).
All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front).
A real Pharo image is overkill for this as a ton of plugins get involved etc.
The core system should be the same for Pharo/Squeak/... :
VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation
and of course the Slang things (VMMaker-Support and VMMaker-Translation to C).
What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed.
Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you?
Phil
Getting the simulator working in Pharo could be a GSoC project? or is it too advanced? cheers -ben
With proper support, this is doable I think. But the student will have to be really motivated and smart I suppose. Which raises the question: how does one find such ones? Phil On Thu, Feb 13, 2014 at 3:19 PM, <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
Ron,
Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue.
The key advantage is that the Smalltalk VM is written in itself.
Now, what do I experience is that it is hard to embark on VM work.
Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle.
The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.
I am not in the league of the VM maintainers obviously.
But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down.
We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter).
All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front).
A real Pharo image is overkill for this as a ton of plugins get involved etc.
The core system should be the same for Pharo/Squeak/... :
VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation
and of course the Slang things (VMMaker-Support and VMMaker-Translation to C).
What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed.
Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you?
Phil
Getting the simulator working in Pharo could be a GSoC project? or is it too advanced? cheers -ben
On Thu, Feb 13, 2014 at 6:19 AM, <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
Ron,
Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue.
The key advantage is that the Smalltalk VM is written in itself.
Now, what do I experience is that it is hard to embark on VM work.
Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle.
The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.
I am not in the league of the VM maintainers obviously.
But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down.
We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter).
All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front).
A real Pharo image is overkill for this as a ton of plugins get involved etc.
The core system should be the same for Pharo/Squeak/... :
VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation
and of course the Slang things (VMMaker-Support and VMMaker-Translation to C).
What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed.
Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you?
Phil
Getting the simulator working in Pharo could be a GSoC project? or is it too advanced?
If you guys would read and contribute to vm-dev you'd already know that someone with no VM experience (tty) just implemented event processing for the simulator window. The simulator only supported the old polling event architecture. So no it's not too advanced. But more importantly why aren't you all discussing vm stuff on the vm forum?
cheers -ben
-- best, Eliot
Well, I just had a look and vm-dev messages weren't coming to me anymore as it looks like there is some spam rejection active somewhere on my address. So, that's why - I hit reply but this was pharo-dev... Phil On Thu, Feb 13, 2014 at 6:40 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Thu, Feb 13, 2014 at 6:19 AM, <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
Ron,
Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue.
The key advantage is that the Smalltalk VM is written in itself.
Now, what do I experience is that it is hard to embark on VM work.
Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle.
The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.
I am not in the league of the VM maintainers obviously.
But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down.
We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter).
All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front).
A real Pharo image is overkill for this as a ton of plugins get involved etc.
The core system should be the same for Pharo/Squeak/... :
VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation
and of course the Slang things (VMMaker-Support and VMMaker-Translation to C).
What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed.
Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you?
Phil
Getting the simulator working in Pharo could be a GSoC project? or is it too advanced?
If you guys would read and contribute to vm-dev you'd already know that someone with no VM experience (tty) just implemented event processing for the simulator window. The simulator only supported the old polling event architecture. So no it's not too advanced. But more importantly why aren't you all discussing vm stuff on the vm forum?
cheers -ben
-- best, Eliot
participants (8)
-
btc＠openinworld.com -
David T. Lewis -
Eliot Miranda -
Esteban Lorenzano -
J. Vuletich (mail lists) -
phil＠highoctane.be -
Ron Teitelbaum -
Stefan Marr