- Pharo-dev - lists.pharo.org

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

Versioner

by Diego Lont

I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started. I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded. Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind. The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know. 1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows: A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards. B. For the âcross-platformâ projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a âreleasedâ version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues. C. For the âmooseâ projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes. I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale): When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported. 2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this? 3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too? And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ... 4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem. Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways. 5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures. Regards, Diego

June 30, 2014

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

by Nicolai Hess

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

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

by Nicolai Hess

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

Re: [Pharo-dev] TaskIT Revealed

by Santiago Bragagnolo

yeah, the name of the extension for executing in a second image is forkit. instead of [ 2+2 ] shootIt, do [ 2+2 ]forkIt, The difference in between both is the runner. Meanwhile shootIt is like this: shootIt ^ TKTOneShotRunner new run: self forkIt is forkIt ^ FKTOneShotAtThirdInstanceRunner new run: self We are changing this for the next version, but it will be similar, but more dynamic (we will take more advantage of our reification of process) 2014-06-30 0:05 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Impressive! > > Can I specify the semantic behind #shootIt ? I mean, now you are spawning > processes right? Can I instead open a new image to have the work done? > > Alexandre > > On Jun 22, 2014, at 6:39 PM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > > > > > Hi all, im glad to announce TaskIT. You may already knew about, after > all it's not confidential ;) and it has documentation on-going since some > months ago. > > > > Task IT is package that provides a cool way to deal with processes. Even > when this version is stable, it still in design and we want to make it > consistent and powerfull. > > > > It counts with a chapter in pharo enterprise book and some cool tests. > > > > We have moved the main distribution repo to CAR > > > > http://smalltalkhub.com/#!/~CAR/TaskIT/ > > > > > > The main easy things to do with this revision are: > > > > " closures " > > val := [ 2+2 ] shootIt. > > val isKindOf: TKTFuture. > > val onSuccess: [: rslt | rslt == 4 ] "async" > > val value == 4. " sync " > > > > rslt := [ 2+2 ] shootIt asResult. > > rslt == 4 "sync on demand" > > > > " objects " > > > > val := 2 paralellize + 2. > > val == 4 "sync on demand" > > > > > > " staying in tune " > > > > val := [ "some task" ] shootIt asStickyReference. > > > > val := nil. > > " sticky means that if this future is taken by the GC, it will kill the > process" > > > > > > > > " looping " > > > > > > val := server paralellize looping serveOnce: anyParameter > asStickyReference. > > > > "this will execute in a new process, in a loop, server serveOnce: > anyParameter." > > > > You can stop it by doing > > val:= nil. > > > > "or using a disgusting magic variable, for that check the samples :). > But do not rely on that kind of things, because it will not be supported " > > > > > > > > For more advanced and cool usages, check the Doc. > > > > > > FAQ: > > > > 1- Yes, the "sync" on demand is implemented with a proxy and a become. > > 2- Yes, we are changing the API of the processes that persist in time. > > > > CREDITS > > All CAR team in general was great inspiration, particularly, Guille > Polito full operational commiter and of course is always a good idea to > discuss with him, Nick Papoylias, is also great to discuss with him. Luc, > Noury, Jannik: several ideas are discussed with them as well, and they > always gave me support. > > > > and from RMOD Esteban Lorenzano, also discussing and proposing. > > > > Thanks all :). > > > > > > OTHERS: > > If you want to go to the darkside (dark because is not documented yet, > but in the case of PoolIT, that it has some doc ) you can also add to your > combo: > > ActIT: a simple Actor extention for taskit. > > ForkIT: an extention that runs blocks in background image (it adds a > nice button to the test runner, letting you run all your tests in a > background image and installing the results after the execution) > > PoolIT: it adds a pool of workers, it consumes tasks and ensure you a > limited amount of threads. > > PlanIT: a basic and not yet full developed algebra for composing > processes. > > > > > > > > I encourage you to use it, it is being used in PhaROS since a lot of > time. And please any bug and enhancements, you can contact us. Since we are > working on the next version is a good time to define what features are > really needed. > > > > > > Salut. > > > > > > Santiago. . > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Alexandre Bergel

Hi Sean! I guess you can use the very same technique to store pictures in the image. Mime64 is your friend :-) I can look for code snippets if you needâ¦ Let me know Cheers, Alexandre On Jun 28, 2014, at 11:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > How do we do this now with MC? Are there options other than "encode in string > returned by method" like I've seen done for image data? > > My use case is that I have a very static domain, and so doesn't require user > changes. I think the easiest way to distribute it would be to edit the data > on a dev image, and then somehow save the data in a way that can be > committed with MC so that loading via MetaC config loads the latest version > of the data. What would be the best way to do that? > > Thanks. > > p.s. on a related note, I'm also interested in distributing static files > with the code e.g. maybe a PDF readme > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Sean P. DeNigris

HernÃ¡n Morales Durand wrote > I've used Dropbox to > download resource files to a directory. Thanks I'll check it out ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765646.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Sean P. DeNigris

Guillermo Polito wrote > With Martin we started on friday to sketch a kind of resource manager Sounds exciting. Can't wait to play with it! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765645.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2014