April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Please, test our 64bits builds

by Alistair Grant

Hi Esteban, On Fri, Apr 14, 2017 at 08:06:05AM +0000, Alistair Grant wrote: > > I've basically moved my personal environment to 64 bits, which means all > of the following have been loaded and most have had some adhoc testing: > > Iceberg > OSProcess If I try this with any of the VMs I built, OSProcess causes the image to lock up as soon as a process is forked (there aren't any error messages on the console and Ctrl-. doesn't work). Also the grimReaper process fails regularly. I haven't tried every recent commit, but it appears that the only VM I have that works with OSProcess is: $ ./pharo --version 5.0-201704120850 Wed Apr 12 09:11:51 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Apr 12 10:50:48 2017 +0200 $ Plugins: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-05737cd5-38bf-479c-9575-20f53c3bf93b 3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux plugin path: /dev/shm/pharo64/pharo-vm/lib/pharo/5.0-201704120850 [default: /dev/shm/pharo64/pharo-vm/lib/pharo/5.0-201704120850/] Note: I'm building from https://github.com/pharo-project/pharo-vm.git Should I open an issue in fogbugz for this (with code to reproduce and more details on the grim reaper process)? P.S. I think Pharo 5 included in the commit id in the version information. It would be nice for that to reappear in V6. Thanks! Alistair

April 16, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Tudor Girba

However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable. The only thing we need is to Metacello to be able to load new versions of the configuration/baseline. Cheers, Doru > On Apr 16, 2017, at 8:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > For the record, the way we load the latest version of Moose is to explicitly load the configurations we know about as being in the base Pharo image. Like this: > > ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; package: 'ConfigurationOfGTSpotter'; package: 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTPlaygroundCore'; package: 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore'; package: 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true andQuit: true." > > This is a horrible hack, and like any hack it backfires in time. It backfired now because we forgot about MooseAlgos being in the base Pharo image :). > > Cheers, > Doru > > >> On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> >> On 15/04/2017 23:16, Tudor Girba wrote: >>> Hi, >>> >>> Ok, that is a better reason. >>> >>> As far as I can tell, the baseline situation is not much better, is it? >>> >>> Cheers, >>> Doru >>> >> >> Yes. >> >> If the process would have been the same for Pharo 7 than for Pharo 6 I >> would have suggest to unload the configurations after every update of a >> project using configuration. >> >> Here, since the process will change I wait to see how the new process >> will look like. But I would like the configurations/baselines to be >> unload of Pharo to avoid this. >> >> I would like to unload all the configurations of the image of Pharo 6 to >> remove a potential bug source of Pharo 6 for future users who would need >> an update of GlamourCore, a GT tool, Ston, UFFI or any other project >> having his configuration in the image. >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > -- www.tudorgirba.com www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

April 16, 2017

Re: [Pharo-dev] [Pharo-users] why is adding instance variables so slow?

by Tudor Girba

Hi, Please letâs move this discussion on pharo-dev. And keep going :) Cheers, Doru > On Apr 14, 2017, at 12:09 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-04-14 11:09 GMT+02:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Hi, I think the problem was not clearly explained. This is the scenario that is problematic. > This scenario does not happen in the new Spur implementation of forwarding, but I think is happening in the old one. > > 1. You have, let's say 3 instances of ClassA. > 2. You add a new instance variable to ClassA. It produces > 2a. A new ClassAv2 is created with the instances variables of ClassA and the newone > 2b. 3 Instances of ClassAv2 are created > 2c. The values of the instance variables of ClassA are copied to the ones in ClassAv2 (the ones missing are left in nil). > 2d. The 3 instances of ClassA are becomed forward to the 3 instances of ClassAv2 > 2e. The ClassA is becomed forward ClassAv2 > > I still not see why my example not reflects all these steps. I checked also scenario with class becoming: > > c1 := Class1 new. > c2 := Class2 new. > c1 becomeForward: c2. > Class1 becomeForward: Class2. > Class2 allInstances "=>#(aClass2)" > > It also works in Cog -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

April 16, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Tudor Girba

Hi, For the record, the way we load the latest version of Moose is to explicitly load the configurations we know about as being in the base Pharo image. Like this: ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; package: 'ConfigurationOfGTSpotter'; package: 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTPlaygroundCore'; package: 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore'; package: 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true andQuit: true." This is a horrible hack, and like any hack it backfires in time. It backfired now because we forgot about MooseAlgos being in the base Pharo image :). Cheers, Doru > On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 15/04/2017 23:16, Tudor Girba wrote: >> Hi, >> >> Ok, that is a better reason. >> >> As far as I can tell, the baseline situation is not much better, is it? >> >> Cheers, >> Doru >> > > Yes. > > If the process would have been the same for Pharo 7 than for Pharo 6 I > would have suggest to unload the configurations after every update of a > project using configuration. > > Here, since the process will change I wait to see how the new process > will look like. But I would like the configurations/baselines to be > unload of Pharo to avoid this. > > I would like to unload all the configurations of the image of Pharo 6 to > remove a potential bug source of Pharo 6 for future users who would need > an update of GlamourCore, a GT tool, Ston, UFFI or any other project > having his configuration in the image. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

April 16, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Hilaire

Life can be very UNFAIR but I don't see how it is related to the previously expressed opinions about what people fell. Le 15/04/2017 Ã 17:07, Stephane Ducasse a Ã©crit : > behavior. I'm just thinking that it is UNFAIR!!!! -- Dr. Geo http://drgeo.eu

April 16, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Dimitris Chloupis

Totally agree Phil even on the documentation front we are light years ahead of version 2. I think it will become a problem that Pharo improves to fast, but that's a blessing problem.kudos to the amazing work of Pharo devs . On Sat, 15 Apr 2017 at 21:32, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Bah, I made GTSpotter dark theme work with SublimishTheme and got the > "yeah, for Pharo7". > > It is pissing me off but what can I say, just follow what is released. > > Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues. > > Phil > > On Sat, Apr 15, 2017 at 4:48 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> I vote for a voting system for these kind of changes. I cannot say it >> more clearly, and I don't know why is asking for a voting system negative? >> >> We all have problems. In the meantime you will make all the changes you >> like to do, and I will continue working on my own way, until I find there >> is more voice for the "small minority". >> >> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Hi Hernan >>> >>> Why are you always so negative? Do you think that this is easy? >>> >>> Inria paid Denis to build a remote tool suite for ***research purpose*** >>> and we discovered that a new remote invocation framework was needed and >>> that they were far too many discussions between the model and the view. >>> Denis proposed to build a new browser (and it was not in our plans) and >>> we decided that we cannot do it otherwise. >>> We could keep this tool for us but we share it with the community. >>> >>> Do you want another example? >>> I asked christopher to build versionner and he discovered that he cannot >>> script well enough the model. And versionner was made >>> for everybody. Now with git we will have to revise it. >>> >>> Do you want another example? >>> Iceberg we payed nicolas passerini to analyse the situation and to build >>> a system that other people >>> can use it. >>> >>> Do you want another example? >>> Esteban got in his face the FFI problem: you see Spur arrives and FFI >>> nabive boost does not so what do we do? >>> He worked like a mad (and it was not planned because we thought that >>> igor would adpta NB to spur then to 64 bits). >>> And the FFI is for everbody. >>> >>> Do you want another example? >>> We spent one year with pavel, guillermo and christophe to make sure that >>> we can make sure that the three yars >>> effort of the phd of guillermo on bootstrap are not lost. >>> >>> Do you want more? >>> All my books are open-source? Do you know how much time I take to write >>> a book? >>> >>> I spent 8 months designing a mooc and do you know how much I earned >>> doing it: 3000 Euros ( so I will make the computation to know how much per >>> hour I lost) and the mooc is free. >>> >>> May be all these examples have no value for you. But for me they have. >>> >>> So you see you can piss on us if it makes you feeling better, and you >>> can rant in your corner. >>> But this is not the vision I have about a community because we are >>> sharing all the things that we are doing. >>> >>> Stef >>> >>> >>> >>> >>> On Sat, Apr 15, 2017 at 9:05 AM, HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>>> >>>> 2017-04-14 8:44 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>>> >>>>> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>>> Also I am really wondering that this decision was not publicly >>>>>> discussed. We should vote for such kind of changes. >>>>>> >>>>>> >>>>>> no, this is not how it works. >>>>>> >>>>> >>>>> yes, it is how it could work :) >>>>> >>>>> Current approach is not bad for technical choices because it is >>>>> difficult to make everybody evolved in particular technical topic. >>>>> But look&feel is different. You just open Pharo and have impression is >>>>> it looks good or not. Voting can work here. >>>>> >>>> >>>> I would forget about it. I stopped waiting for votes long time ago in >>>> this community. Also I decided to stop contributing to external projects >>>> (including reporting bugs) because who knows which tool (browser, morphic, >>>> etc) the board would like to add/remove tomorrow. I will not invest my time >>>> fixing tools who knows what's the plan on them. >>>> >>>> The best you can do is to work in the dark and adapt your stuff with >>>> each new Pharo version. >>>> Of course anyone with enough time/money could fork a new more >>>> democratic Pharo ;) >>>> >>>> HernÃ¡n >>>> >>>> >>> >> >

April 15, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by ClÃ©ment Bera

Isn't a couple days before release a bit late to change the default theme ? Aren't we in feature freeze mode ? If for marketing it makes sense to switch to the dark theme, then let's switch to dark theme. But why not switching for Pharo 7 instead ? Instability is bad for marketing anyway, isn't it ? I don't mind for myself, I will always switch back with user settings to the light theme it's more about the general perception of Pharo stability. On Sat, Apr 15, 2017 at 11:31 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Bah, I made GTSpotter dark theme work with SublimishTheme and got the > "yeah, for Pharo7". > > It is pissing me off but what can I say, just follow what is released. > > Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues. > > Phil > > On Sat, Apr 15, 2017 at 4:48 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> I vote for a voting system for these kind of changes. I cannot say it >> more clearly, and I don't know why is asking for a voting system negative? >> >> We all have problems. In the meantime you will make all the changes you >> like to do, and I will continue working on my own way, until I find there >> is more voice for the "small minority". >> >> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Hi Hernan >>> >>> Why are you always so negative? Do you think that this is easy? >>> >>> Inria paid Denis to build a remote tool suite for ***research purpose*** >>> and we discovered that a new remote invocation framework was needed and >>> that they were far too many discussions between the model and the view. >>> Denis proposed to build a new browser (and it was not in our plans) and >>> we decided that we cannot do it otherwise. >>> We could keep this tool for us but we share it with the community. >>> >>> Do you want another example? >>> I asked christopher to build versionner and he discovered that he cannot >>> script well enough the model. And versionner was made >>> for everybody. Now with git we will have to revise it. >>> >>> Do you want another example? >>> Iceberg we payed nicolas passerini to analyse the situation and to build >>> a system that other people >>> can use it. >>> >>> Do you want another example? >>> Esteban got in his face the FFI problem: you see Spur arrives and FFI >>> nabive boost does not so what do we do? >>> He worked like a mad (and it was not planned because we thought that >>> igor would adpta NB to spur then to 64 bits). >>> And the FFI is for everbody. >>> >>> Do you want another example? >>> We spent one year with pavel, guillermo and christophe to make sure that >>> we can make sure that the three yars >>> effort of the phd of guillermo on bootstrap are not lost. >>> >>> Do you want more? >>> All my books are open-source? Do you know how much time I take to write >>> a book? >>> >>> I spent 8 months designing a mooc and do you know how much I earned >>> doing it: 3000 Euros ( so I will make the computation to know how much per >>> hour I lost) and the mooc is free. >>> >>> May be all these examples have no value for you. But for me they have. >>> >>> So you see you can piss on us if it makes you feeling better, and you >>> can rant in your corner. >>> But this is not the vision I have about a community because we are >>> sharing all the things that we are doing. >>> >>> Stef >>> >>> >>> >>> >>> On Sat, Apr 15, 2017 at 9:05 AM, HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>>> >>>> 2017-04-14 8:44 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>>> >>>>> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>>> Also I am really wondering that this decision was not publicly >>>>>> discussed. We should vote for such kind of changes. >>>>>> >>>>>> >>>>>> no, this is not how it works. >>>>>> >>>>> >>>>> yes, it is how it could work :) >>>>> >>>>> Current approach is not bad for technical choices because it is >>>>> difficult to make everybody evolved in particular technical topic. >>>>> But look&feel is different. You just open Pharo and have impression is >>>>> it looks good or not. Voting can work here. >>>>> >>>> >>>> I would forget about it. I stopped waiting for votes long time ago in >>>> this community. Also I decided to stop contributing to external projects >>>> (including reporting bugs) because who knows which tool (browser, morphic, >>>> etc) the board would like to add/remove tomorrow. I will not invest my time >>>> fixing tools who knows what's the plan on them. >>>> >>>> The best you can do is to work in the dark and adapt your stuff with >>>> each new Pharo version. >>>> Of course anyone with enough time/money could fork a new more >>>> democratic Pharo ;) >>>> >>>> HernÃ¡n >>>> >>>> >>> >> >

April 15, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Cyril Ferlicot D.

On 15/04/2017 23:16, Tudor Girba wrote: > Hi, > > Ok, that is a better reason. > > As far as I can tell, the baseline situation is not much better, is it? > > Cheers, > Doru > Yes. If the process would have been the same for Pharo 7 than for Pharo 6 I would have suggest to unload the configurations after every update of a project using configuration. Here, since the process will change I wait to see how the new process will look like. But I would like the configurations/baselines to be unload of Pharo to avoid this. I would like to unload all the configurations of the image of Pharo 6 to remove a potential bug source of Pharo 6 for future users who would need an update of GlamourCore, a GT tool, Ston, UFFI or any other project having his configuration in the image. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

April 15, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Tudor Girba

Hi, Ok, that is a better reason. As far as I can tell, the baseline situation is not much better, is it? Cheers, Doru > On Apr 15, 2017, at 11:12 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 15/04/2017 23:08, Tudor Girba wrote: >> Hi, >> >> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see? >> >> Cheers, >> Doru >> >> > > If you have a project depending on another project that got his > configuration in the image, the configuration will not be updated if you > do not do it explicitly. > > We found with Pavel that the version of MooseAlgo used by Moose was > outdated because ConfigurationOfMooseAlgos was in the image with 5-6 > commits late. > > Users should not have to update the configuration of the dependencies of > their project by hand in their builds because Pharo has old > configurations inside the image. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

April 15, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Tudor Girba

Of course. But, that will only be applicable to people using Pharo 7 and beyond. For people using Pharo 6, they will still rely on how the code was packaged for that release. Or did I miss something? Doru > On Apr 15, 2017, at 11:11 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I understand that since the whole development will be Git-based, then the configurations will be pretty much obsolete. > > Alexandre > > >> On Apr 15, 2017, at 6:08 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see? >> >> Cheers, >> Doru >> >> >> >>> On Apr 14, 2017, at 2:24 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>> >>> >>> 2017-04-14 14:20 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> >>> >>> On Apr 14, 2017 14:13, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: >>> >>> >>> 2017-04-14 12:52 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> Isn't it a bit too late for such a change? Might break projects that expect configurations to be present. >>> >>> I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream. >>> >>> Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present. >>> >>> For the record, I still think it's not the best idea to do this now :) >>> >>> Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too. >>> >>> -- Pavel >>> >>> >>> Cheers, >>> Andrei >>> >>> >>> Cheers, >>> -- Pavel >>> >>> >>> Cheers, >>> Andrei >>> >>> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos). >>> >>> So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step? >>> >>> Cheers, >>> -- Pavel >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com www.feenk.com "No matter how many recipes we know, we still value a chef."

April 15, 2017