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

Re: [Pharo-dev] Pharo and Amber relationship

by Norbert Hartl

Am 29.06.2014 um 20:52 schrieb Stephan Eggermont <stephan(a)stack.nl>: > Sean wrote: >> Have you checked it out lately? The current procedure seems very streamlined... >> >> # Install the CLI tools (only needs to be done once per computer) >> sudo npm install -g amber-cli > > Are you serious? That is like saying you can install Pharo by double-clicking a Pharo image. > That misses a few steps. And there are several ways to install prerequisites, some of which don't work at all, others cannot be upgraded. > To be fair we should see that pharo can be installed easier but cannot used as a web project that way. It needs extra steps for deployment which aren't too easy. In the amber case installing and deployment is basically the same thing. Norbert

June 30, 2014

Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by phil＠highoctane.be

After half an hour it worked again. Other sites were reachable from my machine, so nothing to do with the connectivity. Regards, Phil On Mon, Jun 30, 2014 at 10:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 30 Jun 2014, at 10:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yeah, works for me too > > (in an old xp) > > can we know a bit more about your conditions, to see if we can fix it? > > Esteban > > > On 29 Jun 2014, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Works for me. > > Doru > > > On Sun, Jun 29, 2014 at 10:49 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Not downloading.... >> >> Annoying, I wanted to demo Pharo to someone from scratch :-( >> >> Phil >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > >

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Le 30/06/2014 09:09, Nicolai Hess a Ã©crit : > Yes, we had quite some bugs with this package tree update in the past. > What I don't understand is, why > is the whole tree removed and rebuild, maybe this is a common strategy > in Morphic, update a list ore tree > will always rebuild the whole morph structure? But it happens even if > the structure is the same and > just this little package/dirty package icon is updated. I let you as an exercise write the necessary code to do a partial update of the displayed tree :) Don't forget to remember which nodes were expanded and which were not. > Another issue is this "selected package/package selection". The tree > (and for example the > category list and/or method list" as well), stores the selection on > multiple ways, in the model (PackageTreeNautilus), the > UI (PackageTreeNautilusUi) and the treelist morph. Once as a > SelectedTreeNode, a Package from Nautilus Model and > once as a PackgeTreeSelection/PackageTreeTagSelection. > I find it pretty confusing. This is the Nautilus approach. You don't have to do it that way. > BTW, I still can not reproduce this memory leak behavior. I tried this: > > [ Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. > > with and without an open SystemBrowser. But the load time and > memory consumption is the same. Select a package in Nautilus first. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 30, 2014

Supporting deep into pharo

by stepharo

Hi! Maybe one of Deep into Pharoâs reader can write a review on: http://www.amazon.com/Deep-into-Pharo-Alexandre-Bergel/dp/3952334162 This will help everybody by promoting our favorite language... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Le 30/06/2014 10:15, Johan Brichau a Ã©crit : > Hi Nicolai, > > Do you have a method selected in the browser? > As the memory leak happens via the selectedMorphs instvar, it requires a package to be selected (and maybe even a method). > > Before and after the load. I do this and notice the increase. My test sequence: open PackageTreeNautilus, select a package. Then the following script with the values: PackageTreePackageNodeModel allInstances size. 313. (ConfigurationOfSmaCC project version: #stable) load. Smalltalk garbageCollect. PackageTreePackageNodeModel allInstances size. 14215 I don't track MorphTreeNodeMorph because AltBrowser uses them as well. SmaCC is around 10 packages. Thierry > Smalltalk garbageCollect. > MorphTreeNodeMorph allInstances size. > > It really only becomes problematic (i.e. out-of-mem) when you load large projects. Maybe MOOSE will qualify? > > Yes, I was astonished as well when I noticed that every update was rebuilding the entire set of Morphs. It's the easiest solution of course but it does impose a lot of overhead. > First, I will see how to solve that leaking problem. Then I will take a look at the update itself. > > I can only spend some of my free time on this, so I will continue tonight. > > best, > Johan > > On 30 Jun 2014, at 09:09, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: >> >> On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> It seems to depend on the Nautilus window state. If you've just opened it, then nothing seems to be amiss. If you start to select things in it, you start to see time spent in updateClassView, but why? >> >> I just found that the instances are being kept by the MorphTreeListManager#selectedMorphs instvar. So, that observation is correct: you need to have a package selected. >> >> What seems to happen is that on every package load, the Nautilus package tree is updated (which means a PackageTreePackageNodeModel is created for each package in the image via #asNautilusNodeWithModel:). >> This update does not clear the selectedMorphs list and just this single reference seem to keep the entire package tree model and its Morphs in memory. >> >> There were 496 morphs in the selectedMorphs list and when I cleaned that, all trailing Morphs and PackageNodeModelNodes (and all the other garbage) could be gc'ed. >> >> On to investigating the growth of the selectedMorphs variable... >> >> Johan >> >> >> Yes, we had quite some bugs with this package tree update in the past. What I don't understand is, why >> is the whole tree removed and rebuild, maybe this is a common strategy in Morphic, update a list ore tree >> will always rebuild the whole morph structure? But it happens even if the structure is the same and >> just this little package/dirty package icon is updated. >> >> Another issue is this "selected package/package selection". The tree (and for example the >> category list and/or method list" as well), stores the selection on multiple ways, in the model (PackageTreeNautilus), the >> UI (PackageTreeNautilusUi) and the treelist morph. Once as a SelectedTreeNode, a Package from Nautilus Model and >> once as a PackgeTreeSelection/PackageTreeTagSelection. >> I find it pretty confusing. >> >> >> BTW, I still can not reproduce this memory leak behavior. I tried this: >> >> [ Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. >> >> with and without an open SystemBrowser. But the load time and >> memory consumption is the same. >> >> >> Nicolai >> >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 30, 2014

Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by Esteban Lorenzano

On 30 Jun 2014, at 10:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah, works for me too (in an old xp) can we know a bit more about your conditions, to see if we can fix it? Esteban > > On 29 Jun 2014, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Works for me. >> >> Doru >> >> >> On Sun, Jun 29, 2014 at 10:49 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> Not downloading.... >> >> Annoying, I wanted to demo Pharo to someone from scratch :-( >> >> Phil >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

June 30, 2014

Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by Esteban Lorenzano

yeah, works for me too On 29 Jun 2014, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Works for me. > > Doru > > > On Sun, Jun 29, 2014 at 10:49 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Not downloading.... > > Annoying, I wanted to demo Pharo to someone from scratch :-( > > Phil > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Johan Brichau

Hi Nicolai, Do you have a method selected in the browser? As the memory leak happens via the selectedMorphs instvar, it requires a package to be selected (and maybe even a method). Before and after the load. I do this and notice the increase. Smalltalk garbageCollect. MorphTreeNodeMorph allInstances size. It really only becomes problematic (i.e. out-of-mem) when you load large projects. Maybe MOOSE will qualify? Yes, I was astonished as well when I noticed that every update was rebuilding the entire set of Morphs. It's the easiest solution of course but it does impose a lot of overhead. First, I will see how to solve that leaking problem. Then I will take a look at the update itself. I can only spend some of my free time on this, so I will continue tonight. best, Johan On 30 Jun 2014, at 09:09, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: > > On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > It seems to depend on the Nautilus window state. If you've just opened it, then nothing seems to be amiss. If you start to select things in it, you start to see time spent in updateClassView, but why? > > I just found that the instances are being kept by the MorphTreeListManager#selectedMorphs instvar. So, that observation is correct: you need to have a package selected. > > What seems to happen is that on every package load, the Nautilus package tree is updated (which means a PackageTreePackageNodeModel is created for each package in the image via #asNautilusNodeWithModel:). > This update does not clear the selectedMorphs list and just this single reference seem to keep the entire package tree model and its Morphs in memory. > > There were 496 morphs in the selectedMorphs list and when I cleaned that, all trailing Morphs and PackageNodeModelNodes (and all the other garbage) could be gc'ed. > > On to investigating the growth of the selectedMorphs variable... > > Johan > > > Yes, we had quite some bugs with this package tree update in the past. What I don't understand is, why > is the whole tree removed and rebuild, maybe this is a common strategy in Morphic, update a list ore tree > will always rebuild the whole morph structure? But it happens even if the structure is the same and > just this little package/dirty package icon is updated. > > Another issue is this "selected package/package selection". The tree (and for example the > category list and/or method list" as well), stores the selection on multiple ways, in the model (PackageTreeNautilus), the > UI (PackageTreeNautilusUi) and the treelist morph. Once as a SelectedTreeNode, a Package from Nautilus Model and > once as a PackgeTreeSelection/PackageTreeTagSelection. > I find it pretty confusing. > > > BTW, I still can not reproduce this memory leak behavior. I tried this: > > [ Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. > > with and without an open SystemBrowser. But the load time and > memory consumption is the same. > > > Nicolai > >

June 30, 2014

[New] academic partner program

by stepharo

Dear Friends The Pharo consortium http://consortium.pharo.org is launching a new program in direction to academic partners: teachers, Universities and research institutes. We realized that the advantages/duties to be an academic member were unclear. We really want to build a strong community. http://files.pharo.org/consortium/Membership%20Agreement%20for%20Academic%2… Here are the key facts extracted from the documentation. Here are the main advantages as an academic partner: - Direct access to Pharo core developers via an automatic subscription to a specific mailing list. - Access to Pharo documents and courses. - Its logo posted on the Pharo Website Academic pages. - The possibility to propose and participate in actions. Here are the main duties (which you are already doing) - Put a link to Pharo Consortium Website from its institutional website. - When using Pharo to teach, create web pages with document courses related to Pharo. - Provide Inria with an annual report of at most half a page of its actions to promote and sustain Pharo. As member of the Pharo Consortium, the Academic Partner shall make its best efforts to: - Give courses on Pharo or related topics to its students - Participate to the development of open source software libraries in Pharo - Participate to selected Pharo mailing lists : pharo-dev(a)lists.pharo.org and/or pharo-users(a)lists.pharo.org - Participate in the authoring of open-source books on Pharo and related topics. So we really hope that you will register and help us making Pharo grow and be a really cool and friendly ecosystem. The Pharo Board.

June 30, 2014

Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows

by Guillermo Polito

There is an end key in many keyboards, but some others do not have it. Can you (or better, How would you) have ctrl+end in keyboards that doesn't? Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + home, if you can just add a keybinding to ctrl + a? On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi >> >> hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to >> make ctrl+home and ctrl+end working. Like you I was very surprised by such >> keyboard events crappy state. >> >> > > So, having ctrl+end and ctrl+d working at the same time is not possible? > > > > > > > >> >> >> 2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> 2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> There is a problem in the whole keyboard events: they treat keys as >>>> characters and vice versa. And that's not always true: >>>> - the backspace key is a key, but currently the image interprets it as >>>> a character because we only use keypress events in general. >>>> - the shift key is a key, and since current image does not use keyup >>>> nor keydown, we cannot know if JUST a shift is pressed normally. >>>> >>>> >>>> On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> >>>>> I don't know anything about event handling, but I once had a look at >>>>> Character constants, and found this: >>>>> >>>>> Character class>>#home >>>>> ^ self value: 1 >>>>> >>>>> How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH >>>>> (Start of header), sometimes typed as CTRL-A. And there are other strange >>>>> constants like that there. >>>>> >>>>> On 25 Jun 2014, at 08:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> > Hi, >>>>> > >>>>> > I am on Windows, using Pharo 3.0, and I am trying to get the >>>>> keybindings to work in Rubric using Windows convention (so, Ctrl instead of >>>>> Cmd as a modifier), >>>>> > >>>>> > It worked reasonably well, but the problem is that somehow Ctrl+a is >>>>> mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect >>>>> the same behavior in the regular PluggableTextMorph. >>>>> > >>>>> > Does anyone have an idea of where the problem comes from? >>>>> > >>>>> > Doru >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > www.tudorgirba.com >>>>> > >>>>> > "Every thing has its own flow" >>>>> >>>>> >>>>> >>>> >>> >>> ctrl+a has the same strange behavior as ctrl+d >>> ctrl+a -> ctrl+home >>> ctrl+d -> ctrl+end >>> >>> look at KeyboardEvent>>#hasSpecialCTRLKeyValue >>> I am not exactly sure why it is handled that way. >>> Replace the method with >>> >>> hasSpecialCTRLKeyValue >>> ^ self controlKeyPressed and: [ keyValue <= 26 ] >>> >>> now, ctr+a and ctr+d working as expected. >>> But I don't know about the side-effects. >>> >>> >>> nicolai >>> >>> >> >

June 30, 2014