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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.