I'll try again:
I have 19 Connectors nodes showing in my project. There are 19 x 18 connectors -a fully connected graph. I want to be able to easily tell all connectors to hide using Etoys scripting. I already know how to do this with Squeak, but it isn't obvious at all how to make it work with etoys, despite the existence of a scripting option "tellAllIncomingConnections" and "tellAllOutgoingConnections" I can't figure it out. I've dropped down into the System browser and looked at the Smalltalk code for #tellAllIncomingConnections: aMessageSelector and #tellAllOutgoingConnections: aMessageSelector "Send the given message selector to all the players of the receiver's costume's outgoing connections" self costume outgoingConnections do: [:m | m playerRepresented ifNotNilDo: [:p | p performScriptIfCan: aMessageSelector]] I've even tried putting ^#hide into the script. Is this aspect of Connectors + Etoys broken or am I missing something? I can specify a SPECIFIC Connector to hide, but I have potentially 19 x 18 or even 256 x 255 of them to work with, so obviously this isn't an option. Do I have to go with my incredibly cumbersome code I worked out in my Squeak youtube tutorials and stick that into a script, instead? Thanks. L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan _______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
The problem as I understand it is how to propagate messages to tell all outgoing connections from the current object and all sucessors outgoing connetions etc. See solution below: Each node is a Sibling and Each Connector is a Sibling. So when I run "hideConnOut" it tells all its "outgoing connections" to hide AND tells all its succesors to do the same. FYI Siblings are very useful when you want a bunch of objects to have the same behavior. They share scripts and variables (ie: if you create a variable in one sibling they all have that script, but one could be running and the other not. Same with variables add one and they all Siblings have that variable (but they can have different values). Below is from the Etoys reference manual:
On Sat, Sep 14, 2013 at 4:45 PM, Lawson English <[hidden email]> wrote: I'll try again: To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up. When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity. - Martin Harverbeke (from Eloquent JavaScript) _______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
In reply to this post by LawsonEnglish
First #tellAllIncomingConnections: aMessageSelector and #tellAllOutgoingConnections: aMessageSelector
are just the first level connectors directly connected to the morph in question. Its one level deep.
You can look at Player>>tellAllSuccessors: aMessageSelector If you change self costume successors do: to self costume allSuccessors do: you get a graph of all the morphs successors to the morph
This is IMO a bug. It says tellAllSuccessors but tells only the first node in the successor graph. Same goes for tellAllPredecessors: Karl On Sat, Sep 14, 2013 at 10:45 PM, Lawson English <[hidden email]> wrote: I'll try again: _______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
You can also work around not having the whole graph in tellAllSuccessors
Look at attached project On Tue, Sep 17, 2013 at 8:36 PM, karl ramberg <[hidden email]> wrote:
_______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev connector.001.pr (255K) Download Attachment |
In reply to this post by Karl Ramberg
On Tue, Sep 17, 2013 at 2:36 PM, karl ramberg <[hidden email]> wrote:
Well looking at this again, it seems using "tell all" is a bad wording choice.
All of the "tell" tiles are "tell all" tiles. Perhaps it would be better to have two versions "tell" tiles (for connectors and successors) which tell the 1st level and "tell all" which go all the way down/up the chain. And also get rid of the extraneous "all" in the other tell commands.
Of course the problem with #3 and its like is that it could break older projects which would not want to do. You might be able to determine which version it was saved in and deal with that I don't know.
The above said as Karl demonstrated with his project it is possible to build that functionality by scripting the nodes properly. Stephen _______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
On 2013-09-18, at 05:54, Steve Thomas <[hidden email]> wrote:
Agreed, though the bug is only in the naming, the behavior is correct. Mathematically speaking we mean the direct successors, but for brevity this got shortened to just successors. Note that the help bubble for "tell all outgoing connections" is very carefully worded: "Send a message to all the connectors whose source end is connected to me" whereas the help for "tell all successors" is just "Send a message to all graph successors" which is both factually wrong (it's only direct successors) and should include a mention of connectors, perhaps "Send a message to all objects at the destination end of my outgoing connections"
All of the current behavior in Etoys is centered on a single object: *my* siblings, *my* children, *my* connections. This comes from the object-centric view of Etoys. So "all" means "all the objects I know" not "all objects there are" which would be a global view, not object-centric. I'm not convinced that we should give up that very fundamental property of Etoys for a little convenience in a very limited scenario.
I like the "all" in the wording because it alerts the user that something is happening to multiple objects at once. It is not strictly necessary because with careful reading the plural "s" will reveal as much. I still think a single letter is not quite enough to make clear that this is, in fact, a very unusual thing, compared to the normal explicit object relationships. - Bert - _______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
On Wed, Sep 18, 2013 at 3:57 PM, Bert Freudenberg <[hidden email]> wrote:
This sounds good. Karl
_______________________________________________ etoys-dev mailing list [hidden email] http://lists.squeakland.org/mailman/listinfo/etoys-dev |
Free forum by Nabble | Edit this page |