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