November 2016 - Pharo-users

Re: [Pharo-users] Looking for the library to sort object

by Tudor Girba

Hi, Indeed, I forgot about this one. I would like to add this in Moose because it looks quite handy. Cheers, Doru > On Nov 7, 2016, at 2:35 PM, stepharo <stepharo(a)free.fr> wrote: > > Thanks! > > > > Le 7/11/16 Ã 12:37, Sven Van Caekenberghe a Ã©crit : >> This is very nice: >> >> http://smalltalkhub.com/#!/~emaringolo/SortFunctions >> >>> On 7 Nov 2016, at 12:25, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> I know that "steffen" did a nice library to sort objects and I know that this is a nice extension. >>> >>> But I cannot find it. >>> >>> Stef >>> >>> >> >> > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

Hi Dale, 2016-11-07 12:03 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On 11/7/16 7:15 AM, Thierry Goubier wrote: > > > > 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. > > Thierry, If I'm not mistaken, Esteban is referring to the fact that in > FileTree we are still using Monticello to do the load of the packages and > even when we are running metadataless, we end creating fake meta data to > simulate an mcz ... you and I have had conversations about ways to > eliminate this "requirement" because it is meaningless in a git context ... > Yes, this I understood. I do believe that what I suggested at one point (have the ability to compare versions with an 'isAncestorOf') would be very nice for that transition (work in mcz as well as on git with/without metadata). > > With the work that Richard Sargent did on the > CypressReferenceImplementation, I would prefer to say that Cypress can > provide an Alternative to Monticello rather than replace it ... the > CypressReferenceImplementation includes a package loader so it isn't > necessary to convert Filetree format on disk to Mcz format in the image --- > without all of the ancestry, "latest version stuff" and package-cache the > loading process becomes much, much simpler... > > I think that both Monticello and Cypress can live together in the image ... > For me, MC is also the code / diff model behind: will Cypress rewrites all that too? > > I have created a version of Metacello that uses Monticello OR Cypress and > I expect to eventually (in the next several months --- it doesn't take that > long, but I've got other things on my plate) to have a version of Metacello > that uses Monticello AND/OR Cypress again I think that smooth transitions > (that may take a long time) are better supported in this fashion than to > draw a line in the sand and force the usage of one OR the other ... > As long as Cypress behaves as a MC repository and fits into the same API, I really don't see where is the difficulty. As we are saying now, adding a type of repository / emulating the MC overall API is no real difficulty in itself and isolates one from all the project management issues (because that means Metacello, ConfigurationOf and BaselineOf just keep working as usual). We need to get the MC repository API to evolve a bit, in part to handle the "save multiple packages, do one commit without using package dependencies." required now, and also to expose more of the repository organisation (remotes, branches) for the GUI above. And remove some of the things saying "I'm MC trying to do Metacello's job". What is a bit annoying, really, is this talk of rewriting everything where some of the pieces (the project browsing you're talkin about, for example) is already there in the image, just not exposed. I'm trying to code a little something for that... stay tuned for a screenshot soon. Thierry > > Dale >

Nov. 7, 2016

Re: [Pharo-users] Looking for the library to sort object

by stepharo

Thanks! Le 7/11/16 Ã 12:37, Sven Van Caekenberghe a Ã©crit : > This is very nice: > > http://smalltalkhub.com/#!/~emaringolo/SortFunctions > >> On 7 Nov 2016, at 12:25, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I know that "steffen" did a nice library to sort objects and I know that this is a nice extension. >> >> But I cannot find it. >> >> Stef >> >> > >

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by stepharo

[ ... ] > > 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. > > 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 ;) No my point was not that. My point is that it is important to pay attention and not to add more noise than necessary. Let us take the time and move alltogether. Stef > > Thierry

Nov. 7, 2016

Re: [Pharo-users] UK Smalltalk User Group Meeting - Monday, November 28th

by Dimitris Chloupis

I will most likely be in London 7-10th of December , because I won a Google competition in April that gave me a free visit to London Google Campus which will be also probably a collection of workshop/seminars etc. We wait from British Council in Athens for the details. https://www.campus.co/london/en I would not want to change your schedule because currently I am sure about the dates because they have informed us about the flight tickets but I am not so sure about the schedule at google campus. But if my schedule is flexible enough and you don't mind pushing the date for 7-10 of December , I would love to attend. If you do I understand because even I don't know if I will be able to attend and I would not want to cause any trouble and then not attend. On Mon, Nov 7, 2016 at 8:50 AM Giovanni Corriga <giovanni(a)corriga.net> wrote: > Hi, > > The next meeting of the UK Smalltalk User Group Meeting will be on Monday, > November 28th. > > We'll meet at our usual venue The Counting House ( > http://www.the-counting-house.com/) at 7pm. > > If you'd like to join us, you can just show up at the pub. You can also > sign up in advance at the meeting's Meetup page: > https://www.meetup.com/UKSTUG/events/233683252/ . > > Thanks, > > Giovanni >

Nov. 7, 2016

Re: [Pharo-users] Looking for the library to sort object

by Sven Van Caekenberghe

This is very nice: http://smalltalkhub.com/#!/~emaringolo/SortFunctions > On 7 Nov 2016, at 12:25, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I know that "steffen" did a nice library to sort objects and I know that this is a nice extension. > > But I cannot find it. > > Stef > >

Nov. 7, 2016

Looking for the library to sort object

by stepharo

Hi I know that "steffen" did a nice library to sort objects and I know that this is a nice extension. But I cannot find it. Stef

Nov. 7, 2016

Re: [Pharo-users] About balkanisation

by Dale Henrichs

On 11/7/16 7:36 AM, Esteban Lorenzano wrote: >> 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). Well, I don't think that Iceberg is doing package loads and I don't think that Iceberg will provide support for mcz repositories so I still think there is a need for this Metacello Project Browser ... the Metacello Project Browser would delegate to Iceberg for all of the services that it does provide. The Metacello Project Browser would not be a purely git/github tool ... Metacello Projects are repository format neutral so svn, hg, etc. would be equally supported from the Metacello Project Browser ... the standard set of operations: save/load/diff/log are needed for all different repository types ... I don't think it's a lot of work to implement the Metacello Project Browser tool and it is important that there be one place to look for and manage the projects loaded in image .... this is the "unifying" bit ... > >> 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 :) Well I am specifically referring to this issue[1] and this comment by Guille[2] and Nico[3]. If Iceberg isn't going to load packages, then you need a tool that will load a package ... and as I say above this tool must work with ConfigurationOf and BaselineOf for svn, hg, etc. repositories ... [1] https://github.com/npasserini/iceberg/issues/184 [2] https://github.com/npasserini/iceberg/issues/184#issuecomment-254139549 [3] https://github.com/npasserini/iceberg/issues/184#issuecomment-257865003 > >> 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). again in tODE, the Metacello Project Browser (aka project list) allows one to view projects that are cloned to local disk but not loaded in the current image ... note that I an using the term "project" not git repository ... the catalog browser defines "load specs" for projects ... but the developer is not able to control how the project gets loaded ... a better more flexible catalog browser would actually download spec objects into the Metacello Project Browser and allow developers to adjust the "load spec" for their environment, share this "load spec" with the other images in the "image cluster" and use the "load spec" to clone github projects to local disk and then load from the Metacello Project Browser ... > >> 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 :) I would agree that not far is fair and I don't think that there is a ton of work to be done, but it is work that needs to be done ... so going the last little bit is necessary ... Nico is open to discussion, but I am not sure that all of the things that need to go into the Metacello Project Browser belong in Iceberg .... > 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. > > oops now you tell me:) Dale

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Dale Henrichs

On 11/7/16 7:15 AM, Thierry Goubier wrote: > > > 2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > >> On 7 Nov 2016, at 10:03, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@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. > > > I'd like to. Simulating mcz? That I don't get it. Thierry, If I'm not mistaken, Esteban is referring to the fact that in FileTree we are still using Monticello to do the load of the packages and even when we are running metadataless, we end creating fake meta data to simulate an mcz ... you and I have had conversations about ways to eliminate this "requirement" because it is meaningless in a git context ... With the work that Richard Sargent did on the CypressReferenceImplementation, I would prefer to say that Cypress can provide an Alternative to Monticello rather than replace it ... the CypressReferenceImplementation includes a package loader so it isn't necessary to convert Filetree format on disk to Mcz format in the image --- without all of the ancestry, "latest version stuff" and package-cache the loading process becomes much, much simpler... I think that both Monticello and Cypress can live together in the image ... I have created a version of Metacello that uses Monticello OR Cypress and I expect to eventually (in the next several months --- it doesn't take that long, but I've got other things on my plate) to have a version of Metacello that uses Monticello AND/OR Cypress again I think that smooth transitions (that may take a long time) are better supported in this fashion than to draw a line in the sand and force the usage of one OR the other ... Dale

Nov. 7, 2016

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Dimitris Chloupis

no problemo , I prefer people changing my content than not contributing at all the to the documentation. So your interest makes me more than happy ;) On Mon, Nov 7, 2016 at 11:23 AM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 2016-11-07 10:10 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > I did not advertise Nireas because I wanted free advertisement , if that > was the case I would be advertising Ephestos which has been a far more > important project for me and a project I invested far more effort. > > The idea with Nireas is a theme that allows easy customisation to any kind > of theme the user wants. I completely disagree that themes are not one of > the most basic tools of an IDE. How my environment looks like is extremely > important to me and how easy it is to read code. Dark theme has been > probably the biggest enhancement Pharo had since day one for me and has > helped boost my productivity a lot more than any other tool. I also > remember how happy the community has been to accept the dark theme in its > arms. So obviously themes matter a ton to the average Pharo user. > > I can imagine myself living without the blue theme, but I cannot imagine > myself coding in Pharo without the blue theme and the dark theme. > > Hmm thanks for mentioning not working, this is weird, it works fine in > Pharo 6 , it has a MNU in Pharo 5. I will fix it today. > > In any case I have no issue removing the mentioning of Nireas , go ahead > and do it. I never had a problem with people changing my content in PBE5. > But simply I cannot agree with your opinion . > > > I will remove it. > My opinion is not that themes are not important, but that it looks out of > context in this chapter. > > This chapter has an overview stating what we will describe in this > chapter, then having this intermediate step about changing the theme, open > CatalogBrowser, loading Nireas and talking about > that it has a theme editor ..., which looks totally unrelated to the other > content that is about the core tools (browser, debugger, finder ...) > > > > > > > > On Mon, Nov 7, 2016 at 10:54 AM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > 2016-11-07 9:52 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > In case someone missed it I will be doing a release for version 5 (pharo > version = pbe version) this weekend , since we had Pharo 7 initiated few > days ago. > > Essentially that means that the repo will be tagged for version 5, which > means a git commit is associated as a last commit for that version and > there will be a frozen release - download for Pharo by Example version 5. > After that we move to Pharo By Example version 6 or PBE6 for short > > The repo wont change otherwise and the process of submitting commits, pull > requests and issues remains the same. > > If you have found a flaw of any sort in the documentation , please open an > issue in the github issue tracker that can be found here > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues > > I will try to fix any problem reported but if I cannot , the fix will have > to move to version 6 > > As always thanks to all people contributing into the impossible .... > making Pharo more amazing > > If you want to contribute feel free to do so with a pull request. > > Does not matter if you are beginner because even minor corrections like > correcting mistakes in the grammar or content of the text, updated > pictures, or just a few lines of extra info are more than enough and more > than welcomed. Many Pharo beginners have already done so . > > -Salute to fellow Guardians of The Light > > > > Duh, please don't advertise your own theme and tools and not in this > place. > In the chapter about the key tools, there is an introducion, listing all > tools (browser/finder/...) following by a description of this tools, > AND in between(!) a paragraph about themes and loading Nireas and silly > tool for editing this theme. > > > *simple* tool (BTW it does not work) > > > > This is totally unrelated to the other content. > And if at all, I would only mention the dark theme ( as it is somhow > popular to have a dark theme), but not at this place, maybe > at the introduction where we show a first screenshot of the enviroment. > (But I don't use the dark theme, so I don't know if the Pharo 5 version > is "production ready". > > >

Nov. 7, 2016