[Pharo-project] type-inference: it works!
Load the attached ChangeSets: first Ti-Engine and then Ti-Support. You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed. TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} " TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}" TiSystem current explore. Analysing 'Display boundingBox' shows a couple of surprises: 1. The code never goes through the #new method (it creates objects using #basicNew and #@) 2. Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised. I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001... Cheers, Francisco
cool Stef On Mar 30, 2012, at 12:47 AM, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: ⢠The code never goes through the #new method (it creates objects using #basicNew and #@)
how do you see that with the explorer?
⢠Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
Hi Francisco, I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true? Cheers, Alexandre On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
No unit tests, sorry... Is not profiling, it's abstract intrepretation using types instead of objects. - Francisco On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ah okays. Have you made some comparison with the result of Roel Typer? That would be an interesting point to compare with. cheers, Alexandre On 30 Mar 2012, at 09:33, Francisco Garau wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I think they are not comparable. They both try to do Type-Inference. But... what is a Type? Roel Typer works backwards. My TiEngine works forwards. Roel Typer works backwards because it starts analysing a method a finds a message send, lets say "anObject setup". It then asks the question, who implements the method #setup and if it finds 13 different classes, then those are the "Type" of the anObject. My TiEngine starts executing code without actually executing anything. It simulates execution making sure it goes through all the possible execution paths. That's is not always possible, so some compromise should be made. Reflection is the killer of any sort of static analysis. - Francisco On 30 March 2012 17:17, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Ah okays. Have you made some comparison with the result of Roel Typer? That would be an interesting point to compare with.
cheers, Alexandre
On 30 Mar 2012, at 09:33, Francisco Garau wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
1. The code never goes through the #new method (it creates objects using #basicNew and #@) 2. Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ti is an abstract interpreter from your description. On Mar 30, 2012, at 8:20 PM, Francisco Garau wrote:
I think they are not comparable.
They both try to do Type-Inference. But... what is a Type?
Roel Typer works backwards. My TiEngine works forwards.
Roel Typer works backwards because it starts analysing a method a finds a message send, lets say "anObject setup". It then asks the question, who implements the method #setup and if it finds 13 different classes, then those are the "Type" of the anObject.
My TiEngine starts executing code without actually executing anything. It simulates execution making sure it goes through all the possible execution paths. That's is not always possible, so some compromise should be made.
Reflection is the killer of any sort of static analysis.
- Francisco
On 30 March 2012 17:17, Alexandre Bergel <alexandre.bergel@me.com> wrote: Ah okays. Have you made some comparison with the result of Roel Typer? That would be an interesting point to compare with.
cheers, Alexandre
On 30 Mar 2012, at 09:33, Francisco Garau wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: ⢠The code never goes through the #new method (it creates objects using #basicNew and #@) ⢠Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ah okay. But still, I think a comparison is scientifically relevant. Alexandre On 30 Mar 2012, at 14:20, Francisco Garau wrote:
I think they are not comparable.
They both try to do Type-Inference. But... what is a Type?
Roel Typer works backwards. My TiEngine works forwards.
Roel Typer works backwards because it starts analysing a method a finds a message send, lets say "anObject setup". It then asks the question, who implements the method #setup and if it finds 13 different classes, then those are the "Type" of the anObject.
My TiEngine starts executing code without actually executing anything. It simulates execution making sure it goes through all the possible execution paths. That's is not always possible, so some compromise should be made.
Reflection is the killer of any sort of static analysis.
- Francisco
On 30 March 2012 17:17, Alexandre Bergel <alexandre.bergel@me.com> wrote: Ah okays. Have you made some comparison with the result of Roel Typer? That would be an interesting point to compare with.
cheers, Alexandre
On 30 Mar 2012, at 09:33, Francisco Garau wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises: The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find. frank On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Another interesting read, is from Peter Ahe who applied the same sort of analysis to the Resilient Smalltalk. http://tinyurl.com/cz9kslu I have some slides explaining my work. I can email them to you, if you wish. Cheers, Francisco On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 30 March 2012 23:56, Francisco Garau <francisco.garau@gmail.com> wrote:
Another interesting read, is from Peter Ahe who applied the same sort of analysis to the Resilient Smalltalk.
I have some slides explaining my work. I can email them to you, if you wish.
That would be great! One thing I've not taken the time to figure out is the relationship (if any) between the approach in Concrete Type Inference and Olin Shivers et al's k-CFA approach. k-CFA is also an abstract interpreter, but I don't know if it's just same in the name, or how the two approaches differ. Shivers also uses variants of CFA for things like tracking garbage collection. A recent paper by Matt Might titled "Abstracting Abstract Machines (http://matt.might.net/papers/vanhorn2010abstract.pdf) covers the various uses to which CFA can be put. frank
Cheers, Francisco
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Will come to you after my holiday break ... On Saturday, 31 March 2012, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 23:56, Francisco Garau <francisco.garau@gmail.com> wrote:
Another interesting read, is from Peter Ahe who applied the same sort of analysis to the Resilient Smalltalk.
I have some slides explaining my work. I can email them to you, if you wish.
That would be great!
One thing I've not taken the time to figure out is the relationship (if any) between the approach in Concrete Type Inference and Olin Shivers et al's k-CFA approach. k-CFA is also an abstract interpreter, but I don't know if it's just same in the name, or how the two approaches differ.
Shivers also uses variants of CFA for things like tracking garbage collection. A recent paper by Matt Might titled "Abstracting Abstract Machines (http://matt.might.net/papers/vanhorn2010abstract.pdf) covers the various uses to which CFA can be put.
frank
Cheers, Francisco
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com>
wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to isSharedVarNode ^ self type = 4 and: [key isVariableBinding] TypeInference works in both! Now I have some mczs, but I don't have a place to publish them... frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful. As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done. I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo? Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo. Cheers, Francisco PS: I am thinking in giving the Type Inference project a name: Telar or Tilar. Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language). I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا) On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.) I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package. fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding". One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log. frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode   ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I already upload it to ss3. http://ss3.gemstone.com/ss/ConcreteTypeInference 2012/4/4 Frank Shearar <frank.shearar@gmail.com>
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email,
it
seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Santiago, it looks like you don't have any of the Support stuff: there are no extensions to the parse nodes, so you can't use this out of the box as per Francisco's earlier examples: TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} " (You can with mine, because I folded in both changesets.) frank On 4 April 2012 14:00, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I already upload it to ss3. http://ss3.gemstone.com/ss/ConcreteTypeInference
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode   ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
aaaa, ok, you're right, there are extension methods that i forget. right? Ill upload to ss3 later. Thanks :D. 2012/4/4 Frank Shearar <frank.shearar@gmail.com>
Santiago, it looks like you don't have any of the Support stuff: there are no extensions to the parse nodes, so you can't use this out of the box as per Francisco's earlier examples:
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
(You can with mine, because I folded in both changesets.)
frank
On 4 April 2012 14:00, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I already upload it to ss3. http://ss3.gemstone.com/ss/ConcreteTypeInference
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com>
wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com>
wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com
wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 4 April 2012 15:27, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
aaaa, ok, you're right, there are extension methods that i forget. right? Ill upload to ss3 later. Thanks :D.
:) Just waiting for ss3 to recompute its indices or whatever, but I've pushed my two mczs up to the repository. frank
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
Santiago, it looks like you don't have any of the Support stuff: there are no extensions to the parse nodes, so you can't use this out of the box as per Francisco's earlier examples:
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
(You can with mine, because I folded in both changesets.)
frank
On 4 April 2012 14:00, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I already upload it to ss3. http://ss3.gemstone.com/ss/ConcreteTypeInference
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode   ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
It'd be great if you can also push the attached ChangeSet. They are not SUnits but contain some simple expressions that I've used while developing. It might not be very difficult to extract some simple test cases from them. The Challenger is a simple application to teach kids the times tables. It simply ask a question (how much is 3 x 4) and gives you some positive or negative feedback. At the moment it doesn't work as it is using the old FillInTheBlankMorph. - Francisco On 4 April 2012 16:18, Frank Shearar <frank.shearar@gmail.com> wrote:
On 4 April 2012 15:27, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
aaaa, ok, you're right, there are extension methods that i forget. right? Ill upload to ss3 later. Thanks :D.
:) Just waiting for ss3 to recompute its indices or whatever, but I've pushed my two mczs up to the repository.
frank
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
Santiago, it looks like you don't have any of the Support stuff: there are no extensions to the parse nodes, so you can't use this out of the box as per Francisco's earlier examples:
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
(You can with mine, because I folded in both changesets.)
frank
On 4 April 2012 14:00, Santiago Bragagnolo <
santiagobragagnolo@gmail.com>
wrote:
I already upload it to ss3. http://ss3.gemstone.com/ss/ConcreteTypeInference
2012/4/4 Frank Shearar <frank.shearar@gmail.com>
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am
trying
to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
frank
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here:
https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into
it
and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 4 April 2012 13:29, Frank Shearar <frank.shearar@gmail.com> wrote:
On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.
Attached! fbs.1 is the result of my loading your two changesets into a clean image and moving the -Support extensions to the *TypeInference category. (So for example all the #mirrorIn: implementations were in 'type inference' and are now in '*TypeInference' so that Monticello can recognise they're in the TypeInference package.)
I didn't keep all the method changes to Set: if Sets need their behaviour adjusted, we should fix Set directly, rather than from this package.
fbs.2 just adds the change I described earlier: I replaced "key class == Association" with "key isVariableBinding".
One thing the package definitely needs is a large test suite :) That would also let someone assess whether they've hit a known limitation of the inference engine or a bug. For example, analysing 'n := 2. n log' told me that "UndefinedObject would not understand #contextTag" and I'm unsure why a MethodContext (the only implementor of #contextTag) would be involved in calculating a log.
I had a quick look at your example (2 log) and it seems that it seems a limitation to analise classVariableNames (Ln10 in this case). This can be seen in the "stack trace" left in the Transcript. (<SmallInteger> log in [Number | #log]) (<SmallInteger> asFloat in [SmallInteger | #asFloat]) (<Float> log in [Float | #log]) (<Float class ?> infinity in [Float class | #infinity]) (<DomainError class ?> signal: <ByteString> from: <SmallInteger> in [DomainError class | #signal:from:]) You might wonder why it starts analysing the #infinity method. By definition Concrete Type is the exact class of the object and the concrete type of each instance variable. This is a bit problematic when analysing class methods (as in this case). If I have to find the concrete type of each instance variable of a class, then would end up analysing the superclass, the method dictionaries and maybe the whole system... That's why you can the type <Float class ?>. The question mark means that I hold the reference to the class itself. But as Ln10 is referenced in the method #log, then the engine starts going through each class variable. That needs to be fixed/optimised somehow... Look a the class side method in TObject (from the TiTest changeset I've recently sent to you). There is a category called 'global variables' that shows some of the code is capable of analysing. No class variable names, unfortunately. - Francisco
As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.
I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?
Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.
Cheers, Francisco
PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.
Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).
I also just learn that Loom in Arabic is pronounced Nul or ( اÙصÙرا)
On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
Interestingly, typing 'Display boundBox' fails in Squeak trunk because "UndefinedObject won't understand #origin:corner:". Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find.
It turns out that in Pharo we use Association and in Squeak we use ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode to
isSharedVarNode ^ self type = 4 and: [key isVariableBinding]
TypeInference works in both!
Now I have some mczs, but I don't have a place to publish them...
frank
frank
On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email,
it
seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In case anyone's interested in the paper behind Francisco's work (thanks Francisco!), you can find "Concrete Type Inference: Delivering Object Oriented Applications" here: https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf Interestingly, typing 'Display boundBox' fails in Squeak trunk because UndefinedObject won't understand #origin:corner:. Odd, since evaluating same will happily return a Rectangle. I'll look into it and see what I can find. frank On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
No unit tests, sorry...
Is not profiling, it's abstract intrepretation using types instead of objects.
- Francisco
On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Francisco,
I've tried your implementation. It seems to work in Pharo 1.4. Do you have unit test somewhere? How does your profiler work? From what you have said in your email, it seems you are profiling the execution. Is that true?
Cheers, Alexandre
On 29 Mar 2012, at 18:47, Francisco Garau wrote:
Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
You could then evaluate the below expressions -- watch the Transcript to see which methods are being analysed.
TiSystem current reset. string := '3 + 4'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<SmallInteger>} "
TiSystem current reset. string := 'Display boundingBox'. Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
TiSystem current explore.
Analysing 'Display boundingBox' shows a couple of surprises:
The code never goes through the #new method (it creates objects using #basicNew and #@) Object code goes through Object>>value but knowing that the implementation just answers self, it could be easily optimised.
I will try to package it more nicely under Monticello -- there are still a few rough edges that need to be polished before getting it to the same state it was in 2001...
Cheers, Francisco <Ti-Engine.2.cs><Ti-Support.2.cs>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (5)
-
Alexandre Bergel -
Francisco Garau -
Frank Shearar -
Santiago Bragagnolo -
Stéphane Ducasse