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