Pragmas in VMMaker (was: Cryptography plugins (was: Re: [squeak-dev] Re: Cog bugs (was Re: Cog on linux))
On Wed, Jul 21, 2010 at 01:45:13AM +0200, Levente Uzonyi wrote:
On Thu, 15 Jul 2010, C. David Shaffer wrote:
Can you send me your Crypto plugin fixes so I can merge them into squeaksource? Thanks!
I uploaded it to http://leves.web.elte.hu/cryptography/CryptographyPlugins-ul.2.mcz . I think the current VMMaker for SqueakVM support pragma declarations, but I'm not sure. If it doesn't, then some changes will have to be reverted. The VMMaker of CogVM is unhappy with the old message-style declarations (#var:type: #var:declareC: #export: etc.).
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
It should be feasible to have the Cog VMMaker handle message send declarations (although I have not tried), but the reverse may not be supportable. If that is the case, then plugins that are intended for use on both SqueakVM and Cog would need to use message-based declarations, at least until such time as we decide to move SqueakVM to use method annotations.
Follow-up discussion concerning method annotations in SqueakVM and Cog VMMaker is probably best moved to the vm-dev list.
Dave
On Tue, 20 Jul 2010, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 01:45:13AM +0200, Levente Uzonyi wrote:
On Thu, 15 Jul 2010, C. David Shaffer wrote:
Can you send me your Crypto plugin fixes so I can merge them into squeaksource? Thanks!
I uploaded it to http://leves.web.elte.hu/cryptography/CryptographyPlugins-ul.2.mcz . I think the current VMMaker for SqueakVM support pragma declarations, but I'm not sure. If it doesn't, then some changes will have to be reverted. The VMMaker of CogVM is unhappy with the old message-style declarations (#var:type: #var:declareC: #export: etc.).
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
That's a totally valid reason to avoid pragmas if the current VMMaker is used with pre-3.9 images. I don't think it's a useful feature, but a real world use-case can convince me.
It should be feasible to have the Cog VMMaker handle message send declarations (although I have not tried), but the reverse may not be supportable. If that is the case, then plugins that are intended for use on both SqueakVM and Cog would need to use message-based declarations, at least until such time as we decide to move SqueakVM to use method annotations.
The Cog VMMaker accepts some plugins with message-based declarations (like the SqueakSSL plugin), but I got some compilation errors because of undefined functions like vardeclareC and missing variables in some plugins (IIRC the FTPlugin was one of them and the DESPlugin was another, but I'm not sure). After fixing a 10-20 methods, I decided to rewrite most plugins.
Levente
Follow-up discussion concerning method annotations in SqueakVM and Cog VMMaker is probably best moved to the vm-dev list.
Dave
On 7/20/2010 7:10 PM, David T. Lewis wrote:
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
But these Squeak images won't run on the generated VM either. There is a point and a time when it's worthwhile to move forward and given that we've just hit a new major version in Squeak it seems quite reasonable to say that the VMMaker 4 series requires Squeak 4 to run on.
Just a thought.
Cheers, - Andreas
On Wed, Jul 21, 2010 at 12:42:06AM -0700, Andreas Raab wrote:
On 7/20/2010 7:10 PM, David T. Lewis wrote:
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
But these Squeak images won't run on the generated VM either. There is a point and a time when it's worthwhile to move forward and given that we've just hit a new major version in Squeak it seems quite reasonable to say that the VMMaker 4 series requires Squeak 4 to run on.
Actually many older images do run on the latest VMs. I frequently run Squeak 3.6 (and sometimes Squeak 2.4) on the latest VM whenever I want to look at older versions of methods to figure out how they were originally intended to work. I do expect these older images to run on newer VMs to the extent possible.
I regularly run VMMaker in a 3.8 image, and I always run that image on the latest generated VM. But the only real reason I do that is to verify some degree of backward compatibility for VMMaker updates, so I don't really know if this matters to anyone else.
Certainly for most of the folks on this list, doing VM work in a recent Squeak, Pharo, or Cuis image is a reasonable expectation. On the other hand, there may still be people who for various reasons prefer to use other images, and it would be nice if the most up to date VMMaker remains loadable in those images where possible.
If anyone on the list *does* know of a need for VMMaker to work on images that do not support pragmas, please speak up now so we do not cause unnecessary problems.
I am also curious about the motivation for using method annotations here. Is it a style preference, or is there a functional benefit?
Dave
On Wed, 21 Jul 2010, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 12:42:06AM -0700, Andreas Raab wrote:
On 7/20/2010 7:10 PM, David T. Lewis wrote:
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
But these Squeak images won't run on the generated VM either. There is a point and a time when it's worthwhile to move forward and given that we've just hit a new major version in Squeak it seems quite reasonable to say that the VMMaker 4 series requires Squeak 4 to run on.
Actually many older images do run on the latest VMs. I frequently run Squeak 3.6 (and sometimes Squeak 2.4) on the latest VM whenever I want to look at older versions of methods to figure out how they were originally intended to work. I do expect these older images to run on newer VMs to the extent possible.
That's a nice feature. I think I didn't try running anything older than 3.6 on the 4.0.x SqueakVM. IIRC some numbered primitives were reused, so I don't expect current VMs to function correctly with older images. I usually run then with their own VMs.
I regularly run VMMaker in a 3.8 image, and I always run that image on the latest generated VM. But the only real reason I do that is to verify some degree of backward compatibility for VMMaker updates, so I don't really know if this matters to anyone else.
Certainly for most of the folks on this list, doing VM work in a recent Squeak, Pharo, or Cuis image is a reasonable expectation. On the other hand, there may still be people who for various reasons prefer to use other images, and it would be nice if the most up to date VMMaker remains loadable in those images where possible.
If anyone on the list *does* know of a need for VMMaker to work on images that do not support pragmas, please speak up now so we do not cause unnecessary problems.
I am also curious about the motivation for using method annotations here. Is it a style preference, or is there a functional benefit?
I think the biggest benefit is the separation of declarations and slang code.
Levente
Dave
On Wed, Jul 21, 2010 at 6:56 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jul 21, 2010 at 12:42:06AM -0700, Andreas Raab wrote:
On 7/20/2010 7:10 PM, David T. Lewis wrote:
The current VMMaker for SqueakVM does not use or support pragmas (method annotations). Converting to pragmas makes VMMaker unloadable in older Squeak images.
But these Squeak images won't run on the generated VM either. There is a point and a time when it's worthwhile to move forward and given that we've just hit a new major version in Squeak it seems quite reasonable to say that the VMMaker 4 series requires Squeak 4 to run on.
Actually many older images do run on the latest VMs. I frequently run Squeak 3.6 (and sometimes Squeak 2.4) on the latest VM whenever I want to look at older versions of methods to figure out how they were originally intended to work. I do expect these older images to run on newer VMs to the extent possible.
I regularly run VMMaker in a 3.8 image, and I always run that image on the latest generated VM. But the only real reason I do that is to verify some degree of backward compatibility for VMMaker updates, so I don't really know if this matters to anyone else.
Certainly for most of the folks on this list, doing VM work in a recent Squeak, Pharo, or Cuis image is a reasonable expectation. On the other hand, there may still be people who for various reasons prefer to use other images, and it would be nice if the most up to date VMMaker remains loadable in those images where possible.
I don't see the rationale. If one wants to produce a VM for an older image I don't see why one needs to be able to run the VMMaker in that image. What am I missing?
If anyone on the list *does* know of a need for VMMaker to work on images that do not support pragmas, please speak up now so we do not cause unnecessary problems.
I am also curious about the motivation for using method annotations here. Is it a style preference, or is there a functional benefit?
They're much neater in that they need no associated implementation, and in the VMMaker's case since they're purely used for communicating with Slang that's goodness (I think pragmas having implementations is a good thing in a Smalltalk context, e.g. preferences, menu building etc). It means the simulator doesn't execute them. It means less work for Slang to extract them. They're much easier to browse and analyse because the arguments are immediately available; with messages in bytecode one needs to compile the method and walk the parse tree to extract arguments.
I added quite a few pragmas, doNotGenerate, doNotGenerate: api api: asmLabel: cmacro: volatile, and it was much easier to do than the fake method in object, parse tree walk approach necessitated by the old scheme. In short, leaner 'n meaner.
But the Slang in Cog does support the older source annotations. TMethod & SmartSyntaxPluginTMethod recordDeclarations still walk the parse tree to check for old annotations, so the Cog Slang should, fingers crossed, still translate the current VMMaker Interpreter. That would be a worth-while experiment to see if it produces a functional interpreter.
If you do think of moving forward to pragmas I have some scripts I used to convert the VMMaker to pragmas wen I started on Cog, but I think Lukas' Squeak/Pharo rewrite editor from the refactoring browser is a much better way of doing it. I've recently taken the Cog interpreter out from under ObjectMemory using Lukas' fork of the rewrite editor. Let me know and I can lend a hand developing a script to convert from null messages to pragmas.
best, Eliot
Dave
On Wed, Jul 21, 2010 at 07:48:22PM -0700, Eliot Miranda wrote:
On Wed, Jul 21, 2010 at 6:56 PM, David T. Lewis lewis@mail.msen.com wrote:
Certainly for most of the folks on this list, doing VM work in a recent Squeak, Pharo, or Cuis image is a reasonable expectation. On the other hand, there may still be people who for various reasons prefer to use other images, and it would be nice if the most up to date VMMaker remains loadable in those images where possible.
I don't see the rationale. If one wants to produce a VM for an older image I don't see why one needs to be able to run the VMMaker in that image. What am I missing?
I sincerely do not know. It may not matter to anyone at all, in which case it will be best to move SqueakVM the pragma declarations. But if it *does* matter, I want to ask and find out about it now, rather than try to undo it later.
If anyone on the list *does* know of a need for VMMaker to work on images that do not support pragmas, please speak up now so we do not cause unnecessary problems.
I am also curious about the motivation for using method annotations here. Is it a style preference, or is there a functional benefit?
They're much neater in that they need no associated implementation, and in the VMMaker's case since they're purely used for communicating with Slang that's goodness (I think pragmas having implementations is a good thing in a Smalltalk context, e.g. preferences, menu building etc). It means the simulator doesn't execute them. It means less work for Slang to extract them. They're much easier to browse and analyse because the arguments are immediately available; with messages in bytecode one needs to compile the method and walk the parse tree to extract arguments.
I added quite a few pragmas, doNotGenerate, doNotGenerate: api api: asmLabel: cmacro: volatile, and it was much easier to do than the fake method in object, parse tree walk approach necessitated by the old scheme. In short, leaner 'n meaner.
But the Slang in Cog does support the older source annotations. TMethod & SmartSyntaxPluginTMethod recordDeclarations still walk the parse tree to check for old annotations, so the Cog Slang should, fingers crossed, still translate the current VMMaker Interpreter. That would be a worth-while experiment to see if it produces a functional interpreter.
If you do think of moving forward to pragmas I have some scripts I used to convert the VMMaker to pragmas wen I started on Cog, but I think Lukas' Squeak/Pharo rewrite editor from the refactoring browser is a much better way of doing it. I've recently taken the Cog interpreter out from under ObjectMemory using Lukas' fork of the rewrite editor. Let me know and I can lend a hand developing a script to convert from null messages to pragmas.
Thanks for the explanation and for the offer to help. Let's let the matter rest for a week or two and see if anyone has any objections, then do the change. If you can provide the conversion scripts that you used for Cog, that would be great.
Dave
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
Levente Uzonyi