- Pharo-users - lists.pharo.org

Re: [Pharo-users] ARM vm limitations ?

by Mariano Martinez Peck

On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi, I'd like to play around with pharo on ARM devices (like a > HummingBoard, the ones from ODROID or one of the beagleboards). But I am > not sure if I have to take care of the ARM architecture version (ARMv6 / > ARMv7 / ARMv8) when choosing my toy. > > I found this vm: > http://files.pharo.org/vm/pharo-spur32/linux/armv6/ > Is it only for armv6 like the folder name says or is ARMv7 and ARMv8 > working too? > > Are there any limitations I should know before choosing a ARM device? > > Is there a vm for 64bit (aarch64)? > Hi Albrecht, I am also interested in this answer. In general, I am interested in IoT support for Smalltalk. The only thing I found aside from ARMv6 is this: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM… But I don't know what's the status of it. You may have more chances to get an answer with the vm list: <vm-dev(a)lists.squeakfoundation.org> Or maybe Pharo dev list. Cheers, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 9, 2019

Re: [Pharo-users] Richard Kenneth Eng is NOT Mr. Smalltalk

by horrido

BTW, I've also said many unkind things about Python. And C++. And Scala and Swift. But I'm being criticized for what I've said about JavaScript? Really??? There is certainly no hint of bias here. Michael J. Zeder wrote > Hey Ben, > > I leave it with this answer, as you suggested, thank you for picking up > the ball! > First, I admit again, I have thought about it one whole day, if and how > I should do this "intervention", which is absolutly not my usual style, > but I decided for myself, to be intentionally blunt, provocative, and > parade his virtual presence around here in front of all Pharo users... > In the hope that this kicks off something and, of course, that it will > not be the final word. > > I tried to avoid being seen as the hurt one (seems, that I did not > quite succeed with this). Javascript is most popular, so R.K. Eng > cannot damage this platform with his â let's say... â "opinions", > but he can damage Smalltalk and its small community. So I started with > making noise, not with the story from my client's managers, who > dismissed Pharo, because of his highly ranked Google search results â > last year (But in fact, I was annoyed two days ago, I was googling > actually a very specific topic about compiler optimization in > prototype-based OO, and R.K. Engs ill-informed superficial "lecturing" > rants showed up again at third or fourth place, I think, sigh). > > Short answers to your questions: > > * Yep, one main concern is his connection between Smalltalk advocacy > and discrediting other languages â or making dogmatic, condescending > and un-empirical statements of strong typing over weak typing, or > class-based over prototype-based OO etc. Just separate that clearly. JS > has huge momentum (IMHO absolutly justified), and it would be advisable > to say something like "Hey, you like JS? Then look at ST, it is similar > but the 'original thing', more pure, and takes the basic concepts even > further". > > * I have to correct myself concerning "wrong statements about ST": it > is not so much, that he writes "wrong" things about Pharo, but it is > more that R.K.Eng often uses old 1980ies marketing language (like "It > is just objects all the way down!"). That was nice back then, a > completely new way of thinking, but today, a whole bunch of languages > has sprung up from this legacy (dynamic, OO, introspection etc.), among > them JS, and have taken the concepts to new forms. His superficial > knowledge combined with the over-confident and condescending attitude > scares away interested people. The quote I mentioned ("just object all > the way down") was one of the blog topics the managers, to whom I tried > to advertise Pharo, found ridiculous and laughed at it ("does it work > by magic then? What are the primitives and basic value types then?" > etc). > > * Pushing ones own projects is fine, again. But all his publicity > effort have a strong taste (maybe it is cultural), that he wants > control public perception of the community (and thus steering it). > Being "Mr. Smalltalk" is extremly presumptive, in German it would > usually refer to an official spokesperson (I think actually, for native > English speakers, too...). And if I remember correctly, he did not get > a warm welcome, true, but before that, he showed up without any > Smalltalk background and just proclaimed himself the new > project/marketing manager, without ever asking, what the community > actually needs and what the current state is. > > * The top search results in Google are a major concern for every FOSS > project... > > * If a person constantly and loudly points out that he is "altruistic", > and that his self-initiated work (unasked, and reasonably rejected in > part) would be worth a lot of money, than this is the opposite of > altruistic... Again, maybe a cultural thing. > > But yes, I like to see becoming this a success story. > Thank you! M > > > > Am Fr, 1. MÃ¤r, 2019 um 6:15 NACHMITTAGS schrieb Ben Coman > < > btc@ > >: >> Hi Michael, >> >> Thanks for your thoughtful followup. >> >> On Fri, 1 Mar 2019 at 19:59, Michael Zeder < > post@ > > >> wrote: >>> >>> I have carefully thought about, if I should really go publicly >>> against one person within the community, and to start this "tirade", >>> including the possibility that this causes an escalation, of course >>> you cannot/must not silence a person ("Streisand" effect, did not >>> know the term, but very fitting). But I decided that this kind of >>> public conflicts is what is needed (and will make the community look >>> better, not worse), _if_ a certain point is reached. >> >> I certainly subscribe to the tenet "Community standards do not >> maintain themselves: They're maintained by people actively applying >> them, visibly, in public." [1] >> And I understand the tension in deciding to do so, with the >> accompanying risk of making things worse (been there myself) >> For me what weakened your first post was the name calling and sense >> you were coming from a position of hurt with a story you needed to >> justify by "making him wrong". :) >> Much better second time round. >> >> [1] http://www.catb.org/esr/faqs/smart-questions.html#not_losing >> >> >>> I stand by it, but have reconsidered some points: >>> * I do (did) not call for _immediate_ exclusion, but an >>> "admonishment" that if certain behaviour is not about to change >>> fundamentally, the community will have to act (by publicly >>> separating this individual out). >>> * Take older articles down, which start flamewars against other >>> languages, or more precise: separate them from Smalltalk advocacy! >>> If he wants to flame JS (for its various birth defects), fine, but >>> don't connect that with pro-Smalltalk articles, for example. >> >> That seems a reasonable position and a good way to frame it. >> >> >>> * Community efforts shall follow follow some community consensus. >>> Core developers are no dictators, of course, but they are the ones >>> knowing, what the state of the project is, and where _their_ work >>> will lead to. Constantly ignoring this common guidance is >>> detrimental to the community. So either, learn Smalltalk core coding >>> and challenge the leadership, or do accept that there is some common >>> agenda (and there are lots of open tasks: writing tutorials, >>> documentation, make old scientific research available, linking and >>> connecting showcases). >> >> His earlier articles got hammered and its natural that created a >> defensive position for him to disconnect from the community >> leadership. >> The trick as for everyone is to not carry those forever and try >> starting anew. >> >> >>> * Public opinion does matter. The fact I mentioned Google SEO was >>> indeed the starting point for me, to get into or start this flame >>> war. Here is my story: >>> Two of my clients (medium-sized enterprises) are classical C++/C# >>> Windows development companies. I advertised Pharo to them for an >>> _internal_ tool (their commerical products won't change to Smalltalk >>> of course, but for their own internal dev tasks, Pharo whould have >>> been a nice fit). When the managers got back to me, they had googled >>> it, and told me, this thing sounds very dubious ("unseriÃ¶s"). I >>> enquired, what they had read, and they told me, this "spokesperson" >>> (sic!!!) sounds like a trolling script kid, and they can't employ >>> something which is developed (sic!!!) by such people. After some >>> explanation, I managed to convince them, that this person is just a >>> lonely person, who showed up out of nowhere, is not involved in the >>> actual work, and just produces himself on the internet. But too >>> late, their impression on Smalltalk was already formed by R.K.Engs >>> "blogs" (in the meantime, they rank on top in Google search result). >> >> You should have led with that !!!! An experience has a lot more >> power than an opinion. >> >> >>> When I did some research of my own yesterday, and saw again, that >>> R.K. Engs dubious blog entries were listed on top, I decided to take >>> action. >>> >>> >>> I like to answer to your balanced and thoughtful responses: >>> >>>> You may disagree about *how* he does such work, the actual content, >>>> for sure, but that's a feedback better directed to mr. Eng himself. >>> >>> R.K. Eng has made it clear in the past many many times in uncertain >>> wording, that he is not willing to follow community advice in these >>> matters, if his gut is telling him something different... >>> >> >> Some of that community advice has been delivered fairly >> confrontation-ally and not really conducive to having someone listen. >> >>>> Hopefully I've expressed a balanced enough position that this >>>> doesn't draw too many responses. >>>> >>> yes, you did. thank you. >>> >>> >>>>> I agree "Mr Smalltalk" is quite a presumptive title, but really >>>>> anyone following the mail lists soon gets an idea of who are the >>>>> community merit leaders. >>> >>> Well, I disagree, based on the experience, I have written down >>> above. The internet is very much about who is in the center of the >>> focus (SEO/social media). Anybody new to Smalltalk will at first >>> glance identify our community with this "spokesperson" (as I have >>> experienced with two people, last year already btw) >> >> Point taken. >> >> >>> Maybe it is a language thing, but "Mr. Smalltalk" is _extremely_ >>> presumptive (in German, it means the embodiment of the denoted >>> thing). If a person is not doing very very thorough reading of ages >>> old mail list discussions or is researching, that this person in >>> fact never committed any code to the repos, then any newcomer will >>> think, this "Mr. Smalltalk" is at least a versed and informed >>> Smalltalk developer (which, given his newbie questions he is >>> absolutely not). >> >> Got it. So apart from fighting directly against his presumption to >> the title (which seems difficult) >> would cleaning some other-language-denigration from old articles go >> some way towards mitigating your concern? >> >>>>> You are right he hasn't committed any code, but I've not actually >>>>> seen him claim credit for any code in Pharo, so this point seems >>>>> off. >>> true. but as I just wrote, that is what people presume, given his >>> way and manner of producing himself. If he wrote honestly wrote "I >>> am a fanboy, supporter and advocate of Smalltalk...", great! But he >>> claims he worked many many hours without a dime, but worth many >>> dollars, and had "tremendous success" in creating a new Smalltalk >>> wave. >> >> I'm pretty by many-hours-without-a dime he meant his evangelism. >> If it didn't come across like that, that is probably specific >> copy-edit feedback that would be useful to him. >> >>>>>> * ...is doing SEO to make Google show his own results before FOSS >>>>>> community or sciences pages. >>>>> I think its equally likely that most in our community are too busy >>>>> coding to try getting articles ranked, >>>>> so its more lack of effort by most of us. Most of his articles >>>>> mention Pharo so people end up finding us anyway. >>> might be true (some criticism to the community agenda..? different >>> topic) >>> The thing is, the wrong information are getting more and more in the >>> focus of the internet, pushing aside the community-driven Pharo >>> sites (or real scientific papers or well-done tutorials). >> >> I've read most of his articles. I don't think he gets much factually >> wrong about Pharo (and has corrected those when pointed out). >> It seems your main concern about wrong information is attacks on >> other languages, which is fair. >> >> >>>>> Any money he gets for his writing is not anything that concerns me >>>>> personally. Those articles are his own effort. >>> >>> Sorry, misunderstanding! Of course, he may earn with his writing, >>> whatever he gets for it. >>> I was referring to the "up-coming" Smalltalk Coding Competition. >> >> btw, a few weeks ago when Richard asked for help to program the >> competition, I volunteered. >> I've criticized some of his articles, and maybe there are other >> "better" the money could be spent, >> but I admire he has stuck to his vision and think its a big thing he >> has taken on. >> If its going to happen anyway, for me its better to help make it a >> success than a flop. >> [Sidebar: I haven't managed to do much on it yet since I'm run ragged >> on a personal development course until mid-April >> that includes running a community project of my own... >> https://www.nanpopcode.fun/] >> >> >>> Now, yes, that money doesn't go into his own pockets (would be >>> criminal fraud), but the thing is, he controls this money. >>> Who will be the judges? Who will set parameters for the competition? >>> Transparency? >>> What is the benefit that goes back into the community? Now, it is >>> fine, that he is pushing for things like that, but again, he is >>> doing it without synchronising this effort with what is needed by >>> the community. >> >> He got a reasonable number of supporters on GoFundMe (I wasn't one at >> the time), >> and I believe the majority of the money comes from a few companies >> so I expect its really their opinion that counts about how their >> money is spent. >> >> >>>>>> * ...denies community leadership by merit (Pharo core developers >>>>>> do know, what they have created and where they want to go in the >>>>>> future, >>>>> I don't see him claiming leadership of our community or trying to >>>>> set our agenda. >>>>> He just didn't let community criticism of his writing slow him >>>>> down. >>>>> All I observed is that several people bit him and he bit back - >>>>> fairly usual sort of poor communication on both sides (including >>>>> me). >>> >>> Well, as written above, the manner of his web appearance is >>> implicitly a claim of community leadership. Not an exclusive one of >>> course, but he wants to be perceived of one of the most important >>> persons in the community (he told so many times, explicitly). And >>> given my experience, read above, this had already a (negative) >>> success with it. >>> And I think he is setting agenda: "Make Smalltalk great/mainstream >>> again" is the baseline, and that is something, only the core dev >>> team and the community as a whole can decide/make happen (I love >>> Smalltalk, but he promises wrong things, so if, just for example, >>> C++/Qt devs or _modern_ JS devs have a first look at Smalltalk with >>> the expectation they could already do the same thing as in their >>> usual platforms, they will be disappointed --> synchronize a >>> marketing agenda with what this great project currently is about, >>> but he is not willing to cooperate with the core dev team) >> >> Fair enough. Since in a couple of months I'll be helping him out, >> I'll have an opportunity to raise these concerns with him. >> >>>>> Him swearing about a group of Pharo people is good ammunition to >>>>> bring to the mail list to support your point, >>>>> but I also see he was rather provoked. Overall I feel this >>>>> extract was better left in that small corner of the internet >>>>> rather than fan flames here. >>> >>> :) Yeah... no! I think this is really a central point (so I put him >>> in the pillory here with intent). There is something called >>> community/FOSS ethics and structures. >>> He does not show _respect_ towards those people, who did the work, >>> but produces himself, and pushes for things, which the people who >>> devoted their work to this project, told him that it is >>> counter-productive. That is, in the long-run, a very dangerous >>> situation. >> >> I agree, its not great. But he didn't get a warm welcome and some of >> his early interactions were abrasive. >> Considering two extremes, you can either be inclusive and hopefully >> nurture/mold, or exclude and lose any chance at that. >> Like a lot of things, the path is somewhere in the middle and needs a >> bit of give and take on both sides. >> >>>>>> PS: a side note on Javascript (with lower S). wether you love or >>>>>> hate this quirky lovechild of Lisp and Self/Smalltalk, telling JS >>>>>> developers they are stupid and that they should abandon powerful >>>>>> Vue.js, for example, in favor of Amber Smalltalk [cudos to Amber >>>>>> devs! great thing!]) is utterly stupid! >>>>> Agree. But banning everyone in the world for similar stupidity >>>>> would leave the internet awfully quiet. >>> Sure! Again: I am against silencing or banning anybody (and how >>> could you). But if this becomes unbearable, there needs to be a >>> public separation, so he does not drag the project down. People need >>> to speak up against such usurpation. >> >> I appreciate the stand your are taking for the community. >> I've gained from your share of your workplace experience. >> >>>>>> (which in the end are only a self-serving, ego-centric, >>>>>> attention-greedy campaign to promote "Mr. Smalltalk" himself, a >>>>>> total newbie, who claims credit for the work of others). >>>>> Your repeated "claims credit for the work of others" is quite >>>>> provocative and I haven't noticed this in his writings. Could you >>>>> provide a link? >>> >>> See above, maybe it is a cultural thing, but as I told in my >>> experience, all of his appearance screams for being recognized as >>> one of the most important persons in the community (he is >>> condescendingly mocking marketing efforts of the last 40 years, >>> claims that he is the one who will "make smalltalk great again"...) >>> >>> Yes I am provocative this time, not my normal style (and I admit, I >>> was tripped-out by his provocative blog title "Even people who >>> understand prototypal programming do not like it â an inconvienent >>> truth"; that is dripping off arrogance and ignorance... And sheds a >>> bad light on Smalltalk, with which he wants to be identified in the >>> web) >> >> Got it. >> Let me ask to park this thread for the moment, because it can be >> quite distracting if everyone chips in an opinion. >> I think you've made some fair points and I'll put myself on the line >> to discuss them with Richard when I start helping him with his >> competition project. >> >> cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 9, 2019

Re: [Pharo-users] Richard Kenneth Eng is NOT Mr. Smalltalk

by horrido

I just accidentally came across this thread. I feel I have to provide some clarifications... First of all, the sobriquet "Mr. Smalltalk" started way back in October of 2016 with this article <https://medium.com/@richardeng/domo-arigato-mr-smalltalk-aa84e245beb9> . It was meant as a marketing gimmick to take advantage of the popularity of the Mr. Robot television series. I figured it would be a good way to attract attention. After all, /that's what marketing is all about/. I had no intention of making this an egotistical thing. I don't care to be a representative of the Smalltalk community. My one and only priority is to market Smalltalk any way I can, something that I made perfectly clear in the article and something that I have adhered to unwaveringly over the past several years. Second, I have never denigrated the contributions of the Smalltalk community. I applaud their efforts. However, I feel I must remain true to my mission: to market Smalltalk (and Pharo). People may disagree with my marketing strategy. That's fine. I cannot make everybody happy. But let's be very clear: many people also *agree* with my marketing strategy. So, who should I listen to? The answer is: nobody. On what basis would I allow others to influence my strategy? There is no central governing body for Smalltalk in all of its various incarnations (Pharo, Squeak, GNU Smalltalk, Dolphin Smalltalk, Cuis Smalltalk, VisualWorks, VA Smalltalk, GemStone/S, etc.). Trying to obtain consensus among such a broad range of communities would be pure folly. Third, I am entitled to my opinions, just as everyone else in this world is. My opinion is that Smalltalk (and Pharo) is a great language that deserves better marketing. There are some who disagree with me. Many people have told me that Smalltalk is moribund and way past its due date. I accept disagreement, but I don't have to let it stop me. My opinion is that JavaScript is a shit language. There are some who disagree with me. I accept disagreement, but I don't have to let it stop me. Michael Zeder is clearly a JavaScript fan. However, I can tell you that at Quora, where I often express my opinions about JavaScript, tens of thousands have upvoted my answers. In other words, there is tremendous support for my position. Again, who should I listen to? Let's be very clear about this: Only a JavaScript fan would be turned off by my opinions. JavaScript critics love me for them. It seems to me that Mr. Zeder's criticism of me is based almost entirely on the fact that he greatly admires JavaScript. Is that fair? Fourth, the culmination of my marketing campaign is JRMPC <https://jrmpc.ca> . After this, I'm done. Support for JRMPC has been quite positive. This was very clear at the Salta conference last November <https://hackernoon.com/my-keynote-at-the-salta-conference-435dfaccc888> . Vance Kershner of LabWare was impressed enough by my campaign to support me. At GoFundMe, none other than Alan Kay and Kent Beck also supported me. Alan Kay and Kent Beck!!!!! Whoa, that just blew my mind! So you know what? I don't feel I need to apologize for my efforts. I'm not seeking gratitude (though it would be nice to receive some). Finally, let me say, I'm not happy with my name showing up in SEO all over the place, either. I have never wanted to be the centre of attention. I wanted Smalltalk (and Pharo) to be in the limelight. But what I can do? That's the price I have to pay for marketing Smalltalk aggressively. I leave you with this Oscar Wilde quote: "There is only one thing in life worse than being talked about, and that is not being talked about." Hopefully, people are talking about Smalltalk. Ben Coman wrote > Hi Michael, > > Thanks for your thoughtful followup. > > On Fri, 1 Mar 2019 at 19:59, Michael Zeder < > post@ > > wrote: > >> >> I have carefully thought about, if I should really go publicly against >> one >> person within the community, and to start this "tirade", including the >> possibility that this causes an escalation, of course you cannot/must not >> silence a person ("Streisand" effect, did not know the term, but very >> fitting). But I decided that this kind of public conflicts is what is >> needed (and will make the community look better, not worse), _if_ a >> certain >> point is reached. >> > > I certainly subscribe to the tenet "Community standards do not maintain > themselves: They're maintained by people actively applying them, visibly, > in public." [1] > And I understand the tension in deciding to do so, with the accompanying > risk of making things worse (been there myself) > For me what weakened your first post was the name calling and sense you > were coming from a position of hurt with a story you needed to justify by > "making him wrong". :) > Much better second time round. > > [1] http://www.catb.org/esr/faqs/smart-questions.html#not_losing > > > >> I stand by it, but have reconsidered some points: >> * I do (did) not call for _immediate_ exclusion, but an "admonishment" >> that if certain behaviour is not about to change fundamentally, the >> community will have to act (by publicly separating this individual out). >> > * Take older articles down, which start flamewars against other languages, >> or more precise: separate them from Smalltalk advocacy! If he wants to >> flame JS (for its various birth defects), fine, but don't connect that >> with >> pro-Smalltalk articles, for example. >> > > That seems a reasonable position and a good way to frame it. > > > >> * Community efforts shall follow follow some community consensus. Core >> developers are no dictators, of course, but they are the ones knowing, >> what >> the state of the project is, and where _their_ work will lead to. >> Constantly ignoring this common guidance is detrimental to the community. >> So either, learn Smalltalk core coding and challenge the leadership, or >> do >> accept that there is some common agenda (and there are lots of open >> tasks: >> writing tutorials, documentation, make old scientific research available, >> linking and connecting showcases). >> > > His earlier articles got hammered and its natural that created a defensive > position for him to disconnect from the community leadership. > The trick as for everyone is to not carry those forever and try starting > anew. > > > * Public opinion does matter. The fact I mentioned Google SEO was indeed >> the starting point for me, to get into or start this flame war. *Here is >> my story*: >> Two of my clients (medium-sized enterprises) are classical C++/C# Windows >> development companies. I advertised Pharo to them for an _internal_ tool >> (their commerical products won't change to Smalltalk of course, but for >> their own internal dev tasks, Pharo whould have been a nice fit). When >> the >> managers got back to me, *they had googled it, and told me, this thing >> sounds very dubious ("unseriÃ¶s"). I enquired, what they had read, and >> they >> told me, this "spokesperson" (sic!!!) sounds like a trolling script kid, >> and they can't employ something which is developed (sic!!!) by such >> people*. >> After some explanation, I managed to convince them, that this person is >> just a lonely person, who showed up out of nowhere, is not involved in >> the >> actual work, and just produces himself on the internet. But too late, >> their >> impression on Smalltalk was already formed by R.K.Engs "blogs" (in the >> meantime, they rank on top in Google search result). >> > > You should have led with that !!!! An experience has a lot more power > than > an opinion. > > > >> When I did some research of my own yesterday, and saw again, that R.K. >> Engs dubious blog entries were listed on top, I decided to take action. >> >> >> I like to answer to your balanced and thoughtful responses: >> >> You may disagree about *how* he does such work, the actual content, for >> sure, but that's a feedback better directed to mr. Eng himself. >> >> >> R.K. Eng has made it clear in the past many many times in uncertain >> wording, that he is not willing to follow community advice in these >> matters, if his gut is telling him something different... >> >> > Some of that community advice has been delivered fairly confrontation-ally > and not really conducive to having someone listen. > > >> Hopefully I've expressed a balanced enough position that this doesn't >> draw >> too many responses. >> >> yes, you did. thank you. >> >> >> I agree "Mr Smalltalk" is quite a presumptive title, but really anyone >>> following the mail lists soon gets an idea of who are the community >>> merit >>> leaders. >>> >> >> Well, I disagree, based on the experience, I have written down above. The >> internet is very much about who is in the center of the focus (SEO/social >> media). Anybody new to Smalltalk will at first glance identify our >> community with this "spokesperson" (as I have experienced with two >> people, >> last year already btw) >> > > Point taken. > > > Maybe it is a language thing, but "Mr. Smalltalk" is _extremely_ >> presumptive (in German, it means the embodiment of the denoted thing). If >> a >> person is not doing very very thorough reading of ages old mail list >> discussions or is researching, that this person in fact never committed >> any >> code to the repos, then any newcomer will think, this "Mr. Smalltalk" is >> at >> least a versed and informed Smalltalk developer (which, given his newbie >> questions he is absolutely not). >> > > Got it. So apart from fighting directly against his presumption to the > title (which seems difficult) > would cleaning some other-language-denigration from old articles go some > way towards mitigating your concern? > > >> You are right he hasn't committed any code, but I've not actually seen >> him >>> claim credit for any code in Pharo, so this point seems off. >>> >> true. but as I just wrote, that is what people presume, given his way and >> manner of producing himself. If he wrote honestly wrote "I am a fanboy, >> supporter and advocate of Smalltalk...", great! But he claims he worked >> many many hours without a dime, but worth many dollars, and had >> "tremendous >> success" in creating a new Smalltalk wave. >> > > I'm pretty by many-hours-without-a dime he meant his evangelism. > If it didn't come across like that, that is probably specific copy-edit > feedback that would be useful to him. > > >> * ...is doing SEO to make Google show his own results before FOSS >>>> community or sciences pages. >>>> >>> I think its equally likely that most in our community are too busy >>> coding >>> to try getting articles ranked, >>> so its more lack of effort by most of us. Most of his articles mention >>> Pharo so people end up finding us anyway. >>> >> might be true (some criticism to the community agenda..? different topic) >> The thing is, the wrong information are getting more and more in the >> focus >> of the internet, pushing aside the community-driven Pharo sites (or real >> scientific papers or well-done tutorials). >> > > I've read most of his articles. I don't think he gets much factually > wrong > about Pharo (and has corrected those when pointed out). > It seems your main concern about wrong information is attacks on other > languages, which is fair. > > > >> Any money he gets for his writing is not anything that concerns me >>> personally. Those articles are his own effort. >>> >> >> Sorry, misunderstanding! Of course, he may earn with his writing, >> whatever >> he gets for it. >> I was referring to the "up-coming" Smalltalk Coding Competition. >> > > btw, a few weeks ago when Richard asked for help to program the > competition, I volunteered. > I've criticized some of his articles, and maybe there are other "better" > the money could be spent, > but I admire he has stuck to his vision and think its a big thing he has > taken on. > If its going to happen anyway, for me its better to help make it a success > than a flop. > [Sidebar: I haven't managed to do much on it yet since I'm run ragged on a > personal development course until mid-April > that includes running a community project of my own... > https://www.nanpopcode.fun/] > > > >> Now, yes, that money doesn't go into his own pockets (would be criminal >> fraud), but the thing is, he controls this money. >> > Who will be the judges? Who will set parameters for the competition? >> Transparency? >> > What is the benefit that goes back into the community? Now, it is fine, >> that he is pushing for things like that, but again, he is doing it >> without >> synchronising this effort with what is needed by the community. >> > > He got a reasonable number of supporters on GoFundMe (I wasn't one at the > time), > and I believe the majority of the money comes from a few companies > so I expect its really their opinion that counts about how their money is > spent. > > > >> * ...denies community leadership by merit (Pharo core developers do know, >>>> what they have created and where they want to go in the future, >>>> >>> I don't see him claiming leadership of our community or trying to set >>> our >>> agenda. >>> He just didn't let community criticism of his writing slow him down. >>> All I observed is that several people bit him and he bit back - fairly >>> usual sort of poor communication on both sides (including me). >>> >> >> Well, as written above, the manner of his web appearance is implicitly a >> claim of community leadership. Not an exclusive one of course, but he >> wants >> to be perceived of one of the most important persons in the community (he >> told so many times, explicitly). And given my experience, read above, >> this >> had already a (negative) success with it. >> And I think he is setting agenda: "Make Smalltalk great/mainstream again" >> is the baseline, and that is something, only the core dev team and the >> community as a whole can decide/make happen (I love Smalltalk, but he >> promises wrong things, so if, just for example, C++/Qt devs or _modern_ >> JS >> devs have a first look at Smalltalk with the expectation they could >> already >> do the same thing as in their usual platforms, they will be disappointed >> --> synchronize a marketing agenda with what this great project currently >> is about, but he is not willing to cooperate with the core dev team) >> > > Fair enough. Since in a couple of months I'll be helping him out, I'll > have an opportunity to raise these concerns with him. > > >> Him swearing about a group of Pharo people is good ammunition to bring to >>> the mail list to support your point, >>> but I also see he was rather provoked. Overall I feel this extract was >>> better left in that small corner of the internet >>> rather than fan flames here. >>> >> >> :) Yeah... no! I think this is really a central point (so I put him in >> the >> pillory here with intent). There is something called community/FOSS >> ethics >> and structures. >> He does not show _respect_ towards those people, who did the work, but >> produces himself, and pushes for things, which the people who devoted >> their >> work to this project, told him that it is counter-productive. That is, in >> the long-run, a very dangerous situation. >> > > I agree, its not great. But he didn't get a warm welcome and some of his > early interactions were abrasive. > Considering two extremes, you can either be inclusive and hopefully > nurture/mold, or exclude and lose any chance at that. > Like a lot of things, the path is somewhere in the middle and needs a bit > of give and take on both sides. > > >> PS: a side note on Javascript (with lower S). wether you love or hate >> this >>>> quirky lovechild of Lisp and Self/Smalltalk, telling JS developers they >>>> are >>>> stupid and that they should abandon powerful Vue.js, for example, in >>>> favor >>>> of Amber Smalltalk [cudos to Amber devs! great thing!]) is utterly >>>> stupid! >>>> >>> Agree. But banning everyone in the world for similar stupidity would >>> leave the internet awfully quiet. >>> >> Sure! Again: I am against silencing or banning anybody (and how could >> you). But if this becomes unbearable, there needs to be a public >> separation, so he does not drag the project down. People need to speak up >> against such usurpation. >> > > I appreciate the stand your are taking for the community. > I've gained from your share of your workplace experience. > > (which in the end are only a self-serving, ego-centric, attention-greedy >>>> campaign to promote "Mr. Smalltalk" himself, a total newbie, who claims >>>> credit for the work of others). >>>> >>> Your repeated "claims credit for the work of others" is quite >>> provocative >>> and I haven't noticed this in his writings. Could you provide a link? >>> >> >> See above, maybe it is a cultural thing, but as I told in my experience, >> all of his appearance screams for being recognized as one of the most >> important persons in the community (he is condescendingly mocking >> marketing >> efforts of the last 40 years, claims that he is the one who will "make >> smalltalk great again"...) >> >> Yes I am provocative this time, not my normal style (and I admit, I was >> tripped-out by his provocative blog title "Even people who understand >> prototypal programming do not like it â an inconvienent truth"; that is >> dripping off arrogance and ignorance... And sheds a bad light on >> Smalltalk, >> with which he wants to be identified in the web) >> > > Got it. > Let me ask to park this thread for the moment, because it can be quite > distracting if everyone chips in an opinion. > I think you've made some fair points and I'll put myself on the line to > discuss them with Richard when I start helping him with his competition > project. > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 9, 2019

Screencasts on Debugger driven development

by stephan

Some work Vincent Blondeau and I have been doing on the Taskbar has inspired me to make some screencasts showing how to do debugger driven development, and take the first steps towards refactoring the TaskBarMorph, driven by tests. Part 1 https://vimeo.com/329317634 Part 2 https://vimeo.com/329368348 Stephan

April 9, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Roelof Wobben

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Richard O'Keefe

You are expected to use my code fragments for *ideas*, not to incorporate them *literally* in your code. As I explained, *without seeing the specification*, I have no way to tell whether the specification uses a left-handed or right-handed coordinate system. For what it's worth, here's a complete program in my Smalltalk dialect. It doesn't plug into the exercism testing framework because I can do not know what it looks like. But if it makes the code more complicated that this, it's doing it wrong. require: 'geometry.st' "Point" require: 'print.st' "OutputStream>>print:" Object subclass: #Robot instanceVariableNames: 'position direction' poolDirectionaries: 'FileStream' methods for: 'initialising' pvtPostNew position := 0@0. direction := 1@0. methods for: 'accessing' direction ^direction copy location ^location copy obey: commands commands do: [:each | each caseOf: { [$A] -> [position := position + direction]. [$L] -> [direction := direction leftRotated]. [$R] -> [direction := direction rightRotated] }]. class methods for: 'main' start [StdIn atEnd] whileFalse: [ |robot| robot := Robot new. Robot obey: StdIn nextLine. StdOut print: Robot location; cr]. On Tue, 9 Apr 2019 at 02:58, Roelof Wobben <r.wobben(a)home.nl> wrote: > yes, this is a real tests from the pharo track on exercism.io > > I understand what you mean but maybe I overthinking things. > But if we have a robot facing north and the robot turns to the left , im > my oponion it faces now to the east. > > like this test is saying : > > > test04_RotatesTheRobotsDirection90DegreesClockwiseChangesTheDirectionFromEastToSouth > | result | > result := robotSimulatorCalculator > moveDirection: 'east' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'R'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'south'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself); > yourself) > > > but I cannot come to the same outcome with this code : > > > pointToName: aPoint > ^aPoint x isZero > ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] > ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] > > > maybe exercism.io is not a good way to practice and learn smalltalk but I > found not a better one. or smalltalk is not for me. > > Roelof > > > > > > > > > > > > Op 8-4-2019 om 16:44 schreef Richard O'Keefe: > > The basic issue here is abstraction. > An instance of "Robot" in your program is not a > physical object. How could it possibly point North, > South, or Nor-nor-west? It cannot. > Its location and direction are abstract values > *metaphorically* related to real world notions > like position vectors and velocity vectors. > "North" in this program is not a real thing, > it is an *idea* which could be represented by > 'North', 'north', #North, #north, $N, $n, > 'Raki', 'raki', #Raki, #raki, $R, $r, > 137, (0@ -1), a picture of the star Polaris, > the colour red (the conventional colour for > that end of a compass needle which points north), > a sound recording of a lecture by Alfred North > Whitehead, or anything you please, as long as, > inside the program, it *acts* the way *you* want > "north" to act (which is not necessarily the way > the physical direction North acts, and in fact in > this case it most certainly is not). > > Locations and movements in a 2D space are, in Smalltalk, > commonly represented by Points. "Represented by." > > As for this method: > > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > | result | > result := robotSimulatorCalculator > moveDirection: 'north' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'A'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 1; > yourself); > yourself) > > PLEASE tell me that is not what they are actually using. > Let's start with > (Dictionary new) > add: k1 -> v1; > ... > add: kn -> vn; > yourself > Did you know that sending #add: to a dictionary is not > portable? Storing actual Association objects inside > Dictionaries was originally an encapsulation error and > remains a performance error, so there are Smalltalks > that do not make that mistake. The *portable* way to > make a Dictionary is > (Dictionary new) > at: k1 put: v1; > ... > at: kn put: vn; > yourself. > > And why in the name of sanity are the keys *strings* > instead of *symbols*? This is not Smalltalk. It is > Javascript in drag. > > Now exercism.io has a habit of insisting on particular > implementations. For example, I completed the SML track, > and found that the test code ONLY worked with Poly and > not with any of the three SML implementations I already > had on my machine. Since you are doing this in Pharo, > I take it that exercism.io will insist on the Smalltalk > track being done in Pharo, and in that case it is > *nauseating* to use a Dictionary when you could use a > Point. Old-fashioned Smalltalk style would have been > to return something like > #(<direction> <x> <y>) > e.g. #(north 1 0), and I still prefer that. > > In fact *good* Smalltalk style for something like this > would be > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > robotSimulatorCalculator > moveTo: 0@0; > head: #north; > obey: 'A'. > self assert: robotSimulatorCalculator heading equals: #north. > self assert: robotSimulatorCalculator location equals: 0@1. > > -- We're starting to get the idea that identifiers like > robotSimulatorCalculator are not a very good idea when > simulatedRobot would do the job as well or better. > > (This is also pointing us towards Betrand Meyer's > Command/Query Separation principle, but we shan't > go there today.) > > This is important feedback to give to the exercism.io > people. The test code should use a SMALLTALK interface, > not a warmed-over JAVASCRIPT interface. > > Now, how do we map between direction *names* and > direction *points*? Well, we have to start by > laying down clearly what we *mean* by the directions. > > To move North one step is to add 1 to y and 0 to x. > (We know that from the appalling test case above.) > To move South one step is to add -1 to y and 0 to x. > (South is the opposite of North.) > To move East one step, oh we have a problem. > THIS NEEDS SPELLING OUT. And one of the things the > exercism.io exercises are HORRIBLY BAD AT is specifying > the problem. Nearly every single exercise I have tried, > I have been unable to tell what the problem is without > examining the test cases, and that is not the way > exercises are supposed to work. (Yeah, that's why I'm > screaming about it. I've taught a class using exercises > like this that were not of my writing and vague specifications > really upset the students. People who had taken the class > under someone else several years before were still angry > about it.) > > The geometric classes in Smalltalk were written to support > graphic user interfaces. And in user interfaces, the y > coordinate increases DOWN. So if we take the compass rose > and rotate it so that North is DOWN, it follows that > West is right and East is left. So > > To move East one step is to add -1 to x and 0 to y. > To move West one step is to add 1 to x and 0 to y. > > The chances are excellent that the problem specification > is inconsistent with this. Sigh. Let's proceed, though. > > North 0@1 > South 0@ -1 > East -1@0 > West 1@0 > > > pointToName: aPoint > ^aPoint x isZero > ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] > ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] > > nameToPoint: aSymbol > aSymbol = #north ifTrue: [^0 @ 1]. > aSymbol = #south ifTrue: [^0 @ -1]. > aSymbol = #west ifTrue: [^1 @ 0]. > aSymbol = #east ifTrue: [^-1 @ 0]. > aSymbol error: 'not a compass direction in lower case'. > > Another problem I had with exercism was a "Space-Age" > exercise where the README.md capitalised the planet names > but test_Space-Age.<whatever> insisted on lower case. > That might well happen here. > > Just for grins, > Dictionary>> > asPoint > ^(self at: 'x') @ (self at: 'y') > > Point>> > asDictionary > ^(Dictionary new) > at: 'x' put: self x; > at: 'y' put: self y; > yourself > > > > > On Mon, 8 Apr 2019 at 22:15, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> Richard thanks. >> >> One thing I do not see direct. >> >> you said : >> >> >> A direction could be represented by a pair of integers >> dx, dy such that |dx|+|dy| = 1. It could also be >> represented by a Point with integer components. >> >> for me a direction is the direction the robot is facing so something like >> north or east. >> >> the challenge also wants a output like this : >> >> >> test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth >> | result | >> result := robotSimulatorCalculator >> moveDirection: 'north' >> position: >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 0; >> yourself) >> instructions: 'A'. >> self >> assert: result >> equals: >> (Dictionary new >> add: 'direction' -> 'north'; >> add: >> 'position' >> -> >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 1; >> yourself); >> yourself) >> >> so how do I "convert" the point you are using to the text. >> >> Or do I misunderstood you somewhere wrong. >> >> Roelof >> >> >> >> >> Op 8-4-2019 om 10:57 schreef Richard O'Keefe: >> >> One thing I have often seen and lamented is students >> writing excessively complicated code with way too many >> classes. There is a huge difference between >> "A Robot knows its position and direction." >> and >> "A Robot has-a Position and has-a Direction." >> The first is the important one. The second is >> an over-commitment to too many classses. For a >> problem like this, you really really do not want >> a Direction class, and you certainly have no use >> for double dispatch. >> >> A position can be represented by a pair of integers >> x, y. It could also be represented by a Point with >> integer components. >> >> A direction could be represented by a pair of integers >> dx, dy such that |dx|+|dy| = 1. It could also be >> represented by a Point with integer components. >> >> For movement, you need to be able to add the direction >> to the location, which could be simply >> x := x + dx. y := y + dy. >> or it could be >> position := position + direction. >> For turning, you need to be able to rotate a direction >> vector by ninety degrees. Now it so happens that >> Point has methods #leftRotated and #rightRotated. >> >> So we can do the following: >> a Robot has position (a Point) and direction (aPoint) >> position := 0 @ 0. >> direction := 0 @ 1. >> To move forward without turning: >> position := position + direction. >> To turn left without moving: >> direction := direction leftRotated. >> To turn right without moving: >> direction := direction rightRotated. >> To obey a sequence of characters, commands: >> commands do: [:each | >> each caseOf: { >> [$A] -> [--move forward--]. >> [$L] -> [--turn left--]. >> [$R] -> [--turn right--] >> }]. >> >> >> One of the key ideas in extreme programming is >> "You Ain't Gonna Need It", abbreviated to YAGNI! >> The idea is *DON'T* generalise beyond your immediate >> needs. In this case, for example, the likelihood of >> *this* program needing to deal with more general >> kinds of movement is ZERO. And the only reason for >> using Point here instead of just using a few simple >> assignment statements is that Point already exists, >> so costs nothing to write, and as a familiar class, >> code using it should be easy to read. >> >> If someone challenges you to do something counter-productive, >> refuse the challenge. >> >> On Mon, 8 Apr 2019 at 17:21, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> I can try to explain what I trying to solve. >>> >>> I have a Robot which can turn left, turn right or moveForward. >>> >>> now I have a string like 'LAR' >>> >>> that means the robot needs to turn left (l) , move forward one place (A) >>> and turn left. >>> and I have to keep track to which direction the robot is facing and on >>> which coordinate it stands. >>> >>> so to summarize with the above string >>> >>> lets say the robot is facing north on coordinate (0,0) >>> then it has to turn left , so its facing east and still on coordinate >>> (0,0) >>> then it has to move forward, so its still facing east but are on >>> coordinate(0,1) >>> then it has to turn right, so its facing north and on coordinate (0,1) >>> >>> and TimMacKinnon has challenged me to do this with double dispatch. >>> >>> So I think now I need a object Direction, a sub object North and a sub - >>> sub object TurnLeft, turnRight and moveForward. >>> >>> So I can use double dispath first the direction North, East, South, West >>> and then use double dispatch to find the right move. >>> >>> Roelof >>> >>> >>> >>> >>> >>> Op 8-4-2019 om 06:50 schreef Richard O'Keefe: >>> >>> It would really REALLY **REALLY** help if we knew what >>> the heck you were trying to do. There is an excellent >>> chance that it is MUCH simpler than you think. If you >>> cannot show us the Smalltalk version of the problem, >>> can you show us the version for some other language? >>> >>> >>> On Sun, 7 Apr 2019 at 20:15, Roelof Wobben <r.wobben(a)home.nl> wrote: >>> >>>> Op 6-4-2019 om 15:15 schreef K K Subbu: >>>> > On 06/04/19 4:49 PM, Roelof Wobben wrote: >>>> >> Hello, >>>> >> >>>> >> I just learned double dispatch. >>>> >> And now for the Robot challenge of exercism Tim has pointed me to >>>> >> this >>>> >> article( >>>> https://blog.metaobject.com/2019/04/accessors-have-message-obsession.html) >>>> >>>> >> >>>> >> but I fail to see how the move method looks like in that article. >>>> >> I had a conversation with Tim in the exercism channel and the way he >>>> >> explains it, it looks like double dispatch for me. >>>> >> >>>> >> Am I on the right track or do I oversee something here. >>>> > unary methods like moveRight perform specific ops and are not >>>> > parametric, so only a single dispatch, depending on the receiver, is >>>> > needed. >>>> > >>>> > If you change it to move: aDistanceOrAngle, then performing requests >>>> > like "move: 3 cms" or "move: 30 degrees" will depend not only on the >>>> > receiver but also on the class of the argument. This would need >>>> double >>>> > dispatch (aka multiple polymorphism). The first dispatch would be >>>> > based on the receiver and the receiver's method would then dispatch >>>> it >>>> > based on the class of the argument (i.e. Distance>>move or >>>> Angle>>move ) >>>> > >>>> > HTH .. Subbu >>>> > >>>> > >>>> >>>> >>>> hmm, still stuck >>>> >>>> I have now a class Direction with as instance variables north, south, >>>> east, west >>>> and made the accessors. >>>> >>>> then I thought I need a initialize like this : >>>> >>>> initialize >>>> north = Direction( 0, -1). >>>> east = Direction( 1, 0). >>>> south = Direction( 0, 1). >>>> west = Direction(-1, 0). >>>> >>>> but the Direction (0,-1) is a problem . the compiler does not like the >>>> (0,-1) part >>>> >>>> to give you the big picture. I have a Robot which can turnRight , >>>> turnLeft and moveForward and I try to understand how the page would >>>> work >>>> in my case. >>>> >>>> So I have a object Direction as described above and a Object >>>> MoveForward >>>> which is a subobject of Direction. >>>> MoveForward has only 1 method : >>>> >>>> IsMove >>>> ^ 'A' >>>> >>>> Roelof >>>> >>>> >>>> >>> >> >

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Roelof Wobben

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Richard O'Keefe

The basic issue here is abstraction. An instance of "Robot" in your program is not a physical object. How could it possibly point North, South, or Nor-nor-west? It cannot. Its location and direction are abstract values *metaphorically* related to real world notions like position vectors and velocity vectors. "North" in this program is not a real thing, it is an *idea* which could be represented by 'North', 'north', #North, #north, $N, $n, 'Raki', 'raki', #Raki, #raki, $R, $r, 137, (0@ -1), a picture of the star Polaris, the colour red (the conventional colour for that end of a compass needle which points north), a sound recording of a lecture by Alfred North Whitehead, or anything you please, as long as, inside the program, it *acts* the way *you* want "north" to act (which is not necessarily the way the physical direction North acts, and in fact in this case it most certainly is not). Locations and movements in a 2D space are, in Smalltalk, commonly represented by Points. "Represented by." As for this method: test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth | result | result := robotSimulatorCalculator moveDirection: 'north' position: (Dictionary new add: 'x' -> 0; add: 'y' -> 0; yourself) instructions: 'A'. self assert: result equals: (Dictionary new add: 'direction' -> 'north'; add: 'position' -> (Dictionary new add: 'x' -> 0; add: 'y' -> 1; yourself); yourself) PLEASE tell me that is not what they are actually using. Let's start with (Dictionary new) add: k1 -> v1; ... add: kn -> vn; yourself Did you know that sending #add: to a dictionary is not portable? Storing actual Association objects inside Dictionaries was originally an encapsulation error and remains a performance error, so there are Smalltalks that do not make that mistake. The *portable* way to make a Dictionary is (Dictionary new) at: k1 put: v1; ... at: kn put: vn; yourself. And why in the name of sanity are the keys *strings* instead of *symbols*? This is not Smalltalk. It is Javascript in drag. Now exercism.io has a habit of insisting on particular implementations. For example, I completed the SML track, and found that the test code ONLY worked with Poly and not with any of the three SML implementations I already had on my machine. Since you are doing this in Pharo, I take it that exercism.io will insist on the Smalltalk track being done in Pharo, and in that case it is *nauseating* to use a Dictionary when you could use a Point. Old-fashioned Smalltalk style would have been to return something like #(<direction> <x> <y>) e.g. #(north 1 0), and I still prefer that. In fact *good* Smalltalk style for something like this would be test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth robotSimulatorCalculator moveTo: 0@0; head: #north; obey: 'A'. self assert: robotSimulatorCalculator heading equals: #north. self assert: robotSimulatorCalculator location equals: 0@1. -- We're starting to get the idea that identifiers like robotSimulatorCalculator are not a very good idea when simulatedRobot would do the job as well or better. (This is also pointing us towards Betrand Meyer's Command/Query Separation principle, but we shan't go there today.) This is important feedback to give to the exercism.io people. The test code should use a SMALLTALK interface, not a warmed-over JAVASCRIPT interface. Now, how do we map between direction *names* and direction *points*? Well, we have to start by laying down clearly what we *mean* by the directions. To move North one step is to add 1 to y and 0 to x. (We know that from the appalling test case above.) To move South one step is to add -1 to y and 0 to x. (South is the opposite of North.) To move East one step, oh we have a problem. THIS NEEDS SPELLING OUT. And one of the things the exercism.io exercises are HORRIBLY BAD AT is specifying the problem. Nearly every single exercise I have tried, I have been unable to tell what the problem is without examining the test cases, and that is not the way exercises are supposed to work. (Yeah, that's why I'm screaming about it. I've taught a class using exercises like this that were not of my writing and vague specifications really upset the students. People who had taken the class under someone else several years before were still angry about it.) The geometric classes in Smalltalk were written to support graphic user interfaces. And in user interfaces, the y coordinate increases DOWN. So if we take the compass rose and rotate it so that North is DOWN, it follows that West is right and East is left. So To move East one step is to add -1 to x and 0 to y. To move West one step is to add 1 to x and 0 to y. The chances are excellent that the problem specification is inconsistent with this. Sigh. Let's proceed, though. North 0@1 South 0@ -1 East -1@0 West 1@0 pointToName: aPoint ^aPoint x isZero ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] nameToPoint: aSymbol aSymbol = #north ifTrue: [^0 @ 1]. aSymbol = #south ifTrue: [^0 @ -1]. aSymbol = #west ifTrue: [^1 @ 0]. aSymbol = #east ifTrue: [^-1 @ 0]. aSymbol error: 'not a compass direction in lower case'. Another problem I had with exercism was a "Space-Age" exercise where the README.md capitalised the planet names but test_Space-Age.<whatever> insisted on lower case. That might well happen here. Just for grins, Dictionary>> asPoint ^(self at: 'x') @ (self at: 'y') Point>> asDictionary ^(Dictionary new) at: 'x' put: self x; at: 'y' put: self y; yourself On Mon, 8 Apr 2019 at 22:15, Roelof Wobben <r.wobben(a)home.nl> wrote: > Richard thanks. > > One thing I do not see direct. > > you said : > > > A direction could be represented by a pair of integers > dx, dy such that |dx|+|dy| = 1. It could also be > represented by a Point with integer components. > > for me a direction is the direction the robot is facing so something like > north or east. > > the challenge also wants a output like this : > > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > | result | > result := robotSimulatorCalculator > moveDirection: 'north' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'A'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 1; > yourself); > yourself) > > so how do I "convert" the point you are using to the text. > > Or do I misunderstood you somewhere wrong. > > Roelof > > > > > Op 8-4-2019 om 10:57 schreef Richard O'Keefe: > > One thing I have often seen and lamented is students > writing excessively complicated code with way too many > classes. There is a huge difference between > "A Robot knows its position and direction." > and > "A Robot has-a Position and has-a Direction." > The first is the important one. The second is > an over-commitment to too many classses. For a > problem like this, you really really do not want > a Direction class, and you certainly have no use > for double dispatch. > > A position can be represented by a pair of integers > x, y. It could also be represented by a Point with > integer components. > > A direction could be represented by a pair of integers > dx, dy such that |dx|+|dy| = 1. It could also be > represented by a Point with integer components. > > For movement, you need to be able to add the direction > to the location, which could be simply > x := x + dx. y := y + dy. > or it could be > position := position + direction. > For turning, you need to be able to rotate a direction > vector by ninety degrees. Now it so happens that > Point has methods #leftRotated and #rightRotated. > > So we can do the following: > a Robot has position (a Point) and direction (aPoint) > position := 0 @ 0. > direction := 0 @ 1. > To move forward without turning: > position := position + direction. > To turn left without moving: > direction := direction leftRotated. > To turn right without moving: > direction := direction rightRotated. > To obey a sequence of characters, commands: > commands do: [:each | > each caseOf: { > [$A] -> [--move forward--]. > [$L] -> [--turn left--]. > [$R] -> [--turn right--] > }]. > > > One of the key ideas in extreme programming is > "You Ain't Gonna Need It", abbreviated to YAGNI! > The idea is *DON'T* generalise beyond your immediate > needs. In this case, for example, the likelihood of > *this* program needing to deal with more general > kinds of movement is ZERO. And the only reason for > using Point here instead of just using a few simple > assignment statements is that Point already exists, > so costs nothing to write, and as a familiar class, > code using it should be easy to read. > > If someone challenges you to do something counter-productive, > refuse the challenge. > > On Mon, 8 Apr 2019 at 17:21, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> I can try to explain what I trying to solve. >> >> I have a Robot which can turn left, turn right or moveForward. >> >> now I have a string like 'LAR' >> >> that means the robot needs to turn left (l) , move forward one place (A) >> and turn left. >> and I have to keep track to which direction the robot is facing and on >> which coordinate it stands. >> >> so to summarize with the above string >> >> lets say the robot is facing north on coordinate (0,0) >> then it has to turn left , so its facing east and still on coordinate >> (0,0) >> then it has to move forward, so its still facing east but are on >> coordinate(0,1) >> then it has to turn right, so its facing north and on coordinate (0,1) >> >> and TimMacKinnon has challenged me to do this with double dispatch. >> >> So I think now I need a object Direction, a sub object North and a sub - >> sub object TurnLeft, turnRight and moveForward. >> >> So I can use double dispath first the direction North, East, South, West >> and then use double dispatch to find the right move. >> >> Roelof >> >> >> >> >> >> Op 8-4-2019 om 06:50 schreef Richard O'Keefe: >> >> It would really REALLY **REALLY** help if we knew what >> the heck you were trying to do. There is an excellent >> chance that it is MUCH simpler than you think. If you >> cannot show us the Smalltalk version of the problem, >> can you show us the version for some other language? >> >> >> On Sun, 7 Apr 2019 at 20:15, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> Op 6-4-2019 om 15:15 schreef K K Subbu: >>> > On 06/04/19 4:49 PM, Roelof Wobben wrote: >>> >> Hello, >>> >> >>> >> I just learned double dispatch. >>> >> And now for the Robot challenge of exercism Tim has pointed me to >>> >> this >>> >> article( >>> https://blog.metaobject.com/2019/04/accessors-have-message-obsession.html) >>> >>> >> >>> >> but I fail to see how the move method looks like in that article. >>> >> I had a conversation with Tim in the exercism channel and the way he >>> >> explains it, it looks like double dispatch for me. >>> >> >>> >> Am I on the right track or do I oversee something here. >>> > unary methods like moveRight perform specific ops and are not >>> > parametric, so only a single dispatch, depending on the receiver, is >>> > needed. >>> > >>> > If you change it to move: aDistanceOrAngle, then performing requests >>> > like "move: 3 cms" or "move: 30 degrees" will depend not only on the >>> > receiver but also on the class of the argument. This would need double >>> > dispatch (aka multiple polymorphism). The first dispatch would be >>> > based on the receiver and the receiver's method would then dispatch it >>> > based on the class of the argument (i.e. Distance>>move or Angle>>move >>> ) >>> > >>> > HTH .. Subbu >>> > >>> > >>> >>> >>> hmm, still stuck >>> >>> I have now a class Direction with as instance variables north, south, >>> east, west >>> and made the accessors. >>> >>> then I thought I need a initialize like this : >>> >>> initialize >>> north = Direction( 0, -1). >>> east = Direction( 1, 0). >>> south = Direction( 0, 1). >>> west = Direction(-1, 0). >>> >>> but the Direction (0,-1) is a problem . the compiler does not like the >>> (0,-1) part >>> >>> to give you the big picture. I have a Robot which can turnRight , >>> turnLeft and moveForward and I try to understand how the page would work >>> in my case. >>> >>> So I have a object Direction as described above and a Object MoveForward >>> which is a subobject of Direction. >>> MoveForward has only 1 method : >>> >>> IsMove >>> ^ 'A' >>> >>> Roelof >>> >>> >>> >> >

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by Esteban Maringolo

Maybe the abstraction needed wraps everything within a single handler, but internally does a switch like statement dispatching to a particular error handler block. handledBlock exceptionDispatcher on: NotFoundError do: [:ex | ...]; on: MessageNotUnderstood do: [:ex | .. ]. BlockClosure>>exceptionDispatcher | exceptionDispatcher| exceptionDispatcher:= ExceptionDispatcher new. self on: Exception do: [:ex | dispatcher handle: ex ]. ^exceptionDispatcher ExceptionDispatcher>>on: exceptionClass do: aBlock self handlers add: exceptionClass -> aBlock The #exceptionDispatcher method would return this special object that deals with the resolution of each exception class (how to sort them would't be trivial unless done naively). But any resignalling would be only one level deep. Disclaimer: I just wrote the code as I replied this email, not guaranteed to work :) Esteban A. Maringolo El lun., 8 abr. 2019 a las 10:09, jtuchel(a)objektfabrik.de (<jtuchel(a)objektfabrik.de>) escribiÃ³: > > Am 08.04.19 um 14:39 schrieb Richard O'Keefe: > > >> > >> > It's easy enough to add your own methods like >> > on: exn1 do: act1 on: exn2 do: act2 >> > "An imperfect emulation of VAST's #when:do:when:do:" >> > ^[self on: exn1 do: act1] on: exn2 do: act2 >> > >> > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 >> > "An imperfect emulation of VAST's #when:do:when:do:when:do:" >> > ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 >> > to BlockClosure. It won't be fast, but your code might be >> > clearer. > > well, an unwanted side effect might be that the handling of exn1 is also guarded by the outer on:do: . > > Not that this has to be a problem but it introduces new things to think about when you want to #resignalAs: and such. > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by jtuchel＠objektfabrik.de

Am 08.04.19 um 14:39 schrieb Richard O'Keefe: > > > > > It's easy enough to add your own methods like > > on: exn1 do: act1 on: exn2 do: act2 > >Â Â Â "An imperfect emulation of VAST's #when:do:when:do:" > >Â Â Â ^[self on: exn1 do: act1] on: exn2 do: act2 > > > > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 > >Â Â Â "An imperfect emulation of VAST's #when:do:when:do:when:do:" > >Â Â Â ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 > > to BlockClosure.Â It won't be fast, but your code might be > > clearer. > well, an unwanted side effect might be that the handling of exn1 is also guarded by the outer on:do: . Not that this has to be a problem but it introduces new things to think about when you want to #resignalAs: and such. -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

April 8, 2019