March 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to write out simple Json?

by Paul DeBruicker

Of you load the JSON package from Squeaksource (http://www.squeaksource.com/JSON.html) You can do a JSON render: { 'track' -> 'pharo'. 'language' -> 'smalltalk'. 'exercises' -> { 'slug' -> 'hello'. 'id' -> 55. 'topics' -> #('a' 'b' 'c') } } and get a Json string or add e.g. Object>>#asJsonString ^JSON render: self Tim Mackinnon wrote >> On 1 Mar 2019, at 10:35, Sven Van Caekenberghe < > sven@ > > wrote: >> >> Forget about the way you are trying to implement it, to what would >> >> { #key->#value. 1. true } >> >> be rendered in JSON ? >> >> { "key":"value", 1, true } >> >> or >> >> [ "key":"value", 1, true ] >> >> Both are illegal JSON. > > > You didnât read what I said - with those 2 tiny changes - both of those > given an exception just like STONJSON - the only difference is that I > donât have to put asDictionary everywhere. > > Anyway - I think Iâve learned a lot from this discussion - and as Pharo is > malleable I can do my little nasty subclass until I get burned and then I > will probably adopt a proper Config object like Henrik mentioned ;) > > Just as a small additional question - when you do : > > ex := { > #track->#pharo. > #language->#smalltalk. > #exercises->{ > #slug->'hello'. > #id->55. > #topics->#('a' 'b' 'c') } asDictionary } asDictionary. > > Am I right in thinking that with asDictionary the order wonât be > deterministic (which is valid for JSON dictionaries, but annoying for > diffing config files). This is why I was doing asOrderedDictionary as I > though I had seen it change on me a few times when I was generating > output. > > Tim -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 2, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sean P. DeNigris

Richard Sargent wrote > As an aside, this is the kind of information that should be in a method's > comment. Rationale and explanation, rather than what it does. Yes!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 1, 2019

OS X bundle, some progress

by Hilaire

Hi, I did some progress on the Dr.Geo bundle for OS X. The Mac admin of my school told me to download from Safari and authorized the drgeo.eu web site (not sure what this exactly does), then we installed the DrGeo.app at the Application location. DrGeo started fine but emit a startup error at the image level, related to stdout. It looks like a stdout file can not be created. The stack is enclosed here. When looking at the execution stack, I could not determine (I have to go teaching) where the image wants to create this stdout file. Any idea or opinion on this stdout matter? Thanks Hilaire -- Dr. Geo http://drgeo.eu

March 1, 2019

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

by Michael Zeder

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(a)openinworld.com>: > Hi Michael, > > Thanks for your thoughtful followup. > > On Fri, 1 Mar 2019 at 19:59, Michael Zeder <post(a)michael-j-zeder.de> > 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

March 1, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Tim Mackinnon

Hey - sometimes these more philosophical conversations do amount to something. I will propose to gene changes and submit a pr - as after all, Pharo is ours and pointing someone to #downTo: or #upTo: would be very rewarding (and for Richard - #to: would remain the same so everyone wins) Tim Sent from my iPhone Sent from my iPhone >> On 1 Mar 2019, at 18:30, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> >> On 01/03/19 5:35 PM, Sven Van Caekenberghe wrote: >> I like this too. >> Why would this not happen ? It is just one selector more. >> I think the only possible issue is that #to:do: is known by the >> compiler, which makes it faster than any other iteration, even do: - >> there is always a tradeoff between readability and raw speed. > > Thank you for the kind words. I am not sure if speed would be affected much by: > > downTo: stop > ^self to: stop by: -1 > > downTo: stop do: aBlock > ^self to: stop by: -1 do: aBlock > > In performance critical paths, one can always use to:do: with explicit steps. > > Regards .. Subbu >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Richard Sargent

On Fri, Mar 1, 2019 at 12:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ah, it is an optimisation: if the first #== fails, but the argument is > also a Symbol, then that means the are different for sure, so false is > returned early, instead of failing in super's #= after that. > > And with ByteSymbol and WideSymbol, although they are exclusive (can never > be equal), they can be different and if they are both Symbols, then you can > return early (not just when their classes differ). > Thanks for explaining that! As an aside, this is the kind of information that should be in a method's comment. Rationale and explanation, rather than what it does. > > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Why ? Please explain ... > > > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> > >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: > >>> > >>> > >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >>>> > >>>> > >>>> From: Petr Fischer <petr.fischer(a)me.com> > >>>> Subject: Symbol equality method #= - weird condition in the Pharo > sourcecode > >>>> Date: 1 March 2019 at 17:08:03 GMT+1 > >>>> To: pharo-users(a)lists.pharo.org > >>>> > >>>> > >>>> Hello, this is Symbol equality method in Pharo: > >>>> > >>>> 1: = aSymbol > >>>> 2: "Compare the receiver and aSymbol." > >>>> 3: self == aSymbol ifTrue: [^ true]. > >>>> 4: self class == aSymbol class ifTrue: [^ false]. > >>>> 5: "Use String comparison otherwise" > >>>> 6: ^ super = aSymbol > >>>> > >>>> Look at line 4 - what does it mean? That's wrong, isn't it? > >>>> > >>>> Typically, every symbol comparisons end up in line 3, but if you do > some work with forward proxies for example, condition on line 3 is "false" > and then weird things on line 4 happens. > >>>> > >>>> If line 4 and further are correct, can someone explain a little? > >>>> > >>>> Thanks! pf > >>> > >>> Yes, that looks weird. Line 4 should probably be removed, unless I am > missing something. > >> > >> It is wrong in a Spur image, because we now have subclasses of Symbol. > >> But removing line 4 is not the right solution. See Nicolas' > implementation > >> in Squeak: > >> > >> Symbol>>= aSymbol > >> "Compare the receiver and aSymbol." > >> self == aSymbol ifTrue: [^ true]. > >> aSymbol isSymbol ifTrue: [^ false]. > >> "Use String comparison otherwise" > >> ^ super = aSymbol > >> > >> Dave > >> > >>> > >>> Symbols are by definition always #== so in that sense, #= should not > even be implemented (as #= on Object is defined as #==), but since its > direct super class String already overwrote #=, it has to follow. > >>> > >>> The super call in line 6 is what allows Symbols and String to be > compared. > >>> > >>> I would say line 4 is a kind of sanity check, but probably not needed. > > > > >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

Ah, it is an optimisation: if the first #== fails, but the argument is also a Symbol, then that means the are different for sure, so false is returned early, instead of failing in super's #= after that. And with ByteSymbol and WideSymbol, although they are exclusive (can never be equal), they can be different and if they are both Symbols, then you can return early (not just when their classes differ). > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Why ? Please explain ... > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: >>> >>> >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Petr Fischer <petr.fischer(a)me.com> >>>> Subject: Symbol equality method #= - weird condition in the Pharo sourcecode >>>> Date: 1 March 2019 at 17:08:03 GMT+1 >>>> To: pharo-users(a)lists.pharo.org >>>> >>>> >>>> Hello, this is Symbol equality method in Pharo: >>>> >>>> 1: = aSymbol >>>> 2: "Compare the receiver and aSymbol." >>>> 3: self == aSymbol ifTrue: [^ true]. >>>> 4: self class == aSymbol class ifTrue: [^ false]. >>>> 5: "Use String comparison otherwise" >>>> 6: ^ super = aSymbol >>>> >>>> Look at line 4 - what does it mean? That's wrong, isn't it? >>>> >>>> Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. >>>> >>>> If line 4 and further are correct, can someone explain a little? >>>> >>>> Thanks! pf >>> >>> Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. >> >> It is wrong in a Spur image, because we now have subclasses of Symbol. >> But removing line 4 is not the right solution. See Nicolas' implementation >> in Squeak: >> >> Symbol>>= aSymbol >> "Compare the receiver and aSymbol." >> self == aSymbol ifTrue: [^ true]. >> aSymbol isSymbol ifTrue: [^ false]. >> "Use String comparison otherwise" >> ^ super = aSymbol >> >> Dave >> >>> >>> Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. >>> >>> The super call in line 6 is what allows Symbols and String to be compared. >>> >>> I would say line 4 is a kind of sanity check, but probably not needed. >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Steffen MÃ¤rcker

Is it consistent with the definition of #= in String such that 'aSymbol = aString' iff 'aString = aSymbol'? Sorry, I don't have an image at hand. Am 1. MÃ¤rz 2019 18:40:11 MEZ schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >Why ? Please explain ... > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe >wrote: >>> >>> >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users ><pharo-users(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Petr Fischer <petr.fischer(a)me.com> >>>> Subject: Symbol equality method #= - weird condition in the Pharo >sourcecode >>>> Date: 1 March 2019 at 17:08:03 GMT+1 >>>> To: pharo-users(a)lists.pharo.org >>>> >>>> >>>> Hello, this is Symbol equality method in Pharo: >>>> >>>> 1: = aSymbol >>>> 2: "Compare the receiver and aSymbol." >>>> 3: self == aSymbol ifTrue: [^ true]. >>>> 4: self class == aSymbol class ifTrue: [^ false]. >>>> 5: "Use String comparison otherwise" >>>> 6: ^ super = aSymbol >>>> >>>> Look at line 4 - what does it mean? That's wrong, isn't it? >>>> >>>> Typically, every symbol comparisons end up in line 3, but if you do >some work with forward proxies for example, condition on line 3 is >"false" and then weird things on line 4 happens. >>>> >>>> If line 4 and further are correct, can someone explain a little? >>>> >>>> Thanks! pf >>> >>> Yes, that looks weird. Line 4 should probably be removed, unless I >am missing something. >> >> It is wrong in a Spur image, because we now have subclasses of >Symbol. >> But removing line 4 is not the right solution. See Nicolas' >implementation >> in Squeak: >> >> Symbol>>= aSymbol >> "Compare the receiver and aSymbol." >> self == aSymbol ifTrue: [^ true]. >> aSymbol isSymbol ifTrue: [^ false]. >> "Use String comparison otherwise" >> ^ super = aSymbol >> >> Dave >> >>> >>> Symbols are by definition always #== so in that sense, #= should not >even be implemented (as #= on Object is defined as #==), but since its >direct super class String already overwrote #=, it has to follow. >>> >>> The super call in line 6 is what allows Symbols and String to be >compared. >>> >>> I would say line 4 is a kind of sanity check, but probably not >needed.

March 1, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by K K Subbu

On 01/03/19 5:35 PM, Sven Van Caekenberghe wrote: > I like this too. > > Why would this not happen ? It is just one selector more. > > I think the only possible issue is that #to:do: is known by the > compiler, which makes it faster than any other iteration, even do: - > there is always a tradeoff between readability and raw speed. Thank you for the kind words. I am not sure if speed would be affected much by: downTo: stop ^self to: stop by: -1 downTo: stop do: aBlock ^self to: stop by: -1 do: aBlock In performance critical paths, one can always use to:do: with explicit steps. Regards .. Subbu

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

Why ? Please explain ... > On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: >> >> >>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>> >>> >>> From: Petr Fischer <petr.fischer(a)me.com> >>> Subject: Symbol equality method #= - weird condition in the Pharo sourcecode >>> Date: 1 March 2019 at 17:08:03 GMT+1 >>> To: pharo-users(a)lists.pharo.org >>> >>> >>> Hello, this is Symbol equality method in Pharo: >>> >>> 1: = aSymbol >>> 2: "Compare the receiver and aSymbol." >>> 3: self == aSymbol ifTrue: [^ true]. >>> 4: self class == aSymbol class ifTrue: [^ false]. >>> 5: "Use String comparison otherwise" >>> 6: ^ super = aSymbol >>> >>> Look at line 4 - what does it mean? That's wrong, isn't it? >>> >>> Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. >>> >>> If line 4 and further are correct, can someone explain a little? >>> >>> Thanks! pf >> >> Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. > > It is wrong in a Spur image, because we now have subclasses of Symbol. > But removing line 4 is not the right solution. See Nicolas' implementation > in Squeak: > > Symbol>>= aSymbol > "Compare the receiver and aSymbol." > self == aSymbol ifTrue: [^ true]. > aSymbol isSymbol ifTrue: [^ false]. > "Use String comparison otherwise" > ^ super = aSymbol > > Dave > >> >> Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. >> >> The super call in line 6 is what allows Symbols and String to be compared. >> >> I would say line 4 is a kind of sanity check, but probably not needed.

March 1, 2019