Hi -
Chronos (http://www.chronos-st.org & http://www.squeaksource.com/Chronos ) would load into and work in Squeak 3.9, but it won't load into 4.2. The error given is 'Futures must be sent messages' I think this comes up because Chronos has a class InfiniteTimepoint that has two class side methods:
InfiniteTimepoint class >> polarity: polarity ^polarity ifTrue: [self future] ifFalse: [self past]
and
InfiniteTimepoint class >> future Future == nil ifTrue: [Future := (self basicNew) bePositive; beImmutable]. ^Future
For some reason when polarity: is compiled it is using Object>>future rather than the version of future that is defined by InfiniteTimepoint.
Is there any way to change the load/compile order of those two methods when loading into 4.2? I know I could rename the InfiniteTimepoint version of future to something else but its a package that works as is on VisualWorks, Dolphin, Pharo, and Gemstone. So I'd either maintain a separate version for squeak or have to get the package maintainer to make a change for all platforms and users.
I'm using linux and the all-in-one app from squeak.org
Thanks for any guidance you can provide.
Paul
On Tue, 8 Mar 2011, Paul DeBruicker wrote:
Hi -
Chronos (http://www.chronos-st.org & http://www.squeaksource.com/Chronos ) would load into and work in Squeak 3.9, but it won't load into 4.2. The error given is 'Futures must be sent messages' I think this comes up because Chronos has a class InfiniteTimepoint that has two class side methods:
InfiniteTimepoint class >> polarity: polarity ^polarity ifTrue: [self future] ifFalse: [self past]
and
InfiniteTimepoint class >> future Future == nil ifTrue: [Future := (self basicNew) bePositive; beImmutable]. ^Future
For some reason when polarity: is compiled it is using Object>>future rather than the version of future that is defined by InfiniteTimepoint.
Is there any way to change the load/compile order of those two methods when loading into 4.2? I know I could rename the InfiniteTimepoint version of future to something else but its a package that works as is on VisualWorks, Dolphin, Pharo, and Gemstone. So I'd either maintain a separate version for squeak or have to get the package maintainer to make a change for all platforms and users.
I'm using linux and the all-in-one app from squeak.org
Thanks for any guidance you can provide.
#future and #future: sends are inlined by the compiler. Currently there's no way to turn this off, but it can be easily implemented. IIRC Croquet needs these methods to be inlined.
Levente
Paul _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Chronos REQUIRES that the message #future NOT be inlined. The requirement PREDATES the inlining of #future, and so WILL NOT BE CHANGED, since temporal precedence MUST BE RESPECTED.
Also, 'future' belongs with greater weight and precedent to the domain of time, and date/time functionality is more fundamental than the competing usage.
Finally, and most critically: Inlining of messages is a direct contradiction of the principles on which Smalltalk is based.
-- View this message in context: http://forum.world.st/Chronos-package-loading-error-tp3341396p3345206.html Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Inlining, as in flattening message sends and inlining machine code? Am I misunderstanding your words or is that what you actually mean to say?
BTW, I really enjoyed Smalltalk: Getting the Message, and I've recommended it to a lot of people. Thanks for writing it!
On Mar 9, 2011, at 9:11 PM, Chronos alan.lovejoy@gmail.com wrote:
Chronos REQUIRES that the message #future NOT be inlined. The requirement PREDATES the inlining of #future, and so WILL NOT BE CHANGED, since temporal precedence MUST BE RESPECTED.
Also, 'future' belongs with greater weight and precedent to the domain of time, and date/time functionality is more fundamental than the competing usage.
Finally, and most critically: Inlining of messages is a direct contradiction of the principles on which Smalltalk is based.
-- View this message in context: http://forum.world.st/Chronos-package-loading-error-tp3341396p3345206.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On 10.03.2011, at 14:35, Casey Ransberger wrote:
Inlining, as in flattening message sends and inlining machine code? Am I misunderstanding your words or is that what you actually mean to say?
See http://forum.world.st/-td965885.html
- Bert -
BTW, I really enjoyed Smalltalk: Getting the Message, and I've recommended it to a lot of people. Thanks for writing it!
On Mar 9, 2011, at 9:11 PM, Chronos alan.lovejoy@gmail.com wrote:
Chronos REQUIRES that the message #future NOT be inlined. The requirement PREDATES the inlining of #future, and so WILL NOT BE CHANGED, since temporal precedence MUST BE RESPECTED.
Also, 'future' belongs with greater weight and precedent to the domain of time, and date/time functionality is more fundamental than the competing usage.
Finally, and most critically: Inlining of messages is a direct contradiction of the principles on which Smalltalk is based.
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Casey Ransberger -
Chronos -
Levente Uzonyi -
Paul DeBruicker