BTW about porting from VW, you see a friend of mine wanted to see how to help porting Siren to Pharo. Now this is not possible because he could not get a personal VW license.
So even if people want to help pointing to a store database is equivalent to /dev/null for most people. For example I cannot (and also does not for legal reason) run VW on my machine. Not talking about the new M1 I will get. S > On 27 Mar 2022, at 22:12, seasidebook <seasideb...@free.fr> wrote: > > Hi christian > > I took the squeakValues60 becau se I thought that this is what you wanted > that we do. > I should continue but I’m busy > > > ahhh I did not know that you already did it. > Do you need help to package your changes? > Because you can fork my repo and load your changes. > > I got lost with the explanation of OrderedDictionary below because I’m dead > :) - worked too mcuh today. > But what we can do is to package the one that is working for you under > http://github.com/pharo-container <http://github.com/pharo-container> > and update the baseline to load it. > Alternatively we could see what is wrong in the pharo’s one. > > Now my brain decided to shut down :) so I need to sleep. > > S > >> Hi Stef, >> >> Great! Thank you for your work. >> Good example for the tonel format. >> >> Which sources were you using? >> How did you generate this? >> Do you use VW to create the output? >> >> >> For the last ESUG (2.5 years ago – sigh), I already did the transformation >> for Values for Pharo. Thanks to you, I revised them and published the result >> on GitHub (https://github.com/PortingPDFtalk/PharoValues >> <https://github.com/PortingPDFtalk/PharoValues>) and added a Pharo porting >> page to the wiki (https://wiki.pdftalk.de/doku.php?id=pharoport >> <https://wiki.pdftalk.de/doku.php?id=pharoport>). Please have a look. >> >> The fileouts are for Pharo versions 6.1, 7.0, 8.0 and 9.0 (7.0 to 9.0 have >> identical sources). The sources load without errors or warnings and all 27 >> tests pass. >> >> >> Some of the problems in your code have to do with OrderedDictionary as >> superclass of Valuemap. When I did my first round on the port, I had a class >> OrderedDictionary in my Values implementation. Unfortunately, >> OrderedDictionary does not work as I expected. >> >> (OrderedDictionary with: #a -> 1 with: #b -> 2) = >> (OrderedDictionary with: #b -> 2 with: #a -> 1) >> >> answers true, although the order is different. Therefore, it cannot be used >> as value. >> >> Instead of raising this issue on a Pharo list (sorry), I decided to use a >> new name: Valuemap. >> A Valuemap is an OrderedDictionary where the order is relevant for >> comparisons. >> Squeak had the same problem where it was considered a bug and fixed. >> While I subclass Dictionary for Valuemap in Pharo, I can use >> OrderedDictionary in Squeak. This removes a lot of methods from the fileout. >> >> >> A remark about the renamings you propose in your commit comment. >> Thank you for the suggestions, but I decline for two reasons: >> Names for classes, methods and variables are very important to me. Naming is >> part of the creative expression of the code author. I do think much about >> the right names and therefore, I claim the liberty and right to name things >> according to my feeling. > > Yes now you may want to read an excellent book that just came out: > http://books.pharo.org <http://books.pharo.org/> Pharo with Styles. > If you want to have future contributors this is good to follow good practices > Else I’m quite sure that you would not like a French Pharo :) > >> Maybe my names are a bit influenced by German, where we tend to have longer >> names. Therefore, my names are not so heavily camel-cased J. In contrast, >> Pharo has quite a different style with a love for camel-casing J >> (#timeStamp, #nanoSeconds etc.). >> From a practical view, it would be a lot of work to rename all references to >> the items in this basic systems library. There is a lot of code out there >> using it. Of course, if there is a good reason for a renaming (like a >> spelling mistake or misleading name), it should be done and I am >> appreciating any suggestions. > > A pattern that we use is the following. > You introduce a new name and let the old one as an empty subclass. Like that > you can migrate and still be backward compatible. > > For the method level refactoring we have a gorgeous mechanism that > automatically rewrite client code…. > > http://www.jot.fm/issues/issue_2022_01/article1.pdf > <http://www.jot.fm/issues/issue_2022_01/article1.pdf> > > S
