[Pharo-project] Compiler compile:
Hi list, consider this code: c := Compiler compile: 'meth "bla" ^ 2'. Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth". This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though. Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system: I changed Compiler>compile: to do the following: class side: compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass instance side: compiledMethodFor: textOrStream onClass: aClass | methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:. Cheers, Niko
+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method 2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Hi list,
consider this code:
c := Compiler compile: 'meth "bla" Â ^ 2'.
Try using c:= Compiler new compiledMethodFor: ... The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class: MyClass compile: ....
Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth".
This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though.
Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system:
I changed Compiler>compile: to do the following: class side:
compile: aString onClass: aClass     ^ self new compiledMethodFor: aString onClass: aClass
instance side:
compiledMethodFor: textOrStream onClass: aClass
    | methodNode method |     class := aClass.     self from: textOrStream class: class context: nil notifying: nil.     methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed'].     method := methodNode generate: #(0 0 0 0).     self interactive ifTrue:         [method := method copyWithTempsFromMethodNode: methodNode].     ^method
This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:.
Cheers,
Niko
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+1 too. Fewer side-effects and/or more side-effect free refactoring is better. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile:
+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method
2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Hi list,
consider this code:
c := Compiler compile: 'meth "bla" ^ 2'.
Try using
c:= Compiler new compiledMethodFor: ...
The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class:
MyClass compile: ....
Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth".
This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though.
Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system:
I changed Compiler>compile: to do the following: class side:
compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass
instance side:
compiledMethodFor: textOrStream onClass: aClass
| methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method
This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:.
Cheers,
Niko
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested. Niko On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote:
+1 too. Fewer side-effects and/or more side-effect free refactoring is better.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile:
+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method
2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Hi list,
consider this code:
c := Compiler compile: 'meth "bla" ^ 2'.
Try using
c:= Compiler new   compiledMethodFor: ...
The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class:
MyClass compile: ....
Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth".
This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though.
Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system:
I changed Compiler>compile: to do the following: class side:
compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass
instance side:
compiledMethodFor: textOrStream onClass: aClass
| methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method
This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:.
Cheers,
Niko
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/3 Lukas Renggli <renggli@gmail.com>:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
You are right , of course. But inner API should be simplified. For instance, take a look at compiler invocation here: self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. i really don't understand, why compiler would be interested in a method's category? What is the purpose of passing this extra info to compiler? The main purpose of compiler is to produce the CompiledMethod instance, and compiler should not care about anything related to installation of the resulting method into class and its categorization.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I think that what we should get is Compiler compile: 'text' with: aCompilingContext aCompilingContext should hold the information about where: in classified: failing noytfying .... Stef On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote:
2009/11/3 Lukas Renggli <renggli@gmail.com>:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
You are right , of course.
But inner API should be simplified. For instance, take a look at compiler invocation here:
self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock.
i really don't understand, why compiler would be interested in a method's category? What is the purpose of passing this extra info to compiler? The main purpose of compiler is to produce the CompiledMethod instance, and compiler should not care about anything related to installation of the resulting method into class and its categorization.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I think that what we should get is
Compiler compile: 'text' with: aCompilingContext
aCompilingContext should hold the information about     where: in     classified:     failing     noytfying     ....
Since i tried to get rid of that in Moebius, it wont hurt if i share my experience here :) Currently i end up with following public entry points for parsing and compiling: parse: sourceStream in: environment requestor: aRequestor parseDoIt: sourceStream in: environment requestor: aRequestor compile: aSourceStream in: env requestor: aRequestor compileDoIt: sourceStream in: environment requestor: aRequestor the requestor object in one who responsible for handling errors, warnings and notifications etc. and environment object is one who responsible for providing essentials, needed for a method where it will be installed & work, like resolving variables bindings etc. In most cases, the environment is some class. But there are things like doits in specific context during debugging, where environment object should 'see' not only the variables of receiver, but also temporary variables, declared in current context. These two objects + source code is enough to parse & produce a compiled method. I'm also had a variation, where Requestor was responsible for answering whether incoming source is doit or not (by having #noPattern method), but then i found that it would be more convenient to designate such intent more directly , and use different selector instead of requiring the requestor to implement additional protocol ('noPattern' method).
Stef
On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote:
2009/11/3 Lukas Renggli <renggli@gmail.com>:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
You are right , of course.
But inner API should be simplified. For instance, take a look at compiler invocation here:
self compilerClass new                compile: code                in: self                classified: category                notifying: requestor                ifFail: failBlock.
i really don't understand, why compiler would be interested in a method's category? What is the purpose of passing this extra info to compiler? The main purpose of compiler is to produce the CompiledMethod instance, and compiler should not care about anything related to installation of the resulting method into class and its categorization.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Every project needs to have sacred cows that may not be tipped :D. Well, alright, in case that we can't agree on renaming, how about my original proposal, which left everything the way it was and only added the class-side compile:onClass: method to Compiler? Possibly sided by compile:onClass:ifFail: Cheers, Niko On Tue, Nov 3, 2009 at 10:23 PM, Lukas Renggli <renggli@gmail.com> wrote:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Niko what would be cool is that you design a new interface so that we can see how it feels and we integrate it. rename is for simple and fast stuff. Migrating is for used software. :) On Nov 4, 2009, at 10:20 AM, Niko Schwarz wrote:
Every project needs to have sacred cows that may not be tipped :D.
Well, alright, in case that we can't agree on renaming, how about my original proposal, which left everything the way it was and only added the class-side compile:onClass: method to Compiler? Possibly sided by compile:onClass:ifFail:
Cheers,
Niko
On Tue, Nov 3, 2009 at 10:23 PM, Lukas Renggli <renggli@gmail.com> wrote:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What would be nice is to propose a nice interface (based on compiler context to remove this argument plague) Then to slowly migrate to it using deprecation. Stef On Nov 3, 2009, at 10:23 PM, Lukas Renggli wrote:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Things is not so easy as it looks at first sight. The problem here, i think, that compiling process is overburden with different other functionality, which not related to compiling per se, but related to recording the method source, and error handling. The compilation should be broken on stages: - creating a compiled method instance (Compiler responsibility) - installing method into class (Behavior responsibility) - announcing the change (system-change framework responsibility) the facilities which should log the change should live in separate layer, and listen for system change announcement, as well as any other tools. Because, if you look at currently the number of selectors which start from 'compile:' #compile: #compile:class: #compile:classified: #compile:classified:notifying: #compile:classified:notifying:trailer:ifFail: #compile:classified:withStamp:notifying: #compile:classified:withStamp:notifying:logSource: #compile:classified:withStamp:notifying:logSource:inClass: #compile:in:classified:notifying:ifFail: #compile:in:notifying:ifFail: #compile:in:requestor: #compile:notifying: #compile:selector: its really terrifying... 2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Niko
On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote:
+1 too. Fewer side-effects and/or more side-effect free refactoring is better.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile:
+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method
2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Hi list,
consider this code:
c := Compiler compile: 'meth "bla" ^ 2'.
Try using
c:= Compiler new   compiledMethodFor: ...
The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class:
MyClass compile: ....
Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth".
This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though.
Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system:
I changed Compiler>compile: to do the following: class side:
compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass
instance side:
compiledMethodFor: textOrStream onClass: aClass
| methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method
This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:.
Cheers,
Niko
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
There are a lot of things that are worse in the Squeak image. I'm not saying this is good and should not improve, but if those selectors are spread over suitable classes (acting as entry points) with some convenience methods among the list, it's not necessarily that much worse than Dolphin's organization of it. That's a lot of "ifs" though. +1 (and then some) on the idea of making it easy to create a compiled method w/o installing it, and for making it clear (probably by where the methods are placed the selector/arguments) which versions do nothing but compile, and which versions install the method if successful. Clear comments won't hurt either. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, November 03, 2009 4:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Compiler compile: Things is not so easy as it looks at first sight. The problem here, i think, that compiling process is overburden with different other functionality, which not related to compiling per se, but related to recording the method source, and error handling. The compilation should be broken on stages: - creating a compiled method instance (Compiler responsibility) - installing method into class (Behavior responsibility) - announcing the change (system-change framework responsibility) the facilities which should log the change should live in separate layer, and listen for system change announcement, as well as any other tools. Because, if you look at currently the number of selectors which start from 'compile:' #compile: #compile:class: #compile:classified: #compile:classified:notifying: #compile:classified:notifying:trailer:ifFail: #compile:classified:withStamp:notifying: #compile:classified:withStamp:notifying:logSource: #compile:classified:withStamp:notifying:logSource:inClass: #compile:in:classified:notifying:ifFail: #compile:in:notifying:ifFail: #compile:in:requestor: #compile:notifying: #compile:selector: its really terrifying... 2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested.
Niko
On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote:
+1 too. Fewer side-effects and/or more side-effect free refactoring +is better.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile:
+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method
2009/11/3 Niko Schwarz <niko.schwarz@googlemail.com>:
Hi list,
consider this code:
c := Compiler compile: 'meth "bla" ^ 2'.
Try using
c:= Compiler new   compiledMethodFor: ...
The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class:
MyClass compile: ....
Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth".
This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though.
Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system:
I changed Compiler>compile: to do the following: class side:
compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass
instance side:
compiledMethodFor: textOrStream onClass: aClass
| methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method
This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:.
Cheers,
Niko
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Gary Chambers -
Igor Stasenko -
Lukas Renggli -
Niko Schwarz -
Schwab,Wilhelm K -
Stéphane Ducasse