- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Toon Verwaest

> I guess it would be cool to transform it to message like > > 'self undefinedVariableAccess: #varName' > and: > 'self undefinedVariableAccess: #varName value: val' > for assignments. > > Then later, when given method will run, it will trigger an error and > developer can fix it in debugger. > > (Unless, of course you simply raise an error during (re)compilation > when given ivar removed from class). That's the plan yes. Niko is working on that part now. I guess for now we might keep it on Eliot's proposal of just transforming to an undefined field access; but we'll see. One of the ideas is of course to collect the methods that get affected by a change and report back to the user; just like with all other types of errors that can occur during class modification. We have a pretty cool model already so it's becoming increasingly easy to install such hooks. I hate self error: 'your class is invalid because of something somewhere', and we'll get that all fixed! > If you create a copy of method, copy the method's trailer. > > > trailer := oldMethod trailer. > > newMethod := CompiledMethod newBytes: ... trailerBytes: ***trailer*** > nArgs: ... nTemps: .. nStack: ... nLits: ... primitive: ... It seems that the opal compiler has a compiledMethodWith: trailer. Useful ;) I just had to set the methodClass: and selector: myself. Fair enough. @Eliot thanks for the hints. I'll take it into account to make the recompilation complete. If Niko doesn't finish it this evening I'll probably do it tomorrow... I'm in the need of a small break :) Ignoring the fact that it doesn't support removing instance variables yet, it would very well already. Pretty cool to see methods updated on bytecode level without slow recompilation. Aaah... rewriting the classbuilder is starting to pay off :) And then on to stateful traits. Just for credits: I'm working together with Camillo Bruni and Niko Schwarz on this. cheers, Toon

March 27, 2011

[Pharo-project] A stupid magritte question :(

by StÃ©phane Ducasse

Hi all and (lukas in particular) I have an object which hold a list of strings and I would like to describe it using magritte so I thought that I should use a MAContainer. But how should I specify the fact that the elements are of a specific class? Stef

March 27, 2011

Re: [Pharo-project] [Seaside] rack/wsgi/ring for smalltalk

by Sven Van Caekenberghe

On 27 Mar 2011, at 19:13, Sean Allen wrote: > Is there a smalltalk equivalent for rack/wsgi/ring etc out there? > > I have an idea I'm going to play with that would be best served by > building on something like rack. > If there isn't one already, I'll implement one first and then move on > to the idea that builds on it. > If there is one, I'd rather see if it meets my needs and use it. > > Any pointers to anything appreciated. > > For anyone not familiar with rack et al: > > They are basically' middleware' layers providing a standard interface > between webservers and applications. > Middleware is a little deceptive... a better description might be that > it is an interface that allows you to > hook into between a webserver and other end points by either hooking > up an application or middleware > ( authentication, file serving ) that can be composed together as part > of a specific application. > > http://rack.rubyforge.org/ > https://github.com/mmcgrana/ring > http://www.wsgi.org/wsgi/ Might be cool and useful. I guess that Seaside's WAServerAdaptor concept comes very close. It has the advantage that it's proven in the field, supporting many servers in different Smalltalk implementations. But maybe you already knew this. Sven

March 27, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by StÃ©phane Ducasse

Hi toon this is a good news. I would really like to see Opal taking off the ground. Stef On Mar 27, 2011, at 7:14 PM, Toon Verwaest wrote: > For whoever might care: I rewrote / fixed the Opal decompiler. > > Sorry about me being a bit bad... my only test is this: > > CompiledMethod allInstances collect: [ :m | > (OCBytecodeDecompiler new decompile: m) compiledMethod ] > > At least on the helvetia image that doesn't give any errors :) > > On to hooking it in with my new classbuilder and MethodModification model to apply bytecode rewriting for hyperfast class changes. I'll be back in an hour ;P > > cheers, > Toon >

March 27, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Eliot Miranda

On Sun, Mar 27, 2011 at 10:46 AM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > Does anybody know what I'm supposed to transform accesses to removed > instance variables into? Updating indexes of instance variables already > works. > In the current model it should convert into a reference to an entry in Undeclared. i.e. it should do exactly what removing an inst var from a class def does. The sequence is delete an inst var from a class, reshape the instances of the class without the inst var, recompile the methods of the class. In the last step any references to the inst var name in source will not be resolved in the class definition and will hence result in being compiled as undeclared var refs. There are edge-cases. If the inst var name was masking an inst var of the same name in a superclass it would get resolved to that inst var. But the current class builder (rightly) disallows this and so it can be discounted. If the inst var name was masking a global of the same name in a class pool or shared pool it would get resolved to that. So the correct approach is to bind names with the same semantics that the compiler uses to binds names. best, Eliot > And what data do I have to copy over to the new method so that it keeps a > pointer to the original source, the class pointer and the selector? > > cheers, > Toon > > > On 03/27/2011 07:33 PM, Igor Stasenko wrote: > >> On 27 March 2011 19:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >> >>> For whoever might care: I rewrote / fixed the Opal decompiler. >>> >>> Sorry about me being a bit bad... my only test is this: >>> >>> CompiledMethod allInstances collect: [ :m | >>> (OCBytecodeDecompiler new decompile: m) compiledMethod ] >>> >>> At least on the helvetia image that doesn't give any errors :) >>> >>> On to hooking it in with my new classbuilder and MethodModification model >>> to >>> apply bytecode rewriting for hyperfast class changes. >>> >> I'll be back in an hour ;P >> >> and bring a new compiler/decompiler for us this time :) >> >> cheers, >>> Toon >>> >>> >>> >> >> > >

March 27, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Igor Stasenko

On 27 March 2011 19:46, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > Does anybody know what I'm supposed to transform accesses to removed > instance variables into? Updating indexes of instance variables already > works. > I guess it would be cool to transform it to message like 'self undefinedVariableAccess: #varName' and: 'self undefinedVariableAccess: #varName value: val' for assignments. Then later, when given method will run, it will trigger an error and developer can fix it in debugger. (Unless, of course you simply raise an error during (re)compilation when given ivar removed from class). > And what data do I have to copy over to the new method so that it keeps a > pointer to the original source, the class pointer and the selector? > If you create a copy of method, copy the method's trailer. trailer := oldMethod trailer. newMethod := CompiledMethod newBytes: ... trailerBytes: ***trailer*** nArgs: ... nTemps: .. nStack: ... nLits: ... primitive: ... > cheers, > Toon > > On 03/27/2011 07:33 PM, Igor Stasenko wrote: >> >> On 27 March 2011 19:14, Toon Verwaest<toon.verwaest(a)gmail.com> Â wrote: >>> >>> For whoever might care: I rewrote / fixed the Opal decompiler. >>> >>> Sorry about me being a bit bad... my only test is this: >>> >>> CompiledMethod allInstances collect: [ :m | >>> Â Â (OCBytecodeDecompiler new decompile: m) compiledMethod ] >>> >>> At least on the helvetia image that doesn't give any errors :) >>> >>> On to hooking it in with my new classbuilder and MethodModification model >>> to >>> apply bytecode rewriting for hyperfast class changes. >> >> Â I'll be back in an hour ;P >> >> and bring a new compiler/decompiler for us this time :) >> >>> cheers, >>> Toon >>> >>> >> >> > > > -- Best regards, Igor Stasenko AKA sig.

March 27, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Toon Verwaest

Does anybody know what I'm supposed to transform accesses to removed instance variables into? Updating indexes of instance variables already works. And what data do I have to copy over to the new method so that it keeps a pointer to the original source, the class pointer and the selector? cheers, Toon On 03/27/2011 07:33 PM, Igor Stasenko wrote: > On 27 March 2011 19:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >> For whoever might care: I rewrote / fixed the Opal decompiler. >> >> Sorry about me being a bit bad... my only test is this: >> >> CompiledMethod allInstances collect: [ :m | >> (OCBytecodeDecompiler new decompile: m) compiledMethod ] >> >> At least on the helvetia image that doesn't give any errors :) >> >> On to hooking it in with my new classbuilder and MethodModification model to >> apply bytecode rewriting for hyperfast class changes. > I'll be back in an hour ;P > > and bring a new compiler/decompiler for us this time :) > >> cheers, >> Toon >> >> > >

March 27, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Igor Stasenko

On 27 March 2011 19:14, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > For whoever might care: I rewrote / fixed the Opal decompiler. > > Sorry about me being a bit bad... my only test is this: > > CompiledMethod allInstances collect: [ :m | > Â Â (OCBytecodeDecompiler new decompile: m) compiledMethod ] > > At least on the helvetia image that doesn't give any errors :) > > On to hooking it in with my new classbuilder and MethodModification model to > apply bytecode rewriting for hyperfast class changes. I'll be back in an hour ;P and bring a new compiler/decompiler for us this time :) > > cheers, > Toon > > -- Best regards, Igor Stasenko AKA sig.

March 27, 2011

[Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by Toon Verwaest

For whoever might care: I rewrote / fixed the Opal decompiler. Sorry about me being a bit bad... my only test is this: CompiledMethod allInstances collect: [ :m | (OCBytecodeDecompiler new decompile: m) compiledMethod ] At least on the helvetia image that doesn't give any errors :) On to hooking it in with my new classbuilder and MethodModification model to apply bytecode rewriting for hyperfast class changes. I'll be back in an hour ;P cheers, Toon

March 27, 2011

[Pharo-project] rack/wsgi/ring for smalltalk

by Sean Allen

Is there a smalltalk equivalent for rack/wsgi/ring etc out there? I have an idea I'm going to play with that would be best served by building on something like rack. If there isn't one already, I'll implement one first and then move on to the idea that builds on it. If there is one, I'd rather see if it meets my needs and use it. Any pointers to anything appreciated. For anyone not familiar with rack et al: They are basically' middleware' layers providing a standard interface between webservers and applications. Middleware is a little deceptive... a better description might be that it is an interface that allows you to hook into between a webserver and other end points by either hooking up an application or middleware ( authentication, file serving ) that can be composed together as part of a specific application. http://rack.rubyforge.org/ https://github.com/mmcgrana/ring http://www.wsgi.org/wsgi/

March 27, 2011