June 2016 - Pharo-dev - lists.pharo.org

IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Esteban Lorenzano

Hi, (this mail is intended to Voyage/MongoTalk users and collaborators) Iâm spending a couple of days in Cologne, at 2Denker offices and I was talking Norbert about organisation of Voyage and the NoSQL driversâ¦ As a conclusion, we want to propose to move the Voyage and MongoTalk development to github, into a common team where other NoSQL drivers can eventually arrive (Voyage will incorporate other backends that might well be there). One reason from this is that I do not consider appropriate to keep Voyage into my repository, because is more a community project than a personal one. I want others to be able to participate more and I think this is the right step (also Dale is porting it to Gemstone soâ¦) Using github we can benefit of their tools to improve our process (issue tracker, travis and appveyor, etc.) and we will improve project visibility. So, we wanted to create âPharoNoSQL" team, and move all thereâ¦ then we will close sthub projects to avoid confusion and we will handle configurations and baselines same way as Yuriy does with QualityAssistance (so it will be available through catalog as always). Opinions? Esteban

June 8, 2016

Re: [Pharo-dev] Story of one small fix

by Esteban Lorenzano

> On 08 Jun 2016, at 11:13, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Just a quick comment. > Did you edited the configurations and their dependencies by hand? Since some time I never update them by hand, only use versioner to generate a new version for ConfigurationOfGToolkitCore and automatically also update all dependencies to all other configurations that I need. Then I make just one issue to integrate ConfigurationOfGToolkitCore that also loads/updates all other configurations. I know this is still not ideal but it's significant less work than what you described. > which is why I made that tool that -almost- no one uses :) Esteban

June 8, 2016

Re: [Pharo-dev] Story of one small fix

by Pavel Krivanek

2016-06-08 11:13 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi Pavel, > > On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> we had in the system circular package dependency between Catalog and >> GTools and we decided to solve it by simple moving of one method from >> one package to other one. However, these two packages are external packages >> managed by configurations. That means that we needed move the method, save >> dirty packages and fix both configurations. >> >> For the catalog we have very simple configuration because it manages only >> one package (and dependency on STON). ConfigurationOfGTInspectorCore was >> more complicated because the repository already included newer development >> version of the modified package so we needed to merge. But because we are >> not the maintainers, we cannot know if the change in this package is not >> requiring changes in other packages provided by the configuration. >> Well, the new configurations were prepared and copied into inbox. We >> needed to create next two issues for updating of the configuration in the >> system. We did it and integrated all together in one update. But that is >> not all... >> ConfigurationOfGTInspectorCore is used by three other configurations ( >> ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and >> ConfgurationOfGTDebugger) that specify number of >> ConfigurationOfGTInspectorCore version. In ideal state you should create >> new versions of the configurations but that means that you need to modify >> configurations of all other configurations that use them. It is simpler >> just modify current configuration and upgrade required version number of >> GTInspectorCore. That means to create three next issues, each for one >> configuration, create new configuration versions (and check and merge the >> newer versions in the home repository if needed), copy them to the inbox, >> wait for the review and hope that during integration the Integrator will >> not create new versions of some packages. If yes, you need to update >> configurations again. >> > > Just a quick comment. > Did you edited the configurations and their dependencies by hand? Since > some time I never update them by hand, only use versioner to generate a new > version for ConfigurationOfGToolkitCore and automatically also update all > dependencies to all other configurations that I need. Then I make just one > issue to integrate ConfigurationOfGToolkitCore that also loads/updates all > other configurations. I know this is still not ideal but it's significant > less work than what you described. > Yes, by hand. I do not use Versionner for packages of others because I'm not 100% sure that it will not break something. -- Pavel > > Chees, > Andrei > > >> So at the end you have at least six issues because you wanted to change >> package for one method that has still the same content and is placed in the >> same class... And it can be worse. Both of these external projects have >> public access to the repository and are managed the same way (not mixing MC >> with GIT). >> >> As you see, it is crazy and unmaintainable. >> >> It is clear that we need to change the process. We need to discuss it >> deeply and some of the results may touch maintainers of the external >> projects integrated in Pharo but please keep in mind that the current >> system is clearly bad. >> >> Cheers, >> -- Pavel >> >> >> >

June 8, 2016

Re: [Pharo-dev] CMD Shift B + N is not equal to CMD B + CMD Shift N

by Nicolai Hess

2016-06-08 9:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > I was coding with a student on a french keyboard (argh) on linux and I was > > teaching him to use shortcuts and we saw that the shortcut reported is > displaying > > Cmd shift B + N > > for class refs while it should be CMD B + CMD Shift N > I'll open a bug retpor. > > I do not know how to fix it but this is confusing for newcomers. > > > Stef > > >

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Esteban Lorenzano

> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr> wrote: > > the fact that I cannot access Spotter without hurting my hand it is also probably why I do not try more. yeah, shortcut has to be configurable, for people with big hands :)

June 8, 2016

Re: [Pharo-dev] endless loop again

by Sven Van Caekenberghe

> On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > > >> >> IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). >> >> Not just because it's cool, but because it's necessary :) >> >> Cheers, >> Henry >> >> >> Very true. >> >> Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly). >> > > Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, > throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ? > And, it could be done with virtually no costs at all - hardware check for this anyway. Good to know ! There is hope then ;-) > Jan > >

June 8, 2016

Re: [Pharo-dev] endless loop again

by Jan Vrany

>> >> IMHO, all Pharo beginner tutorials should start by showing off Cmd >> - dot (or Alt - dot, on Win / Linux). >> >> Not just because it's cool, but because it's necessary :) >> >> Cheers, >> Henry > > Very true. > > Yet, and I have already mentioned this years ago, it is technically > totally possible to properly detect massive stack growth, before > things get out of control. Sadly, VM people think this is not needed > (or too costly). Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) And, it could be done with virtually no costs at all - hardware check for this anyway. Jan

June 8, 2016

Re: [Pharo-dev] Story of one small fix

by Andrei Chis

Hi Pavel, On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > we had in the system circular package dependency between Catalog and > GTools and we decided to solve it by simple moving of one method from one > package to other one. However, these two packages are external packages > managed by configurations. That means that we needed move the method, save > dirty packages and fix both configurations. > > For the catalog we have very simple configuration because it manages only > one package (and dependency on STON). ConfigurationOfGTInspectorCore was > more complicated because the repository already included newer development > version of the modified package so we needed to merge. But because we are > not the maintainers, we cannot know if the change in this package is not > requiring changes in other packages provided by the configuration. > Well, the new configurations were prepared and copied into inbox. We > needed to create next two issues for updating of the configuration in the > system. We did it and integrated all together in one update. But that is > not all... > ConfigurationOfGTInspectorCore is used by three other configurations ( > ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and > ConfgurationOfGTDebugger) that specify number of > ConfigurationOfGTInspectorCore version. In ideal state you should create > new versions of the configurations but that means that you need to modify > configurations of all other configurations that use them. It is simpler > just modify current configuration and upgrade required version number of > GTInspectorCore. That means to create three next issues, each for one > configuration, create new configuration versions (and check and merge the > newer versions in the home repository if needed), copy them to the inbox, > wait for the review and hope that during integration the Integrator will > not create new versions of some packages. If yes, you need to update > configurations again. > Just a quick comment. Did you edited the configurations and their dependencies by hand? Since some time I never update them by hand, only use versioner to generate a new version for ConfigurationOfGToolkitCore and automatically also update all dependencies to all other configurations that I need. Then I make just one issue to integrate ConfigurationOfGToolkitCore that also loads/updates all other configurations. I know this is still not ideal but it's significant less work than what you described. Chees, Andrei > So at the end you have at least six issues because you wanted to change > package for one method that has still the same content and is placed in the > same class... And it can be worse. Both of these external projects have > public access to the repository and are managed the same way (not mixing MC > with GIT). > > As you see, it is crazy and unmaintainable. > > It is clear that we need to change the process. We need to discuss it > deeply and some of the results may touch maintainers of the external > projects integrated in Pharo but please keep in mind that the current > system is clearly bad. > > Cheers, > -- Pavel > > >

June 8, 2016

Re: [Pharo-dev] endless loop again

by Sven Van Caekenberghe

> On 08 Jun 2016, at 10:40, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 04 Jun 2016, at 9:13 , stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 3/6/16 Ã 19:16, Esteban A. Maringolo a Ã©crit : >>> Regarding the first part of your email, about UI lockups, it is almost >>> unavoidable, because in Pharo almost everything happens in the main >>> thread, as you pointed out. >> Yes. This is all my point. > > IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). > > Not just because it's cool, but because it's necessary :) > > Cheers, > Henry Very true. Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly). Consider the following in Common Lisp (LispWorks): CL-USER 1 > (defun fac (n) (if (< n 2) 1 (* n (fac (1- n))))) FAC CL-USER 2 > (fac 5) 120 CL-USER 3 > (fac 100) 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 CL-USER 4 > (fac 400) Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 5 : 1 > :c 1 Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 6 : 1 > :c 1 64034522846623895262347970319503005850702583026002959458684445942802397169186831436278478647463264676294350575035856810848298162883517435228961988646802997937341654150838162426461942352307046244325015114448670890662773914918117331955996440709549671345290477020322434911210797593280795101545372667251627877890009349763765710326350331533965349868386831339352024373788157786791506311858702618270169819740062983025308591298346162272304558339520759611505302236086810433297255194852674432232438669948422404232599805551610635942376961399231917134063858996537970147827206606320217379472010321356624613809077942304597360699567595836096158715129913822286578579549361617654480453222007825818400848436415591229454275384803558374518022675900061399560145595206127211192918105032491008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 CL-USER 7 > (defun infinite () (cons 'a (infinite))) INFINIT CL-USER 8 > (infinite) Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 9 : 1 > :a CL-USER 10 > Just having an upper limit to the stack catches 99% of infinite loops - that would be nice to have. This has existed for 10s of years AFAIK. Sven PS: Of course, the stack size can be set larger to begin with, if necessary. I believe it is even per execution thread.

June 8, 2016

Story of one small fix

by Pavel Krivanek

Hi, we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations. For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration. Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all... ConfigurationOfGTInspectorCore is used by three other configurations ( ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again. So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT). As you see, it is crazy and unmaintainable. It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad. Cheers, -- Pavel

June 8, 2016