- Pharo-users - lists.pharo.org

mentor question 2.
by Roelof Wobben April 26, 2020

April 26, 2020

Hello, I have to make some code that convert a binary to a decimal and im not allowed to use the convert methods that Pharo has. So I have written this : decimalFromBinary: aString Â Â Â | result isValid | Â Â Â isValid = self isValidBinary: aString. Â Â Â isValid Â Â Â Â Â Â ifTrue: [ result := 0. Â Â Â Â Â Â Â Â Â aString reverse Â Â Â Â Â Â Â Â Â Â Â Â withIndexDo: Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ :digit :index | result := result + (digit digitValue * (2 raisedTo: index - 1)) ]. Â Â Â Â Â Â Â Â Â ^ result ] Â Â Â Â Â Â ifFalse: [ ^ nil ] isValidBinary: aString Â Â Â ^ aString allSatisfy: [ :c | c = 0 or: [ c = 1 ] ] but on the first method I see a message that the temp variables are read before written. and the second one I see a message that I use a or instead of searching literals. Where didÂ I think wrong here ? Roelof

1 0

Re: [Pharo-users] mentor wanted
by Richard O'Keefe April 26, 2020

April 26, 2020

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 >

2 1

Re: [Pharo-users] mentor question 1
by Richard Sargent April 25, 2020

April 25, 2020

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 > > >

2 4

Re: [Pharo-users] mentor question 1
by tbrunz April 25, 2020

April 25, 2020

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

1 0

[ANN] Cheer for THE Medusa - the single Smalltalk based battle snake
by Jerry Kott April 25, 2020

April 25, 2020

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

1 0

Re: [Pharo-users] mentor question 1
by tbrunz April 25, 2020

April 25, 2020

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. 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)." 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

2 2

mentor question 1
by Roelof Wobben April 25, 2020

April 25, 2020

1 0

Re: [Pharo-users] mentor wanted
by Richard O'Keefe April 25, 2020

April 25, 2020

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? On Thu, 23 Apr 2020 at 23:16, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello, > > I like Pharo a lot but I hit a wall very often. > With complex problems I do not see how to solve things in small steps. > > Is there somewhere who is willing to mentor me in how I can overcome > that problem. > > Roelof > >

3 2

Re: [Pharo-users] All file accesses get externalCalledFailed exceptions.
by Tim Mackinnon April 24, 2020

April 24, 2020

H Michael- that seems strange, I just tried the following on a Pharo8 with Catalina: OSPlatform current currentWorkingDirectoryPath. > /Users/macta/Dev/Smalltalk/Pharo/Pharo 8.0 - 64bit Iâm using PharoLauncher, although my images are not stored in Documents, but ~/Dev/Smalltalk/Pharo (I adjusted the launcher settings). Not sure if that makes a difference? Or - perhaps you didnât allow Pharo disk read privileges (that is a new security check in Catalina - see the OSX System Preferences, Security and Privacy, Files and Folders. Mine has a pharo entry with access to Downloads, Documents and Desktop). Tim > On 22 Apr 2020, at 10:25, Michael Burns via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Michael Burns <michaelburns(a)mac.com> > Subject: All file accesses get externalCalledFailed exceptions. > Date: 22 April 2020 at 10:25:56 BST > To: Pharo users <pharo-users(a)lists.pharo.org> > > > Newbie to Pharo > Just installed the latest 8.0 stable image. > Some things work, but anything I do to access any files gets an exception dealing with getcwd in libc.dylib. > > I am running MacOS Catalina. > I searched and found the lib.dylib file and it is an alias to another .dylib file. > > Is there something else I need to install or configure? > > <e876cb42-0161-4573-bdb7-0bf57c073efb.png> > Sent from my iPad >

2 1

April 24, 2020

Found the link. As I guess not legal, I send private. Iâve the book. I liked it if I remember ;) https://doc.lagout.org/programmation/Smalltalk/Smalltalk%20-%20Objects%20an… Cheers, CÃ©drick

2 2