- Pharo-dev - lists.pharo.org

Class comments need review (English speakers welcome)

by Cyril Ferlicot Delbecque

Hi! I begun to improve the comments of Collection Sequenceable's classes. I would like the community to review few things: - The English! Since I learned English on video games let's say that my level in far from been perfect :) I most probably made mistakes and I would like English speakers to review that part. - The content. Maybe I wrote bad/useless informations? Maybe I forgot something? Maybe there is an implementation detail you know and that deserve to be in the comment? Maybe you have a cool example to add? - I did not improved the comment of some classes because I don't have enough knowledge on them. (Mostly SharedQueue, SparseLargeTable, SparseLargeArray) It would be welcome that people improve those comments. Or if you don't want to do it you can send me a message with a description of the class and example of usages in the system (since I think that they are used by the core of Pharo). I mostly changed those classes comment: - Interval - LinkedList - OrderedCollection - SortedCollection - OrderedDictionary - OrderedIdentityDictionary If you want to help you can merge this slice from Pharo50Inbox: Name: SLICE-Issue-16945-Improve-Collection-Sequenceable-comments-CyrilFerlicot.3 Author: CyrilFerlicot Time: 26 March 2016, 9:50:43.042998 pm UUID: 54adf1ee-27e4-49e3-ab07-2552486f5f62 Ancestors: SLICE-Issue-16945-Improve-Collection-Sequenceable-comments-CyrilFerlicot.2 Dependencies: Collections-Sequenceable-CyrilFerlicot.238 add example to OrderedIdentityDictionary Thank you in advance for your help! Let's make Pharo a user friendly environment. :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

March 26, 2016

Because organization defeats time

by HernÃ¡n Morales Durand

Some rules and policies of other big popular projects: Python ===== Voting Rules: https://www.python.org/psf/membership/ Membership roster: https://www.python.org/psf/members/ R = Release policies: http://r-pkgs.had.co.nz/release.html Ruby ==== https://www.ruby-lang.org/en/community/ruby-core/#coding-standards https://bugs.ruby-lang.org/projects/ruby/wiki/ReleaseEngineering Does Pharo have something similar? I am the only one who feel Pharo needs better rules/organization? Don't we have something to learn from other projects? HernÃ¡n

March 26, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 073848: 50662

by Tudor Girba

Yes. The other thing it does is that it speeds up Spotter significantly. Doru > On Mar 26, 2016, at 3:14 PM, stepharo <stepharo(a)free.fr> wrote: > > Is this fixing the flickering and unselection deselection in spotter? > > > Le 26/3/16 11:08, GitHub a Ã©crit : >> Moose >> >> http://files.pharo.org/image/50/50662.zip > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

March 26, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Tudor Girba

Hi, > On Mar 26, 2016, at 5:04 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 25/03/2016 13:31, Esteban Lorenzano a Ã©crit : >> Hi, >> >> actually there is a tree implementation based on fast table, but Iâm not >> sure is production ready (Cyril can say something about). >> But anyway since I never understood why we have a tree there (since we >> will âopenâ attribute in next panel), I do agree, strongly :) > > Hi, > > There is a working FTTree with examples and doc in Pharo 5 and there is > a Glamour adaptor as for FastTable (With examples in GLMExampleBrowser). > Since it is not use for now they might be some bugs. I think that the > code would benefits some review from experienced people since I am still > far from being as good as most of the developers here :) > For example some things I do not like: > - Since I warped data into Items object I had to add a "realElementAt:" > method in the dataSource. This is not wanted in my opinion but I don't > know how to remove it and I don't have the time to work on it anymore. > - Some features cause infinite loop if the number of children is > infinite (for example, search in all the items). I wrote it in the > documentation when that might happen but maybe we can reduce the number > of feature that can provoke that? > - I think that the search/filtering time can be improve when we have to > check in the complete tree. > > I would like that experienced people check the code before we really use > it because if there is some change in the design to do, we should do it > now. As far as I saw, this is just a tree, not a tree with table (like the one used in the Raw presentation). Am I wrong? Cheers, Doru >> not sure, I open and it takes some seconds to actually show anything. I >> thought it was caused because of the catalog refresh to populate >> projects, but Iâm not sure. >> In any case, load catalog projects in spotter is cool, but we need to >> find a better implementation. One that does not freezes spotter until it >> refresh (remember, Pharo is also used in places with crapy connection or >> not connection at all). >> >> yes! >> >> if you want to suffer, do this experiment: >> 1. open a Pharo2 and open debugger on anything >> 2. then Pharo3, 4 and 5â¦ feel the incremental slowdown >> 3. cry :â( >> >> Esteban >> >> > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

March 26, 2016

Re: [Pharo-dev] GTExample support is pretty cool!

by Tudor Girba

Hi, Thanks. > On Mar 26, 2016, at 3:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > hi! > > Not sure if some of you are aware of it. Stefan has been working on a support for example. > Examples are accessible only by inspecting a class. > Try to inspect Dictionary and you will see a tab examples. > > Inspect RTDSM (when you have Roassal loaded) to have graphical example. > > For the GT team: it would be great to have a better management of the Tab for classes. Currently it is a mess :-) What do you mean more specifically? Doru > Anyway, this example support is pretty cool! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

March 26, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by stepharo

Le 26/3/16 15:50, Cyril Ferlicot D. a Ã©crit : > Le 26/03/2016 09:19, stepharo a Ã©crit : >> But you see you are becoming the most aware for athens >> and what we should do is document document. >> Now I got ****EXHAUSTED**** to document things that I did not build or >> use daily. This effort for me is gigantic >> and I cannot do it each time. > In my opinion Pharo should refuse to include any class without at least > a one line documentation for the small classes. And when someone review > a bug correction and see that an important class have a really small > documentation it should be a stop for the integration. > > I never saw a Java class without documentation on oracle site. :) at least you made my day comparing pharo with oracle I felt proud :) > > This will slow down the integration of some project, but since everyone > agree that pharo included too many project, this should not be a > problem. At least we would integrate only projects understandable by the > others.

March 26, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by phil＠highoctane.be

My point was about the Versioning approach. Tiki is about all kinds of things. That's what you get with millions of lines of PHP code and, indeed, millions of downloads etc. It is a community building tool. Check https://tiki.org/Features and mix and match them as most things can be combined orthogonally (like security meet calendar, or trackers meet articles). That's a hell of a powerful tool I can tell you. I used it to support several businesses and it rocks. Like Squeak and Pharo, it may lead to some "what's this thing?" impressions. Phil On Sat, Mar 26, 2016 at 3:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Phil, > > > > > _,,,^..^,,,_ (phone) > On Mar 26, 2016, at 3:07 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > In Tiki, our versioning policy is like this: > > https://tiki.org/Versions > > > Hmmph! :-). Tiki's "About" page is one of those maddeningly useless ones > that speaks to the choir. It should start with a "Tiki is a ..." paragraph > that explains what tiki is to those that have never heard of it before. > Instead it gushes on for ages declaring "we have history", "we eat dog > food", "we have a huge install base" but I still have /no idea/ what tiki > is as a black box or a white box. Grrrr ;-) > > > Going on nicely since 2009. > > Phil > > This email has been sent from a virus-free computer protected by Avast. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > <#m_-5685355456190387811_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Stef, >> >> On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> So guys, you do not want Xtreams (and prefer to use Streams that have >>> been "designed" decades ago) ;D ? >>> no bootstrapped core (clement you do not want to have a mini image :) ? >>> and a new UI frameworks? >>> >> >> yes, of course :-) >> >> >>> I personnally want to have new widgets, a real UI builder and massively >>> cleaning Spec. >>> Now I would like to have multiple tool sets - I understand that people >>> like the new debugger (I do not like it) - >>> I want the possibility to have a mini tools tool set. >>> >> >> +1 >> >> >>> If you want to clean Pharo you can start cleaning Komitter stupid use of >>> state pattern generating >>> a lot of garbage instead of having a single animated morph. >>> >>> We should clean Versionner- I have the impression that half of the >>> classes are not mandatory. >>> >> >> I don't think this is either or. I don't think Hilaire is saying "don't >> do feature-rich releases". I think Hilaire is saying "do separate >> feature-rich and consolidation releases". >> >> I think Hilaire is making a good suggestion of having some releases being >> for new functionality and some for consolidation. So perhaps the community >> could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, >> where M is even (or odd) and a Pharo N, where N is odd (or even), and have >> the N.1, or N is odd (or even) releases being consolidation releases as >> Hilaire describes, with no new features and only bug fixes and performance >> improvements. If the community can manage it, it could do one new feature, >> followed by one consolidation release a year. But if so, the community >> needs to be serious about the consolidation releases and put real effort >> into them. >> >> The advantage for the broader user base is clear; there is a steady >> stream of releases that more conservative users can use, that exhibits good >> stability and better performance than the bleeding edge. >> >> Also, there's no reason why these release cycles can't overlap. The only >> time they must not overlap is when the community needs to focus on the new >> release. So for example, for two months of the year, six months apart, the >> community should focus on the new release, be it consolidation or >> feature-rich, and make sure we release promptly and correctly. But the >> other ten months of the year there's no reason why the community cannot >> work on either release. This requires infrastructure such as two >> repositories, one for each, such as pharo-features and pharo-stable, and >> the discipline to separate one's work correctly, but it could be a really >> good thing. I'm sure others can think this through better than I. What do >> others suggest? >> >> Stef >>> >>> 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >>> >>>> Not exactly related to Announcement, but I remember when I first port >>>> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >>>> change/update when objects in the canvas changed. It was terribly slow, >>>> and later opted for a top-down update in the list of object. >>>> >>>> So some sometime what look like a cool stuff (decoupled objects) is just >>>> a drag. >>>> >>>> Regarding optimizing, I share my opinion here months ago, I think Pharo >>>> need consolidation releases: no new features, only bugs fix and speed >>>> improvement. There are enough new features in Pharo for a couple of >>>> years, but the product need to *be* solid and *feel* solid. >>>> >>> >>> +1 >>> >>> >>>> >>>> Hilaire >>>> >>>> Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : >>>> > On 25-03-16 11:49, Nicolai Hess wrote: >>>> >> Morphic drasticallly slower ? I would expect morphic code is mostly >>>> >> the same in pharo and squeak. If pharo is slower, this is a good >>>> >> starting point for optimising. Can you gives some hints? >>>> > I do not have the impression that morphic is so much slower. >>>> > We had/have a problem of too many announcements being send and >>>> > too many redraws happening. >>>> > >>>> > Stephan >>>> > >>>> > >>>> >>>> -- >>>> Dr. Geo >>>> http://drgeo.eu >>>> >>>> >>>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > >

March 26, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by phil＠highoctane.be

Good luck with things like Roassal or Seaside. As of Java, sure, but Javadoc is only a small part. Try to understand Swing with Javadocs and no thick book, good luck with that. The Java Tutorial is another matter. Phil This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Mar 26, 2016 at 3:50 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 26/03/2016 09:19, stepharo a Ã©crit : > > > > But you see you are becoming the most aware for athens > > and what we should do is document document. > > Now I got ****EXHAUSTED**** to document things that I did not build or > > use daily. This effort for me is gigantic > > and I cannot do it each time. > > In my opinion Pharo should refuse to include any class without at least > a one line documentation for the small classes. And when someone review > a bug correction and see that an important class have a really small > documentation it should be a stop for the integration. > > I never saw a Java class without documentation on oracle site. > > This will slow down the integration of some project, but since everyone > agree that pharo included too many project, this should not be a > problem. At least we would integrate only projects understandable by the > others. > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

March 26, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Cyril Ferlicot D.

Le 25/03/2016 13:31, Esteban Lorenzano a Ã©crit : > Hi, > > actually there is a tree implementation based on fast table, but Iâm not > sure is production ready (Cyril can say something about). > But anyway since I never understood why we have a tree there (since we > will âopenâ attribute in next panel), I do agree, strongly :) Hi, There is a working FTTree with examples and doc in Pharo 5 and there is a Glamour adaptor as for FastTable (With examples in GLMExampleBrowser). Since it is not use for now they might be some bugs. I think that the code would benefits some review from experienced people since I am still far from being as good as most of the developers here :) For example some things I do not like: - Since I warped data into Items object I had to add a "realElementAt:" method in the dataSource. This is not wanted in my opinion but I don't know how to remove it and I don't have the time to work on it anymore. - Some features cause infinite loop if the number of children is infinite (for example, search in all the items). I wrote it in the documentation when that might happen but maybe we can reduce the number of feature that can provoke that? - I think that the search/filtering time can be improve when we have to check in the complete tree. I would like that experienced people check the code before we really use it because if there is some change in the design to do, we should do it now. > not sure, I open and it takes some seconds to actually show anything. I > thought it was caused because of the catalog refresh to populate > projects, but Iâm not sure. > In any case, load catalog projects in spotter is cool, but we need to > find a better implementation. One that does not freezes spotter until it > refresh (remember, Pharo is also used in places with crapy connection or > not connection at all). > > yes! > > if you want to suffer, do this experiment: > 1. open a Pharo2 and open debugger on anything > 2. then Pharo3, 4 and 5â¦ feel the incremental slowdown > 3. cry :â( > > Esteban > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

March 26, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Eliot Miranda

Hi Phil, _,,,^..^,,,_ (phone) > On Mar 26, 2016, at 3:07 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > > In Tiki, our versioning policy is like this: > > https://tiki.org/Versions Hmmph! :-). Tiki's "About" page is one of those maddeningly useless ones that speaks to the choir. It should start with a "Tiki is a ..." paragraph that explains what tiki is to those that have never heard of it before. Instead it gushes on for ages declaring "we have history", "we eat dog food", "we have a huge install base" but I still have /no idea/ what tiki is as a black box or a white box. Grrrr ;-) > > Going on nicely since 2009. > > Phil > > This email has been sent from a virus-free computer protected by Avast. > www.avast.com > >> On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Stef, >> >>> On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote: >>> So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? >>> no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks? >> >> yes, of course :-) >> >>> I personnally want to have new widgets, a real UI builder and massively cleaning Spec. >>> Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - >>> I want the possibility to have a mini tools tool set. >> >> +1 >> >>> If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating >>> a lot of garbage instead of having a single animated morph. >>> >>> We should clean Versionner- I have the impression that half of the classes are not mandatory. >> >> I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases". >> >> I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them. >> >> The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge. >> >> Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest? >> >>> Stef >>>> 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >>>>> Not exactly related to Announcement, but I remember when I first port >>>>> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >>>>> change/update when objects in the canvas changed. It was terribly slow, >>>>> and later opted for a top-down update in the list of object. >>>>> >>>>> So some sometime what look like a cool stuff (decoupled objects) is just >>>>> a drag. >>>>> >>>>> Regarding optimizing, I share my opinion here months ago, I think Pharo >>>>> need consolidation releases: no new features, only bugs fix and speed >>>>> improvement. There are enough new features in Pharo for a couple of >>>>> years, but the product need to *be* solid and *feel* solid. >>>> >>>> +1 >>>> >>>>> >>>>> Hilaire >>>>> >>>>> Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : >>>>> > On 25-03-16 11:49, Nicolai Hess wrote: >>>>> >> Morphic drasticallly slower ? I would expect morphic code is mostly >>>>> >> the same in pharo and squeak. If pharo is slower, this is a good >>>>> >> starting point for optimising. Can you gives some hints? >>>>> > I do not have the impression that morphic is so much slower. >>>>> > We had/have a problem of too many announcements being send and >>>>> > too many redraws happening. >>>>> > >>>>> > Stephan >>>>> > >>>>> > >>>>> >>>>> -- >>>>> Dr. Geo >>>>> http://drgeo.eu >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >

March 26, 2016