November 2016 - Pharo-users

Re: [Pharo-users] about balkanisation

by Dimitris Chloupis

> > Cuis basically delegates everything to git and use one file per package. > > yes thats the direction I want to go with this, if possible kill any kind of meta information and turn everything to Smalltalk code. Even fileout contains meta data. > > He has a nice lib interface targetting both mercurial? and git; a kind of > ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X > are you talking about this https://github.com/janvrany/libgit2 his last commit was 4 years ago. this is going the exact opposite direction once again tries to bring git inside the pharo image. Or are you talking about something else ? "I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours." I try to refrain from criticising Pharo, because I don't want to decrease the motivation of people contributing to Pharo which I consider critical to the improvement of Pharo and secondly because my criticisms are largely based on personal taste which I think would make for a very poor discussion since personal taste cannot be debated. The summary of my ideology is that there are only parts of Smalltalk I really like and not the whole thing. I have several ideas about Pharo. Whether some or all of those ideas will be proven bad or too difficult to implement , time will tell. Some of those ideas are 1) a component based environment similar to Delphi (one of the things I loved about Delphi). Basically Objects on steroids. 2) An enhancement of visual coding experience in Pharo. Roassal could help here. 3) The ability to use Emacs as an alternative code editor outside the box. Shampoo has accomplished this goal, but I have not tested it yet. 4) Deep integration with both C++ and Python, this is more than a need since I depend both on Python and C++, this idea is the closest to materialisation and probably my most critical one 5) Modular image = This one I am lucky enough that is already a Pharo goal and an ongoing project 6) A more powerful documentation system , Pillar could help here and the inspector / gtspotter 7) Auto update in the background , not a high priority goal since I will be using the Steam API that handles updates but it would be nice 8) Fragmentation of the image format, this one will be a combination of fuel (or custom format) and bootstrap 9) Removal of any mid ground between Smalltalk code and Git , this is the idea I was talking early on 10) Integration with OS tools , like file browsers, web browsers , system utilities etc 11) Replacement of Morphic with QT, I already can do this at least in part with my python bridge but for now its a low priority 12) Management of user analytics, that will be specific to my games and probably will utilise Steam's and Unreal's analytics for gathering information about the user , obviously with the permission of the user, most likely this will require minimum Pharo code 13) Unification of Browser, Workspace , GTInspector, GTDebugger and GtSpotter under one tool 14) More strict evaluation of potential errors and user mistakes and many more. All those ideas are mostly long term so it may be years if not a decade before they materialise and probably will change along the process to fit practical needs. You could say that Ephestos most likely will turn into an alternative Pharo Distribution like Cuis is for Squeak but with very different goals. Again my goal is not to produce something for public consumption but merely an image that follows more closely my personal taste.

Nov. 7, 2016

Re: [Pharo-users] About balkanisation

by Dale Henrichs

On 11/7/16 6:42 AM, Norbert Hartl wrote: >> Am 07.11.2016 um 10:40 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: >> >> >> >> On 11/7/16 2:59 AM, Tudor Girba wrote: >>> Hi Dale, >>> >>> I think I missed your mails. I would be interested in hearing your opinion. Letâs aim for a chat sometime next week. Would this work for you? >> You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me â¦ >> > Would it make sense to make that a group conversation? > I don't mind, but I do have to say that I am struggling in communicated some of the "simple concepts" ... My talk last Wednesday was my first attempt and I don't think I did a good job of communicating about some of the more complicated tasks that come up like: load specs, clone/lock/rehome, sharing local clones across multiple images, private image clones, etc. ... My inclination is to have a focused conversation with Doru to help me express the key concepts ... then a more public discussion with another straw man where we put the ideas out again ... Dale

Nov. 7, 2016

Re: [Pharo-users] About balkanisation

by Esteban Lorenzano

> On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 11/7/16 4:52 AM, Esteban Lorenzano wrote: >> btw this is pharo-dev discussion, redirecting there. >> >> Esteban >> >>> On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> We are developing Icebergâ¦ and I know is not enough :) >>> Which âunifying toolsâ are you referring ? > The main unifying tool is a Metacello Project Browser (or something like the tODE project list). > > You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... > > There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level > > From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... > > This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): > - save > - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) > - diff -- project level diff over a collection of packages > - commit log -- For ConfigurationOf, list the commit history of the Configuration. > For a BaselineOf list the commit log for the git repository > > The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with â¦ this is what is provided by icebergâ¦ it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below). > > The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... > > The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par â¦ also, this is supposed to be provided by iceberg. > > The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git â¦ Iceberg is not package-oriented. It just show repositories/packages/classes/methodsâ¦ this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :) > > Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together this is something to thinkâ¦ I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided). > > I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think â¦ I do not think we are so far from your vision. I think you did not get it Iceberg rightâ¦ please, take a second look :) nowâ¦ is true that now everything you say is already doneâ¦ but this is general orientation :) Esteban ps: all of this is *clearly* not pharo-users but pharo-dev discussion, letâs move there. >>> >>> I have followed very close your TOdE developmentâ¦ in a moment I was planning a migration of it for pure-pharo, justâ¦ lack of time as always and then later we started iceberg. > Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :) >>> now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. > Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git.... >>> >>> What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ > As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ... > > Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years > > >>> and that way of doing has a limit. A limit I think we already passed. >>> >>> Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) > the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ... > > Dale >

Nov. 7, 2016

Re: [Pharo-users] About balkanisation

by Dale Henrichs

On 11/7/16 4:52 AM, Esteban Lorenzano wrote: > btw this is pharo-dev discussion, redirecting there. > > Esteban > >> On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> We are developing Icebergâ¦ and I know is not enough :) >> Which âunifying toolsâ are you referring ? The main unifying tool is a Metacello Project Browser (or something like the tODE project list). You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): - save - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) - diff -- project level diff over a collection of packages - commit log -- For ConfigurationOf, list the commit history of the Configuration. For a BaselineOf list the commit log for the git repository The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with ... The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par ... The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git ... Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think ... >> >> I have followed very close your TOdE developmentâ¦ in a moment I was planning a migration of it for pure-pharo, justâ¦ lack of time as always and then later we started iceberg. Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :) >> now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git.... >> >> What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ... Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years >> and that way of doing has a limit. A limit I think we already passed. >> >> Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ... Dale

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi Esteban, > > I cut out the rest, because I agree with all your points, except for... > > 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> [ ... ] >> >> Replacing Monticello with git goes in this direction: >> >> [ ... ] >> > > And this one I don't understand. A smooth, git / iceberg oriented > transition over Monticello/Metacello is perfectly doable... As Dale > explained. A nice Iceberg gui reworking / making git usable is perfect. > > > Wellâ¦ I disagree with this. > All my experience says the opposite: this is a convenience usage that in > the long way does not match (the thing that we simulate mcz packages do not > workâ¦ and makes things a lot harder to maintain later). > Nico has worked a lot on this, maybe he has something to say. > I'd like to. Simulating mcz? That I don't get it. I've seen many things done in Pharo that have a strong NIH tag attached to them. So I allways take the 'I reimplement everything because I know better' with a grain of salt. Nico has a huge task. > > > But why make the transition so hard? You get Stef angry on a Sunday > morning because he can't find things anymore... even if he is a strong > proponent of the strategy he complains about ;) > > > Stef was angry because he needs to clone, pull, commit, push and make a PR > to collaborateâ¦ and because that process is not correctly > documented/tooled. > Sadly, this will not changeâ¦ it will always be like that. > What we can do is easy the task creating the toolsâ¦ but that will need to > be there. > Agreed. It's about time, by the way. Pharo lost some usability on the SLICES/mcz front over the years, and its painfull when teaching Pharo. Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Sven Van Caekenberghe

> On 7 Nov 2016, at 10:43, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Its clear that I want to live outside the image. > > Its clear that others want to live inside the image. > > Its clear that I am a tiny minority , if not the only one. I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours. Sven

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Esteban Lorenzano

> On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Esteban, > > I cut out the rest, because I agree with all your points, except for... > > 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > [ ... ] > > Replacing Monticello with git goes in this direction: > > [ ... ] > > And this one I don't understand. A smooth, git / iceberg oriented transition over Monticello/Metacello is perfectly doable... As Dale explained. A nice Iceberg gui reworking / making git usable is perfect. Wellâ¦ I disagree with this. All my experience says the opposite: this is a convenience usage that in the long way does not match (the thing that we simulate mcz packages do not workâ¦ and makes things a lot harder to maintain later). Nico has worked a lot on this, maybe he has something to say. > > But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;) Stef was angry because he needs to clone, pull, commit, push and make a PR to collaborateâ¦ and because that process is not correctly documented/tooled. Sadly, this will not changeâ¦ it will always be like that. What we can do is easy the task creating the toolsâ¦ but that will need to be there. Esteban > > Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 10:43 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > " > Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me > (Jan's format is even more conflict-oriented than Filetree metadata, but it > is a design goal). Cuis git repository is a mess to me; very hard to build > a coherent 'rebuild a new Cuis here' process on it like I routinely do on > Pharo." > > > Cuis I downloaded it, does not seem to have such a tool, talking about > auto export of code. > Cuis basically delegates everything to git and use one file per package. > > Jon Vrany which I found here > > https://github.com/janvrany?tab=overview&from=2015-12-01&to= > 2015-12-31&utf8=â > > appears that he has not done any Smalltalk coding for more than a year and > I could not find one repo that has such tool. > He has a nice lib interface targetting both mercurial? and git; a kind of ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X > > Just to make it clear what I am proposing here is not just a replacement > for filetree but I complete bypass of Monticello. I have been a frequent > visitor of the pharo mailing lists for more than 5 years not I never head > of such a thing. It is also the first time I mention this idea as well. I > had in my mind for so long but it has been a low priority because filetree > worked without any issues other than browsing the code in code editor and > online Github. > > "I've seen over the years many, many attempts at replacing the filetree > format. I used to contest and debate, now I just let them go and die a few > months later. Because none of the alternatives are clearly superior, and it > is not worth the effort to reimplement." > > Well if by dying you mean none else but me will use it, most certainly you > are correct. But all my projects are foremost personal I never make > something for public consumption other than offering a helping hand with > Pharo documentation. > I mean really dying: like in even the creator isn't using it anymore. You really need good code to hold something alone over the years, something that keeps working across Pharo versions as they evolve with minimum changes. Trust me on that! One strategy is to base yourself on stable core components of Pharo. Some stuff in Pharo changes a lot, some has been very stable since Pharo 3 (or upgraded very nicely while maintaining the same API). You may be better off reimplementing stuff changing too fast / or too buggy in their current incarnation, just to decouple yourself: when you go for a self/alone project, your goals do not align with the main image. > > I am perfectly ok with the fact that people do not use my projects. > > And foremost its not as if a tool that would bypass monticello and > filetree and gitfiletree and iceberg has any chance to be used when for > months now the mailing list has been talking about Iceberg. > > Its clear that I want to live outside the image. > > Its clear that others want to live inside the image. > > Its clear that I am a tiny minority , if not the only one. > I think you're less radical than you believe :) Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Esteban Lorenzano

> On 7 Nov 2016, at 10:42, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >>> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 7 Nov 2016, at 10:13, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>> >>>> I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. >>>> >>>> (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) >>> >>> Indeed. I agree 100%. >> >> I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources âas in Pharoâ :) >> a Seaside app to do that would not be hard, I thinkâ¦ and can be hosted on PharoCloud (or whatever you want). >> > I fully agree to your previous mail (the long one) but want to add that it is not only the number of things to maintain that plays an important role in taming complexity. You can count the complexity of each project into that calculation. And proposing something using seaside is not an approach according to this rule ;) I know :) Iâm not saying I will do itâ¦ or maintain itâ¦ just that it would be cool and fairly easy :P Esteban > > Norbert

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Dimitris Chloupis

" Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo." Cuis I downloaded it, does not seem to have such a tool, talking about auto export of code. Jon Vrany which I found here https://github.com/janvrany?tab=overview&from=2015-12-01&to=2015-12-31&utf8… appears that he has not done any Smalltalk coding for more than a year and I could not find one repo that has such tool. Just to make it clear what I am proposing here is not just a replacement for filetree but I complete bypass of Monticello. I have been a frequent visitor of the pharo mailing lists for more than 5 years not I never head of such a thing. It is also the first time I mention this idea as well. I had in my mind for so long but it has been a low priority because filetree worked without any issues other than browsing the code in code editor and online Github. "I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement." Well if by dying you mean none else but me will use it, most certainly you are correct. But all my projects are foremost personal I never make something for public consumption other than offering a helping hand with Pharo documentation. I am perfectly ok with the fact that people do not use my projects. And foremost its not as if a tool that would bypass monticello and filetree and gitfiletree and iceberg has any chance to be used when for months now the mailing list has been talking about Iceberg. Its clear that I want to live outside the image. Its clear that others want to live inside the image. Its clear that I am a tiny minority , if not the only one. >

Nov. 7, 2016