[Pharo-project] Literal array with evaluated value of stmts, vars etc..
Would this be of interest in general... I have always wanted a more capable literal array than what we have now.. #( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection.. so I just tried this out with a BlockClosure: asArray | stmts anArray | stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far.. Any comments.. -Skrish
how different from { 'ac'->23 . 2->'casd' } Stef On Jul 22, 2010, at 2:09 PM, Sudhakar Krishnamachari wrote:
Would this be of interest in general... I have always wanted a more capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It's different because evaluated only once, either at method compilation or at first execution (lazy initialization). Nicolas 2010/7/22 Stéphane Ducasse <stephane.ducasse@inria.fr>
how different from
{ 'ac'->23 . 2->'casd' }
Stef
On Jul 22, 2010, at 2:09 PM, Sudhakar Krishnamachari wrote:
Would this be of interest in general... I have always wanted a more capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 22, 2010, at 2:33 PM, Nicolas Cellier wrote:
It's different because evaluated only once, either at method compilation or at first execution (lazy initialization).
but Sudhakar use case did not show that he wanted something different. or I totally do not understand.
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
Would this be of interest in general... I have always wanted a more capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ah maybe, I interpreted literal literally. Let Sudhakar talk... Nicolas 2010/7/22 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Jul 22, 2010, at 2:33 PM, Nicolas Cellier wrote:
It's different because evaluated only once, either at method compilation or at first execution (lazy initialization).
but Sudhakar use case did not show that he wanted something different. or I totally do not understand.
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
Would this be of interest in general... I have always wanted a more
capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start
to: end) for: self receiver logged: false.
anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1.
instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do
their job their way...
but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, What you seek is something like - Dolphin ##( ) construction - or VW [] once trick from Travis Grigg based on using the #become: power (search once upon a time or something like that on his blog) I was thinking of this very subject recently and have a draft proposition not really ready (must think of it twice). The first idea would be to use the existing indirection for shared variables by always access their value via a message send. With a class implementing #value with a second indirection, this could solve the problem of package load order and cyclic dependencies, as well as shared variable initialization by using systematic lazy evaluation schemes. The second idea would be to define static variables local to the method (thus not shared) using the same #value principle, but there we need a syntax extension (something I just can't decide by myself). With such scheme, direct access to the value is not possible, so VM optimization fetching the second ivar or JIT techniques might have to be changed. Impact on performance has to be studied. However, polymorphic inline cache could eventually reduce this negative impact. Nicolas 2010/7/22 Sudhakar Krishnamachari <skrishnamachari@gmail.com>
Would this be of interest in general... I have always wanted a more capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
* *>* > It's different because evaluated only once, either at method compilation *>* or at first execution (lazy initialization). * { localVar1. instVar1. 'asd'->123 } is great.. and would suffice for many use cases, it does evaluate at method execution. But bound execution at later point that BlockClosure gives is interesting.
What you seek is something like - Dolphin ##( ) construction - or VW [] once trick from Travis Grigg based on using the #become: power (search once upon a time or something like that on his blog) I was thinking of this very subject recently and have a draft proposition not really ready (must think of it twice).
Other stuff I will eagerly wait for.. Well, I am not aware of Dolphin syntax as much, but in VA it is for evaluate once at method compilation. VW I have not known any ecquivalent... so Travis's is news ... To the current point: {...} is good.. and usable.. but this also gives a possibility to clean up: BlockClosure>>asArray | stmts anArray | stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| anArray at: indx put: (Compiler evaluate: eaNode ). ]. ^anArray or something more cleaner.. would allow late bound executions... and hold for all other use cases.. -Skrish On Thu, Jul 22, 2010 at 5:39 PM, Sudhakar Krishnamachari < skrishnamachari@gmail.com> wrote:
Would this be of interest in general... I have always wanted a more capable literal array than what we have now..
#( 123 23 'das' ) whynot: #( 'ac'->23 2->'casd' myVar1) ... evaluates to a collection..
so I just tried this out with a BlockClosure:
asArray
| stmts anArray |
stmts := self decompile statements. anArray := Array new: stmts size. stmts doWithIndex: [ :eaNode :indx| | start end value| start := (eaNode asString indexOf: ${)+1. end := (eaNode asString lastIndexOf: $})-1. value := Compiler evaluate: (eaNode asString copyFrom: start to: end) for: self receiver logged: false. anArray at: indx put: value]. ^anArray
So we could do: ['abc'->123. 'def'->456. 'efg'->789. 'hij'->123. 'klm'->456.] asArray. [self checkThisUsingKeywordMethod: 'abc' with:'efg'. localVar1. instanceVar1 ] asArray
to yield arrays.. not neat, I would much rather prefer the literals do their job their way... but works.. for the narrow set I have tried so far..
Any comments.. -Skrish
And of course the extensibility it gives: [ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary ... On Thu, Jul 22, 2010 at 7:48 PM, Sudhakar Krishnamachari < skrishnamachari@gmail.com> wrote:
* *>* > It's different because evaluated only once, either at method compilation *>* or at first execution (lazy initialization). *
2010/7/22 Sudhakar Krishnamachari <skrishnamachari@gmail.com>
And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
I think Travis Griggs' once is much much nicer: [{ 1->'asd'. 2->'asd'. 3->'dsd' } asDictionary] once when once is sent to a BlockClosure it becomes itself into a CachedBlockClosure that remembers and answers the evaluated value. You could add selectors to this such as onceEachSession - destroy the cached value on image startup It doesn't require any special compiler machinery (unlike ##(...)) and so there are no problems with browsing references or senders within compile-time evaluated forms. It is easily extensible to different life-times. It is portable. my 2¢ Eliot
...
On Thu, Jul 22, 2010 at 7:48 PM, Sudhakar Krishnamachari < skrishnamachari@gmail.com> wrote:
* *>* > It's different because evaluated only once, either at method compilation *>* or at first execution (lazy initialization). *
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
and here's a port to closures... On Thu, Jul 22, 2010 at 10:39 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
2010/7/22 Sudhakar Krishnamachari <skrishnamachari@gmail.com>
And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
I think Travis Griggs' once is much much nicer:
[{ 1->'asd'. 2->'asd'. 3->'dsd' } asDictionary] once
when once is sent to a BlockClosure it becomes itself into a CachedBlockClosure that remembers and answers the evaluated value. You could add selectors to this such as onceEachSession - destroy the cached value on image startup
It doesn't require any special compiler machinery (unlike ##(...)) and so there are no problems with browsing references or senders within compile-time evaluated forms. It is easily extensible to different life-times. It is portable.
my 2¢
Eliot
...
On Thu, Jul 22, 2010 at 7:48 PM, Sudhakar Krishnamachari < skrishnamachari@gmail.com> wrote:
* *>* > It's different because evaluated only once, either at method compilation
*>* or at first execution (lazy initialization). *
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 22, 2010, at 7:39 43PM, Eliot Miranda wrote:
2010/7/22 Sudhakar Krishnamachari <skrishnamachari@gmail.com> And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
I think Travis Griggs' once is much much nicer:
[{ 1->'asd'. 2->'asd'. 3->'dsd' } asDictionary] once
when once is sent to a BlockClosure it becomes itself into a CachedBlockClosure that remembers and answers the evaluated value. You could add selectors to this such as onceEachSession - destroy the cached value on image startup
It doesn't require any special compiler machinery (unlike ##(...)) and so there are no problems with browsing references or senders within compile-time evaluated forms. It is easily extensible to different life-times. It is portable.
my 2¢
Eliot
I like once as well, after using it in VisualWorks. For my tastes, it's uses just the right amount of magickery to both be able to easily understand how it works, and provide useful functionality. F.ex. I wrote a tool where I tagged (time-expensive) methods I suspected of being invariants during a large analysis, the tool then ran those methods wrapped in a once block, and told me which did not affect the end results. Much faster than a manual verification of whether they were really invariants, and provided an ok speedup for the amount of (brain) effort required :D Only problem I've encountered in VW (7.7 at least), is the debugger raising an mnu if you try to step into the once call of a CachedBlockClosure. Cheers, Henry
2010/7/22 Henrik Johansen <henrik.s.johansen@veloxit.no>
On Jul 22, 2010, at 7:39 43PM, Eliot Miranda wrote:
2010/7/22 Sudhakar Krishnamachari <skrishnamachari@gmail.com>
And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
I think Travis Griggs' once is much much nicer:
[{ 1->'asd'. 2->'asd'. 3->'dsd' } asDictionary] once
when once is sent to a BlockClosure it becomes itself into a CachedBlockClosure that remembers and answers the evaluated value. You could add selectors to this such as onceEachSession - destroy the cached value on image startup
It doesn't require any special compiler machinery (unlike ##(...)) and so there are no problems with browsing references or senders within compile-time evaluated forms. It is easily extensible to different life-times. It is portable.
my 2¢
Eliot
I like once as well, after using it in VisualWorks. For my tastes, it's uses just the right amount of magickery to both be able to easily understand how it works, and provide useful functionality.
F.ex. I wrote a tool where I tagged (time-expensive) methods I suspected of being invariants during a large analysis, the tool then ran those methods wrapped in a once block, and told me which did not affect the end results. Much faster than a manual verification of whether they were really invariants, and provided an ok speedup for the amount of (brain) effort required :D
Only problem I've encountered in VW (7.7 at least), is the debugger raising an mnu if you try to step into the once call of a CachedBlockClosure.
In Squeak 4.1 it seems fine :) I really like Assets. The whole framework is small, flexible, useful and easy to understand. best Eliot
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 23, 2010, at 9:24 38AM, Stéphane Ducasse wrote:
I really like Assets. The whole framework is small, flexible, useful and easy to understand. what is assets?
Stef
A really small and neat external resource-management framework in VisualWorks. Its relation to once is being the original use case. I've attached the class comment from VW, which explains how it works pretty well :) There's also this screencast, which shows off the RB integration, and caching speedup due to once use: http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov and this blogpost, explaining once: http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529 Cheers, Henry
ok not this is not what we have with MenuIcons? Stef On Jul 23, 2010, at 2:30 PM, Henrik Johansen wrote:
On Jul 23, 2010, at 9:24 38AM, Stéphane Ducasse wrote:
I really like Assets. The whole framework is small, flexible, useful and easy to understand. what is assets?
Stef
A really small and neat external resource-management framework in VisualWorks.
Its relation to once is being the original use case.
I've attached the class comment from VW, which explains how it works pretty well :) <Assets.rtf>
There's also this screencast, which shows off the RB integration, and caching speedup due to once use: http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov and this blogpost, explaining once: http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529
Cheers, Henry_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 23, 2010, at 3:14 31PM, Stéphane Ducasse wrote:
ok not this is not what we have with MenuIcons?
Stef
A close cousin, I would say. Assets - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file. - keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed. Cheers, Henry
On Jul 23, 2010, at 4:36 PM, Henrik Johansen wrote:
On Jul 23, 2010, at 3:14 31PM, Stéphane Ducasse wrote:
ok not this is not what we have with MenuIcons?
Stef
A close cousin, I would say.
Yes this is a distributed version.
Assets - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file.
so the pragma are more for doing a rebuild.
- keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed.
what is the license? Stef
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
this is a scenario I can understand bring a value.... Stef
I like once as well, after using it in VisualWorks. For my tastes, it's uses just the right amount of magickery to both be able to easily understand how it works, and provide useful functionality.
F.ex. I wrote a tool where I tagged (time-expensive) methods I suspected of being invariants during a large analysis, the tool then ran those methods wrapped in a once block, and told me which did not affect the end results. Much faster than a manual verification of whether they were really invariants, and provided an ok speedup for the amount of (brain) effort required :D
Only problem I've encountered in VW (7.7 at least), is the debugger raising an mnu if you try to step into the once call of a CachedBlockClosure.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I do not see what does this hacks bring. We have closure and objects so far this is enough. After we can find case where an extension can be handy but I prefer to focus on real problem. Stef On Jul 22, 2010, at 4:33 PM, Sudhakar Krishnamachari wrote:
And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
...
On Thu, Jul 22, 2010 at 7:48 PM, Sudhakar Krishnamachari <skrishnamachari@gmail.com> wrote:
It's different because evaluated only once, either at method compilation
or at first execution (lazy initialization).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 On 22 Jul 2010, at 20:57, Stéphane Ducasse wrote:
I do not see what does this hacks bring. We have closure and objects so far this is enough. After we can find case where an extension can be handy but I prefer to focus on real problem.
Stef
On Jul 22, 2010, at 4:33 PM, Sudhakar Krishnamachari wrote:
And of course the extensibility it gives:
[ 1->'asd'. 2->'asd'. 3->'dsd' ] asDictionary
...
On Thu, Jul 22, 2010 at 7:48 PM, Sudhakar Krishnamachari <skrishnamachari@gmail.com> wrote:
It's different because evaluated only once, either at method compilation
or at first execution (lazy initialization).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (6)
-
Alexandre Bergel -
Eliot Miranda -
Henrik Johansen -
Nicolas Cellier -
Stéphane Ducasse -
Sudhakar Krishnamachari