Why is the simulator dependent on VMMaker? curious.
Tim Rowledge tim@sumeru.stanford.edu wrote:
If someone can point me to where the code is I'll check out the simulator changes so we can at least get _them_ done.
http://aspn.activestate.com/ASPN/Mail/Message/squeak/1662509
OK, so far as I can see _none_ of this goes in the basic image and the only issues are a) remembering to rename a couple of things since I am proposing renaming Test* to SmartSyntax* since it is a little less meaningless. b) deciding whether the simulator stuff ought to be dropped in with the VMMaker package or be kept as a separate but dependent package.
This means that this punchlist item now also depends on DeclarativePools :-)
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Got a life, but wasn't sure what to do with it. _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Why is the simulator dependent on VMMaker? curious.
Helloho ;-) The VM (e.g., the actual code seen in ObjectMemory and Interpreter) _are_ the simulator. What the simulator classes do is merely providing a few methods for stuff that we otherwise assume the C compiler does (longAt: ...) including nasty things that we don't have to worry about in Squeak (endianness anyone?).
It's the "living spec" thing all along. If you have VMMaker you've got the VM and you can't simulate the interpreter without actually having it ;-)
Amused, - Andreas
Am Donnerstag, 26.06.03 um 20:44 Uhr schrieb Andreas Raab:
Why is the simulator dependent on VMMaker? curious.
Helloho ;-) The VM (e.g., the actual code seen in ObjectMemory and Interpreter) _are_ the simulator. What the simulator classes do is merely providing a few methods for stuff that we otherwise assume the C compiler does (longAt: ...) including nasty things that we don't have to worry about in Squeak (endianness anyone?).
It's the "living spec" thing all along.
Absolutely. And folks who need to know do know this ;-) But ...
If you have VMMaker you've got the VM
... which is not obvious at all. At least I would have expected the "VMMaker" package to contain the VMMaker tool, not the VM source code itself.
and you can't simulate the interpreter without actually having it ;-)
Of course. It's just a naming confusion, but I would find it more intuitive if there was a separate "VM" package containing ObjectMemory and Interpreter, as well as the standard plugins.
-- Bert
PS: I wouldn't even mind if the "VM" package contained the VMMaker tool, too. Maybe we should just rename it?
Bert Freudenberg bert@isg.cs.uni-magdeburg.de wrote:
If you have VMMaker you've got the VM
... which is not obvious at all. At least I would have expected the "VMMaker" package to contain the VMMaker tool, not the VM source code itself.
and you can't simulate the interpreter without actually having it ;-)
Of course. It's just a naming confusion, but I would find it more intuitive if there was a separate "VM" package containing ObjectMemory and Interpreter, as well as the standard plugins.
-- Bert
PS: I wouldn't even mind if the "VM" package contained the VMMaker tool, too. Maybe we should just rename it?
That would be fine with me. I did intend at one point to make two separate packages (VM & VMMaker) but since the VM code is pretty much pointless without the tools to use it I thought better of it. The only real cost would be finding all those places that refer to the VMMaker package and updating them properly. Can SM do redirection?
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System
Tim,
That would be fine with me. I did intend at one point to make two separate packages (VM & VMMaker) but since the VM code is pretty much pointless without the tools to use it I thought better of it. The only real cost would be finding all those places that refer to the VMMaker package and updating them properly. Can SM do redirection?
You should be able to simply rename it (as packages use UUIDs as refs for the most part). In fact, if you want to do it, I'd say definitely do it before 3.6 gets finalized and choose a nice name such as "Squeak Virtual Machine" or somesuch ;-)
In any case, I agree with your reasoning that for the most part the VM is pretty useless without VMMaker and I don't see much of a reason to separate the two.
Cheers, - Andreas
Hi Tim,
That would be fine with me. I did intend at one point to make two separate packages (VM & VMMaker)...
You should be able to simply rename it (as packages use UUIDs as refs for the most part). In fact, if you want to do it, I'd say definitely do it before 3.6 gets finalized and choose a nice name such as "Squeak Virtual Machine" or somesuch ;-)
If VMMaker is renamed as "Squeak Virtual Machine" (or somesuch, like SqVM ;-) then it might tickle the VM maintainers to have a 'really closer' look at it.
Then, who knows, there may be even an anouncement for 'PCP' (no, it's not 'Peer Cleans Peer', but , 'Plugins Cleaning Project' ;-)
... but since the VM code is pretty much pointless without the tools to use it I thought better of it.
In any case, I agree with your reasoning that for the most part the VM is pretty useless without VMMaker and I don't see much of a reason to separate the two.
And we can even make VMMaker isa Interpreter (can we, can we, can we with a cherry on top ;-)
Cheers,
PhiHo.
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "'Discussing the Squeak Foundation'" squeakfoundation@lists.squeakfoundation.org Sent: Thursday, June 26, 2003 5:36 PM Subject: RE: [Squeakfoundation]re: reviewing the simulator fixes
Tim,
That would be fine with me. I did intend at one point to make two separate packages (VM & VMMaker) but since the VM code is pretty much pointless without the tools to use it I thought better of it. The only real cost would be finding all those places that refer to the VMMaker package and updating them properly. Can SM do redirection?
You should be able to simply rename it (as packages use UUIDs as refs for the most part). In fact, if you want to do it, I'd say definitely do it before 3.6 gets finalized and choose a nice name such as "Squeak Virtual Machine" or somesuch ;-)
In any case, I agree with your reasoning that for the most part the VM is pretty useless without VMMaker and I don't see much of a reason to
separate
the two.
Cheers,
- Andreas
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi guys!
Quoting Tim Rowledge tim@sumeru.stanford.edu:
Bert Freudenberg bert@isg.cs.uni-magdeburg.de wrote:
[SNIP]
PS: I wouldn't even mind if the "VM" package contained the VMMaker tool, too. Maybe we should just rename it?
That would be fine with me. I did intend at one point to make two separate packages (VM & VMMaker) but since the VM code is pretty much pointless without the tools to use it I thought better of it. The only real cost would be finding all those places that refer to the VMMaker package and updating them properly. Can SM do redirection?
You can just change the name of the package!
All references should be by UUID unless we are talking about text mentioning the package or URLs like these (but I don't think many people use these urls - most use the UUID based ones. And SM itself surely don't mind the package changing the name. Unless there is a bug somewhere.):
http://map1.squeakfoundation.org/sm/packagebyname/vmmaker
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Bert Freudenberg wrote:
Of course. It's just a naming confusion, but I would find it more intuitive if there was a separate "VM" package containing ObjectMemory and Interpreter, ...
There will be absolutely no confusion if we have packages like 'Interpreter', 'ObjectMemory' (even if Intepreter isa ObjectMemory ;-)
... as well as the standard plugins.
and one for each equal plugin (of course some are more equal ;-)
And one for all the stuckins (until they are liberated ;-)
Cheers,
PhiHo.
----- Original Message ----- From: "Bert Freudenberg" bert@isg.cs.uni-magdeburg.de To: "Discussing the Squeak Foundation" squeakfoundation@lists.squeakfoundation.org Sent: Thursday, June 26, 2003 4:48 PM Subject: Re: [Squeakfoundation]re: reviewing the simulator fixes
Am Donnerstag, 26.06.03 um 20:44 Uhr schrieb Andreas Raab:
Why is the simulator dependent on VMMaker? curious.
Helloho ;-) The VM (e.g., the actual code seen in ObjectMemory and Interpreter) _are_ the simulator. What the simulator classes do is merely providing a few methods for stuff that we otherwise assume the C compiler does (longAt: ...) including nasty things that we don't have to worry about in Squeak (endianness anyone?).
It's the "living spec" thing all along.
Absolutely. And folks who need to know do know this ;-) But ...
If you have VMMaker you've got the VM
... which is not obvious at all. At least I would have expected the "VMMaker" package to contain the VMMaker tool, not the VM source code itself.
and you can't simulate the interpreter without actually having it ;-)
Of course. It's just a naming confusion, but I would find it more intuitive if there was a separate "VM" package containing ObjectMemory and Interpreter, as well as the standard plugins.
-- Bert
PS: I wouldn't even mind if the "VM" package contained the VMMaker tool, too. Maybe we should just rename it?
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Daniel Vainsencher -
Göran Hultgren -
PhiHo Hoang -
Tim Rowledge