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

Re: [Pharo-dev] New book: Pharo with Style

by Sven Van Caekenberghe

That is a useful contribution, thank you (again) for your efforts ! > On 30 Dec 2018, at 22:13, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hello Fellow Pharoers > > I'm happy to announce a new little book to improve the culture around Pharo. > I will revise it in the future so you can feel free to send feedback > and pull requests > to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle > > Stef > > "The best way to predict the future is to invent" so I do it. > <withstylebook.pdf>

Jan. 1, 2019

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style

by Tim Mackinnon

Iâve always felt the XP book nailed it - donât use comments as a crutch to avoid fixing confusing code and donât do work twice by simply writing a comment that says the same as the code. (You can of course try to write the comment and auto-generate the code, but weâve tried that before). Smalltalk is an expressive language that should read like comments naturally - both with the name of a method, the variables and the statements in it. This leaves comments as a good place to tell a story about the wider context and where to look to get started or learn more. I think this is possibly where Documentor is going to help you navigate along the real code. Of course if after all of this you canât figure out how to fix the code - then a comment is a good last resort. Tim Sent from my iPhone > On 1 Jan 2019, at 12:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Richard, > >> On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> ... >> >> To get an example, I did (String allSelectors atRandom), getting >> #copyWithoutAll:. That has only one definition, in Collection: >> copyWithoutAll: aCollection >> "Answer a copy of the receiver that does not contain any elements >> equal to those in aCollection." >> >> ^ self reject: [:each | aCollection includes: each] >> >> The comment simply paraphrases the rather simple code. > > I agree with pretty much everything you've written, but have a > slightly different view here. > > Including what the method does, even when the code is fairly simple > (OK, not getter / setter methods), is still useful. If the comment is > absent, I have to look at the code, figure out what it does, and then > either figure out if that's what it is supposed to do, or just assume > that I'm correct. Having to figure out whether I've interpreted the > code correctly just increases the cognitive load. If the comment > includes what it is supposed to do, I have a context in which to read > and evaluate the code, and it becomes much less effort. > > Cheers, > Alistair >

Jan. 1, 2019

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style

by Alistair Grant

Hi Richard, On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > ... > > To get an example, I did (String allSelectors atRandom), getting > #copyWithoutAll:. That has only one definition, in Collection: > copyWithoutAll: aCollection > "Answer a copy of the receiver that does not contain any elements > equal to those in aCollection." > > ^ self reject: [:each | aCollection includes: each] > > The comment simply paraphrases the rather simple code. I agree with pretty much everything you've written, but have a slightly different view here. Including what the method does, even when the code is fairly simple (OK, not getter / setter methods), is still useful. If the comment is absent, I have to look at the code, figure out what it does, and then either figure out if that's what it is supposed to do, or just assume that I'm correct. Having to figure out whether I've interpreted the code correctly just increases the cognitive load. If the comment includes what it is supposed to do, I have a context in which to read and evaluate the code, and it becomes much less effort. Cheers, Alistair

Jan. 1, 2019

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Richard O'Keefe

Let us approach this as simply as we can. (1) There are two numbers 1 <= i <= n-3, i+2 <= j <= n-1 such that (s at: i) = (s at: j) and (s at: i+1) = (s at: j+1) Brute force will get us where we want to go: String hasTwoCharacterNonoverlappingRepeat 1 to: self size - 3 do: [:i | i + 2 to: self size - 1 do: [:j | ((self at: i ) = (self at: j ) and: [(self at: i+1) = (self at: j+1)]) ifTrue: [^true]]]. ^false This is pretty much how you would do it in C or Java. This takes O(n**2) time where n is the size of the string. If you want to be *really* clever, you can do something with suffix arrays, but if you just want to be a little bit clever, you can sort the two-character substrings and their positions by just sorting the positions. Make an array a of the integers 1..n-1. Sort it by viewing each i in the array as the triple (s[i],s[i+1],i). You don't *make* the triples, just do the comparisons as if they existed. Now a linear scan of the array will find a match if there is one. The whole process is O(n.lg n). It's only worth doing when n is large. (2) Finding xyx. You did not say whether the middle letter can be the same as the outer ones or must be different. I'm going to suppose that it does not matter. hasXYX 3 to: self size do: [:i | (self at: i-2) = (self at: i) ifTrue: [^true]]. ^false Again, this is just what you would do in Java or C: public static boolean hasXYX(String s) { final int n = s.length(); for (int i = 2; i < n; i++) if (s.charAt(i-2) == s.charAt(i)) return true; } return false; } For what it's worth, in my system this scans a Scrabble dictionary with 146522 words (1,220,068 bytes), finding 2779 "nice" words, in 0.18 seconds, so there's not a lot of point in improving it. In both cases, DON'T copy. DON'T make substrings. Just state the problem simply and convert it to obvious code. Simple boring code is GOOD. On Sun, 30 Dec 2018 at 05:29, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > Still working on AdventOfCode > > Im struggeling to see how this can be solved. > > Now, a nice string is one with all of the following properties: > > - It contains a pair of any two letters that appears at least twice in > the string without overlapping, like xyxy (xy) or aabcdefgaa (aa), but > not like aaa (aa, but it overlaps). > - It contains at least one letter which repeats with exactly one > letter between them, like xyx, abcdefeghi (efe), or even aaa. > > my game plan was this > > 1) group the characters and filter everything out which has a count not > equal to two > > 2) find the indexes of the characters and with the indexes use a copy > method so I have a substring out of it > > 3) do the same with the substring so again 1 and 2 > > but how can I make 2 work. > > Roelof > > >

Jan. 1, 2019

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style

by Richard O'Keefe

I'm not sure that the advice on method comments is as good as it could be. Consider Point >> setX: xValue setY: yValue x := xValue. y := yValue It is pretty obvious what this does, and if I'm reading chapter 4 correctly the advice is that it doesn't need a comment. But it does: why DOESN'T this method check that xValue and yValue are numbers, something which is assumed by practically every method on the instance side? In short, why does (Point x: nil y: nil) r fail when the point is USED instead of when the point is CREATED? *Somewhere*, in the class comment, the class-side #x:y: method, or this method, this ought to be explained. In my own code, every class has an (instance-side) #invariant method which I can call from the debugger. Even if it is just ^super invariant, at least that's explicit documentation. I used to write comments, and then I realised that code I could call was even better. That's something useful to say about comments too. "Method comments should contain sufficient information for a user to know exactly how to use the method, what the method does including any side ef- fects, and what it answers without having to look at the source code." This is advice that almost none of the code in Pharo follows. What the method *does* and *answers* can be determined by reading the code; in Smalltalk you are much more likely to have (decompiled) source code without comments than comments without source code. What the method is *for* is the thing that you cannot see in the code. To get an example, I did (String allSelectors atRandom), getting #copyWithoutAll:. That has only one definition, in Collection: copyWithoutAll: aCollection "Answer a copy of the receiver that does not contain any elements equal to those in aCollection." ^ self reject: [:each | aCollection includes: each] The comment simply paraphrases the rather simple code. It does NOT explain how to use the method: when (if ever) is it better to pass a set than a string? Above all, why is it a good idea for aCollection to be in charge of which elements of the receiver count as equal to something in aCollection instead of the receiver being in charge? Consider |c a| c := IdentitySet with: 0.0. a := Array with: c anyOne * 1.0. { c copyWithoutAll: a. a copyWithoutAll: c } Why does the >Identity<Set use #= for the decision while the Array uses #==? Why is the code not ^self select: [:it | aCollection noneSatisfy: [:each | it = each]] ? It is the code that is NOT there that needs explaining most. I am not blaming the Pharo team here. They have other maddened grizzly bears to stun, and did not invent this particular method. Just by sheer dumb luck, the random number generator turned up a method that has always annoyed me for obviously but inexplicably doing something seriously weird. Oh, there's another important thing about that particular comment. It is wrong. It refers to "elements equal to", which leads the reader to assume that the same notion of equality in every case. It should read something like "Answer a copy of the receiver that does not contain any element equivalent to an element of aCollection, with equivalence defined by aCollection and NOT by the receiver." There should be some advice about wrong or misleading comments being worse than none. PS: Benoit St-Jean did not catch all the typos. On Tue, 1 Jan 2019 at 16:22, Richard O'Keefe <raoknz(a)gmail.com> wrote: > On naming protocols: it would be nice to have clear guidance about > when to use '-ion' and when to use '-ing'. In my own code I've been > using '-ing' except for a few traditional categories like > 'instance creation'. One reason for this was that I didn't want to > keep on re-deciding "is it 'enumerating' or 'enumeration'". > > On Mon, 31 Dec 2018 at 22:04, Benoit St-Jean via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >> Besides, I forgot to add one comment : you should have guidelines for >> protocol naming. It's not critical per se but I find it quite annoying >> to look for stuff in "enumerating" when it's been put in "printing" ! >> loll >> >> On 2018-12-31 03:51, Stephane Ducasse wrote: >> > Thanks! Thanks! >> > I will go over it (now laying on my back :(( stupid muscles strike >> back!) >> > >> > On Mon, Dec 31, 2018 at 2:18 AM Benoit St-Jean <bstjean(a)yahoo.com> >> wrote: >> >> On 2018-12-30 16:13, Stephane Ducasse wrote: >> >>> Hello Fellow Pharoers >> >>> >> >>> I'm happy to announce a new little book to improve the culture around >> Pharo. >> >>> I will revise it in the future so you can feel free to send feedback >> >>> and pull requests >> >>> to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle >> >>> >> >>> Stef >> >>> >> >>> "The best way to predict the future is to invent" so I do it. >> >> StÃ©phane, >> >> >> >> You'll find, attached, a revised PDF version with my comments. >> >> >> >> >> >> >> >> -- >> >> ----------------- >> >> BenoÃ®t St-Jean >> >> Yahoo! Messenger: bstjean >> >> Twitter: @BenLeChialeux >> >> Pinterest: benoitstjean >> >> Instagram: Chef_Benito >> >> IRC: lamneth >> >> Blogue: endormitoire.wordpress.com >> >> "A standpoint is an intellectual horizon of radius zero". (A. >> Einstein) >> >> >> -- >> ----------------- >> BenoÃ®t St-Jean >> Yahoo! Messenger: bstjean >> Twitter: @BenLeChialeux >> Pinterest: benoitstjean >> Instagram: Chef_Benito >> IRC: lamneth >> Blogue: endormitoire.wordpress.com >> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >> >> >>

Jan. 1, 2019

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style

by Richard O'Keefe

On naming protocols: it would be nice to have clear guidance about when to use '-ion' and when to use '-ing'. In my own code I've been using '-ing' except for a few traditional categories like 'instance creation'. One reason for this was that I didn't want to keep on re-deciding "is it 'enumerating' or 'enumeration'". On Mon, 31 Dec 2018 at 22:04, Benoit St-Jean via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Besides, I forgot to add one comment : you should have guidelines for > protocol naming. It's not critical per se but I find it quite annoying > to look for stuff in "enumerating" when it's been put in "printing" ! loll > > On 2018-12-31 03:51, Stephane Ducasse wrote: > > Thanks! Thanks! > > I will go over it (now laying on my back :(( stupid muscles strike back!) > > > > On Mon, Dec 31, 2018 at 2:18 AM Benoit St-Jean <bstjean(a)yahoo.com> > wrote: > >> On 2018-12-30 16:13, Stephane Ducasse wrote: > >>> Hello Fellow Pharoers > >>> > >>> I'm happy to announce a new little book to improve the culture around > Pharo. > >>> I will revise it in the future so you can feel free to send feedback > >>> and pull requests > >>> to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle > >>> > >>> Stef > >>> > >>> "The best way to predict the future is to invent" so I do it. > >> StÃ©phane, > >> > >> You'll find, attached, a revised PDF version with my comments. > >> > >> > >> > >> -- > >> ----------------- > >> BenoÃ®t St-Jean > >> Yahoo! Messenger: bstjean > >> Twitter: @BenLeChialeux > >> Pinterest: benoitstjean > >> Instagram: Chef_Benito > >> IRC: lamneth > >> Blogue: endormitoire.wordpress.com > >> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >> > -- > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > >

Jan. 1, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Ben Coman

On Mon, 31 Dec 2018 at 19:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I created a new release of P3, the modern, lean and mean PostgreSQL client > for Pharo. > > https://github.com/svenvc/P3 > > Version 1.1 contains the following changes: > > - added support for Postgres Extended Query protocol (P3PreparedStatement) > (thx Jan @jvdsandt) > - added support for reading array type values (currently INTEGER[] FLOAT[] > BOOLEAN[] TEXT[] VARCHAR[]) > - added P3-Tests package and moved all tests there > - more comments > - more unit tests > > https://github.com/svenvc/P3/releases/tag/v1.1 > > > Especially Jan's contribution adds a lot of functionality: the ability to > work with prepared statements. This is great to hear. Could you advise what functionality remains missing, and what priority you'd consider each is? cheers -ben

Jan. 1, 2019

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

Hi Doru, On 29/12/18 15:50, Tudor Girba wrote: > Hi, > > Thanks for the link. For some strange reason, I do not see the linked email in my inbox. It was also absent from the web archives of the Pharo mailing list and, as I'm not subscribed to Pharo-Dev I always get a warning about a rejected message (I don't know if this is related somehow to the mails being hard to find). Anyway, I'm hitting "Reply all" button so you'll have the answers from this thread also in your personal mail (and have stopped cc to Pharo-Dev). > > I am happy to hear that you could install GT. > Thanks. >> * The new interfaces and some demo of the graphical elements look >> pretty good >> * After just some operations including window resizing I just get the >> Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png). > Indeed, that is a known problem: > https://github.com/feenkcom/gtoolkit/issues/64 Maybe the main window should indicate more promptly about expected but strange behaviors and point to the Issues repository, somehow. > >> * I like the little triangles to expand thing in the document and the >> run buttons for embedded code, and the "embeddability" of elements >> in the document in a tree like fashion, which of course could lead >> to documents that embed pieces of documents, which embed pieces of >> documentsâ¦ But the dual panel view of code in one side with >> results in the right panel of old GT didn't tend to create such >> "recursion". This dual modal view is the same of >> Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi) >> for interactive documentation and I would like to see examples more >> in that line... but I don't know how it suits the philosophy behind >> Documenter, which seems more aligned to a modal non dual view of the >> document where you enter into edit mode once you click a piece of >> the document and into a view mode once you are out of it (instead of >> the proposed dual view). Would be nice to see is such dual view can >> be used to directly operate on the rendered view and see changes in >> the markup (i.e resizing an image in the rendered view changes the >> value on the edit view). > Interesting observation. The linked tools as all other notebook technologies I saw rely on two distinct modes for edit and view that reside in two distinct widgets (editor and viewer). They do that because they simply cannot have it in one. Because of the design of Bloc we are not constrained to that. Instead, we build a seamless interface that is both optimized for viewing, and for editing with live preview that does not rely on an explicit render button. This approach enables direct manipulation without friction, and we think this is a significant advancement in this space. I don't think is only because other editors can't do it, but because some (most) times you don't want "to conflate two tasks that are /conceptually/ distinct and that, to ensure that people's time is used most effectively and that the final communication is most effective, ought also to be kept /practically/ distinct"[1] which are Composition and typesetting. This seems kind of strange in interactive documentation, because of the bad habits that WYSIWYG word processors installed on authors, but most of the time What You See Is **Only** What You Get, but you need enable comments to yourself, use admonitions, refer to bibliographic keys, and so son. That's why I think is a healthy practice to separate both, composition and typeseting and think in a bi-modal way, instead of a conflated way, in a similar fashion to what Bret Victor demos show for working with graphics and code in a bi-modal way [2][3]. I have experience, first hand, in "documentathons" using CodiMD, how document authors could benefit from bi-modal thinking for their documents, by showing side by side, Markdown and the rendered document changing in real time. I would like something similar for the Pharo environment. [1] http://ricardo.ecn.wfu.edu/~cottrell/wp.html [2] http://worrydream.com/#!/InventingOnPrinciple [3] https://i.imgur.com/vi6bX21.png [4] https://en.wikipedia.org/wiki/GNU_TeXmacs TeXmacs[4] has a really good What You See Is What You *Mea*n (WYSIWYM) editor that conflates composition and typography, but it works like a charm, specially while you're writing mathematics that I have not seen elsewhere (not even in comercial word processors). But when you start to push boundaries (for example by using non traditional templates) the visual approach shows its limits compared to a bi-modal editor. > > About the remark related "to documents that embed pieces of documents, which embed pieces of documentsâ: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part? > Some times when I was browsing the examples I made click on an icon that shows the document embedded in the document where the link appeared and then that happened again. I can't remember the icon or reproduce the experience. It seems that rendering in the lateral panel is working and I don't know how to get this nested embedding behavior again. > >> * I like the different view that a document can have, markup wise: >> Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the >> authoring part [4](https://i.imgur.com/Jc1T5Rm.png). > Interestingly, those extensions exist in the old Inspector as well. > Yes I saw them previously, but the editor make this more... explicit/"explorable"... maybe is related with the rendering, but they seem better now. >> * Its difficult to travel between the panels of a playground. >> Previously you just make click in the lower circle representing the >> panel you want to go at it was done >> [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper >> rectangle representing such panel has no effect >> [6](https://i.imgur.com/8Obo3Ct.png). > For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready. > In Linux those combinations don't work. Any way to get the previous one click behavior? What is the rationale behind having to press more keys, instead of the previous simpler approach? Some collision between shortcuts? >> * The default data science example didn't work at all >> [8](https://i.imgur.com/YhNb8el.png) > Nice catch. Thanks. The path of the file is incorrect when the image is copied. Glad to help :-) [...] > >> I used Moose to build the first Grafoscopio versions, but there was a >> lot of stuff that was related with software analysis that I didn't >> really need for reproducible interactive documentation and publishing >> nor for data science, activism and storytelling. So once old GT was >> integrated into Pharo with Spec I used a more minimal setup to deliver a >> more focused experience. >> >> I think that most times this relationship between Pharo and Moose can be >> of creative tension, one pushing the boundaries and the other offering a >> more stable experience where the innovations of the former are >> integrated and debugged. But even after using Moose as a fully >> integrated vision of what old GT have to offer in the back and front >> end, I didn't see any migration path from previous Moose with the old GT >> to the current GT, which is kind of worrisome. I understand the idea of >> forks in FLOSS as a way of dealing with politics behind the FLOSS >> movement and the relationship between different visions and actors >> (individuals, communities, enterprises, foundations, associations and so >> on). It has happened before with Squeak, Pharo and Cuis and I'm fine >> with that. And I understand that a healthy relationship with the past >> means sometimes to break with it and jump into the future. >> >> That's why I think that the role of for profit and non for profit >> institutions is to balance a sense of momentum and stability around >> FLOSS. I would like to see a more clear road map for GT, knowing ahead >> where backward compatibility will be broken and why, which are the >> visions and, more importantly, how to participate and where are the >> boundaries. These are difficult tasks, but if the participation and >> boundaries are explored collectively, you can also know about the first >> ones (visions, versions, forks, compatibility). In that sense I think >> that Pharo is putting a good example: we have a clear road map document >> and participation process in the public repositories, there are public >> channels for users and developers and the private companies know about >> them, so they can put the boundaries about what is going to be done in >> the open, with the community, and what is to be kept closed inside >> company's frontiers and channels and the company's own velocity. I don't >> know if Feenk is planing something similar for its new vision, product >> and identity, and I don't know if the new alternative will have its own >> non-profit organizations as a neutral entity for all players using GT, >> but would be good to know about that, not because there are not people >> willing to jump into the future, but we would like to know to which >> future we're jumping on. Without that I think that is a safer bet for >> myself to rely on Pharo and see how migration paths could ensure >> compatibility with my own past and the one of my local community using >> Pharo and GT based tools. I hope that the open source nature of both >> products (Pharo and new GT) will ease the cross-pollination of the more >> interesting ideas, even without sharing code, visions or UI. > We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke. > > I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments. As I said, I don't have problems with breaking with the past as a healthy relationship with it. This has happened before. My issue is with not knowing that a jump will be done or where are we jumping on. And also with the places where the process will be open or close. Maybe the way to communicate advances is to work enclosed first and then releasing your prototypes to the open, maybe is about having public issue trackers with fixed deadlines... I don't know what works better for the interaction between feenk and the wider Pharo community, but I think that if the process is more explicit, we, the users of Pharo and old GT can adjust expectations. I really don't know if the cost are worthwhile ATM because I don't know what is the next step of the path in new GT. I like its new renderingÂ features, but I have just a static picture at each step and I don't know where the future is going or how to get there. For me is not about fixed futures but more about open processes and boundaries, as I told before, and with those known we can explore uncertain futures together. > What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, and we think this is trivially possible. Maybe those offerings are invaluable... I really don't know as they're not closer to my context for live documentation, which is not for developers... once the roadmap and processes become clearer I could better asset that profit scenario. > About the roadmap, here it is: we aim to build a complete development environment that will enable moldable development. > > We understand how this can appear vague. I think itâs not because I and my colleagues talk about it since many years now. People pay little attention, so now we set ourselves to deliver a concrete incarnation of what we think the future should look like. We set to create something that does not exist in other parts, and we simply do not quite know how this will look like in details. Yes, more that a roadmap, it seems more like a mission with some glimpses of what forms it can take. As said, I don't have problems with exploring unknowns together or discontinuities with the past. The main issue is more processes and boundaries. I don't want to invest time in a technology that wold be jumping to something incompatible in the future and the time I notice that is when the new glimpse is released. > For example, we do know that we want to build a Coder or a Debugger, we even have advanced ideas and implementations, but we do not know exactly how it will look like and because of that we also do not quite know how long it will take. We have a particular way of approaching development that relies on fast feedback and storytelling, and at the end we always get surprised of where the journey takes us. For example, the current state of Documenter was simply difficult to imagine even 4 months ago, and in the process we threw away more code than is now released. So, we will not detail the concrete steps because we do not work like that. > > We do have a clear vision of what we think software development should be, and we will put forward our guiding principles shortly. > > About the governance process: GT is built by feenk and will continue to be so for the foreseeable future. We put things that we create in the open, we do so for free, and we welcome people to engage with us. Well, once those guiding principles and ways to engage are more explicit and think that those of us who have been using GT will now how to and how much engage with the possibilities that feenk is building (they look impressive, as I said, but would like to know where/when quantum leaps are happening). > I think that not only installation inconveniences is related alpha, but > also this jumping from old GT to new one without a clear migration path > (as is expected from alpha software and processes). I'm fine with that > too, but I think that once the new GT reaches beta status the backward > compatibility should be more important and meanwhile the non regard of > that should be stated more promptly for previous and future GT users. I > imagine that, at some point Feenk will provide its users and customers > with clear support and migration paths regarding its open source > products (kind of what happens with Canonical and the Long Term Support > versions of Ubuntu). > As mentioned above, our focus is to build a new experience. It is likely that a typical Pharo user will not have much issues adapting to the new interface. A developer that depended on the old APIs will be somewhat impacted, but we do not expect a too large effort will be required to adopt the new world. > > Nevertheless, if itâs stability and predictability you are looking for, it is best to wait for now. Yes I will go slower. More than stability and predictability, I'm looking for known processes and boundaries. > >>> A word about the user experience. The current version runs inside the >>> Pharo UI because we need to bootstrap. But, our goal is to build a >>> complete IDE on the new stack. If you want to judge the user >>> experience, it is only meaningful to do it within the GT windows, and >>> not by comparing it with the rest of the existing Pharo UI. >>> >>> Does this clarify the situation? >> Yes, it does. It seems that a fork is coming, at least UI wise regarding >> Pharo and new GT, but if the community knows about it, I'm fine with >> that. I think this thread also clarifies what active users of old GT >> will expect from upcoming versions of new (non alpha) GT regarding >> compatibility, open processes, visions and so on. Hopefully we will >> reach that place together. > I do not think a new piece of code should be called a fork. At this point in time, GT and everything it comes with, loads cleanly in Pharo 7. As I said, the fork would be UI wise, not in the core technologies. But some of us are relaying in the possibilities that current and future UI experiences are providing in Pharo to orientate our own developments and local communities. This critics mean to be constructive, explicitly trying to reach clarities in an open way and I hope that serves the wider Pharo communities. The work feenk is doing is a good showcase of interesting future possibilities and is important to have those futures open for the community and to know how to traverse/connect them. Cheers, Offray

Jan. 1, 2019