Crypto Plugins on Cog
Locked
 
|
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 the latest with 'oscog' as the initials. All test pass GREEN. Rob |
|
|
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. Levente > > All test pass GREEN. > > Rob > > |
|
|
On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi <[hidden email]> wrote:
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.
best Eliot
|
Pragmas in VMMaker (was: Crypto Plugins on Cog)
|
|
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 |
|
|
++1 (i.e., double-plus-good :-)
FWIW, the main advantage I see when using method tags is that we don't need to carry all of these Object>>var:declareC: methods around. While not a problem for plugins, they can be a real hazzle for inline primitives such as Bitmap>>compress:toByteArray: etc. Cheers, - Andreas On 9/7/2010 9:56 AM, David T. Lewis wrote: > > 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 > > |
|
|
In reply to this post by Levente Uzonyi-2
Sorry for the delay Levente. I finally made time to look into this.
I had to rename the methods because two Classes had the same method names and the gcc linker, I imagine, had problems with it. With my fixes, all four Plugins build with Cog. I looked again, into history and I don't see any category or method comments. What is this about something generating these methods? Why? I am sure there must be a good reason, though I cannot think of one at the moment. Cheers, Rob -------------------------------------------------- From: "Levente Uzonyi" <[hidden email]> Sent: Tuesday, September 07, 2010 2:30 AM To: "The general-purpose Squeak developers list" <[hidden email]> Cc: "Squeak Crypto" <[hidden email]> Subject: Re: [squeak-dev] Crypto Plugins on Cog > 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. > > > Levente > >> >> All test pass GREEN. >> >> Rob >> > > |
|
|
Quoting Rob Withers <[hidden email]>:
> Sorry for the delay Levente. I finally made time to look into this. > > I had to rename the methods because two Classes had the same method > names and the gcc linker, I imagine, had problems with it. With my > fixes, all four Plugins build with Cog. That's strange, because I already compiled the plugins for Cog and I didn't have such issue. Did you try to build the plugins as internal? http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152005.html > > I looked again, into history and I don't see any category or method comments. MD5Plugin >> md5ProcessBuffer: buffer withState: state "This method is generated. See #compileMethods on the class side." ... Also the method's category is "generated". > > What is this about something generating these methods? Why? I am > sure there must be a good reason, though I cannot think of one at > the moment. Just look at the body of this method, and you'll see why. Levente > > Cheers, > Rob > > -------------------------------------------------- > From: "Levente Uzonyi" <[hidden email]> > Sent: Tuesday, September 07, 2010 2:30 AM > To: "The general-purpose Squeak developers list" > <[hidden email]> > Cc: "Squeak Crypto" <[hidden email]> > Subject: Re: [squeak-dev] Crypto Plugins on Cog > >> 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. >> >> >> Levente >> >>> >>> All test pass GREEN. >>> >>> Rob >>> >> >> > > |
|
|
-------------------------------------------------- From: "Levente Uzonyi" <[hidden email]> Sent: Tuesday, September 07, 2010 8:23 PM To: <[hidden email]> Subject: Re: [squeak-dev] Crypto Plugins on Cog > Quoting Rob Withers <[hidden email]>: > >> Sorry for the delay Levente. I finally made time to look into this. >> >> I had to rename the methods because two Classes had the same method >> names and the gcc linker, I imagine, had problems with it. With my >> fixes, all four Plugins build with Cog. > > That's strange, because I already compiled the plugins for Cog and I > didn't have such issue. Did you try to build the plugins as internal? > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152005.html Yes, they were internal. > >> >> I looked again, into history and I don't see any category or method >> comments. > > MD5Plugin >> md5ProcessBuffer: buffer withState: state > "This method is generated. See #compileMethods on the class side." > ... I missed it somehow. I was looking at md5InitializeState. > > Also the method's category is "generated". > >> >> What is this about something generating these methods? Why? I am sure >> there must be a good reason, though I cannot think of one at the moment. > > Just look at the body of this method, and you'll see why. > Yep. How's this correction? processBufferWithStateHeader ^ 'md5ProcessBuffer: buffer withState: state ... Rob > > Levente > >> >> Cheers, >> Rob >> >> -------------------------------------------------- >> From: "Levente Uzonyi" <[hidden email]> >> Sent: Tuesday, September 07, 2010 2:30 AM >> To: "The general-purpose Squeak developers list" >> <[hidden email]> >> Cc: "Squeak Crypto" <[hidden email]> >> Subject: Re: [squeak-dev] Crypto Plugins on Cog >> >>> 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. >>> >>> >>> Levente >>> >>>> >>>> All test pass GREEN. >>>> >>>> Rob >>>> >>> >>> >> >> > > > > > |
|
|
On Tue, 7 Sep 2010, Rob Withers wrote:
> > > -------------------------------------------------- > From: "Levente Uzonyi" <[hidden email]> > Sent: Tuesday, September 07, 2010 8:23 PM > To: <[hidden email]> > Subject: Re: [squeak-dev] Crypto Plugins on Cog > >> Quoting Rob Withers <[hidden email]>: >> >>> Sorry for the delay Levente. I finally made time to look into this. >>> >>> I had to rename the methods because two Classes had the same method names >>> and the gcc linker, I imagine, had problems with it. With my fixes, all >>> four Plugins build with Cog. >> >> That's strange, because I already compiled the plugins for Cog and I didn't >> have such issue. Did you try to build the plugins as internal? >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152005.html > > Yes, they were internal. Well, I can imagine that the linker is unhappy with the same function names in that case. > >> >>> >>> I looked again, into history and I don't see any category or method >>> comments. >> >> MD5Plugin >> md5ProcessBuffer: buffer withState: state >> "This method is generated. See #compileMethods on the class side." >> ... > > I missed it somehow. I was looking at md5InitializeState. > >> >> Also the method's category is "generated". >> >>> >>> What is this about something generating these methods? Why? I am sure >>> there must be a good reason, though I cannot think of one at the moment. >> >> Just look at the body of this method, and you'll see why. >> > > Yep. How's this correction? > > processBufferWithStateHeader > > ^ 'md5ProcessBuffer: buffer withState: state > ... That'll will do it. Note that there's another generated method. Levente > > Rob > >> >> Levente >> >>> >>> Cheers, >>> Rob >>> >>> -------------------------------------------------- >>> From: "Levente Uzonyi" <[hidden email]> >>> Sent: Tuesday, September 07, 2010 2:30 AM >>> To: "The general-purpose Squeak developers list" >>> <[hidden email]> >>> Cc: "Squeak Crypto" <[hidden email]> >>> Subject: Re: [squeak-dev] Crypto Plugins on Cog >>> >>>> 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. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> All test pass GREEN. >>>>> >>>>> Rob >>>>> >>>> >>>> >>> >>> >> >> >> >> >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |