August 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] What is the plan with Pharo changes?

by Mariano Martinez Peck

Hi guys. PLEASE: I DON'T WANT TO START A WAR. I am just concerned about Pharo and it's future. I am totally in favor of making progress even if it breaks compatibility. I am all in favor of having to spend time and effort in updating projects to use latest Pharo changes. Today I faced a couple of problems with Metacello and Pier. Most problems were related to: 1) SystemChangeNotifier -> SystemAnnouncer 2) FileDirectory -> FileSystem so...after a couple of fixes, I was able to make them both to work in last Pharo version. So, DO NOT GO OFFTOPIC please. My question is, how can we make sure that we are not all trying to updated existing packages? I mean, I have updated Metacello (a part of it) and Pier. So what do we do? where do I commit without affecting all those not using Pharo 2.0 ? how can others take advantage of it? thanks guys. -- Mariano http://marianopeck.wordpress.com

Aug. 3, 2012

[Pharo-project] about mirroring

by StÃ©phane Ducasse

Hi guys I would like to raise this issue while this is calm and that the servers are working. What do we do to replicate our servers: ss3 and smalltalkHub I asked nicolas and christophe to check because the original plan (I still like it) is to host SmalltalkHub servers on INRIA infrastructure and the plan was to replicate it in three nodes of the server rooms across the country. Now we could have a mirroring also between such server and the one hosted by nicolas company. I will start to migrate all my projects from Squeaksource. Stef

Aug. 3, 2012

Re: [Pharo-project] Memory usage

by StÃ©phane Ducasse

> Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(. I imagine well, believe me and I'm a bit sad about all the story around VMs. I see all the infrastructure that igor built and there is not much cooperation around it even if esteban happily uses it and build on top. I see igor's fixes not even commented by other VM maintainers, probably too busy. So I have the impression that soon or later we will have to take our responsibilities but I would have preferred another situation with more collaboration. Anyway this is like that and we have to grow our knowledge on VMs. Because we can be the best on image side, if there is nobody to improve the VMs we will all be dead. Funnily google contacted igor, esteban and camillo to work on VMs for them. Now we will see I hope that the consortium will bring enough money to pay one guy to work on that. RMOD will put 6 months salary on the table for sure to pay igor. Stef

Aug. 3, 2012

[Pharo-project] NOC meets NEC and good energy happens!

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=6519 I really love seeing that happens. Thanks camillo! I like that because I spent time cleaning OCompletion to avoid duplication and being able to load it with ECompletion, Esteban did a pass and made my work working and now you give the final touch. I think that this is a good illustration of the power of improving infrastructure step by step and being able to build on the previous step. Stef

Aug. 3, 2012

Re: [Pharo-project] Memory usage

by jannik.laval

No, no, The experiment was made with the VM included in the one-click Moose, in a MacOs X 10.8. For now, I do not succeed to use the 64bit VM and build a usable 64bit image. Jannik On Aug 3, 2012, at 10:09 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(. > > But, I think the experiment of Jannik was done with the special 64-bit VM. Jannik, am I right? > > Cheers, > Doru > > > On 3 Aug 2012, at 15:00, StÃ©phane Ducasse wrote: > >> so this means that the comment of Fabrizio about the limit of 500 mb was only for windows. >> >> Stef >> >> >> >>> Not bad :) >>> >>> Doru >>> >>> On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: >>>> >>>> On Aug 2, 2012, at 10:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> On Aug 2, 2012, at 10:17 PM, jannik.laval wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I tried the VM included in Moose (moosetechnology.org) >>>>>> If I remember well, it is a cog vm. >>>>>> >>>>>> The maximal heap size is (precisely): 2138046463 bytes. >>>>>> Why this number ? I don't know. But I will need more than 2Gb. >>>>> >>>>> HI jannik >>>>> >>>>> was the system usable? >>>>> Because the problem with more memory is that you need specific GCes. >>>> >>>> It seems. >>>> I built a DSM on a 1300 packages system. >>>> >>>> Jannik >>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>>> >>>>>> I will try the 64bits vm, and see. >>>>>> >>>>>> Cheers, >>>>>> Jannik >>>>>> >>>>>> On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> There is no regression in the interpreter VM ... well actually there was >>>>>>> about 6 months back, but I keep an eye on it and it's fixed again now :) >>>>>>> >>>>>>> The 32-bit interpreter VM will not fail on any 2GB or 4BG boundaries, >>>>>>> and an interpreter VM compiled for the 64-bit object format can handle >>>>>>> images greater than 7GB (probably much more, but my 8GB PC is too small >>>>>>> to do anything larger). >>>>>>> >>>>>>> I'm not sure if all of the necessary fixes are in place for the StackVM >>>>>>> and Cog. If not, I'm sure it will be addressed over time (it's just not >>>>>>> something that I have ever checked). >>>>>>> >>>>>>> I believe that Jannik is interested in running very large images, at >>>>>>> least on an experimental basis. For anything over a few GB, this requires >>>>>>> an interpreter VM and a 64-bit image. As you know, this is sure to run >>>>>>> into problems for the garbage collector as the number of objects >>>>>>> increases, but it would certainly be interesting to see how far the >>>>>>> current garbage collector can go in real world conditions before it >>>>>>> turns to mollasses. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 01, 2012 at 08:57:02AM -0400, John McIntosh wrote: >>>>>>>> A few years back the interpreted virtual machine was fixed to allow an >>>>>>>> image to grow to the 4 GB limit. >>>>>>>> It is unclear to me if someone regressed the software to impose a 2GB limit >>>>>>>> again, or if the 2GB number >>>>>>>> mentioned is based on how things worked10 years ago? >>>>>>>> >>>>>>>> On Wed, Aug 1, 2012 at 5:01 AM, St?phane Ducasse >>>>>>>> <stephane.ducasse(a)inria.fr>wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 31, 2012, at 11:46 PM, johnmci wrote: >>>>>>>>> >>>>>>>>>> David Lewis and I spent a far amount of time a few years back to make >>>>>>>>> the 32 >>>>>>>>>> vm 4gb clean. So are you running on stale knowledge here, or does the vm >>>>>>>>>> crash when to goes over 2gb? >>>>>>>>> >>>>>>>>> sorry my english limit does not let me know understanding what you mean >>>>>>>>> exactly. >>>>>>>>> Jannik in the context of moose would like to see if we can have image >>>>>>>>> larger than 500 mb (on mac it should be possible). >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>> >>>>>> >>>>>> --- >>>>>> Jannik Laval >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> --- >>>> Jannik Laval >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > -- > www.tudorgirba.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > --- Jannik Laval

Aug. 3, 2012

Re: [Pharo-project] Completion

by Camillo Bruni

On 2012-08-03, at 22:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Please keep in mind that the reason for showing only the OCompletion list at first was speed. If you are using both at the same time, you might get a performance penalty. so far it works reasonably fast. and looking at the code I see that the complete list is calculated each time anyway. not showing the complete list IMO renders the completion utterly useless.

Aug. 3, 2012

Re: [Pharo-project] Completion

by Tudor Girba

Please keep in mind that the reason for showing only the OCompletion list at first was speed. If you are using both at the same time, you might get a performance penalty. Cheers, Doru On 3 Aug 2012, at 21:55, Camillo Bruni wrote: > yep we just figured that out... > so now we will only have one list which displays all the matches. > the first 6 are by priority, the rest sorted alphabetically. > > this will hopefully be much more productive > > On 2012-08-03, at 21:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> When using OCompletion, if you scroll to the bottom of the list (with keydown), you should get the ECompletion list. >> >> Cheers, >> Doru >> >> >> On 3 Aug 2012, at 18:42, Esteban Lorenzano wrote: >> >>> please go :) >>> >>> NEController and NOController would be the place >>> >>> On Aug 3, 2012, at 6:21 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> I don't particularly like the current completion mechanism in pharo: >>>> >>>> - the OCompletion (or what it is called) only displays a limited number of selectors >>>> - the second completion (which is complete!) using CMD-Q is in many cases more helpful >>>> >>>> >>>> Could we combine these two? Simply concatenate the two lists and we're done! >>>> Where is the place to look for that? >>>> >>>> best >>>> cami >>> >>> >> >> -- >> www.tudorgirba.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Aug. 3, 2012

Re: [Pharo-project] Memory usage

by Tudor Girba

Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(. But, I think the experiment of Jannik was done with the special 64-bit VM. Jannik, am I right? Cheers, Doru On 3 Aug 2012, at 15:00, StÃ©phane Ducasse wrote: > so this means that the comment of Fabrizio about the limit of 500 mb was only for windows. > > Stef > > > >> Not bad :) >> >> Doru >> >> On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: >>> >>> On Aug 2, 2012, at 10:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Aug 2, 2012, at 10:17 PM, jannik.laval wrote: >>>> >>>>> Hi, >>>>> >>>>> I tried the VM included in Moose (moosetechnology.org) >>>>> If I remember well, it is a cog vm. >>>>> >>>>> The maximal heap size is (precisely): 2138046463 bytes. >>>>> Why this number ? I don't know. But I will need more than 2Gb. >>>> >>>> HI jannik >>>> >>>> was the system usable? >>>> Because the problem with more memory is that you need specific GCes. >>> >>> It seems. >>> I built a DSM on a 1300 packages system. >>> >>> Jannik >>> >>>> >>>> Stef >>>> >>>> >>>> >>>>> >>>>> I will try the 64bits vm, and see. >>>>> >>>>> Cheers, >>>>> Jannik >>>>> >>>>> On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> There is no regression in the interpreter VM ... well actually there was >>>>>> about 6 months back, but I keep an eye on it and it's fixed again now :) >>>>>> >>>>>> The 32-bit interpreter VM will not fail on any 2GB or 4BG boundaries, >>>>>> and an interpreter VM compiled for the 64-bit object format can handle >>>>>> images greater than 7GB (probably much more, but my 8GB PC is too small >>>>>> to do anything larger). >>>>>> >>>>>> I'm not sure if all of the necessary fixes are in place for the StackVM >>>>>> and Cog. If not, I'm sure it will be addressed over time (it's just not >>>>>> something that I have ever checked). >>>>>> >>>>>> I believe that Jannik is interested in running very large images, at >>>>>> least on an experimental basis. For anything over a few GB, this requires >>>>>> an interpreter VM and a 64-bit image. As you know, this is sure to run >>>>>> into problems for the garbage collector as the number of objects >>>>>> increases, but it would certainly be interesting to see how far the >>>>>> current garbage collector can go in real world conditions before it >>>>>> turns to mollasses. >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> On Wed, Aug 01, 2012 at 08:57:02AM -0400, John McIntosh wrote: >>>>>>> A few years back the interpreted virtual machine was fixed to allow an >>>>>>> image to grow to the 4 GB limit. >>>>>>> It is unclear to me if someone regressed the software to impose a 2GB limit >>>>>>> again, or if the 2GB number >>>>>>> mentioned is based on how things worked10 years ago? >>>>>>> >>>>>>> On Wed, Aug 1, 2012 at 5:01 AM, St?phane Ducasse >>>>>>> <stephane.ducasse(a)inria.fr>wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jul 31, 2012, at 11:46 PM, johnmci wrote: >>>>>>>> >>>>>>>>> David Lewis and I spent a far amount of time a few years back to make >>>>>>>> the 32 >>>>>>>>> vm 4gb clean. So are you running on stale knowledge here, or does the vm >>>>>>>>> crash when to goes over 2gb? >>>>>>>> >>>>>>>> sorry my english limit does not let me know understanding what you mean >>>>>>>> exactly. >>>>>>>> Jannik in the context of moose would like to see if we can have image >>>>>>>> larger than 500 mb (on mac it should be possible). >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>> >>>>> >>>>> --- >>>>> Jannik Laval >>>>> >>>>> >>>> >>>> >>> >>> --- >>> Jannik Laval >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Aug. 3, 2012

Re: [Pharo-project] Completion

by Camillo Bruni

yep we just figured that out... so now we will only have one list which displays all the matches. the first 6 are by priority, the rest sorted alphabetically. this will hopefully be much more productive On 2012-08-03, at 21:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > When using OCompletion, if you scroll to the bottom of the list (with keydown), you should get the ECompletion list. > > Cheers, > Doru > > > On 3 Aug 2012, at 18:42, Esteban Lorenzano wrote: > >> please go :) >> >> NEController and NOController would be the place >> >> On Aug 3, 2012, at 6:21 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I don't particularly like the current completion mechanism in pharo: >>> >>> - the OCompletion (or what it is called) only displays a limited number of selectors >>> - the second completion (which is complete!) using CMD-Q is in many cases more helpful >>> >>> >>> Could we combine these two? Simply concatenate the two lists and we're done! >>> Where is the place to look for that? >>> >>> best >>> cami >> >> > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > >

Aug. 3, 2012

Re: [Pharo-project] Completion

by Tudor Girba

When using OCompletion, if you scroll to the bottom of the list (with keydown), you should get the ECompletion list. Cheers, Doru On 3 Aug 2012, at 18:42, Esteban Lorenzano wrote: > please go :) > > NEController and NOController would be the place > > On Aug 3, 2012, at 6:21 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I don't particularly like the current completion mechanism in pharo: >> >> - the OCompletion (or what it is called) only displays a limited number of selectors >> - the second completion (which is complete!) using CMD-Q is in many cases more helpful >> >> >> Could we combine these two? Simply concatenate the two lists and we're done! >> Where is the place to look for that? >> >> best >> cami > > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Aug. 3, 2012