September 2020 - Pharo-users

Re: roman numbers

by Roelof Wobben

Sept. 17, 2020

Re: roman numbers

by Aliaksei Syrel

Hi Roelof, You will not believe! 2 printStringRoman âIIâ Have fun! On Thu, 17 Sep 2020 at 18:20, Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello, > > > > Can someone help me with a good plan to convert numbers to roman numbers. > > > > I could make a dictionary with 1,4,5,9,10,99,100, 999, 1000 but that > > feels like a overkill. > > > > Regards, > > > > Roelof > > -- Cheers, Alex

Sept. 17, 2020

roman numbers

by Roelof Wobben

Hello, Can someone help me with a good plan to convert numbers to roman numbers. I could make a dictionary with 1,4,5,9,10,99,100, 999, 1000 but that feels like a overkill. Regards, Roelof

Sept. 17, 2020

Re: ported and refreshed Crypto-Nacl to GitHub (from StH)

by Jonathan van Alteren

Hi Torsten and anyone interested, I know this project probably isn't critical for you, but for me it represents a nice opportunity to work on something visible in the broader community. With the limited time I currently have available, that is. I would love to hear your feedback on my comments. Cheers! Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com On 8 Sep 2020, 17:10 +0200, Jonathan van Alteren <jvalteren(a)objectguild.com>, wrote: > Hi Torsten, > > Thanks for your message, those are some good questions/comments. > Â 1. Looking at the frequency of the last commits on SmalltalkHub, I think I can step in as maintainer for the moment. Please let me know if you think something needs to be changed/added to the README to reflect that. > Â 2. Although I am fine with making it more accessible to the community, I think it should not be integrated in the Cryptography repository. If I am correct, the Cryptography packages are a standalone, native implementation of ASN1 and several cryptography related libraries. Crypto-Nacl is a wrapper for Libsodium which uses uFFI, and will therefore only support features that Sodium offers. > > What are criteria for a repository to be placed under the pharo-contributions organization? > Â 3. Thanks, I've updated the LICENSE file to add Tony and HernÃ¡n. > Â 4. I changed the name earlier, but decided to revert to the original name in SmalltalkHub. If a name change is warranted, I think it should be libsodium-pharo, since the original NaCl library has been superseded by Sodium and other libsodium bindings follow a similar naming convention (seeÂ https://github.com/search?q=libsodium&type=Repositories) > Â 5. Of course it would. At the moment, I only migrated the project from SmalltalkHub, refreshed a small bit of code and enabled smalltalkCI with GitHub Actions. Currently, you'd need to look at the tests for some examples. > > Any particular examples you would be interested in? Perhaps you can open an issue with a request. > Â 6. It might already work on Windows, since the Nacl FFILibrary defines 'libsodium.dll' as win32 module (library) name. However, I don't currently run any Windows systems, so that would be a good opportunity for a contribution. Is that something you can help with? > > Thanks again for the feedback. I'm interested to work on this to gain more experience with maintaining an open source project, especially since this one doesn't seem very demanding at the moment. > > Are you familiar with Pieter Hintjens work and ideas on OS software? I find his C4 model (Collective Code Construction Contract) to be very interesting and I'm open to trying that out. > > See here for more context:Â https://hintjens.gitbooks.io/social-architecture/content/chapter4.html > (The rest of the book is interesting as well.) > > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > > jvalteren(a)objectguild.com > On 31 Aug 2020, 17:37 +0200, Torsten Bergmann , wrote: > > Hi Jonathan, > > > > nice, thanks for investing time and effort into this. Such utilities are needed for serious applications. Some thoughts and questions: > > > > Â 1.Â What is the mid-term or long-term plan regarding collaboration? Will you be able to step in as maintainer? > > > > Â 2. As it already seems to be authored by several people and contains functionality of general interest it should beÂ considered to move it to > > Â Â Â a central community place likeÂ https://github.com/pharo-contributions[https://github.com/pharo-contributio… where several people from community have already > > Â Â Â access.Â It would then be in alignment withÂ https://github.com/pharo-contributions/Cryptography[https://github.com/phar… too and maintenance of > > contributions as well as releases could be done from different sides and more centrally. > > > > Â Â Â You and anyone can then regulary fork from the community repo to an own (customized) repo like https://github.com/objectguild/Crypto-Nacl > > > > Â Â Â I guess Esteban can add you as contributor to "pharo-contribution" organization if you follow that path. > > > > Â 3. I guess LICENSE file need to be updated to give additionall credit to the original authors or mention more general "Pharo community" > > Â Â Â (currently it mentionsÂ Object Guild solely) > > > > Â 4. Can it be changed to use "NaCl" instead of "Nacl" which is more suitable name for SodiumÂ Â (a similar name fixing was done in the Cuis port too) > > > > Â 5. Would it be possible to add some expressions/samples or docu in the README for end users on how to use it. This would give people a quick guide > > on how to do things. > > > > Â 6. Any plans for making it work on Windows too? > > > > Thanks > > Torsten > > > > > > Gesendet:Â Montag, 31. August 2020 um 09:52 Uhr > > Von:Â "Jonathan van Alteren" <jvalteren(a)objectguild.com> > > An:Â "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > > Betreff:Â [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH) > > > > Hi all, > > > > I wanted to let you know that I ported the Crypto-Nacl library from SmalltalkHub to GitHub here:Â https://github.com/objectguild/Crypto-Nacl[https://github.com/objectguild/C… > > > > The original author is Tony Garnock-Jones, with contributions from HernÃ¡n Morales Durand. See the README for more details. > > > > Libsodium has evolved a lot over time, which means that there is plenty of additional functionality that can be unlocked through this library. I don't have a need for it at the moment, but that might change in the near future. My interest is in using the cryptographic features to enhance security of business applications. > > > > Oh, and thanks to the Buenos Aires Smalltalk team (https://github.com/ba-st/[https://github.com/ba-st/]) for inspiration on using GitHub Actions with smalltalkCI :-) > > > > > > Cheers, > > > > Jonathan van Alteren > > > > Founding Member | Object Guild B.V. > > Sustainable Software for Purpose-Driven Organizations > > > > jvalteren(a)objectguild.com > >

Sept. 17, 2020

[ANN] Pharo Consortium New Academic Member: Laboratoire DISP

by Marcus Denker

The Pharo Consortium is very happy to announce that DISP Lab has joined the Consortium as an Academic Member. About - Laboratoire DISP: https://disp-lab.fr/ - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Sept. 17, 2020

Re: How can I make this more OOP

by StÃ©phane Ducasse

respondTo: is different from a perform based on forging a selector. respondTo: implies a different control while perform: is just sending a message. Some logic of Spec or something else was doing respondTo: and it is an indication of weak polymorphism. Either objects are polymorphic or they are not. Because else you expect a behavior and because of a hidden respondTo: you get a api not invoked. This forces you to read all the code and step to find the super cool users of respondTo: So I really stand on my claim respondTo: should only be used in last resort. It covers shitty design. S. > On 16 Sep 2020, at 19:28, sean(a)clipperadams.com wrote: > > StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > refrain from using respondTo: I make code difficult to evolve and can introduce vicious bugs. > > Steph, would you say more about this? Itâs something Iâve been wondering about. > > I was recently reading the Strategy pattern in the Smalltalk Companion to the GOF book. On p. 339, they proposed the following "Smalltalk way" as an alternative to the common class-per-strategy implementation: > > [[[language=smalltalk > > Composition>>repair > > "Without the strategy pattern, but using perform:." > > | selector | > > "Construct the name of the method to invoke:" > > selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol. > > self perform: selector > > ]]] > > It then dismissed the approach as "''clever but difficult from a program understanding perspective. Even static analysis tools such as code browsers' "senders" and "messages" fail on this code.''" > > It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct the algorithm selector via string concatenation. Maybe "senders" search capabilities have gotten more sophisticated since publication, but Pharo seems to support symbol arguments, even for e.g. message renames. I thought, why not the following: > > [[[language=smalltalk > > Composition>>repair > > "Without the strategy pattern, but using perform:." > > self perform: self formattingStrategy > > ]]] > > Then client code like ==aComposition formattingStrategy: #formatWithSimpleAlgorithm== would show up in senders, message renames, etc. > > But from what youâre saying, I feel I may be missing somethingâ¦ > > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 16, 2020

Re: How can I make this more OOP

by Richard Sargent

On Wed, Sep 16, 2020 at 10:28 AM <sean(a)clipperadams.com> wrote: > StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > refrain from using respondTo: I make code difficult to evolve and can > introduce vicious bugs. > > Steph, would you say more about this? Itâs something Iâve been wondering > about. > > I was recently reading the Strategy pattern in the Smalltalk Companion to > the GOF book. On p. 339, they proposed the following "Smalltalk way" as an > alternative to the common class-per-strategy implementation: > > [[[language=smalltalk > > Composition>>repair > > "Without the strategy pattern, but using perform:." > > | selector | > > "Construct the name of the method to invoke:" > > selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol. > > self perform: selector > > ]]] > > It then dismissed the approach as "''clever but difficult from a program > understanding perspective. Even static analysis tools such as code > browsers' "senders" and "messages" fail on this code.''" > It is always best to have senders of the methods you use. Additionally, it's far better to properly manage the user-friendly identification of a thing and the thing itself. e.g. Plain language name mapped to a selector or a block. Remember, "the fact that one *can* do something is far different from whether one *should* do that thing." (I have suffered far too often and far too long from clever programs preferring the former without thinking about the latter.) It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct > the algorithm selector via string concatenation. Maybe "senders" search > capabilities have gotten more sophisticated since publication, but Pharo > seems to support symbol arguments, even for e.g. message renames. I > thought, why not the following: > > [[[language=smalltalk > > Composition>>repair > > "Without the strategy pattern, but using perform:." > > self perform: self formattingStrategy > > ]]] > > Then client code like ==aComposition formattingStrategy: > #formatWithSimpleAlgorithm== would show up in senders, message renames, etc. > > But from what youâre saying, I feel I may be missing somethingâ¦ > > >

Sept. 16, 2020

Re: How can I make this more OOP

by sean＠clipperadams.com

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > refrain from using respondTo: > I make code difficult to evolve and can introduce vicious bugs. Steph, would you say more about this? Itâs something Iâve been wondering about. I was recently reading the Strategy pattern in the Smalltalk Companion to the GOF book. On p. 339, they proposed the following "Smalltalk way" as an alternative to the common class-per-strategy implementation: \[\[\[language=smalltalk Composition>>repair "Without the strategy pattern, but using perform:." | selector | "Construct the name of the method to invoke:" selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol. self perform: selector \]\]\] It then dismissed the approach as "''clever but difficult from a program understanding perspective. Even static analysis tools such as code browsers' "senders" and "messages" fail on this code.''" It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct the algorithm selector via string concatenation. Maybe "senders" search capabilities have gotten more sophisticated since publication, but Pharo seems to support symbol arguments, even for e.g. message renames. I thought, why not the following: \[\[\[language=smalltalk Composition>>repair "Without the strategy pattern, but using perform:." self perform: self formattingStrategy \]\]\] Then client code like ==aComposition formattingStrategy: #formatWithSimpleAlgorithm== would show up in senders, message renames, etc. But from what youâre saying, I feel I may be missing somethingâ¦

Sept. 16, 2020

Re: [Pharo-dev] Updating lists.pharo.org: New server, Mailman3 and more

by Marcus Denker

Yes, I had a complaint/question that I need to check, I have set it to private for now. Marcus > On 15 Sep 2020, at 20:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > marcus I tried and I could not see the archive. > Apparently the archive is still private. > >> On 14 Sep 2020, at 19:54, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Migration is Complete! >> >> If you want to login at the website, you need to create a new account with the email address that the lists are now sending emails to. >> >> https://lists.pharo.org <https://lists.pharo.org/> >> >> >> >>> On 14 Sep 2020, at 19:18, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> So: sending emails should now be ok, but the web-interface is still syncing the archives (pharo-dev is there, pharo-users >>> will be soon). >>> >>> But this means that everyone should be fine to send mails again. >>> >>> Marcus >>> >>>> On 14 Sep 2020, at 19:11, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> >>>> Testing if this is send via the new serverâ¦ the new Archive is at https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org <https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org> >>>> >>>> Marcus >>>> >>>>> On 14 Sep 2020, at 17:42, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> We are updating the mailinglists (everything https://lists.pharo.org/ <https://lists.pharo.org/>) >>>>> >>>>> -> New server, thus: new IPâ¦ >>>>> -> the server will run Mailman3 (we used Mailman2) >>>>> -> There will be a better Archive >>>>> >>>>> >>>>> I will do the change of the IP address today. >>>>> >>>>> The only thing that could happen is that mails send still via the old server will not be in the >>>>> new archive, everything else should be transparent. >>>>> >>>>> I will send another mail when it is done. >>>>> >>>>> Marcus >>>> >>> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Sept. 16, 2020

Re: How can I make this more OOP

by StÃ©phane Ducasse

still my point holds. And Iâm like saint christophe I only believe what I saw and we will never see what you are doing so it does not exist. This is the rule of open-source. S. > On 16 Sep 2020, at 04:51, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > In a language like Java or C# or Ada we can insist at > compile time that an argument conforms to a protocol, > whatever class it might be an instance of. > > In Smalltalk, we can use #isKindOf: to test whether > an object inherits from a class, but that is often the > wrong test. We can use (multiple calls to) #respondsTo: > to tell whether an object conforms to a protocol. > > The only snag, of course, is that in too many Smalltalk > systems, #respondsTo: is not trustworthy. If a class > has a method that sends #subclassResponsibility or > #shouldNotImplement, it's still counted as responding > to the selector in question. > > This is not a problem in my Smalltalk because > (a) you are not allowed to create a direct instance of > a class where any method calls #subclassResponsibility. > (b) #shouldNotImplement appears only in test cases. > Since I already have named protocols, with classes > declaring their intention to conform to them, I've > been thinking about adding > aClass implements: aProtocol > anInstance conformsTo: aProtocol > but have not done that yet. > > I note that Pharo V7.0.3 had 132 senders of #respondsTo: > and Pharo V8.0.0 has 126 senders of #respondsTo:. > These neatly bracket Dolphin 7's 130. > > > > On Wed, 16 Sep 2020 at 06:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > >> On 14 Sep 2020, at 16:02, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: >> >> >> Thanks Richard for this explanation. >> and I like also your idea of using #respondTo instead of asking a object if its a collection or a item. > > refrain from using respondTo: > I make code difficult to evolve and can introduce vicious bugs. > > S. >> Roelof >> >> >> Op 14-9-2020 om 14:28 schreef Richard O'Keefe: >>> "OOP is not asking an object what it is"? You've lost me. >>> I'm reminded of a joke exam question that goes something >>> like this: >>> Some things have ping nature and other things have pong nature. >>> Discuss, with examples. >>> >>> Whatever else it is, OOP is a means to an end, not an end in itself. >>> It's not a religion. Allah will not cast you into the Fire for using >>> something which is not ritually pure. >>> >>> The whole point of the Design Patterns movement was not to present >>> canned solutions but to describe common *situations* characterised >>> by (metaphorical) *forces* pushing you in incompatible directions. >>> >>> Question 1: Why do you even have a stream there? >>> flattenArray: aCollection >>> |buffer| >>> buffer := OrderedCollection new: aCollection size. >>> self flattenArray: aCollection into: buffer. >>> ^buffer asArray >>> >>> flattenArray: anObject into: buffer >>> (anObject respondsTo: #do:) >>> ifTrue: [anObject do: [:each | self flattenArray: each into: buffer] >>> ifFalse: [anObject ifNotNil: [buffer addLast: anObject]. >>> >>> (CAUTION: untested code.) >>> >>> Question 2: is there any point in *trying* to make this more ping and less pong? >>> I have to say that in 40 years of programming, I have *never* wanted to flatten >>> a completely arbitrary structure. When I have wanted to flatten something, it >>> has always been an instance of the Composite design pattern, so that a specific >>> and quite small set of classes has been involved. >>> >>> I am well aware that some Smalltalk systems have some sort of 'flatten' >>> lying around like a rake in the grass, but I have found no two which agree >>> on the specification. >>> >>> Question 3: Let's consider an if-less alternative. >>> >>> Stream >>> flattenInto: buffer >>> self do: [:each| each flattenInto: buffer]. >>> >>> Collection >>> flattenInto: buffer >>> self do:[:each | each flattenInto: buffer]. >>> >>> Object >>> flattenInto: buffer >>> buffer addLast: self. >>> >>> UndefinedObject >>> flattenInto: buffer >>> "Do nothing." >>> >>> This is Smalltalk, where we *can* add methods to system classes like these. >>> When the payoff is worth it, I have no qualms whatever in doing so. >>> But putting methods of little or no utility into the interface of EVERY >>> object just feels so wrong. >>> >>> Here we have opposing forces: >>> - The first approach adds two methods to your worker class, >>> and no methods to any system class. Instead, it uses >>> "does this object know how to iterate over its elements?" >>> and "is this object nil?". This does minimal damage to >>> system structure at the price of a little ritual impurity. >>> >>> - The second approach adds a method to four system classes, >>> enlarging the interface of every object in the system, >>> creating a level of coupling we'd be better without, and >>> making it harder for someone reading your code to figure >>> out what's going on. >>> >>> In the context of a Composite, with a limited number of >>> application classes involved, the second approach is better; >>> the method is/methods are not defined anywhere they should >>> not be. >>> >>> In the context of *this* problem, the first approach is >>> better. MUCH better. Why? Because *encapsulation* is much >>> more important to OOP than absence-of-IFs. >>> >>> On Sun, 13 Sep 2020 at 21:26, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: >>> Hello, >>> >>> I know that OOP is not asking a object what it is but I have to flatten a array so I did this : >>> >>> flattenArray: aCollection >>> ^ (OrderedCollection >>> streamContents: [ :stream | self flatten: aCollection into: stream ]) >>> asArray >>> >>> flatten: anObject into: result >>> ^ anObject isCollection >>> ifTrue: [ anObject do: [ :item | self flatten: item into: result ] ] >>> ifFalse: [ anObject ifNotNil: [ result nextPut: anObject ] ] >>> >>> The name flattenArray is given bij exercism. >>> >>> Now I wonder how I can make this more a OOP solution. >>> >>> Can someone give me some hints or some examples ? >>> >>> Roelof >>> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 16, 2020