Smalltalk › Squeak › SqueakLand

how to hide ALL connectors to/from a specific node in the Connectors package?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

LawsonEnglish

how to hide ALL connectors to/from a specific node in the Connectors package?

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

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Steve Thomas

Re: how to hide ALL connectors to/from a specific node in the Connectors package?

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:

About Siblings (by Karl)

If you hold down shift while copying with the green halo handle you make a copy.

Almost... What you now have are two sibling players, each of which is a "Player" or "Object" in its own right. (Also copies made by the Player Copy tile are siblings.) Each players wears its own separate Morph as its costume. The siblings are related in that they share certain things in common, in particular: scripts and variable definitions. So if you add a variable to one sibling, all siblings will have their own instance of that variable with the same name. The same name, but the values can be different. For example if I add a variable called "speed" to one sibling, all siblings will have a variable with that name. But I can have one sibling with speed=5 and another with speed=10. Same variable name different values.

Also if I add a script to one sibling, all siblings will have the same script (and same scripting tiles, if I change it in any sibling at anytime). But although siblings share a script, each sibling has its own private "status" for that script, i.e.remembers separately whether the script as used by this instance is "normal", "paused,", or "ticking", or set to trigger on mouse-up, etc.; and what the tick-rate is.

When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming

So why would you use siblings? Well besides teaching one of the most fundamental concepts of object oriented programming, you could use siblings in a game to make characters that have similar behaviors (aka scripts) but different looks (you can change the looks by either re-drawing the sketch or by setting the Sketch's graphic (if the object is a Sketch or image you copied in) or changing its size and colors. You could also have ships in a game that keep track of how many times they were hit (using a variable to count the # of hits). That way you can program a basic ship once and make multiple siblings. Then if you decide to change the behavior (ex: modify a script, or add a new variable), you can change it once and all the siblings are changed.

Siblings could also be used to try to simulate or model real world behavior. For example deer population or some other animal. You could create an Object that simulates the behavior of a deer: searches for food, ages, breeds (at a certain age), etc. and make sibling copies of that one object. Then each Sibling (aka individual instance of the Class Deer which you have defined) could age, search for food (and find it or not which could affect its life expectancy), etc at its own rate. You could also create predators and food that grows. Then run multiple simulations varying the amount of food, starting number of dear, # of predators, etc.

If the "all instances" box is not checked in AllPlayers, you'll see the scripts for only one player of each sibling group. This will give you "control" over the scripts of only one of the players. If you want to be able to "control" scripts for both of the siblings, make sure the "all

instances" checkbox is checked.
Unless the "all instances" checkbox is checked, creation of new siblings will typically not result in any noticeable change in the all- scripts tool, since all the scripts of the new sibling will already be represented by another instance in the tool. Perhaps that's what you're seeing.

Also, if the "tickers only" box is checked, only scripts whose status is "ticking" or "paused' are shown in the all-scripts tool. This can be another reason why the all-scripts tool may seem not to be "picking up" on a change.

On Sat, Sep 14, 2013 at 4:45 PM, Lawson English <[hidden email]> wrote:

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

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

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)

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Karl Ramberg

Re: how to hide ALL connectors to/from a specific node in the Connectors package?

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:

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:

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

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Steve Thomas

Re: how to hide ALL connectors to/from a specific node in the Connectors package?

On Tue, Sep 17, 2013 at 2:36 PM, karl ramberg <[hidden email]> wrote:

This is IMO a bug. It says tellAllSuccessors but tells only the first node in the successor graph.

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.

"tell all siblings" ==> "tell siblings"
"tell all embedded objects" ==> "tell embedded objects"
"tell all incoming connections" ==> "tell incoming connections" and "tell all incoming connections"

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

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Bert Freudenberg

Re: how to hide ALL connectors to/from a specific node in the Connectors package?

On 2013-09-18, at 05:54, Steve Thomas <[hidden email]> wrote:

On Tue, Sep 17, 2013 at 2:36 PM, karl ramberg <[hidden email]> wrote:

This is IMO a bug. It says tellAllSuccessors but tells only the first node in the successor graph.

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"

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.

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.

And also get rid of the extraneous "all" in the other tell commands.

"tell all siblings" ==> "tell siblings"
"tell all embedded objects" ==> "tell embedded objects"
"tell all incoming connections" ==> "tell incoming connections" and "tell all incoming connections"
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.

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 -

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Karl Ramberg

Re: how to hide ALL connectors to/from a specific node in the Connectors package?

On Wed, Sep 18, 2013 at 3:57 PM, Bert Freudenberg <[hidden email]> wrote:

On 2013-09-18, at 05:54, Steve Thomas <[hidden email]> wrote:

On Tue, Sep 17, 2013 at 2:36 PM, karl ramberg <[hidden email]> wrote:

This is IMO a bug. It says tellAllSuccessors but tells only the first node in the successor graph.

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"

This sounds good.

Karl

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.

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.

And also get rid of the extraneous "all" in the other tell commands.

"tell all siblings" ==> "tell siblings"
"tell all embedded objects" ==> "tell embedded objects"
"tell all incoming connections" ==> "tell incoming connections" and "tell all incoming connections"

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.

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 -

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland