Pragmas in VMMaker (was: Cryptography plugins (was: Re: [squeak-dev] Re: Cog bugs (was Re: Cog on linux))

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

Pragmas in VMMaker (was: Cryptography plugins (was: Re: [squeak-dev] Re: Cog bugs (was Re: Cog on linux))

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins (was: Re: [squeak-dev] Re: Cog bugs (was Re: Cog on linux))

Levente Uzonyi-2
 
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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins

Andreas.Raab
In reply to this post by David T. Lewis
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins

Levente Uzonyi-2
 
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins

Eliot Miranda-2
In reply to this post by David T. Lewis
 


On Wed, Jul 21, 2010 at 6:56 PM, David T. Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker (was: Cryptography plugins

David T. Lewis
 
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 <[hidden email]> 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