Re: [squeak-dev] Crypto Plugins on Cog

>  
> On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi <[hidden email]> wrote:
>
> > On Sun, 5 Sep 2010, Rob Withers wrote:
> >
> >  I did some rework so that all plugins build on Cog.  This mainly entailed
> >> pulling MD5Plugin from a previous version and renaming several methods
> >> implemented with the same name in MD5Plugin and SHA256Plugin.  The version
> >> is
> >>
> >
> > What was the point of renaming those methods? In MD5Plugin those methods
> > are generated as the category and the method comment states. So renaming
> > them without changing the code that generates those methods is not a good
> > idea.
> > Also the codegenerator should be updated a bit. It should generate code for
> > both litte- and big-endian machines and the C compiler should decide which
> > method to use based on the platform, so the C code can be shared.
> > The current code in the package is generated for 32-bit little-endian
> > machines (it may work for 64-bit but that has to be checked).
> >
> >
> >  the latest with 'oscog' as the initials.
> >>
> >
> > I think that the plugin code (Smalltalk) should be the same for SqueakVM
> > and CogVM, using the non-pragma declarations.
> >
>
> I agree that they should be the same but feel they should /use/ the pragma
> declarations.  We can easily post the pragma declarations support into the
> standard Slang (we should merge Cog's and the standard) and as discussed a
> few weeks ago there really isn't a compelling argument that says one needs
> to be able to run VMMaker in old versions.  That's quite a different
> statement to saying it's not useful to support older VMs; it is.  But the VM
> definition code doesn't need to be backwards-compatible, unless we want to
> be truly shackled.
>

>
> On Tue, Sep 07, 2010 at 09:15:48AM -0700, Eliot Miranda wrote:
>>
>> On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi<[hidden email]>  wrote:
>>
>>> On Sun, 5 Sep 2010, Rob Withers wrote:
>>>
>>>   I did some rework so that all plugins build on Cog.  This mainly entailed
>>>> pulling MD5Plugin from a previous version and renaming several methods
>>>> implemented with the same name in MD5Plugin and SHA256Plugin.  The version
>>>> is
>>>>
>>>
>>> What was the point of renaming those methods? In MD5Plugin those methods
>>> are generated as the category and the method comment states. So renaming
>>> them without changing the code that generates those methods is not a good
>>> idea.
>>> Also the codegenerator should be updated a bit. It should generate code for
>>> both litte- and big-endian machines and the C compiler should decide which
>>> method to use based on the platform, so the C code can be shared.
>>> The current code in the package is generated for 32-bit little-endian
>>> machines (it may work for 64-bit but that has to be checked).
>>>
>>>
>>>   the latest with 'oscog' as the initials.
>>>>
>>>
>>> I think that the plugin code (Smalltalk) should be the same for SqueakVM
>>> and CogVM, using the non-pragma declarations.
>>>
>>
>> I agree that they should be the same but feel they should /use/ the pragma
>> declarations.  We can easily post the pragma declarations support into the
>> standard Slang (we should merge Cog's and the standard) and as discussed a
>> few weeks ago there really isn't a compelling argument that says one needs
>> to be able to run VMMaker in old versions.  That's quite a different
>> statement to saying it's not useful to support older VMs; it is.  But the VM
>> definition code doesn't need to be backwards-compatible, unless we want to
>> be truly shackled.
>>
>
> This topic was covered in a thread on vm-dev here:
> http://lists.squeakfoundation.org/pipermail/vm-dev/2010-July/005077.html
>
> Since that time (July) we have heard no one express an interest in running
> VMMaker in images that do not support pragmas. While I personally prefer
> the non-pragma declarations (probably due to my natural luddite tendencies),
> I think we need to defer to Eliot to cast the deciding vote here.
>
> So one last time - does anyone out there care about running VMMaker on older
> images that do not support Pragmas? If not, then the decision is made and we
> will follow Eliot's lead.
>
> What this means:
>
> The classic SqueakVM in project VMMaker, including all plugins maintained
> in that package, will be updated to use Pragmas exactly as in Cog. This
> will reduce the cosmetic differences between Cog and the traditional
> interpreter, and will make it easier to identify the real differences that
> need to be merged or otherwise addressed.
>
> The old non-pragma declarations should still work, so if you are maintaining
> a plugin outside of the VMMaker project, you will not be forced to change
> the declarations in your package. It will be considered good form if you do,
> but it should not be required.
>
> Dave
>
>