Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows
2014-06-29 16:34 GMT+02:00 Denis Kudriashov dionisi...@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 nicolaih...@web.de: 2014-06-25 8:58 GMT+02:00 Guillermo Polito guillermopol...@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 s...@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 tu...@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
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@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
Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows
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 nicolaih...@web.de wrote: 2014-06-29 16:34 GMT+02:00 Denis Kudriashov dionisi...@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 nicolaih...@web.de: 2014-06-25 8:58 GMT+02:00 Guillermo Polito guillermopol...@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 s...@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 tu...@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
[Pharo-dev] [New] academic partner program
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%20Partner.pdf 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@lists.pharo.org and/or pharo-us...@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.
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
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 nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@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
Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead
yeah, works for me too On 29 Jun 2014, at 11:10, Tudor Girba tu...@tudorgirba.com wrote: Works for me. Doru On Sun, Jun 29, 2014 at 10:49 AM, p...@highoctane.be p...@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
Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead
On 30 Jun 2014, at 10:25, Esteban Lorenzano esteba...@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 tu...@tudorgirba.com wrote: Works for me. Doru On Sun, Jun 29, 2014 at 10:49 AM, p...@highoctane.be p...@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
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
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 nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@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
[Pharo-dev] Supporting deep into pharo
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 -- _,.;:~^~:;._,.;:~^~:;._,.
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
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
Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead
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 esteba...@gmail.com wrote: On 30 Jun 2014, at 10:25, Esteban Lorenzano esteba...@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 tu...@tudorgirba.com wrote: Works for me. Doru On Sun, Jun 29, 2014 at 10:49 AM, p...@highoctane.be p...@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
Re: [Pharo-dev] Supporting deep into pharo
Done --- Philippe Back On Mon, Jun 30, 2014 at 10:39 AM, stepharo steph...@free.fr wrote: 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 -- _,.;:~^~:;._,.;:~^~:;._,.
Re: [Pharo-dev] Pharo and Amber relationship
How hard would it be to get both stacks in http://yeoman.io/ ? Amber seems doable. Pharo+Seaside or Tide, I do not know Phil On Mon, Jun 30, 2014 at 11:21 AM, Norbert Hartl norb...@hartl.name wrote: Am 29.06.2014 um 20:52 schrieb Stephan Eggermont step...@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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40054 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 706bfe: 40054
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 706bfe3124647c874c0a9d3657a17eff50cc0075 https://github.com/pharo-project/pharo-core/commit/706bfe3124647c874c0a9d3657a17eff50cc0075 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: R Nautilus.package/Nautilus.class/class/browser compatibility/openBrowser.st R Nautilus.package/Nautilus.class/class/browser compatibility/openBrowserView_label_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script54.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40054.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/Browser.class/class/instance creation/open.st R Tools.package/Browser.class/class/instance creation/openBrowser.st R Tools.package/ChangeList.class/class/instance creation/openAsMorph_name_multiSelect_.st M Tools.package/ChangeList.class/class/instance creation/open_name_multiSelect_.st M Tools.package/ChangeList.class/definition.st R Tools.package/ChangeList.class/instance/accessing/showsVersions.st R Tools.package/ChangeList.class/instance/filter streaming/selectAllConflicts.st M Tools.package/ChangeList.class/instance/initialization-release/openAsMorphName_multiSelect_.st M Tools.package/ChangeList.class/instance/initialization-release/optionalButtonRow.st R Tools.package/ChangeList.class/instance/initialization-release/wantsPrettyDiffOption.st A Tools.package/ChangeList.class/instance/menu actions/selectAllConflicts.st M Tools.package/ChangeList.class/instance/viewing access/contents.st M Tools.package/ChangeList.class/instance/viewing access/contents_.st R Tools.package/ChangeList.class/instance/viewing access/diffedVersionContents.st R Tools.package/ChangeList.class/instance/viewing access/restoreDeletedMethod.st Log Message: --- 40054 13436 delete empty packages Tabs and NewList https://pharo.fogbugz.com/f/cases/13436 13434 No need for #openBrowser https://pharo.fogbugz.com/f/cases/13434 13435 Clean ChangeList https://pharo.fogbugz.com/f/cases/13435 http://files.pharo.org/image/40/40054.zip
Re: [Pharo-dev] [ANN]: Little NeoJSON Helper
Hi Sean, This has been on my list for quite some time, sorry about that - the problem was also that I do/did not really have a good opinion about this, see further. On one hand, I am really happy that you produced this hack (in the good definition of the word: a neat trick to solve a problem). I am impressed by it, you mix what is available in NeoJSON with the dynamic abilities in Pharo to do something cool (much like coding in the debugger, or using available input to dynamically derive a mapping). You clearly got deep into it (carried away you said yourself) and you do understand NeoJSON very well. But on the other hand, it took me quite some time, browsing your code intensively, reading your mail again and again, to even understand what you did, how it (could) work(s), the goals, the limitations - and I wrote NeoJSON. So the problem is, IMHO, that we cannot expect this to be explainable/understandable to others. This could maybe be fixed by writing more code, maybe some kind of GUI tool, more documentation - but then the question is, is it worth it ? does this really solve a common problem ? It feels like an extension/add-on to me, not something to be part of the core of NeoJSON. I just don't know, what do you think about it in retrospect ? Sven On 01 May 2014, at 20:26, Sven Van Caekenberghe s...@stfx.eu wrote: It is on my list ... On 01 May 2014, at 20:03, Sean P. DeNigris s...@clipperadams.com wrote: I'd like for Sven to take a look and see if it's generally useful and well-designed, but sure... - Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763p4757481.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
Ok, I have the test case showing the problem. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] Fail on the final assert. Switching to single selection hold the same error. Interestingly, reselecting cleans the selectedMorphList. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t setSelectedMorph: t allNodeMorphs first. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] This one has no error. Changing the way Nautilus maintain the selection would work. Forcing selectedMorphList to be cleaned up on addition / removal in the list would be nice too (but possible update code can delete the node morphs by itself). 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. 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 nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@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
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
How about this change, if it rebuilds the whole list, we can savely remove the selection, or not? MorphTreeMorph addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList | morphList | morphList := OrderedCollection new. self addMorphsTo: morphList from: aNodeList withExpandedItems: expandedNodeList atLevel: 0. self insertNewMorphs: morphList. self listManager emptySelection.--- added self listManager updateSelectionFromModel. self roots do: [:r | r updateChildrenRecursively]. self updateColumnMorphs 2014-06-30 15:35 GMT+02:00 Goubier Thierry thierry.goub...@cea.fr: Ok, I have the test case showing the problem. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] Fail on the final assert. Switching to single selection hold the same error. Interestingly, reselecting cleans the selectedMorphList. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t setSelectedMorph: t allNodeMorphs first. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] This one has no error. Changing the way Nautilus maintain the selection would work. Forcing selectedMorphList to be cleaned up on addition / removal in the list would be nice too (but possible update code can delete the node morphs by itself). 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. 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 nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@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
Re: [Pharo-dev] Versioner
I just don't see it the way you do. For me Versioner is a tool to make life a bit easier with Configurations, its not the one ring to rule them all , far from it. What stops anyone from implementing his own configuration tool ? On Mon, Jun 30, 2014 at 10:23 AM, Diego Lont diego.l...@delware.nl wrote: 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
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
It would solve the selection kept while updating the full list, but it won't solve partial updates. You would also be apparently deselecting and reselecting when appending elements to the list. Thierry Le 30/06/2014 16:15, Nicolai Hess a écrit : How about this change, if it rebuilds the whole list, we can savely remove the selection, or not? MorphTreeMorph addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList | morphList | morphList := OrderedCollection new. self addMorphsTo: morphList from: aNodeList withExpandedItems: expandedNodeList atLevel: 0. self insertNewMorphs: morphList. self listManager emptySelection.--- added self listManager updateSelectionFromModel. self roots do: [:r | r updateChildrenRecursively]. self updateColumnMorphs 2014-06-30 15:35 GMT+02:00 Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr: Ok, I have the test case showing the problem. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] Fail on the final assert. Switching to single selection hold the same error. Interestingly, reselecting cleans the selectedMorphList. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t setSelectedMorph: t allNodeMorphs first. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] This one has no error. Changing the way Nautilus maintain the selection would work. Forcing selectedMorphList to be cleaned up on addition / removal in the list would be nice too (but possible update code can delete the node morphs by itself). 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. 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@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
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
I'm trying to see if I could do it in a cleaner way, and I found it! On partial updates, AltBrowser is able to cleanly delete the node morphs because it sends #noteRemovalOfAll: aCollection to MorphTreeMorph, which has the selection testing and removal code. Which means changing MorphTreeMorphupdateContentsWithPreviouslyExpanded: aNodeList nodeList := nil. self noteRemovalOfAll: self allNodeMorphs. -- Changed (self nodeList isNil or: [ self nodeList isEmpty ]) ifTrue: [ nodeList := nil. ^ self emptySelection ]. self addSubmorphsFromNodeList: self currentNodelist previouslyExpanded: aNodeList It solves the problem. However, I don't like this that much overall, because delete is never sent to the node morphs themselves, and this seems very wrong to me. Thierry Le 30/06/2014 16:56, Goubier Thierry a écrit : It would solve the selection kept while updating the full list, but it won't solve partial updates. You would also be apparently deselecting and reselecting when appending elements to the list. Thierry Le 30/06/2014 16:15, Nicolai Hess a écrit : How about this change, if it rebuilds the whole list, we can savely remove the selection, or not? MorphTreeMorph addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList | morphList | morphList := OrderedCollection new. self addMorphsTo: morphList from: aNodeList withExpandedItems: expandedNodeList atLevel: 0. self insertNewMorphs: morphList. self listManager emptySelection.--- added self listManager updateSelectionFromModel. self roots do: [:r | r updateChildrenRecursively]. self updateColumnMorphs 2014-06-30 15:35 GMT+02:00 Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr: Ok, I have the test case showing the problem. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] Fail on the final assert. Switching to single selection hold the same error. Interestingly, reselecting cleans the selectedMorphList. | c w t | c := ClassTreeExample new. w := c openOn: Collection. t := c dependents last. t expandAll. t selectAll. c updateList. t setSelectedMorph: t allNodeMorphs first. t listManager selectedMorphList do: [ :each | self assert: ( t allNodeMorphs includes: each ) ] This one has no error. Changing the way Nautilus maintain the selection would work. Forcing selectedMorphList to be cleaned up on addition / removal in the list would be nice too (but possible update code can delete the node morphs by itself). 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. 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-06-29 22:31 GMT+02:00 Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be: On 27 Jun 2014, at 14:00, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@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
Re: [Pharo-dev] Versioner
Kilon wrote: I just don't see it the way you do. That's fine, you work in a different context than we do. What do you disagree on? You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation. For me Versioner is a tool to make life a bit easier with Configurations, its not the one ring to rule them all , far from it. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations. What stops anyone from implementing his own configuration tool ? Common sense, I hope... Stephan
Re: [Pharo-dev] Versioner
On Mon, Jun 30, 2014 at 8:49 AM, Stephan Eggermont step...@stack.nl wrote: Kilon wrote: I just don't see it the way you do. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations. What stops anyone from implementing his own configuration tool ? Common sense, I hope... Kilon has a point and so does Stephan ... In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) it is much easier to construct custom tools to support variations in workflow ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... Dale
[Pharo-dev] [pharo-project/pharo-core] 091e69: 40055
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 091e69a4d07cb65c1b95d0972dc08116dd22d64e https://github.com/pharo-project/pharo-core/commit/091e69a4d07cb65c1b95d0972dc08116dd22d64e Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script55.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40055.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/instance/testing/isSpecial.st A Slot.package/Slot.class/instance/testing/isSpecial.st R Slot.package/SlotClassBuilder.class/instance/deprecated/client_.st M Slot.package/SlotClassBuilder.class/instance/private/apply_.st R System-ObjectStorage.package/extension/SmalltalkImage/instance/storeDataOn_.st M Tool-Profilers.package/MessageTally.class/instance/collecting leaves/leavesInto_fromSender_.st M Tool-Profilers.package/MessageTally.class/instance/comparing/sonsOver_.st M Tool-Profilers.package/MessageTally.class/instance/printing/printOn_.st M Tool-Profilers.package/QSystemTally.class/instance/testing/isPrimitives.st A Tool-Profilers.package/SpaceTally.class/class/fileout/printSpaceAnalysis.st M Tool-Profilers.package/SpaceTally.class/instance/fileout/printSpaceAnalysis.st M Tool-Profilers.package/TimeProfiler.class/instance/accessing-computed/leaveItems.st A Traits.package/TClassDescription.class/instance/slots/usesSpecialSlot.st Log Message: --- 40055 13441 Small code critique cleanup in Tools https://pharo.fogbugz.com/f/cases/13441 13442 add test to classes for checking non-ivar slots are used https://pharo.fogbugz.com/f/cases/13442 13443 remove #storeDataOn: from SmalltalkImage https://pharo.fogbugz.com/f/cases/13443 http://files.pharo.org/image/40/40055.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40055 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Versioner
Stephan--- That's fine, you work in a different context than we do. What do you disagree on? I disagreed with this Stephan 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. this what I was replying to. You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation. I have read through it yes, I did not argue that Versioner is perfect. I am actually arguing the opposite, that is a rather basic tool, it gets some basic tasks done but obviously its not the one ring to rule them all meaning its up to pharo developers to contribute and improve it or create additional tools to assist with tasks that Versioner can't handle. I disagree that it has an agenda to enforce a single workflow. It is what it is and it can be improved. Common sense, I hope... So basically what you saying is that being in a environment ( Pharo ) which is making it easier to create your own IDE tools is not common sense to create your own IDE tools ? You want to join efforts that fine , you want to do it your own way thats fine too, the end result is tools that solve problems. Obviously joining effort is the preferable choice, but doing your own thing is a recipe that Pharo has been based on. I think its great to have these discussion so people are aware of problems before they face them in real life. I definitely would love to read about these problems and plan ahead my actions. If its a problem for Moose people there is no reason to believe it won't be a problem for others in the near future. --Dale- Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer. I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too.
Re: [Pharo-dev] Versioner
On Mon, Jun 30, 2014 at 10:01 AM, kilon alios kilon.al...@gmail.com wrote: --Dale- Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer. I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too. Cool! I really think it is worthwhile exploring the territory below the GUI or with minimal GUI ... there is no question that a good GUI tool is very useful, but there is a place for the stripped down minimal effort tools as well ... Dale
[Pharo-dev] Amber frontend with Pharo backend
Hi guys, cross-posting to Amber group… I’ve recently published the code of http://tasks.flowingconcept.com Here: http://github.com/sebastianconcept/tasks Have fun sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
Re: [Pharo-dev] Versioner
2014-06-30 13:15 GMT-03:00 Dale Henrichs dale.henri...@gemtalksystems.com: Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI. According to the Unix Philosophy (http://en.wikipedia.org/wiki/Unix_philosophy) Smalltalk, and Pharo, are compliant with the Rule of Modularity whitin the image, but not with the Rule of composition as seen from external programs. Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression. This is also food for thought. In case anybody is still hungry. :) Regards!
Re: [Pharo-dev] Versioner
Kilon wrote: I disagreed with this Stephan 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. this what I was replying to. Ok. The concrete problem we ran into with the current version of Versioner is that it wants to resolve dependencies to exact versions. For configurations depending on Seaside, Magritte or Grease, this is normally unwanted. They should depend on the symbolic release versions. With the high number of changes in Pharo, exact versions have a short lifetime. Dale wrote: In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) it is much easier to construct custom tools to support variations in workflow ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... In order to work together effectively in open source projects it is important that contributors know what workflow is used in a project. That is easier when the number of different workflows is limited. Because projects depend on other projects the number of combinations of workflow is very large. Scriptable tools can easily support these resulting combinations. Building a GUI tool that is both very flexible and very easy to use seems to be less easy. Stephan
Re: [Pharo-dev] Versioner
Esteban, Just to be clear, I believe that there should be Smalltalk scripting/cli from within the image (augment workspace usage) as well as from without ... more food (for lunch) thought:) Dale On Mon, Jun 30, 2014 at 11:36 AM, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-06-30 13:15 GMT-03:00 Dale Henrichs dale.henri...@gemtalksystems.com : Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI. According to the Unix Philosophy ( http://en.wikipedia.org/wiki/Unix_philosophy) Smalltalk, and Pharo, are compliant with the Rule of Modularity whitin the image, but not with the Rule of composition as seen from external programs. Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression. This is also food for thought. In case anybody is still hungry. :) Regards!
Re: [Pharo-dev] Athens and StrikeFont ( again )
The real question was: Why can't we draw a text with StrikeFont and with Athens. Igor, can't we use AthensCairoText (cairo toy text api) for non-truetype fonts? 2014-06-21 1:20 GMT+02:00 Hilaire Fernandes hilaire.fernan...@gmail.com: Gi Igor, For DrGeo it is not a workable option to have different fonts in Morphic widget and Athens canvas (I explained earlier why). However I found the scaling trick of draw text to work reasonably well. Not full perfect as from time to time I can see some artifact. Thanks Hilaire Le 20/06/2014 15:32, Igor Stasenko a écrit : Sure, you can do: make sure you don't render text with same font in Morphic UI and Athens, so they don't interfere with each other. There's no easy way to get rid of interference, because it would require changing Freetype package and its plugin in order to establish a single font management point and funnel all requests to freetype library through it. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa
[Pharo-dev] functions keys
After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
[Pharo-dev] numeric pad
i actualized the vm for linux , but numeric pad of keyboard does not work. The keys are captured (exists KeboardEvent ) but the keys are not displaying in workspace for example. TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
Re: [Pharo-dev] functions keys
To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli pdigonze...@gmail.com wrote: After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA -- *Ing. Pablo Digonzelli* Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
Re: [Pharo-dev] [Pharo-users] functions keys
Yes, no function keys. 2014-07-01 0:06 GMT+02:00 Pablo R. Digonzelli pdigonze...@gmail.com: After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA -- *Ing. Pablo Digonzelli* Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
Re: [Pharo-dev] functions keys
Guille , functions key does not generate event at all. I think it is a problem for some applications. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714 - Mensaje original - De: Guillermo Polito guillermopol...@gmail.com Para: Pharo Development List pharo-dev@lists.pharo.org CC: Any question about pharo is welcome pharo-us...@lists.pharo.org Enviados: Lunes, 30 de Junio 2014 19:26:23 Asunto: Re: [Pharo-dev] functions keys To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli pdigonze...@gmail.com wrote: After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
Re: [Pharo-dev] functions keys
It will be solved for Pharo 4, with the OSWindow integration. 2014-06-30 19:55 GMT-04:00 Pablo R. Digonzelli pdigonze...@gmail.com: Guille , functions key does not generate event at all. I think it is a problem for some applications. -- *Ing. Pablo Digonzelli* Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714 -- *De: *Guillermo Polito guillermopol...@gmail.com *Para: *Pharo Development List pharo-dev@lists.pharo.org *CC: *Any question about pharo is welcome pharo-us...@lists.pharo.org *Enviados: *Lunes, 30 de Junio 2014 19:26:23 *Asunto: *Re: [Pharo-dev] functions keys To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli pdigonze...@gmail.com wrote: After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA -- *Ing. Pablo Digonzelli* Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
[Pharo-dev] numeric pad
Hi all , i need numeric pad working for a linux application. I probe last pharo and last squeak vm and images and does not work . I need to solve it in order to continue developing a business app . Can anybody help me? Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714
Re: [Pharo-dev] functions keys
Nice!! Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714 - Mensaje original - De: Ronie Salgado ronies...@gmail.com Para: Pharo Development List pharo-dev@lists.pharo.org Enviados: Lunes, 30 de Junio 2014 21:01:09 Asunto: Re: [Pharo-dev] functions keys It will be solved for Pharo 4, with the OSWindow integration. 2014-06-30 19:55 GMT-04:00 Pablo R. Digonzelli pdigonze...@gmail.com : Guille , functions key does not generate event at all. I think it is a problem for some applications. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714 De: Guillermo Polito guillermopol...@gmail.com Para: Pharo Development List pharo-dev@lists.pharo.org CC: Any question about pharo is welcome pharo-us...@lists.pharo.org Enviados: Lunes, 30 de Junio 2014 19:26:23 Asunto: Re: [Pharo-dev] functions keys To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli pdigonze...@gmail.com wrote: blockquote After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonze...@softsargentina.com pdigonze...@gmail.com Cel: 5493815982714 /blockquote
Re: [Pharo-dev] Athens and StrikeFont ( again )
On 30 June 2014 21:36, Nicolai Hess nicolaih...@web.de wrote: The real question was: Why can't we draw a text with StrikeFont and with Athens. Igor, can't we use AthensCairoText (cairo toy text api) for non-truetype fonts? Because strike fonts are stored in special format which you cannot render directly by cairo library. Because strike fonts are not scalable. Because it will be horribly slow. Choose one. 2014-06-21 1:20 GMT+02:00 Hilaire Fernandes hilaire.fernan...@gmail.com: Gi Igor, For DrGeo it is not a workable option to have different fonts in Morphic widget and Athens canvas (I explained earlier why). However I found the scaling trick of draw text to work reasonably well. Not full perfect as from time to time I can see some artifact. Thanks Hilaire Le 20/06/2014 15:32, Igor Stasenko a écrit : Sure, you can do: make sure you don't render text with same font in Morphic UI and Athens, so they don't interfere with each other. There's no easy way to get rid of interference, because it would require changing Freetype package and its plugin in order to establish a single font management point and funnel all requests to freetype library through it. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ANN]: Little NeoJSON Helper
Sven Van Caekenberghe-2 wrote I just don't know, what do you think about it in retrospect ? Thanks for taking a look! I don't know either :) - Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763p4765873.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
