Selectors with underscores
Locked
 
|
Hi Sam,
>Supporting underscores in selectors makes a significant change to how the >code looks to the eyes >You can argue its not that important, or folks should just change and >enjoy it, but it does impact readability. You seem to miss my point here. I AGREE with you regarding readability - since I like well written Smalltalk code in the same way you like it. A #fooBar is always better than a #foo_Bar! Nothing said about it - I have no beard but appreciate reading/writing clean Smalltalk code since 1994... BUT: CALL_ME_BACK: is also more readable than CALLMEBACK in an FFI callback, especially when the C function has the same name The other Smalltalks allowed to use underscores in selectors and still have well written and readable Smalltalk methods. You may argue that this is due to their commercial nature - but I believe it's because Smalltalk people really use this feature carefully. I think you fear that after introducing this change anybody is instantly_switching_to_writing_ALL_its_method_selectors_with_underscores - which I just doubt! Therefore I would like to go the way Bert nicely described as: Supporting them: +1 Using them: -1 It's an interesting discussion - I should have read the warning in Ians original changeset more clearly. It said: "Use of this changeset has been officially condemned by the Independent Board of Syntactical Aesthetics for Squeak." :) >Just 2r11 from a "legacy" Smalltalker who, yes, still uses MVC, albeit >running in parallel in a custom VM on a 64-core Tilera chip. ;-) How is the project going, havent heard from it since 2008? ></previous_post_eaten_by_LotusNotes> Since Notes-UI is written in Java I think underscores are OK here Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
|
|
+1
I note that VisualWorks, and I think various other Smalltalks have supported the ability to use underscores in selectors for many years, but it is quite rare to see them. At 10:31 AM 2010-03-12, Torsten Bergmann wrote: Hi Sam, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
|
|
|
In reply to this post by Torsten Bergmann
> "Torsten Bergmann" |
|
|
In reply to this post by Alan Knight-2
VSE supported them as well. The ANSI committee left support for underscores in identifiers as a platform dependent feature.
The only use for them in VSE was in operating system interface external classes. On Mar 12, 2010, at 10:58 AM, Alan Knight wrote:
|
parallelism models (was: Selectors with underscores)
|
|
In reply to this post by Sam Adams-2
Sam Adams wrote on Fri, 12 Mar 2010 11:02:53 -0500
[I'm still trying to catch up] > The Renaissance project is going on nicely. Dave Ungar and I > have VMs for both Tilera Tile64 and Intel Multicore (thanks to > our collaborator Stefan Marr of Vrije Univ). We have also > defined an experimental language for using our new massively > parallel programming model concepts. Its a variant of > Javascript/Self, and we have a fledgling IDE developed for > it in Squeak. More details soon as we are hoping to open source > the effort. I am really looking forward to seeing that! On the same subject, I have a three level plan for parallelism within Squeak. One requirement is that the result should be simple enough that I can explain it to a bright child. This rules out some very elegant solutions that require thinking in ways that most people find hard to learn. === Level 1 - Islands and promises, TeaTime Though the "wait by necessity" model using future object (promises) from parallel Eiffel has worked out very well for me so far, giving each object its own thread has had advantages and problems. http://www.merlintec.com/lsi/selfdiff.html#process http://www.merlintec.com/lsi/tiny.html#rel1 The main issue is that any recursion, direct or indirect, will cause deadlock with this model. The hack I used to fix this for tinySelf 1 wasn't very nice. The Eiffel solution was to only allow certain objects, called actors, to have their own thread. You have to take care that other objects, the passive ones, are only ever referenced by a single actor. That makes it hard to program since it is so each to let references to passive objects "leak" through arguments or return values. By grouping objects into islands this worry goes away since all objects are now equal. One possible island model is to allow objects to migrate between them, but I prefer to have the partition be permanent. In fact, I feel that you should only be able to create a new object in your own island or as the very first object in a completely new island. You wouldn't be able to directly create objects in any other existing island (which seems horrible in terms of security) but you could send a message to an object in the other island and ask it to create an object there for you (if it wants to). We could have #newHere and #newRemote with each class implementing #new in terms of the most appropriate one (user code can use the explicit selectors to override the class default). You should be able to have replicas of a single island on different machines, and TeaTime could be used to keep them in sync. An alternative for replication is read-only islands. This would be a dynamic property (just like in the work that Sam and Dave have done on the Tilera). http://www.opencroquet.org/images/0/0d/2005_Teatime_Framework_Design.pdf === Level 2 - Concurrent Aggregates, APL/FScript Versions of the Collection objects can be built on top of Level 1 such that they appear to exist on multiple islands at the same time. So a 1000 element ConcurrentArray can have 100 elements each on 10 islands and it will seem like a local object on each of those. Using the normal APL or FScript style methods (#collect:, #detect:, etc) instead of the lower level looping ones, you will get a significant performance boost. > http://www-csag.ucsd.edu/teaching/cse291s03/Lectures/Concurrent%20Aggregates%20(CA).ppt === Level 3 - Linda, Agora, Announcements, Subscribe and Publish, Kedama, FScript Something like a Linda TupleSpace can be implemented using ConcurrentAggregates. If we limit tuples to the form ("selector",?arg1,?arg2) then we will have normal Smalltalk messages with an unspecified receiver. Though extremely limited compared to the general Linda scheme, this would be enough for nearly all applications in practice. This one-to-many communication system would implement most of the FScript funcionality not in Level 2 and could trivially host something very similar to Kedama. If some meta information is added to the messages going through these "agoras", this would also double as an implementation of Annoucements. While in Linda a thread can only wait for one kind of tuple at a time, it would be nice for an island to be able to define a set of messages it would like to receive (so we would have the equivalent of ALT in Occam). http://en.wikipedia.org/wiki/Tuple_space http://www.fscript.org/ > http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3310034894 -- Jecel |
Re: parallelism models (was: Selectors with underscores)
|
|
In reply to this post by Sam Adams-2
Main question: garbage collection.
How each of the possible models approaching this, quite complex problem. On 16 March 2010 22:11, Jecel Assumpcao Jr <[hidden email]> wrote: > Sam Adams wrote on Fri, 12 Mar 2010 11:02:53 -0500 > [I'm still trying to catch up] > >> The Renaissance project is going on nicely. Dave Ungar and I >> have VMs for both Tilera Tile64 and Intel Multicore (thanks to >> our collaborator Stefan Marr of Vrije Univ). We have also >> defined an experimental language for using our new massively >> parallel programming model concepts. Its a variant of >> Javascript/Self, and we have a fledgling IDE developed for >> it in Squeak. More details soon as we are hoping to open source >> the effort. > > I am really looking forward to seeing that! > > On the same subject, I have a three level plan for parallelism within > Squeak. One requirement is that the result should be simple enough that > I can explain it to a bright child. This rules out some very elegant > solutions that require thinking in ways that most people find hard to > learn. > > === Level 1 - Islands and promises, TeaTime > > Though the "wait by necessity" model using future object (promises) from > parallel Eiffel has worked out very well for me so far, giving each > object its own thread has had advantages and problems. > > http://www.merlintec.com/lsi/selfdiff.html#process > > http://www.merlintec.com/lsi/tiny.html#rel1 > > The main issue is that any recursion, direct or indirect, will cause > deadlock with this model. The hack I used to fix this for tinySelf 1 > wasn't very nice. The Eiffel solution was to only allow certain objects, > called actors, to have their own thread. You have to take care that > other objects, the passive ones, are only ever referenced by a single > actor. That makes it hard to program since it is so each to let > references to passive objects "leak" through arguments or return values. > By grouping objects into islands this worry goes away since all objects > are now equal. > > One possible island model is to allow objects to migrate between them, > but I prefer to have the partition be permanent. In fact, I feel that > you should only be able to create a new object in your own island or as > the very first object in a completely new island. You wouldn't be able > to directly create objects in any other existing island (which seems > horrible in terms of security) but you could send a message to an object > in the other island and ask it to create an object there for you (if it > wants to). We could have #newHere and #newRemote with each class > implementing #new in terms of the most appropriate one (user code can > use the explicit selectors to override the class default). > > You should be able to have replicas of a single island on different > machines, and TeaTime could be used to keep them in sync. An alternative > for replication is read-only islands. This would be a dynamic property > (just like in the work that Sam and Dave have done on the Tilera). > > http://www.opencroquet.org/images/0/0d/2005_Teatime_Framework_Design.pdf > > === Level 2 - Concurrent Aggregates, APL/FScript > > Versions of the Collection objects can be built on top of Level 1 such > that they appear to exist on multiple islands at the same time. So a > 1000 element ConcurrentArray can have 100 elements each on 10 islands > and it will seem like a local object on each of those. Using the normal > APL or FScript style methods (#collect:, #detect:, etc) instead of the > lower level looping ones, you will get a significant performance boost. > >> http://www-csag.ucsd.edu/teaching/cse291s03/Lectures/Concurrent%20Aggregates%20(CA).ppt > > === Level 3 - Linda, Agora, Announcements, Subscribe and Publish, > Kedama, FScript > > Something like a Linda TupleSpace can be implemented using > ConcurrentAggregates. If we limit tuples to the form > ("selector",?arg1,?arg2) then we will have normal Smalltalk messages > with an unspecified receiver. Though extremely limited compared to the > general Linda scheme, this would be enough for nearly all applications > in practice. > > This one-to-many communication system would implement most of the > FScript funcionality not in Level 2 and could trivially host something > very similar to Kedama. If some meta information is added to the > messages going through these "agoras", this would also double as an > implementation of Annoucements. While in Linda a thread can only wait > for one kind of tuple at a time, it would be nice for an island to be > able to define a set of messages it would like to receive (so we would > have the equivalent of ALT in Occam). > > http://en.wikipedia.org/wiki/Tuple_space > > http://www.fscript.org/ > >> http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3310034894 > > -- Jecel > > > -- Best regards, Igor Stasenko AKA sig. |
Re: parallelism models (was: Selectors with underscores)
|
|
Igor Stasenko wrote on Wed, 17 Mar 2010 02:23:01 +0200
> Main question: garbage collection. > How each of the possible models approaching this, quite complex problem. Yes, distributed garbage collection has been a deep research topic for decades. Here is a good overview of the subject: http://www-sor.inria.fr/publi/SDGC_iwmm95.html For old Squeak images enhanced to deal with inter-image references, my approach is to handle this problem manually. If I need to run a 2.4 image in order to use some old application, then I will create a new copy in the same directory as my more current image(s) from which I will use them and use it exclusively for that purpose. Both the 2.4 and the new images will accumulate some garbage due to circular inter-image references (even after these references go away), but I can live with that. Depending on how I will actually use it, I might not save the 2.4 image but might restarted from the original version each time. For new images with NeoModules there is no sense in having distributed garbage collection. A module is a growing series of read-only files on disk. The idea is that disks get larger and larger at a faster rate than the local creation and modification of objects, so it is no big deal to keep everything. Note that if you create objects on your disk and I download a copy of them to my machine, then this copy is only considered a cache based on the idea that I can throw it away at any time and if it is needed in the future I can download it again from you. Remote and local objects are managed very differently, but the result is that remote objects are someone else's problem and local objects don't have to be garbage collected. -- Jecel |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |