- Pharo-users - lists.pharo.org

Re: [Pharo-users] mentor wanted

by Roelof Wobben

Op 26-4-2020 om 06:30 schreef Richard O'Keefe: > Roelof, *I* was offering to write something. > > On Sat, 25 Apr 2020 at 19:47, Roelof Wobben via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: >> Op 25-4-2020 om 08:30 schreef Richard Sargent: >> >> On Fri, Apr 24, 2020, 22:25 Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> Roelof, I don't think CRC cards or the GRASP patterns or anything like that >>> addresses your immediate needs. Based on other questions of yours it >>> seems to me that your problem is not *organising* the responsibilities in an >>> OO program, but decomposing a problem into responsibilities in the first >>> place. I think this is perhaps the most important part of programming, and >>> the hardest to learn, not least because very few of us are good at teaching >>> it. We're not very good at teaching it in mathematics either. I do not think >>> your issues are anything to do with Pharo, Smalltalk, OOP, or programming >>> as such. >>> >>> One symptom of the general problem that I've noticed is that I see code as >>> a very fluid sort of thing where pieces can be moved around and recombined, >>> while many people think of code as something solid and rather brittle. >>> >>> I was thinking of writing up a short description of what I was thinking for a >>> RosettaCode example anyway. Would that help? >> >> Thank you, Richard. I appreciate your offering this. I am not a teacher, so your help is truly appreciated! >> >> >> >> Moment, I have to look if I understand you right. >> I think you have some strong points but the last one I did not understand well. >> >> Do I have to write for example for a exercism challenge a short description of that problem like people do with rosetta code challenges and example code ? >> >> Roelof >> oke, I also accept this offer also. The more angles I learn to solve this , the more I can use that in later challenges. and if I understand everything right , the solution is very simple linksTowards: anAddress do: aBlock Â Â Â "Simple flood algorithm: route via all outgoing links. However, just loopback if the receiver node is the routing destination." Â Â Â address = anAddress Â Â Â Â Â Â ifTrue: [ aBlock evaluate: loopback ] Â Â Â Â Â Â ifFalse: [ outgoingLinks do: aBlock ] and the flow is this : send: aPacket Â Â Â "Send aPacket, leaving the responsibility of routing to the node." Â Â Â self Â Â Â Â Â Â linksTowards: aPacket destinationAddress Â Â Â Â Â Â do: [ :link | self send: aPacket via: link ] so for linkTwowards the anAddress isÂ the `aPacket destinationAdress `Â and the aBlockÂ is ` [:link | self send: aPacket via: link ` so if the address is the loopback oneÂ it would be ` self send: aPacket via: loopback ` and send is this : send: aPacket via: aLink Â Â Â aLink emit: aPacket so that would beÂ ` loopback emit : aPackageÂ ` and that would lead to : emit: aPacket Â Â Â "Packets are not transmitted right away, but stored. Transmission is explicitly triggered later, by sending #transmit:." Â Â Â packetsToTransmit add: aPacket where packetsToTransmit is a OrderedCollection where the packet is added Waiting till the transmit method is called where the sending of a package is simulated. Roelof

April 26, 2020

Re: [Pharo-users] mentor wanted

by Richard O'Keefe

Roelof, *I* was offering to write something. On Sat, 25 Apr 2020 at 19:47, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Op 25-4-2020 om 08:30 schreef Richard Sargent: > > On Fri, Apr 24, 2020, 22:25 Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> Roelof, I don't think CRC cards or the GRASP patterns or anything like that >> addresses your immediate needs. Based on other questions of yours it >> seems to me that your problem is not *organising* the responsibilities in an >> OO program, but decomposing a problem into responsibilities in the first >> place. I think this is perhaps the most important part of programming, and >> the hardest to learn, not least because very few of us are good at teaching >> it. We're not very good at teaching it in mathematics either. I do not think >> your issues are anything to do with Pharo, Smalltalk, OOP, or programming >> as such. >> >> One symptom of the general problem that I've noticed is that I see code as >> a very fluid sort of thing where pieces can be moved around and recombined, >> while many people think of code as something solid and rather brittle. >> >> I was thinking of writing up a short description of what I was thinking for a >> RosettaCode example anyway. Would that help? > > > Thank you, Richard. I appreciate your offering this. I am not a teacher, so your help is truly appreciated! > > > > Moment, I have to look if I understand you right. > I think you have some strong points but the last one I did not understand well. > > Do I have to write for example for a exercism challenge a short description of that problem like people do with rosetta code challenges and example code ? > > Roelof >

April 26, 2020

Re: [Pharo-users] mentor question 1

by Richard Sargent

On Sat, Apr 25, 2020, 16:17 tbrunz <wild.ideas(a)gmail.com> wrote: > Richard, > > I don't think it was silly. I'm sitting here thinking to myself, "Wow, > that's creative... Pharo being Pharo, you can write applications that can > send *blocks* between nodes, not just *data*..." > I understand. I meant that in the world this exercise models (separate compute nodes connected by a network), the single god-like Pharo application doesn't exist and sending blocks is harder. (Although, GemStone/S does make it simple, at least if all the nodes are connected to the GemStone/S database.) > The concept of sending behaviors as well as data opens up some interesting > and powerful possibilities for applications! (Yet another way ST is > superior to other languages.) > Absolutely! It took a long time to *really* internalize the idea of everything is an object. Once I grokked that, it became easy to think that way all the time. > -Ted > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 25, 2020

Re: [Pharo-users] mentor question 1

by tbrunz

Richard, I don't think it was silly. I'm sitting here thinking to myself, "Wow, that's creative... Pharo being Pharo, you can write applications that can send *blocks* between nodes, not just *data*..." The concept of sending behaviors as well as data opens up some interesting and powerful possibilities for applications! (Yet another way ST is superior to other languages.) -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 25, 2020

Re: [Pharo-users] mentor question 1

by tbrunz

Roelof, The core concept (as I see it) is that each node in your simulated network will receive packets as the simulation progresses, and the nodes must do something with each packet they receive. In OOP, it often helps to think about the objects in terms of "their responsibilities". And by that we mean: "when such-and-such event occurs, or whenever one-or-another situation is active, this object has the responsibility of doing this-or-that". So what about the node objects? The responsibility of a node object is to react appropriately to the event of receiving a packet. There are at least 3 behaviors that each node must employ to meet its responsibilities. Those three are: 1) Forward the packet to one or more other nodes in the network that it's connected to, 2) Accept the packet (if addressed to itself) and "process it", and 3) Drop the packet (because it's been received previously, which means it's already either been forwarded or accepted and processed, so this is a duplicate packet and should no longer be handled). In addition, each node must make the decision which behavior to follow when it receives a packet. It will do this based on information in the packet (its destination address) and the node's own address (so that it can recognize packets that are addressed to itself), and the address of the node that sent the packet (perhaps; for efficiency, you don't want to forward a packet back to the node that just sent it to you -- it already handled the packet and decided it should forward it). For behavior #1, there is more than one way to decide "how" to forward a packet. The "Flood" algorithm is one of many, and is the simplest one. But there are others. Each of these possible forwarding schemes is "a behavior". Blocks in Pharo are behaviors. So I think the "block" that confuses you is "a packet forwarding behavior". When your node decides that the proper way to handle a packet it has received is to forward it (option #1), it must supply two things: The packet to be forwarded, and the forwarding behavior, which will be a block. In this way, your code is more flexible: By changing the block that you provide to the forwarding method, you can change the algorithm that the node uses to decide which link(s) to forward the packet on. And once you have your application finished, and you have more than one forwarding scheme defined, you will be able to run you application, once for each different forwarding scheme, and see how the packets flow through the network -- which will show you (visually) which forwarding schemes are efficient (i.e., minimizing the number of node-to-node transfers) and which are inefficient (i.e., resulting in many node-to-node transfers, most of which are unproductive). You will find that (in general) the easiest forwarding schemes to write code for are also the least efficient schemes. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 25, 2020

Re: [Pharo-users] mentor question 1

by Richard Sargent

On Sat, Apr 25, 2020, 15:50 tbrunz <wild.ideas(a)gmail.com> wrote: > Hi Richard, > > I looked the repo; he's defined 3 classes: one for packets, one for nodes, > and one for links. So yes, he instantiates links. Likely each node has a > collection of links (each of which leads to another node in the network). > The application is to simulate a network by modeling it in ST, so that > means > generating packets, each with a destination node (where nodes have > addresses), and simulating how the packets flow through the network to get > from their source nodes to their destination nodes. > > I hadn't though about sending the blocks to the nodes via the packets, but > that *is* a cool concept... And entirely do-able in Pharo. However, if the > exercise is to make a simple network model that runs to simulate network > operation, I doubt that's what they're looking for, though (since it's not > what you typically do in a packet network). I think they just want you to > model the packet-handling behavior, and that's what the block is for. (I > may be wrong.) > Thanks, Ted. That makes sense. I agree the problem is almost certainly not about sending blocks. Silly of me, really. I didn't see anything in this thread that explained the block. I could imagine that a link object knows how to deliver a packet to the node and the node object knows how to receive the packet. (Or something like that) > -Ted > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 25, 2020

Re: [Pharo-users] mentor question 1

by tbrunz

Hi Richard, I looked the repo; he's defined 3 classes: one for packets, one for nodes, and one for links. So yes, he instantiates links. Likely each node has a collection of links (each of which leads to another node in the network). The application is to simulate a network by modeling it in ST, so that means generating packets, each with a destination node (where nodes have addresses), and simulating how the packets flow through the network to get from their source nodes to their destination nodes. I hadn't though about sending the blocks to the nodes via the packets, but that *is* a cool concept... And entirely do-able in Pharo. However, if the exercise is to make a simple network model that runs to simulate network operation, I doubt that's what they're looking for, though (since it's not what you typically do in a packet network). I think they just want you to model the packet-handling behavior, and that's what the block is for. (I may be wrong.) -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 25, 2020

Re: [Pharo-users] mentor question 1

by Richard Sargent

On Sat, Apr 25, 2020, 11:46 Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Op 25-4-2020 om 20:17 schreef Roelof Wobben: > > Op 25-4-2020 om 20:04 schreef tbrunz: > >> 1. 'loopback' is a node, just like 'source' and 'destination'. A > >> network is > >> a mesh of 'nodes' joined by 'links'. Your Pharo program represents > >> one of > >> those nodes: It is the 'loopback' node. > > > > oke, so I can do : loopback := KNetworkNode new. > > > >> 2. The block in the #linksTowards:do: method is the action to take on a > >> packet, depending on whether its destination is "you" (loopback), or > >> something else. > >> > >> The flood algorithm is the simplest algorithm: "If the destination is > >> not > >> me, send the packet to everyone else (except the one who sent it to > >> me)." > > > > > > and that part I still do not see. I "fail" to see what the block > > exactly is. > > > >> However, there is the possibility of loops in the network, so a slightly > >> better algorithm is to check "have I seen this packet before?" and if > >> the > >> answer is "yes", then drop it; otherwise send it via my links. This will > >> prevent endless packet sending loops in your network. > >> > >> -t > >> > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > > > Oke, > > Did some thinking and see how things are working if the loopback is not > used : > > linksTowards: anAddress do: aBlock > "Simple flood algorithm: route via all outgoing links. > However, just loopback if the receiver node is the routing destination." > > address = anAddress > ifTrue: [ ] > ifFalse: [ outgoingLinks do: aBlock ] > > but still I "fail" to see what need to be done when the loopback is > used with the block. > It's not clear to me if a link is an actual object in your model. I'll respond as if it is. aBlock is the work you want done on the destination node. So, the question is how you get it there. You iterate through the outgoingLinks and ask the link to deliver the block to the destination node. In "blasting", each node sends it on through its own outgoingLinks, until it eventually reaches the destination node. The destination node evaluates aBlock, probably supplying itself as an argument to the block. In the case of a loopback, the node itself seems to be the one intended to evaluate aBlock. (I don't know the problem description, so that may not be entirely correct.) > Roelof > > >

April 25, 2020

[ANN] Cheer for THE Medusa - the single Smalltalk based battle snake

by Jerry Kott

Hi lists, you may recall a mention of Battlesnake in these forums before. Today, the Battlesnake team is holding an online tournament that you can watch live on Twitch: https://www.twitch.tv/battlesnakeofficial <https://www.twitch.tv/battlesnakeofficial>. My entry THE Medusa is the only Smalltalk-based battlesnake in the competition. Itâs listed in the Group D of the Veteran division. Not sure when itâs going be on - currently the Rookie division is playing. I hope you can join, watch, have some fun, get inspired to write and enter your own Smalltalk based snakes for future competition (the arenas are open year-round so you have plenty of time to test your snakes), and if you can, donate a small amount to Food Banks Canada in support of families affected by COVID-19. Cheers, stay safe & stay healthy. Jerry Kott This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5

April 25, 2020

Re: [Pharo-users] mentor question 1

by Roelof Wobben

Op 25-4-2020 om 20:17 schreef Roelof Wobben: > Op 25-4-2020 om 20:04 schreef tbrunz: >> 1. 'loopback' is a node, just like 'source' and 'destination'.Â A >> network is >> a mesh of 'nodes' joined by 'links'.Â Your Pharo program represents >> one of >> those nodes: It is the 'loopback' node. > > oke, so I can do : loopback := KNetworkNode new. > >> 2. The block in the #linksTowards:do: method is the action to take on a >> packet, depending on whether its destination is "you" (loopback), or >> something else. >> >> The flood algorithm is the simplest algorithm: "If the destination is >> not >> me, send the packet to everyone else (except the one who sent it to >> me)." > > > and that part I still do not see. I "fail"Â to see what the block > exactly is. > >> However, there is the possibility of loops in the network, so a slightly >> better algorithm is to check "have I seen this packet before?" and if >> the >> answer is "yes", then drop it; otherwise send it via my links. This will >> prevent endless packet sending loops in your network. >> >> -t >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > Oke, Did some thinking and see how things are working if the loopback is not used : linksTowards: anAddress do: aBlock Â Â Â "Simple flood algorithm: route via all outgoing links. However, just loopback if the receiver node is the routing destination." Â Â Â address = anAddress Â Â Â Â Â Â ifTrue: [Â ] Â Â Â Â Â Â ifFalse: [ outgoingLinks do: aBlock ] but still I "fail"Â to see what need to be done when the loopback is used with the block. Roelof

April 25, 2020