https://github.com/GemTalk/SETT <https://github.com/GemTalk/SETT>
> On Mar 27, 2022, at 3:56 PM, Richard Sargent > <richard.sarg...@gemtalksystems.com> wrote: > > GemTalk Systems published a tool called SETT which is designed to extract > sources from Store into a git repository. I think it's filetree, not to El > format, but getting it (and its history) out of Store is the primary > motivation. > > It requires direct access to the Store database, as far as I understand. > > Look at the GemTalk area on GitHub for the project and details. (I'm on > vacation, using my phone and memory, so pardon the scarcity of detail.) > > On Sun, Mar 27, 2022, 13:17 stephane ducasse <stephane.duca...@inria.fr > <mailto:stephane.duca...@inria.fr>> wrote: > 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 >> <mailto: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 >
