[Pharo-dev] Interactive Notebook
I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. 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] Interactive Notebook
Le 15/07/2014 14:05, Ben Coman a écrit : Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry I'd be very interested in that kind of feature. I'd imagine you have a number of separate text areas in one workspace that are evaluated in order of their origin. Yes, it seems to be the case in the example I was looking at. Sort of the recording of an interactive session with a terminal. Would be interesting to see if we can go back and edit. Only sad thing I see in the way it is presented: output is not part of the program. I recommend you take MathCAD for a test drive. http://www.ptc.com/product/mathcad/ I'll have a look, thanks! cheers, Ben -- 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] Interactive Notebook
Le 15/07/2014 15:19, Stefan Marr a écrit : Hi: On 15 Jul 2014, at 13:33, Goubier Thierry thierry.goub...@cea.fr wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I’m thinking of something like: http://ipython.org/notebook.html Just another example for R, based on knitr: http://ramnathv.github.io/rNotebook/ Thanks (and in R). 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] Interactive Notebook
I've never seen that in VW. But your feedback is interesting; maybe there is something to look at. I wonder if looking at some of the GTPlayground stuff with another angle could be interesting (i.e. page approach) or simply study what could be done if we could capture a task by embedding morphs inside the text. I feel like the notebook concept in itself is poor in that you have to interact with the program objects via the command line (i.e. the language console; be it R or Python, or Mathlab) and that is certainly inferior to the ability to select and run anywhere, inspect, explore, playground stuff. Le 15/07/2014 17:21, Nicolas Cellier a écrit : We had this kind of workbook 20 years ago in VW with mathematical formulae and graphics (plot) embedded. What we did was to avoid continous scrolling of the whole document, but rather have the plan of the document on the left pane of the notebook (just an indented tree like word navigation mode), and the text on the right pane for only the currently selected chapter (in a way, it's a lot like the source code browser). This way, no need to compose very large Text in Smalltalk (I also doubt our editors really scale). Then we could output a static view in PostScript or LaTeX. The greatest limitation IMO was not really the UI, but the principle of the Notebook itself: we soon needed to access the results of previous chunks of code, and we implemented this with an environment (understand some global variables). From software quality POV, working with such global vars is very disappointing and does not really scale either. The second limitation of the workbook is that, while it's very good for small projects (like maybe we can have in school), it's not the right tool for producing documents with a synthesis of the results, which remain the main added value of humans, so which was what we were asked for. However I'm still curious how far we can go with those notebooks, because the idea is seducing. Maybe it was our own usage which was bad... 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] Interactive Notebook
Demo of what? New GUI, new text editor? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de stepharo [steph...@free.fr] Envoyé : mardi 15 juillet 2014 20:00 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Thierry I can tell you that I got a demo made by gary chambers and this is impressive and all done in Pharo. In addition with the new text model, it will really change the situation. Stef On 15/7/14 13:33, Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry
Re: [Pharo-dev] Interactive Notebook
I'm not sure about the replacing everything at once. Good tools doing exactly what they are intended for are great; the ability to switch easily from one tool to another allows for very focused work, where you switch from one task to another, and reduce your cognitive overhead because you don't have to bother with them until you need them. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de kilon alios [kilon.al...@gmail.com] Envoyé : mardi 15 juillet 2014 20:25 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook I have tried to make something similar with Rubric example of Workspace. My dream is a Super Workspace to replace all IDE tools inside pharo, system browser, Monticello, inspector, debugger , versioner , etc inspired by emacs and of course ipython. I am still working on it from time to time, but its a low priority project for now. I am sure other people have similar goals so I am also interested in joining efforts. Also I am interested in visual coding so I am flirting with Phratch and wonder how Phratch would mix with my Super Workspace concept. There is certainly a lot of potential here. On Tue, Jul 15, 2014 at 9:11 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Demo of what? New GUI, new text editor? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de stepharo [steph...@free.frmailto:steph...@free.fr] Envoyé : mardi 15 juillet 2014 20:00 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Thierry I can tell you that I got a demo made by gary chambers and this is impressive and all done in Pharo. In addition with the new text model, it will really change the situation. Stef On 15/7/14 13:33, Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry
Re: [Pharo-dev] Interactive Notebook
No worries. What I wrote in VW 20 years ago is not available anymore either ;) But it could have been used to build a interactive notebook :( Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.n...@gmail.com] Envoyé : mardi 15 juillet 2014 22:10 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook 2014-07-15 17:34 GMT+02:00 Goubier Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr: I've never seen that in VW. But your feedback is interesting; maybe there is something to look at. No, sorry for misunderstanding, it was closed source developments in VW...
Re: [Pharo-dev] Interactive Notebook
Hi Doru, I'd be interested, yes, especially if there is a way to hook or build IDEs for other languages / DSLs. And the underlying abstraction which would allow one to understand and manipulate how the stacked environments are linked to each other. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Tudor Girba [tu...@tudorgirba.com] Envoyé : mardi 15 juillet 2014 22:20 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Hi, Indeed, this is where we want to go with the GTPlayground next :). The idea is to have multiple segments that can be previewed and that are stacked on one another. Modifying an upper segment leads to reevaluating the lower ones. @Thierry: would you like to join efforts? Cheers, Doru On Tue, Jul 15, 2014 at 2:15 PM, Goubier Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Le 15/07/2014 14:05, Ben Coman a écrit : Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry I'd be very interested in that kind of feature. I'd imagine you have a number of separate text areas in one workspace that are evaluated in order of their origin. Yes, it seems to be the case in the example I was looking at. Sort of the recording of an interactive session with a terminal. Would be interesting to see if we can go back and edit. Only sad thing I see in the way it is presented: output is not part of the program. I recommend you take MathCAD for a test drive. http://www.ptc.com/product/mathcad/ I'll have a look, thanks! cheers, Ben -- 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 92tel:%2B33%20%280%29%201%2069%2008%2032%2092 / 83 95 -- www.tudorgirba.comhttp://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Interactive Notebook
Then go for your enhanced workspace :) Making good tools in my experience takes a lot of time, refining details here and there, but it's really worth it because it changes the way you work. I can't relate too much to Emacs, I allways found it a too huge investment (shortcuts, configuration time) for the gain it could bring. Mind you, when I started programming heavily, it was in Smalltalk and Self, so maybe this is why ;) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de kilon alios [kilon.al...@gmail.com] Envoyé : mardi 15 juillet 2014 22:37 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Well at least for me , the one thing I don't like about Pharo is the window hell . Even with window groups , which by the way are a great addition , is easy to get lost and feel uncomfortable. As I said I am inspired by emacs , I like its workflow very much and it will be great if I manage to bring even a small part of the experience to pharo. My goal is not to make something monolithic from the code perspective but offer a unified user experience. I prefer my code as modular as it can be. Emacs after all is extremely modular. At worst I would end up with a slightly more powerful workspace and since workspace is my No1 tool I use to test and try code that is better than nothing :) On Tue, Jul 15, 2014 at 11:25 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: I'm not sure about the replacing everything at once. Good tools doing exactly what they are intended for are great; the ability to switch easily from one tool to another allows for very focused work, where you switch from one task to another, and reduce your cognitive overhead because you don't have to bother with them until you need them. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de kilon alios [kilon.al...@gmail.commailto:kilon.al...@gmail.com] Envoyé : mardi 15 juillet 2014 20:25 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook I have tried to make something similar with Rubric example of Workspace. My dream is a Super Workspace to replace all IDE tools inside pharo, system browser, Monticello, inspector, debugger , versioner , etc inspired by emacs and of course ipython. I am still working on it from time to time, but its a low priority project for now. I am sure other people have similar goals so I am also interested in joining efforts. Also I am interested in visual coding so I am flirting with Phratch and wonder how Phratch would mix with my Super Workspace concept. There is certainly a lot of potential here. On Tue, Jul 15, 2014 at 9:11 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Demo of what? New GUI, new text editor? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de stepharo [steph...@free.frmailto:steph...@free.fr] Envoyé : mardi 15 juillet 2014 20:00 À : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Thierry I can tell you that I got a demo made by gary chambers and this is impressive and all done in Pharo. In addition with the new text model, it will really change the situation. Stef On 15/7/14 13:33, Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry
Re: [Pharo-dev] Thanks for NewVersionBrowser
De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Martin Dias [tinchod...@gmail.com] Envoyé : lundi 14 juillet 2014 21:23 À : Pharo Development List Objet : Re: [Pharo-dev] Thanks for NewVersionBrowser Nice! how can we try this version browser? I'm interested. I used this script to load development version of AltBrowser in Pharo4: Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'; configurationOf: 'AltBrowser'; loadDevelopment. If this script works, then you just need to browse (with AltBrowser) a method from a package where one of the repositories at least is a GitFileTree, and ask for the versions. A good candidate I use is AltBrowser classdefaultPackageCategoriesNames, because it has a long history. Note that this version browser displays both the Changes versions and the git versions, but doesn't try to order them in time (it considers the changes as more recent, that is all) or detect duplicates between the changes and the git. With Jean-Baptiste we pair-programmed a revision walker for libgit2. It should provide what's needed to browse versions in a git repository via the libgit2 bindings. Anyway, the code is still so ugly code that I didn't commit it. It's in the todo after writing a couple of tests... This is great news. I was allways wondering how hard (or how easy) it would be to replace some of the code which uses OSProcess + git to a direct, lower-level access via libgit2. For the version browser type of queries, there is an API entry in MCFileTreeGitRepositorygitVersionsForDefinition: aMCDefinition in: aPackageName which uses git log, and then MCFileTreeGitStReaderzipForDefinition: which loads the method and class properties for a specific commit ID via git archive. If you managed to track method renames through libgit2, that would be a great feature, because I couldn't: git gives me a commit ID, but I don't know how to get the renamed method file :( At times, I really felt alone doing that :( Great to see others looking at it too. Thierry Regards, Martín
[Pharo-dev] Design trends in UI for Mobiles
Food for thought for those working on theming for Pharo: http://arstechnica.com/gadgets/2014/07/the-software-design-trends-that-we-love-to-hate/ Flat buttons for a new kind of game... Finding out what is clickable in a GUI :) Thierry
Re: [Pharo-dev] Metacello-github + filetree-git async
Le 10/07/2014 18:59, Damien Pollet a écrit : as far as I am concerned (I'm certainly not up-to-date on recent enhancements)… - filetree is a pain because of the double-commit workflow (MC with dummy message to serialize, then git) - gitfiletree is a pain because it insists on using a file browser that shows all dotfiles and starts in the stupidest of places Damien, I looked and this stupidest of places of yours is YOUR settings path for your package-cache. Used also by filetree. And all other file-based repositories in Monticello. Regards, Thierry - github is just a snapshot (no updates, no contributions) - there is a mysterious new remote git repo that either uses gitfiletree or the new libgit2 bindings, but I'm not sure what all the parameters are exactly (name of what? subdirectory of where?) This promises to coalesce into a nice workflow, though. Can't wait :D On 10 July 2014 18:47, p...@highoctane.be p...@highoctane.be wrote: I am interested to know too. ATM I do a clone and use filetree:// Phil On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet damien.pol...@gmail.com wrote: Sorry to hijack this discussion… is it by design that the github: scheme takes a snapshot instead of a git clone? github: is convenient for the metacello syntax, but since it just takes a snapshot of a commit, there is no immediate way of pushing changes back. Converting what's on disk to a proper git clone is also not practical since the path of the snapshot under github-cache is specific to the particular commit. On 6 March 2014 13:42, Goubier Thierry thierry.goub...@cea.fr wrote: Ok, I see now. I don't think this can be avoided; it's inherent in the way both github: and gitfiletree: understand repositories. The explanation will go a bit into git and gitfiletree design and FileTree; in the mean time, you may either change a bit the config to clean that (force a load of the last version from gitfiletree, since they are effectively the same) or don't bother, gitfiletree: when saving a new package version will clear that (sort of). The explanation is a bit long. version metadata for FileTree (the format used to write packages for git and others version control systems) is stored in a file under PackageName.package/monticello.meta/versions. This file is often a problem, at least under git: it's a magnet for git merge conflicts. It is also slow to parse[1], especially if you want to know all the versions of the package stored by the git repository (as gitfiletree does), and sometimes is corrupted (git conflicts). So, in the design of gitfiletree:, I decided that I would not read this file, but, instead, recreate its contents from the git log history[2]. This is what you see when you open a gitfiletree: repository. And particularly, versions UUIDs are generated from the git commit ID[3]. Now, when saving a package in a gitfiletree: repository, the versions file will be written, with an UUID generated for it... except that, on rereading, gitfiletree will generate another UUID from the git commitID (which is known, of course, after committing the versions file :() For example, in gitfiletree:, Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 Whereas the file Renraku.package/monticello.meta/versions has Renraku-YuriyTymchuk.4 with id '60141668-a324-4c9d-8938-db82ed2e57de' Older versions are regenerated from the git data, and this is why, in that file, you see Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) [1] Yes, and I tried long and hard to accelerate reading and parsing 200 times the versions file for a moderatly complex project, including the fact that it's easy to find a corrupted versions file in a git repo. Generating ended up a lot cleaner, as well as garanteeing than the history would be browsable. [2] And filtering the git history to keep only the commits significant for the package, and nothing else. [3] Constant mapping: a given git commitID will allways generate the same UUID. Le 06/03/2014 11:41, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 11:35, Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@me.com wrote: On 06 Mar 2014, at 11:17, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 11:09, Yuriy Tymchuk a écrit : Sent from my iPhone On 06 Mar 2014, at 10:28, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 10:08, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 09:48, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 09:32, Yuriy Tymchuk a écrit : Hi guys. My workflow is like this: I load a configuration on CI with github:// magic in metacello conf. Then on local machine I add a local gitfiletree repo to the project packages. The thing is that the last version if loaded, but gitfiletree repo is showing that second last is loaded. And yes, diffs with last one (not loaded by gitfiletree opinion
Re: [Pharo-dev] Division isn't correct
:) in Smalltalk, the division of two integers is a fraction, not a float. i.e. 1/5 is 1/5. Thierry Le 11/07/2014 15:53, Natalia Tymchuk a écrit : Hello. I found interesting thing: Why it is like this? Best regards, Natalia -- 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] [pharo-project/pharo-core] 425fd0: 30852
Thanks Marcus, Thierry Le 10/07/2014 11:10, GitHub a écrit : Log Message: --- 30852 13422 Image crashes because an open Nautilus browser hangs onto many objects while code is being loaded https://pharo.fogbugz.com/f/cases/13422 http://files.pharo.org/image/30/30852.zip -- 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] Thanks for NewVersionBrowser
Hi All, while porting AltBrowser to Pharo4, I had to change my code from the old VersionsBrowser to the NewVersionBrowser based on Spec (for the Git-based method version browser). And I must say: thanks ! The NewVersionBrowser is so easy to extend to use MCMethodDefinitions instead of ChangeRecords, it's like a dream... Being able to wipe out so much ugly unnecessary code :) 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] Metacello-github + filetree-git async
De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Damien Pollet [damien.pol...@gmail.com] Envoyé : jeudi 10 juillet 2014 18:59 À : Pharo Development List Objet : Re: [Pharo-dev] Metacello-github + filetree-git async as far as I am concerned (I'm certainly not up-to-date on recent enhancements)… - filetree is a pain because of the double-commit workflow (MC with dummy message to serialize, then git) - gitfiletree is a pain because it insists on using a file browser that shows all dotfiles and starts in the stupidest of places Starting in one of the default places linked to the image. Yes, this is annoying... I'll look into it. - github is just a snapshot (no updates, no contributions) - there is a mysterious new remote git repo that either uses gitfiletree or the new libgit2 bindings, but I'm not sure what all the parameters are exactly (name of what? subdirectory of where?) GitFileTree for the time being: http://forum.world.st/ANN-GitFileTree-with-no-git-command-line-at-all-td4740317.html This promises to coalesce into a nice workflow, though. Can't wait :D It works as of now :) I'm trying to document some of it in the GitAndPharo chapter of Pharo for the enterprise. Thierry On 10 July 2014 18:47, p...@highoctane.be p...@highoctane.be wrote: I am interested to know too. ATM I do a clone and use filetree:// Phil On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet damien.pol...@gmail.com wrote: Sorry to hijack this discussion… is it by design that the github: scheme takes a snapshot instead of a git clone? github: is convenient for the metacello syntax, but since it just takes a snapshot of a commit, there is no immediate way of pushing changes back. Converting what's on disk to a proper git clone is also not practical since the path of the snapshot under github-cache is specific to the particular commit. On 6 March 2014 13:42, Goubier Thierry thierry.goub...@cea.fr wrote: Ok, I see now. I don't think this can be avoided; it's inherent in the way both github: and gitfiletree: understand repositories. The explanation will go a bit into git and gitfiletree design and FileTree; in the mean time, you may either change a bit the config to clean that (force a load of the last version from gitfiletree, since they are effectively the same) or don't bother, gitfiletree: when saving a new package version will clear that (sort of). The explanation is a bit long. version metadata for FileTree (the format used to write packages for git and others version control systems) is stored in a file under PackageName.package/monticello.meta/versions. This file is often a problem, at least under git: it's a magnet for git merge conflicts. It is also slow to parse[1], especially if you want to know all the versions of the package stored by the git repository (as gitfiletree does), and sometimes is corrupted (git conflicts). So, in the design of gitfiletree:, I decided that I would not read this file, but, instead, recreate its contents from the git log history[2]. This is what you see when you open a gitfiletree: repository. And particularly, versions UUIDs are generated from the git commit ID[3]. Now, when saving a package in a gitfiletree: repository, the versions file will be written, with an UUID generated for it... except that, on rereading, gitfiletree will generate another UUID from the git commitID (which is known, of course, after committing the versions file :() For example, in gitfiletree:, Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 Whereas the file Renraku.package/monticello.meta/versions has Renraku-YuriyTymchuk.4 with id '60141668-a324-4c9d-8938-db82ed2e57de' Older versions are regenerated from the git data, and this is why, in that file, you see Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) [1] Yes, and I tried long and hard to accelerate reading and parsing 200 times the versions file for a moderatly complex project, including the fact that it's easy to find a corrupted versions file in a git repo. Generating ended up a lot cleaner, as well as garanteeing than the history would be browsable. [2] And filtering the git history to keep only the commits significant for the package, and nothing else. [3] Constant mapping: a given git commitID will allways generate the same UUID. Le 06/03/2014 11:41, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 11:35, Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@me.com wrote: On 06 Mar 2014, at 11:17, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 11:09, Yuriy Tymchuk a écrit : Sent from my iPhone On 06 Mar 2014, at 10:28, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 10:08, Yuriy Tymchuk a écrit : On 06
Re: [Pharo-dev] handling method/classes updartes
Hi Uko, not that I know of. It's true that to do that properly, you need to listen to a few announcements but I'd say that the code to filter the relevant announcement isn't very complex. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk [yuriy.tymc...@me.com] Envoyé : jeudi 10 juillet 2014 19:38 À : Pharo Development List Objet : [Pharo-dev] handling method/classes updartes Hi, is there a way to subscribe directly to a method/class, so I san know when it updates/is removed and so on? Because it looks like a pain to subscribe to system announcer and check if the method changed is the one I need. Uko
Re: [Pharo-dev] Workaround monticello issue
Hi Sebastian, which version are you using? I looked into 3.0 and 4.0, and there is nothing there about setting packageList to nil in MCFileRepositoryInspector. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian Sastre [sebast...@flowingconcept.com] Envoyé : lundi 7 juillet 2014 22:45 À : Pharo Development List Objet : [Pharo-dev] Workaround monticello issue Hi there, I’ve just hit an issue that prevented to open packages in monticello MessageNotUnderstood: receiver of indexOf: is nil UndefinedObject(Object)doesNotUnderstand: #indexOf: MCFileRepositoryInspectorpackageSelection PluggableListMorphgetCurrentSelectionIndex PluggableListMorphupdateList PluggableListMorphupdate: MCFileRepositoryInspector(Object)changed: in Block: [ :aDependent | aDependent update: aParameter ] DependentsArraydo: MCFileRepositoryInspector(Object)changed: MCFileRepositoryInspectorrefresh MCFileRepositoryInspectorsetRepository:workingCopy: in Block: [ ... BlockClosurenewProcess in Block: [ ... This is what I’m using as hacky workaround: MCFileRepositoryInspectorpackageSelection ^ self packageList isNil ifTrue:[ 1 ] ifFalse:[ self packageList indexOf: selectedPackage ] The problem is that packageList is nil for some reason. Looks like filetree is involved since 1. I’m using it and 2. it sets an extension method #refresh that makes packageList := nil sebastianhttps://about.me/sebastianconcept o/ blog: http://sebastianconcept.comhttp://sebastianconcept.com/ LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
Re: [Pharo-dev] Workaround monticello issue
Sebastian, FileTree is already integrated in Pharo3 and has probably diverged a bit from Dale FileTree repository, so you don't have to reload it (shouldn't). Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian Sastre [sebast...@flowingconcept.com] Envoyé : mardi 8 juillet 2014 01:19 À : Pharo Development List Objet : Re: [Pharo-dev] Workaround monticello issue Hi Thierry, is a Pharo3.0 Latest update: #30851 with Gofer new url: 'http://ss3.gemstone.com/ss/FileTree'; package: 'ConfigurationOfFileTree'; load. ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load. in it thanks for taking a look! On Jul 7, 2014, at 6:18 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Hi Sebastian, which version are you using? I looked into 3.0 and 4.0, and there is nothing there about setting packageList to nil in MCFileRepositoryInspector. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de Sebastian Sastre [sebast...@flowingconcept.commailto:sebast...@flowingconcept.com] Envoyé : lundi 7 juillet 2014 22:45 À : Pharo Development List Objet : [Pharo-dev] Workaround monticello issue Hi there, I’ve just hit an issue that prevented to open packages in monticello MessageNotUnderstood: receiver of indexOf: is nil UndefinedObject(Object)doesNotUnderstand: #indexOf: MCFileRepositoryInspectorpackageSelection PluggableListMorphgetCurrentSelectionIndex PluggableListMorphupdateList PluggableListMorphupdate: MCFileRepositoryInspector(Object)changed: in Block: [ :aDependent | aDependent update: aParameter ] DependentsArraydo: MCFileRepositoryInspector(Object)changed: MCFileRepositoryInspectorrefresh MCFileRepositoryInspectorsetRepository:workingCopy: in Block: [ ... BlockClosurenewProcess in Block: [ ... This is what I’m using as hacky workaround: MCFileRepositoryInspectorpackageSelection ^ self packageList isNil ifTrue:[ 1 ] ifFalse:[ self packageList indexOf: selectedPackage ] The problem is that packageList is nil for some reason. Looks like filetree is involved since 1. I’m using it and 2. it sets an extension method #refresh that makes packageList := nil sebastianhttps://about.me/sebastianconcept o/ blog: http://sebastianconcept.comhttp://sebastianconcept.com/ LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
Re: [Pharo-dev] PillarHub
Le 03/07/2014 05:38, mikefilonov a écrit : Hi everyone, Thanks! I think Alexey will be really happy to read this thread when he is back to university in a month :) Congratulations! As for versioning yes we plan to implement it. I think it should be easy as Monticello implement it so it should be possible to reuse. I need to see the code though. Also Damien gave a great idea to add a configuration for a hub to sync it's content to GitHub so cloud could be used for backup/versioning. I think it is a perfect solution but I don't see yet how it can be implemented. Is any one knows classes to talk to github? If it can go through Monticello, then you can use GitFileTree or FileTree + Git + OSProcess. Look into the GitFileTree code to see how you can clone from a github repository and do push / pull. If it's not Monticello, but pillar files saved to disk, the same code/approach can be used. 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] 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
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] 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
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 package
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] https://pharo.fogbugz.com/default.asp?13422
What i'd be worried with is the high number of PackageTreePackageNodeModel-102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? I'd look into the package tree structure and updates. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de stepharo [steph...@free.fr] Envoyé : dimanche 29 juin 2014 10:38 À : Pharo Development List Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 I did an 'Smalltalk allClasses collect:[:cl | cl - cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected). The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others. Float-3580540 Point-2149989 Rectangle-818991 Array-573089 MorphExtension-309932 TableLayoutProperties-204571 ByteString-108891 OrderedCollection-107527 IdentityDictionary-103768 ImageMorph-102338 StringMorph-102318 Morph-102313 DependentsArray-102309 TableLayout-102308 RowLayout-102259 MorphTreeNodeMorph-102252 PackageTreePackageNodeModel-102250 Association-26405 Duration-14081 CompiledMethod-11191 MethodChangeRecord-11131 IdentitySet-10843
Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422
Yes, the original emal has stepharo as the sender :) Ok, I try to scan but I don't seem to reproduce. And my netbook is really slow, so scanning the memory for all instances takes forever :( Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Johan Brichau [jo...@inceptive.be] Envoyé : dimanche 29 juin 2014 16:21 À : Pharo Development List Objet : Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 On 29 Jun 2014, at 15:24, GOUBIER Thierry thierry.goub...@cea.fr wrote: What i'd be worried with is the high number of PackageTreePackageNodeModel-102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? It was me ;-) (fogbugz sends email as Stef?) Exactly, this is where I am looking at. I have tried to find who is referencing all those instances but I have not discovered it yet. I'd look into the package tree structure and updates. I started to look at the single PackageTreeNautilusUI instance I have open which should be the root that is keeping all these instance in the image. But I am wandering through unknown code here... Johan
Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
My guess would then be: when updating the list of packages, the selected morph isn't removed from selectedMorphs, however the tree view is rebuilt [*] by recreating all models and all morphs inside, with reselection of the current package (which sees a newly created morph selected and added to selectedMorphs). [*] Yes, on average, what is done when a tree is updated is : destroy all morphs inside the tree view, and all models as well, and recreates everything. Now, why on AltBrowser tree view I haven't seen the issue: single selection versus multiple selection? Or because I have some code to do partial tree updates? We're lacking a nice tree object model for GUI use. I'll try to write a test case tracking this. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Johan Brichau [jo...@inceptive.be] Envoyé : dimanche 29 juin 2014 22:31 À : Pharo Development List Objet : Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo 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
Re: [Pharo-dev] How to get started with Git and Pharo?
Le 26/06/2014 19:11, Yuriy Tymchuk a écrit : I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html I usually mix filetree and gitfiletree. Last one is better, because you don’t have to remember to commit in git each time you commit in pharo. (Also I think that gitfiletree is not working with Pharo4) Because I haven't spent the time updating the configuration for that :( I'm pushing small changes on GitFileTree at the moment; a Pharo4 version should come soon. 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] How to get started with Git and Pharo?
Hi Stéphane, I have to admit then that my presentation to you a month ago was a failure ;) Thierry Le 26/06/2014 18:27, stepharo a écrit : Hi I do not know the dif between git file tree, file tree and I would like to know how to get started with git in Pharo? What should I read? Stef -- 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] about ~=
Le 26/06/2014 18:11, Richard Sargent a écrit : Esteban A. Maringolo wrote If one thing confuses people in that realm is non arithmetic precedence: Eg. 2 + 3 * 4 = 20 instead of the expected 14. And we're not going to change that either. It's not worthy, and I doubt if it is possible at all. I'm probably late to the party with this reply. The primary reason for not changing this is that it would be incorrect. It comes down to intrinsic versus extrinsic meaning. A multiple operator has an intrinsic meaning: it means multiple. But a message name does not have intrinsic meaning (other than it is a good idea to have the name represent what it does). The meaning of a message is determined by the receiver. e.g. if PetitParser defines #* to mean 0 or more repetitions, what happens when someone has decided that it should be evaluated before #+? Message sending precedence can only be defined in terms of the type of message: unary, binary (or infix), and keyword, since the interpretation of the message is the receiver's responsibility, not the compiler's. You could do it, but then you would have to wire the smalltalk parser with additional data (binary messages precedence) that would have to add a way or another to your binary method definition. 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] Nautilus memory leak/hog crashing Pharo
Ok then, a simple profile should do it. I'll have a look. I did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that. Thierry Le 27/06/2014 11:58, p...@highoctane.be a écrit : Same story here. Loading with browsers closed leads to a 10x faster load. Phil Le 27 juin 2014 10:31, Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be a écrit : I reported it as bug 13422 [1]. For now, I was only able to do a comparison before/after which instances are being kept around. Johan [1] https://pharo.fogbugz.com/default.asp?13422#104139 On 26 Jun 2014, at 16:33, Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be wrote: Nicolai, It's not a public configuration and it loads quite some packages. I will pick up this issue this evening to get a better reproducible case. thx Johan On 26 Jun 2014, at 16:03, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-06-26 15:37 GMT+02:00 Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr: Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit : On 26 Jun 2014, at 15:17, Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be wrote: I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) I disagree a bit ;-) Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. Not by much. Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. I disagree with you there. Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). 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 I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers. Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled? regards 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
Le 27/06/2014 13:02, Goubier Thierry a écrit : Ok then, a simple profile should do it. Sort of, it doesn't show up that clearly. I'll have a look. 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 did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that. Went from 15% to 2~3% of Roassal2 loading time :) 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
[Pharo-dev] GUI question
Hi all, is there a rationale for the world menu on left mouse button only in Pharo 4? (and world contents on the right mouse button) Mine would be: - if I press a pull down menu (press a menu bar item or a pull down menu), it's the left mouse button. - If I look for a menu on a non-button thing, it's the right mouse button, i.e. contextual menu. Now, should I consider that the Pharo background is a huge pull-down menu button to understand the rationale behind having the world menu on the left-mouse button? 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] How to get started with Git and Pharo?
Le 26/06/2014 19:11, Yuriy Tymchuk a écrit : I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html I usually mix filetree and gitfiletree. Last one is better, because you don’t have to remember to commit in git each time you commit in pharo. (Also I think that gitfiletree is not working with Pharo4) Now it works with Pharo4! 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] Nautilus memory leak/hog crashing Pharo
Sorry to ask then, but: would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed. I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why). Thierry Le 25/06/2014 20:20, p...@highoctane.be a écrit : Maybe due to some Annoucement being picked up by Nautilus? Phil On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau jo...@inceptive.be mailto:jo...@inceptive.be wrote: Hi, It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so. I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only. When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable. Is this a known issue? Any thoughts on what may be causing this? regards! Johan -- 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
Le 26/06/2014 15:17, Johan Brichau a écrit : I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. Try with a simple configuration: the announcements should already be visible on the profile. But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) Or switch to another browser :) 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] Nautilus memory leak/hog crashing Pharo
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit : On 26 Jun 2014, at 15:17, Johan Brichau jo...@inceptive.be wrote: I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) I disagree a bit ;-) Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. Not by much. Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. I disagree with you there. Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). 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] Brainstorming Pharo4
Le 16/06/2014 16:13, Esteban A. Maringolo a écrit : Add this to the wishlist: - Scoped refactorings. Particularly method renames. I'd like to scope the refactorings to class, hierarchy, package or global level. :) I think it's already there :) Just need a way to use them. I may already have that, need to test (scoped system browser with refactorings coupled to the scope). Try scoped browsing with Nautilus and apply refactorings... 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] [PROVENANCE INTERNET] Re: Brainstorming Pharo4
Le 16/06/2014 16:24, Goubier Thierry a écrit : Le 16/06/2014 16:13, Esteban A. Maringolo a écrit : Add this to the wishlist: - Scoped refactorings. Particularly method renames. I'd like to scope the refactorings to class, hierarchy, package or global level. :) I think it's already there :) Just need a way to use them. I may already have that, need to test (scoped system browser with refactorings coupled to the scope). Try scoped browsing with Nautilus and apply refactorings... And once you're in there, you can refine by cascading scopes. In package X, along hierarchy of class Y, find all methods with name containing visit, rename #visitRootNode: as #acceptRootNode: Can also be combined with RB pattern matching for searching in code, but I'd like to see the GUI for that last one :) Who was said to be working on that? 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] Pharo compilation limits
Hi Clement, I'm hitting the maximum jump size limit. The method is around 1 characters long, with a sequence of ifTrue: ifFalse: Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Clément Bera [bera.clem...@gmail.com] Envoyé : mardi 10 juin 2014 08:15 À : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 2:23 GMT+02:00 GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr: Hi all, anybody would have a way to determine the maximum length / maximum complexity of a method in a Pharo out of a parse tree (or whether if the parse tree is over the limit)? There are many different issues: maximum number of literals, maximum jump size, maximum number of temporaries. Can you precise what problem do you have ? What errors are raised ? The code SmaCC generates easily hit compiler limits (methods too long or too complex), and I have difficulties changing the code generation approach. For Pharo 4, we are implementing a new compiler back end that will remove some of those limits. I have a problem with code generation too and we are solving it. Clément Thanks, Thierry
Re: [Pharo-dev] Pharo compilation limits
Clement, Thanks for the update. Given the way the code is structured, it is a bit hard to work on catching the error: it's refactoring-based, so it prepares a set of refactorings, then applies them in one go. So, once you reach the error, you are very far from the point where you decided to produce the code. I have a working solution for now; from what you tell me, those limits will be raised in the near future and I don't have to worry too much about that. Thanks, Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Clément Bera [bera.clem...@gmail.com] Envoyé : mardi 10 juin 2014 15:52 À : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 14:32 GMT+02:00 GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr: Hi Clement, I'm hitting the maximum jump size limit. The method is around 1 characters long, with a sequence of ifTrue: ifFalse: Hello, For now, this issue is hard to solve. The maximum length of a jump is 1024 instructions (cf bytecode table here: http://clementbera.wordpress.com/2013/09/23/squeakv3plusclosure-bytecode-set/ ). The problem of computing the maximum bytecode length of a sequence form a parse tree is that each AST nodes may generate bytecodes of a variable length. In addition, control flow optimizations are done in Opal after the AST, therefore a block node may generate bytecodes of very different sizes. Lastly, we will change the bytecode set in a few months (partly to solve the issue you have) and your bytecode length assumptions will not be valid any more. I think the best way is to catch the error while compiling and override the error behavior. Right now a generic error is raised but it can be fixed. Look at: IRBytecodeGeneratorjumpForward: , jumpBackward: , jump:if: Replace all the error signals by something like: self error: 'forward jump too big' JumpTooBigCompilationError new info: specificInfosFromCompilerToTipSmaCCOnHowToGenerateWorkingCode; signal. Then you can catch it for your compilations. [ compilation code ] on: JumpTooBigCompilationError do: [ :ex | exception handling code ]. For example: [ Smalltalk compiler source: 'foo ^ nil'; class: Object; failBlock: [^ nil]; compile ] on: JumpTooBigCompilationError do: [ :ex | SmaCC new regenerateMethodBasedOn: ex info ]. However, this issue will be solved in Pharo 4 in a few months. The maximum number of instructions a jump can handle will be increased from 1024 to around 32000. If this is still not enough for you, tell us then we'll patch the compiler backend and the VM front end to work with more important instruction size. Clement Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de Clément Bera [bera.clem...@gmail.commailto:bera.clem...@gmail.com] Envoyé : mardi 10 juin 2014 08:15 À : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 2:23 GMT+02:00 GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr: Hi all, anybody would have a way to determine the maximum length / maximum complexity of a method in a Pharo out of a parse tree (or whether if the parse tree is over the limit)? There are many different issues: maximum number of literals, maximum jump size, maximum number of temporaries. Can you precise what problem do you have ? What errors are raised ? The code SmaCC generates easily hit compiler limits (methods too long or too complex), and I have difficulties changing the code generation approach. For Pharo 4, we are implementing a new compiler back end that will remove some of those limits. I have a problem with code generation too and we are solving it. Clément Thanks, Thierry
Re: [Pharo-dev] Filetree and merging
Le 27/05/2014 23:48, Dale Henrichs a écrit : Johan, From the GemStone side, tODE has a number of git-friendly features and will be available for alpha real-soon-now[TM] ... I use the tODE git merge tool for all of my git merges as I consider it superior to the existing mergetools out there ... but then I'm biased:) I'm willing to share the fundamental classes for parsing the git merge/diff information if folks from Pharo want to get into that business ... Cool. I'm for it :) the Metacello Preview features have also been aimed at support for git-based development and I'm leveraging those features for tODE as well ... Dale 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] Filetree and merging
Le 28/05/2014 11:16, p...@highoctane.be a écrit : Hi Thierry, On Wed, May 28, 2014 at 10:44 AM, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line. CentOS 6 Linux Well, have you set any strange options in the git repository itself? I've seen in the man pages stuff about automatic line ending conversions. What is the current best practice for merging packages that way? As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :)) Yeah, meld here... Or vimdiff At least there is a tool :) I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge: - pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver But I'm not finding the time I need to finish that :( Mmmh, anything not even close to a draft and some notes are welcome! I haven't yet set it to generates the chapter, but it is the GitAndPharo chapter (and I have a GitAndPharoTutorial repository on github to go along, with pre-prepared branches to let people experiment the merge). I'll be presenting that during the next MooseDay, so it can be an occasion to talk. Yeah, I think that I can come over for the first day to listen you that Git talk of yours and show you our thing. Cool. It'll be a pleasure :) Thierry BTW http://www.doesnotunderstand.org/MOOSEDayUPMC/ says Thuesday. I do not know what Thuesday means, but as the next day looks like Friday, I'd advise someone put Thursday (or is it Tuesday after all?). Schedule Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. looks weird too. Phil 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 tel:%2B33%20%280%29%201%2069%2008%2032%2092 / 83 95 -- 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] is ClassOrganization#categories right?
De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Marcus Denker [marcus.den...@inria.fr] Envoyé : mardi 27 mai 2014 09:58 À : Pharo Development List Objet : Re: [Pharo-dev] is ClassOrganization#categories right? On 27 May 2014, at 01:57, Ben Coman b...@openinworld.com wrote: GOUBIER Thierry wrote: In my own code, I allways use ClassOrganization#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. +1 for #protocols returning protocol objects, not symbols… Up to you, just that it is consistent... protocol objects everywhere, or symbols everywhere. #categories for symbols, #protocols for protocol objects (and #addCategory: for symbols, #addProtocol: for protocols, and so on...). A subject for the Pharo Sprint planned by Serge in Paris in two weeks time ? Thierry Marcus
Re: [Pharo-dev] is ClassOrganization#categories right?
In my own code, I allways use ClassOrganization#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.com] Envoyé : lundi 26 mai 2014 21:20 À : Pharo Development List Objet : [Pharo-dev] is ClassOrganization#categories right? Hi, I wonder is current implementation of that method is good: right now, it answers all categories, including virtual ones (—all—). A lot of things are made in that assumption, but I wonder if is not better to answer just real categories and to create a new method called #allCategories to answer the reals and the virtuals. Also, I wonder if wouldn’t be better to just deprecate #categories and use the correct abstraction: #protocols. any opinions? Esteban
Re: [Pharo-dev] blog post explaining the codecity visualization of pharo changes
Le 20/05/2014 13:22, Tudor Girba a écrit : Yes, of course I know about tags. But, they are not used so prominently just yet. For example, take the AST packages: - AST-Core - AST-Interpreter-Core - AST-Interpreter-Extension - AST-Interpreter-Test - AST-Tests-Core Of these, AST-Core does have tags, but the rest are not explicitly related to the AST concept. By using string magic in this case all of these would appear close together. That is why I used strings instead of tags. We probably have a few versions of code doing packages classifications based on prefix floating around :) It works fairly well. I do have some code which also scans catalogKeywords in configurations to improve the classification. 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] Pharo in Rasbian ?
Hi Jannick, I want to know about that too :) Thierry Le 20/05/2014 16:30, jannik laval a écrit : Hi Juan, I don't know. I did not have enough time to try that. We should try, and see :) Jannik 2014-05-20 16:23 GMT+02:00 Juan smalltalker.marc...@gmail.com mailto:smalltalker.marc...@gmail.com: Jannik the phratch proyect provides access to GPIO port? ffi to achieve such access is available? any ideas? thanks in advance best jmdc On Tue, May 20, 2014 at 10:36 AM, jannik laval jannik.la...@gmail.com mailto:jannik.la...@gmail.com wrote: Hi, Probably he does not know phratch for Rasberry-Pi: https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RPi/ Cheers :) 2014-05-20 15:32 GMT+02:00 Alexandre Bergel alexandre.ber...@me.com mailto:alexandre.ber...@me.com: Hi! A friend of mine recently bought a Raspberry pi and installed Rasbian, a Debian-like OS for Raspberry. Squeak and Scratch are installed per default. There is room to fill here... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/ -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/ -- 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] Serial port support on Pharo (2 or 3)
Hi all, has anybody success using serial ports with Pharo on Mac or Linux? We're having reports of lack of success, including lack of success in recompiling a Pharo VM with a correct serial port access (a few months ago), where the same approach was sucessfull with a squeak VM. 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] I love the Pharo 3 Dark Theme
Le 14/05/2014 14:36, Esteban A. Maringolo a écrit : 2014-05-14 5:39 GMT-03:00 Sven Van Caekenberghe s...@stfx.eu: Hi, I have been using the new Pharo 3 Dark Theme since it was announced on May 1st. In my specific case, I am using the FreeType fonts Open Sans Regular 11 and Source Code Pro Regular 11 on a MacBookAir, both on the 13 inch 1440x900 built in screen and on a 23 inch 1920x1024 external monitor. Every day there is a moment that I think: this looks so nice, this is so pleasant to use. Really Esteban, I don't know how you did it, but the color palette is really well chosen, plain beautiful. Let's make this either a permanent part of Pharo or an easy to load extension, real soon. I want to say thanks too. I'm using it since day one, it's easier for my eyes. And even got somebody attention, who asked me what I was using... I vote to make it permanent. Regards! ps: I'm using the default DejaVu fonts, how do you set the TTF font programatically? I do it in the settings... and export them; However, when I rebuilt an image, I need to execute: FreeTypeFontProvider current updateFromSystem For the settings to apply. Thierry Esteban A. Maringolo -- 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] I love the Pharo 3 Dark Theme
Le 14/05/2014 15:08, Esteban A. Maringolo a écrit :
Thanks for the snippets.
Is the Source Pro family available for Ubuntu Linux 13.04?
You will have to install them yourselves. I have the instructions
somewhere...
Yes: I have
SourceCodePro_FontsOnly-1.017.zip
SourceSansPro_FontsOnly-1.038.zip
Downloaded somewhere (sourceforge, I guess)
Oh, from there:
http://askubuntu.com/questions/193072/how-to-use-the-new-adobe-source-code-pro-font
I also know Doru has a package for Pharo somewhere.
Thierry
Regards!
Esteban A. Maringolo
2014-05-14 10:01 GMT-03:00 Esteban Lorenzano esteba...@gmail.com:
thanks for the nice comments.
yes, I’m working on making it something better that a hack (I will probably
finish it next week). Then, we think on including it in a future update on
Pharo 3.
now… it will be available, but I do not think it will be the default theme.
But it will be there for choosing it. Also, I think theme it-self still need
some care, let me know your findings and I will fix it as soon as possible
:)
for programatically, I have added a fonts.st fonts to the autoconfiguration
of pharo
StartupLoader default executeAtomicItems: {
StartupAction
name: 'Fonts 3.0'
code: [
| pointSize fontName codeFontName |
FreeTypeSystemSettings loadFt2Library: true.
FreeTypeFontProvider current updateFromSystem.
pointSize := 10.
fontName := 'Source Sans Pro'.
codeFontName := 'Source Code Pro'.
StandardFonts
setAllStandardFontsTo: (LogicalFont familyName: fontName pointSize:
pointSize);
haloFont: (LogicalFont familyName: fontName pointSize: pointSize - 1);
balloonFont: (LogicalFont familyName: fontName pointSize: pointSize - 1);
windowTitleFont: (LogicalFont familyName: fontName pointSize: pointSize +
1);
listFont: (LogicalFont familyName: fontName pointSize: pointSize);
menuFont: (LogicalFont familyName: fontName pointSize: pointSize);
codeFont: (LogicalFont familyName: codeFontName pointSize: pointSize)
]
runOnce: true.
}.
this is usually in:
OSX: ~/Library/Preferences/pharo/3.0
Linux: ~/.config/pharo/3.0 (I’m not sure, but somewhere there)
Windows: no idea :)
cheers,
Esteban
On 14 May 2014, at 14:48, Goubier Thierry thierry.goub...@cea.fr wrote:
Le 14/05/2014 14:36, Esteban A. Maringolo a écrit :
2014-05-14 5:39 GMT-03:00 Sven Van Caekenberghe s...@stfx.eu:
Hi,
I have been using the new Pharo 3 Dark Theme since it was announced on May
1st. In my specific case, I am using the FreeType fonts Open Sans Regular 11
and Source Code Pro Regular 11 on a MacBookAir, both on the 13 inch 1440x900
built in screen and on a 23 inch 1920x1024 external monitor.
Every day there is a moment that I think: this looks so nice, this is so
pleasant to use. Really Esteban, I don't know how you did it, but the color
palette is really well chosen, plain beautiful. Let's make this either a
permanent part of Pharo or an easy to load extension, real soon.
I want to say thanks too.
I'm using it since day one, it's easier for my eyes.
And even got somebody attention, who asked me what I was using...
I vote to make it permanent.
Regards!
ps: I'm using the default DejaVu fonts, how do you set the TTF font
programatically?
I do it in the settings... and export them; However, when I rebuilt an
image, I need to execute:
FreeTypeFontProvider current updateFromSystem
For the settings to apply.
Thierry
Esteban A. Maringolo
--
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
--
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] I love the Pharo 3 Dark Theme
Le 14/05/2014 15:01, Esteban Lorenzano a écrit : thanks for the nice comments. yes, I’m working on making it something better that a hack (I will probably finish it next week). Then, we think on including it in a future update on Pharo 3. Cool. I want that! I'm still using the old Pharo theme, mostly because the Dark theme merge takes ages, particularly on my home machine... now… it will be available, but I do not think it will be the default theme. But it will be there for choosing it. Also, I think theme it-self still need some care, let me know your findings and I will fix it as soon as possible :) There you go: grabing or clicking the scrollbar gives you no feedback (same as the default Pharo 3 theme before philippe corrected it). 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] I love the Pharo 3 Dark Theme
Le 14/05/2014 15:53, p...@highoctane.be a écrit : On Wed, May 14, 2014 at 3:45 PM, Esteban A. Maringolo emaring...@gmail.com mailto:emaring...@gmail.com wrote: 05-14 10:42 GMT-03:00 p...@highoctane.be mailto:p...@highoctane.be p...@highoctane.be mailto:p...@highoctane.be: The file is named: SourceCodePro_FontsOnly-1.017.zip In the TTF folder you have: $ ls SourceCodePro-Black.ttf SourceCodePro-Medium.ttf SourceCodePro-Bold.ttfSourceCodePro-Regular.ttf SourceCodePro-ExtraLight.ttf SourceCodePro-Semibold.ttf SourceCodePro-Light.ttf Must click on each to install the font via font manager. Other automated black magic welcome. I copied .otf files to ~/.fonts/ directory, and were picked-up by Ubuntu immediately. Is it possible to do that for all users at once? Yes, by copying in one of the system font folders. There is probably a /usr/local/ ... /fonts something for a clean add. 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] [ANN] Pharo3 Dark Theme is available
Bravo Esteban! By the way, I have added a PharoExtras UIThemes project to Smalltalkhub, right in time it seems ;) About a morphic redesign, I just had a look at Cuis to see how was their Morphic. Thierry
Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available
De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.com] By the way, I have added a PharoExtras UIThemes project to Smalltalkhub, right in time it seems ;) yeah, the problem is that currently there are a lot of changes happening to make the dark theme possible (I removed hardcoded colors everywhere, re-direct default colors to theme everywhere, modified without any contemplation packages like Morphic*, Spec* and Nautilus*… along with Polymorph* packages, of course. Yes, I had a look in the Pharo3DarkTheme package :) This is the only thing which dissuades me from using it right now :( The time for the merge to happen on my netbook is just too long... And I have to do screenshots for PharoForTheEnterprise :) So… I need to work a lot more in polishing, ensure all continues working, make appropriate SLICES, etc. I see this as part of the “tool oriented” direction of Pharo 4. I shared because I think the result is good enough and people can take benefit of having it (also, then people can help on making the work, he). But in any case, is not close at all of being integrable to core image, or to a standard theme project :( But it will be, it has to :) You've given us something to dream about, and to start to use to boot :) About a morphic redesign, I just had a look at Cuis to see how was their Morphic. yeah, not sure that I want to follow that path, but we need to start discussing it :) I know Alain Plaintec started to work on a new morphic, and I suppose best scenario is all community joining efforts to achieve the goal, but for that we first need to discuss/agree on a design. I've seen Alain's effort the last time I went to Brest, but I never took the time to try it. I think it's probably a good base; as it is use-driven, it is important to exercise it with the most complex Morphic / Spec GUIs we can build, which means community support. What happens now is that every morph is a HUGE ball of mud, with mixed responsibilities and many dependencies to other “layers”: is very famous the dependency of HandMorph with the event dispatcher (now cleaned), but that was just an example. Now it is mixed with Polymorph in a very dirty way, etc. etc. As it's easy for me to see that, it's also frightening to see how many protocols in Morphic are extensions for packages which do not exist anymore. And the complexity of all the PluggableXXX is frightening, and it introduces serious performance problems. In a ver corse grained way, I imagine a future morphic well split in his different concerns: graphic “atoms”, skins and widgets. And with a more understandable layout API, and with simpler widgets to connect to models, and with working caching so that we don't busy lock Pharo when exploring long collections, and that Moose doesn't have to use that ugly paging tree/list morph, and ... While still keeping what made Morphic so great in the first place :) Thierry cheers, Esteban Thierry
Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available
De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sean P. DeNigris [s...@clipperadams.com] Envoyé : jeudi 1 mai 2014 20:31 À : pharo-dev@lists.pharo.org Objet : Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available EstebanLM wrote About a morphic redesign... I suppose best scenario is all community joining efforts to achieve the goal, but for that we first need to discuss/agree on a design. Yes!!! IMHO our Morphic implementation's ocmplexity is the biggest thing holding back our creative spirit. It seems that many other things have been cleared out of our way and now is the time to make this happen. I think you hit the nail right on the head: 1) all interested parties join forces - there have been too many experimental cleanups and re-implementations that are interesting but ultimately unused/unusable, and 2) start with a solid design. Morphic's power is incredible and it would be great to have that available when you need it, with all the more-business-friendly UI objects built on top. Some good places I've found ideas and insights are ARK, Self, Lively Kernel, KScript, and Cuis. Note on the design: I wouldn't hesitate to have some of the business-friendly objects slightly on the side of the overall design: we don't need the full complexity and power of Morphic for many business objects... Doru's work with Glamour may be a good benchmark of how simple business looking code may be. However, I would dream of merging Roassal(2) and Morphic. Use Roassal DSLs and infrastructure to make Morphic simpler, and build fully integrated GUIs (code exploration tools, or even a system browser) where some of the widgets are Roassal(s). This was my dream when I started my browser: have a full screen representation of the code inside my image, as an interactive background to my Pharo, and editors floating there and there to edit the code, run it, explore it, debug it, etc... I settled for less :) Thierry
[Pharo-dev] Pharo on RPi
Hi all, I'd like to know what is the status of Pharo on the RPi? It would be to use it with serial port communications and seaside development. Thanks, 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] Pharo on RPi
Le 30/04/2014 11:58, jannik laval a écrit : I have a Phratch that begin to work on RPi (https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RPi/). So, you can probably use Pharo 3 Thanks. I'll start moving the infrastructure there then. Thierry Now I have problems with FileSystem, I will ask in another thread. Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/ -- 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] Pharo on RPi
Thanks JB! This is really great! Thierry Le 30/04/2014 13:18, Jean Baptiste Arnaud a écrit : The status of Rpi. The VM work as a StackVM linux one, Except for: - Sound (recent bug will be fixed soon), - NativeBoost (arm), - FFI (recent change from Doug will be here soon) and OsProcess (I just don not try it yet but I didn't look at it). I think the VM is stable enough to be used. I will move the infrastructure to the file server today, the last raspberry pi VM should work. It will be fixed during the day. On 30 Apr 2014, at 12:31, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 30/04/2014 11:58, jannik laval a écrit : I have a Phratch that begin to work on RPi (https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RPi/). So, you can probably use Pharo 3 Thanks. I'll start moving the infrastructure there then. Thierry Now I have problems with FileSystem, I will ask in another thread. Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/ -- 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 Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com mailto:jbaptiste.arn...@gmail.com -- 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] Fast way to load package form github
Le 28/04/2014 10:42, François Stephany a écrit : Sounds *really* good! Do you have a time goal for this integration (even rough estimate)? Sorry if this sound stupid but are we far from an integration with, say, the Changes tool? I think Max should answer that question, he is on it. Then either he will propose another solution to integrate git or I will port gitfiletree on his work, whichever comes first or is considered better from a technical point of view. I think I will have a solution for the merge conflicts sometime by the end of the week, if I don't have too many disruptions... If you need some help somewhere (money or manpower), I'm sure there are quite a few people interesting in donating for this (Ta Mère is). All the development is done in the open, so if you're ready to spend some manpower on it, then please do it :) I'm not into funding, unless you make it a collaborative research project :) but the Pharo association may be interested. At the moment, I'd say the needs are: - gitfiletree//: at most one man-week to add Microsoft Windows support. - libgit integration: Max, this is yours to answer ;) - git merge conflicts resolution: give me until the end of the week and I'll be able to say what is needed. And a bit of dicussion on a git workflow for a small team. Thierry On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Hi François, with gitfiletree://, there isn't any real place describing a multi-developper workflow because it is designed to work along existing workflows... as much as possible. In short, you work like you used to do in git, and gitfiletree ensures that the commit are properly made, that you have access to your development history (your true development history: the git one), and that pushes and pulls are made as painless as possible. After, you just manage your git the way you like it. Branches, merging, one branch per developper, whatever: gitfiletree:// will ensure that what you see inside Pharo is what you have done in git, and that what you do in Pharo is properly committed to git. Now, the bad thing: git merge conflicts :( When merging packages under git, some files will regularly(allways :() conflict: the version history of the package and the method properties. Whatever way you resolve those conflicts, gitfiletree:// will cope because it never reads them, but, still, having conflicts in git isn't cool. We have a better integration coming, through Max Leske work on integrating libgit to Pharo, and we will be able to solve some of the issues above ;) Thierry *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org mailto:pharo-dev-boun...@lists.pharo.org] de la part de François Stephany [tulipe.mouta...@gmail.com mailto:tulipe.mouta...@gmail.com] *Envoyé :* samedi 26 avril 2014 19:06 *À :* Pharo Development List *Objet :* Re: [Pharo-dev] Fast way to load package form github I'm a bit lost of what is currently possible to do with git in Pharo. Is there a place where you describe your workflow in a multi-developer environment? We currently use git flow[1] for our iOS, Android and Rails apps. We would love to use the same for Pharo. What we are doing now is using a filetree repository under a src/ directory sitting next to the image. We use versionner to save all our packages in the filetree tree and then we `git commit/push`. It was working fine while I was alone but we are now two developers working on this and I do not feel confident about this flow; merging filetree tree in CLI doesn't sound like a good idea. probably not be practical. The second developer is working on this since yesterday so we haven't yet decided how we gonna handle this. I would love to hear from people working with git and Pharo. [1] http://nvie.com/posts/a-successful-git-branching-model/ On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Yuri, pure filetree will only allow you access to the latest version (HEAD) of the repository (and will only match if you load that precise version number as stored in the package metadata or if you don't specify a version number). You have to change the commit ID (and branch) via git clone, git checkout and git checkout -b before. github:// urls may be able to select a specific commit ID, but I don't know how. You can select the branch, however. Again, if you specify a version number for your package with a github:// url, the metadata of your package has to agree with you or it will refuse to load (you are able to see only the latest version
Re: [Pharo-dev] Fast way to load package form github
Le 28/04/2014 11:37, François Stephany a écrit : Thank you both for the details! Haha, I understand if you prefere to be on your own for the bindings (at least while it's still in construction). Thierry, If you need some feedback for the merge conflict resolution, I'll be glad to help. Just ask :) Thanks, I'll need it. I let you know, and anybody else interested, when I have something to test; soon. Thierry Max, I don't know how is your master thesis schedule organized but if you're interested, we can maybe try to allocate a summer of code with the libgit2 integration? Cheers, Francois On Mon, Apr 28, 2014 at 11:08 AM, Max Leske maxle...@gmail.com mailto:maxle...@gmail.com wrote: On 28.04.2014, at 10:42, François Stephany tulipe.mouta...@gmail.com mailto:tulipe.mouta...@gmail.com wrote: Sounds *really* good! Do you have a time goal for this integration (even rough estimate)? Sorry if this sound stupid but are we far from an integration with, say, the Changes tool? If you need some help somewhere (money or manpower), I'm sure there are quite a few people interesting in donating for this (Ta Mère is). It’s on the way but we still have some way to go. I’ll be off the grid for the next 4 weeks and after that I’ll have to prepare for my exams. Still, I hope that I can show a prototype for using github around mid June (I’m pessimistic on purpose here). BTW: push and fetch via SSH / HTTPS already work (but you don’t want to see the code…). I’m glad you’re so enthusiastic but it’s a complex project and I don’t want to rush it (it’s also part of my master’s thesis btw). I’m posting updates from time to time with “FileSystem-Git update X” or similar in the subject if you want to follow. There’s also a dedicated mailing list: smalltalk-...@googlegroups.com mailto:smalltalk-...@googlegroups.com To answer your questions: - no, there is no concrete plan other than “ships with Pharo4” (I hope…) - tool integration should be pretty straight forward once the bindings work. But I really can’t give you a date. As soon as there’s stuff that can be easily partitioned into workable chunks I’ll take to the mailing list. But I want to do the bindinds first, preferably on my own (requires a lot of special knowledge about git / libgit2 / NativeBoost). But thanks for the offer anyway. Much appreciated! Cheers, Max On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Hi François, with gitfiletree://, there isn't any real place describing a multi-developper workflow because it is designed to work along existing workflows... as much as possible. In short, you work like you used to do in git, and gitfiletree ensures that the commit are properly made, that you have access to your development history (your true development history: the git one), and that pushes and pulls are made as painless as possible. After, you just manage your git the way you like it. Branches, merging, one branch per developper, whatever: gitfiletree:// will ensure that what you see inside Pharo is what you have done in git, and that what you do in Pharo is properly committed to git. Now, the bad thing: git merge conflicts :( When merging packages under git, some files will regularly(allways :() conflict: the version history of the package and the method properties. Whatever way you resolve those conflicts, gitfiletree:// will cope because it never reads them, but, still, having conflicts in git isn't cool. We have a better integration coming, through Max Leske work on integrating libgit to Pharo, and we will be able to solve some of the issues above ;) Thierry *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org mailto:pharo-dev-boun...@lists.pharo.org] de la part de François Stephany [tulipe.mouta...@gmail.com mailto:tulipe.mouta...@gmail.com] *Envoyé :* samedi 26 avril 2014 19:06 *À :* Pharo Development List *Objet :* Re: [Pharo-dev] Fast way to load package form github I'm a bit lost of what is currently possible to do with git in Pharo. Is there a place where you describe your workflow in a multi-developer environment? We currently use git flow[1] for our iOS, Android and Rails apps. We would love to use the same for Pharo. What we are doing now is using a filetree repository under a src/ directory sitting next to the image. We use versionner to save all our packages in the filetree tree and then we `git commit/push
Re: [Pharo-dev] Fast way to load package form github
Hi Johan, thanks for the answer, this is perfect :) When reading the Metacello source, I didn't understand that you could, instead of the branch, use a tag or a commit ID as the version identifier. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Johan Brichau [jo...@inceptive.be] Envoyé : dimanche 27 avril 2014 11:22 À : Pharo Development List Objet : Re: [Pharo-dev] Fast way to load package form github On 26 Apr 2014, at 16:46, GOUBIER Thierry thierry.goub...@cea.fr wrote: That said, if you found a way to refer a specific commit via github://, I'd really like to know how :) In metacello, you can do it [1,2]: github:// github user / github project [ : version identifier ] [ / repository path ] Did I misunderstand your question? cheers Johan [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStartedWithGitHub.md [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScriptingAPI.md#github
Re: [Pharo-dev] Fast way to load package form github
Yuri, I think the best would be a github:// url in a configuration. Shortest is something like: Gofer new url: 'http://smalltalkhub.com/mc/Yuri/ProjectOfYuri/main/'; configurationOf: 'ProjectOfYuri'; loadStable (with the github:// url inside ConfigurationOfProjectOfYuri) Note that I have added back https access to github in gitfiletree, but, still, it implies OSProcess and git command line access (but no need to register on github.com) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk [yuriy.tymc...@me.com] Envoyé : samedi 26 avril 2014 09:34 À : Pharo Development List Objet : Re: [Pharo-dev] Fast way to load package form github Yes, but this requires user to clone the repository, this is not as fast as just Gofer with Monticello. I know that there is a support for github:// URIs in Metacello, but as far as I remember they don’t work in Gofer. Uko On 26 Apr 2014, at 09:25, Sven Van Caekenberghe s...@stfx.eu wrote: Gofer with a filetree:// URL as package ? Using the Monticello UI Tool you can just add a repo, select filetree as type and load any package. On 26 Apr 2014, at 09:21, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? I’m looking for some way to tell people: execute “this” and you will have my package in your image. Cheers Uko
Re: [Pharo-dev] Fast way to load package form github
Yuri, pure filetree will only allow you access to the latest version (HEAD) of the repository (and will only match if you load that precise version number as stored in the package metadata or if you don't specify a version number). You have to change the commit ID (and branch) via git clone, git checkout and git checkout -b before. github:// urls may be able to select a specific commit ID, but I don't know how. You can select the branch, however. Again, if you specify a version number for your package with a github:// url, the metadata of your package has to agree with you or it will refuse to load (you are able to see only the latest version of the package). gitfiletree:// urls allows you to select the branch and any version visible in the git history. Read-only gitfiletree:// urls reduce the git history to one commit, so all versions are listed as .1. (Note that gitfiletree:// urls with https are read-only). That said, if you found a way to refer a specific commit via github://, I'd really like to know how :) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk [yuriy.tymc...@me.com] Envoyé : samedi 26 avril 2014 12:11 À : Pharo Development List Objet : Re: [Pharo-dev] Fast way to load package form github Do you know how to specify versions with pure filetree? I know that I can specify commit SHA or branch in URL, but can I somehow redefine version for a version definition? Uko On 26 Apr 2014, at 11:06, GOUBIER Thierry thierry.goub...@cea.fr wrote: Yuri, I think the best would be a github:// url in a configuration. Shortest is something like: Gofer new url: 'http://smalltalkhub.com/mc/Yuri/ProjectOfYuri/main/'; configurationOf: 'ProjectOfYuri'; loadStable (with the github:// url inside ConfigurationOfProjectOfYuri) Note that I have added back https access to github in gitfiletree, but, still, it implies OSProcess and git command line access (but no need to register on github.com) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk [yuriy.tymc...@me.com] Envoyé : samedi 26 avril 2014 09:34 À : Pharo Development List Objet : Re: [Pharo-dev] Fast way to load package form github Yes, but this requires user to clone the repository, this is not as fast as just Gofer with Monticello. I know that there is a support for github:// URIs in Metacello, but as far as I remember they don’t work in Gofer. Uko On 26 Apr 2014, at 09:25, Sven Van Caekenberghe s...@stfx.eu wrote: Gofer with a filetree:// URL as package ? Using the Monticello UI Tool you can just add a repo, select filetree as type and load any package. On 26 Apr 2014, at 09:21, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? I’m looking for some way to tell people: execute “this” and you will have my package in your image. Cheers Uko
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
Nicolas, I was thinking about it and I ended up with this : If in repository A, I have packages B and C, as well as the C library named libY, in my branch dev-thierry, then if I merge package B from dev-thierry and master, then: - This is a merge for package B, - but, for git, this isn't a merge from the combination of package B, C and libY; this is a kind of cherry picking (or I'm not sure what it is :( ). I already have an idea of how it would be difficult to make Monticello / gitfiletree recognize that the MC merge is coming from two different branches of the git repo (and not from merging from git and a smalltalkhub repo), but even then, at the git level, making that a merge? It isn't; it's something else, an intermediate merge (or kind of). Now, what could work is something like : - git mergetool pharo And then a gui in pharo could: - let us resolve all conflicts the usual way for git users (aka meld) - translate all packages related conflicts into the right operations What do you think? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.n...@gmail.com] Envoyé : vendredi 25 avril 2014 19:44 À : Pharo Development List Objet : Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM 2014-04-25 17:38 GMT+02:00 GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr: Hi Nicolas, from what you describe (double merge: one in git, one in MC), I wonder if my decision to maintain compatibility between gitfiletree and FileTree by writing the metadata (version / methodProperties) in gitfiletree is a good thing? Thierry Very good question indeed. This is spoiling the efficiency of git for merging... I think that the answer is yes though, because not every one is using git (think Eliot's branch). Esteban is not publishing the MC packages back on SmalltalkHub for nothing. Those MC package would not be usable if they loosed their history, and I'm not sure that we are ready to loose that... Yet, resolving the (real code) merge conflicts in an external tool does not feel so cool to me, I'd like to specify git mergetool --pharo ;) Another way would be to not attempt a merge at all via git, it would be simpler to just pick the mc package somewhere, but I don't like it, we're loosing git traceability (and those nice github networks). Otherwise, if development was exclusively git driven, then we would be more comfortable with git tools. But still, we have the image which is a working copy, and not necessarily in sync with gitfiletree, so we have a more complex process than file based environments anyway : one more indirection. image - files - staged files - repo There is still one super-cool feature where git shines that we can use: jumping from one branch to another (modulo the image sync with files), the most usefull one IMO when we are mixing external platform files and Smalltalk code that require some sync. Nicolas
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
Hi Nicolas, from what you describe (double merge: one in git, one in MC), I wonder if my decision to maintain compatibility between gitfiletree and FileTree by writing the metadata (version / methodProperties) in gitfiletree is a good thing? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.n...@gmail.com] Envoyé : vendredi 25 avril 2014 15:46 À : Pharo Development List Objet : Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM 2014-04-25 11:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.commailto:esteba...@gmail.com: Hi Nicolas, I cannot approve your pull requests because there are conflicts (I suspects is all the same conflict). can you fix them? thanks, Esteban Hi Esteban, I don't think there is a single source code conflict... But of course, there is allways 1 conflict : the MC meta information mc/VMMaker-oscog.package/monticello.meta/version Since the branch was not forked from latest master, every other feature branch will rot as soon as you integrate the first one. That's the major limitation of gitfiletree. The way I found to workaround this is to : git checkout master start an image in interactive mode, make sure to have current version from gitfiletree loaded git fetch someRepo someBranch git checkout someBranch From the image, open git file tree and copy modifiedPackage in local MC package-cache git checkout master git merge someBranch git mergetool answer remote/local as you like for .meta/version and say [y] it's fixed (you'll overwrite it soon after) From the image MC merge modifiedPackage copy from the package-cache Republish the merged package in gitfiletree git commit -a -m Merge pull request #... (fix someBranch) That's a bit heavier than a pure MC workflow, but it's bearable IMO... Tell me if this sounds clear enough. Another possibility is to do the exact mirror of this operation : merge master branch in each someBranch. But I don't think it's viable : 1) If I have 10 branches, and don't know in which order you want to integrate, then I'll have to do it 10+9+8+... times - that's 45 times this operation 2) If I know the order, I'll do that job in a single someBranch, it is exactly the mirror of above operation : merge master into someBranch rather than someBranch into master. But then it's both fragile (it can rot at any time if you decide to interleave another fix), and it is against the spirit of git : the feature branch should carry the minimum of changes IMO. The only advantage of this approach is to reduce the bottleneck effect by reducing the work performed by the integrator, especially if you are alone to cope with this burden... Unfortunately I'm out of time right now. I wanted to blog about it, but blogging is taking time... Hope my explanations help. Cheers
Re: [Pharo-dev] OSProcess repo?
Yes, it is. OSProcess and CommandShell. All Pharo specific changes are merged into the common code base there. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Johan Brichau [jo...@inceptive.be] Envoyé : samedi 19 avril 2014 09:46 À : Pharo Development List Objet : [Pharo-dev] OSProcess repo? Is the OSProcess repository on squeaksource still the master reference repository for that project? Johan
Re: [Pharo-dev] why is MorphFocusCtrlNavigation registered in all morphs?
Hi Doru, when I moved the focus navigation to Keymapping, registration was done locally, since the code to navigate is local to the morph (and there was no mecanism for global shortcuts yet). But still in that case it is just about registering the category, not creating it (i.e. global table, local registration), no? Crtl+Tab not working on Mac could be a different issue. The vm not generating the event? Note that Spec usually overrides that navigation, and moving this to a global shortcut would not allow Spec to overrides it anymore. And that would be problematic. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Tudor Girba [tu...@tudorgirba.com] Envoyé : vendredi 18 avril 2014 22:27 À : Discusses Development of Pharo Objet : [Pharo-dev] why is MorphFocusCtrlNavigation registered in all morphs? Hi, I am working on tool support for debugging keymapping related issues, and I just realized that MorphFocusCtrlNavigation (containing Ctrl+Tab and Shift+Ctrl+Tab) appears to be registered in all morphs. Is this a bug or is intended? I think this is a prime candidate for a global shortcut. Or? What is worse, Ctrl+Tab does not seem to work at least on Mac. Doru -- www.tudorgirba.comhttp://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] 13102
Ok, my position: 1) local shortcut should not override global shortcuts, but see 2) 2) global shortcuts should be as restricted as they are in a normal desktop (see your OS HIG documentation for that) - Suggestion: create a namespace with a prefix for application triggering global shortcuts, where each app can add his (x ctrl + w for opening a Workspace, x ctrl + etc...) 4) Warn of overlapping when adding shortcuts. 3) Remove that set :) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Guillermo Polito [guillermopol...@gmail.com] Envoyé : mercredi 16 avril 2014 11:46 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 Bump :) On Mon, Apr 14, 2014 at 4:30 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: Hi! Sorry for the late response... I'm covered with stuff to do lately. To my understanding we are mixing these different issues: 1) whether the global shortcuts should have or not priority over local shortcuts. To my understanding that's what operating systems do. You cannot override alt+tab and if you intend, it will just not work. If any application can override alt+tab, the system will feel inconsistent for the users. So global shortcuts have priority with this intend: Not let the tools mess with what Pharo has decided the global shortcuts should be. So, any points against or in favor to this? 2) which are the actions that should be available globally though a shortcut. This deserves for sure a different discussion than 1). Should we put all tools in there? The more we put, the more difficult is to put shortcuts locally in tools. In any case I think this is orthogonal to 1). 3) are the shortcuts we chose for the tools the right ones? I think the prefixed shortcuts chosen for the tools were thought as a kind of namespace for the shortcuts. Again, I find this orthogonal to 1). Do we open a new thread to discuss this? I think it's important to discuss what is available globally through a shortcut and what's not, and what such shortcuts should be. The only thing I need is: - Spotlight - Finder? - Workspace? - The main menu? The browser I don't really need it because I use spotlight. The finder can cover almost all stuff I search normally trough a workspace :). Even if this is not for Pharo3, it's important for Pharo4.
Re: [Pharo-dev] 13102
Hi Esteban, Marcus, in that particular case, I would propose the following simple fix which could solve the first impression. - Document global shortcuts, ensure that they are single key. - Document an overload (or not) effect when your app redefines a global shortcut. - Change a bit Keymapping so that single key shortcuts match first. This would solve the immediate problem and let us time to consider a more complex solution for Pharo 4. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.com] Envoyé : lundi 14 avril 2014 14:39 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 On 14 Apr 2014, at 14:28, Marcus Denker marcus.den...@inria.fr wrote: On 13 Apr 2014, at 11:26, Stephan Eggermont step...@stack.nl wrote: Hi Marcus, I think 13102 is a showstopper. Can’t explain this to new users. sorry, but I have to disagree… this is an important problem, I agree. But fix that will need (AFAIK) a lot of work and probably a revamp of the keybindings in system. Also… this problem was (again, AFAIK) present since pharo2 and we have been able to continue working even with that annoyance. We will always have problems to fix. And we still have many *really important* problem to fix. But if we do not release even with some bugs, we will never release. Show stopper” IMO, is a bug that prevents the system to continue working. Explain to students an annoyance in the system is bad, but not show stopper. so… I’m with Marcus. We can delay this fix. But I also believe this kind of problems are a “shoot in the foot”, not good for attract newcomers. That’s why we are suggesting that Pharo4 should centred on the tooling: we have the feeling that out tools are one (or several) step(s) behind the power that pharo has. Esteban The question is do we hold up the release for it? That is: is not releasing better than releasing with this? How long do we stop releasing, considering that we will not find anyone to fix it? Marcus
Re: [Pharo-dev] 13102
Tudor, an implementation which randomly determines which shortcut will match is a bug to me, and one worthy of being solved before release. Why wouldn't Moose alone desactivate the global shortcuts if that seems the solution? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Tudor Girba [tu...@tudorgirba.com] Envoyé : lundi 14 avril 2014 15:15 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 Hi, Sorry for not replying before but I was offline. This issue is not to fix Keymapping at this point. The current solution was designed with intent to work in the current way. We can certainly discuss about fixing it, but the solution is not for Pharo 3. The current discussion is about disabling the global shortcuts for opening the Workspace and other tools. In the Moose image, we disable those shortcuts because with the current implementation of Keymapping having complicated global keybindings simply leads to problems (for example, we cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an excellent contribution that simplified a lot an important area. My suggestion is to remove the global mappings for Pharo 3.0, and then continue to work on getting Keymappings to an even better state. Doru On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Hi Esteban, Marcus, in that particular case, I would propose the following simple fix which could solve the first impression. - Document global shortcuts, ensure that they are single key. - Document an overload (or not) effect when your app redefines a global shortcut. - Change a bit Keymapping so that single key shortcuts match first. This would solve the immediate problem and let us time to consider a more complex solution for Pharo 4. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.commailto:esteba...@gmail.com] Envoyé : lundi 14 avril 2014 14:39 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 On 14 Apr 2014, at 14:28, Marcus Denker marcus.den...@inria.frmailto:marcus.den...@inria.fr wrote: On 13 Apr 2014, at 11:26, Stephan Eggermont step...@stack.nlmailto:step...@stack.nl wrote: Hi Marcus, I think 13102 is a showstopper. Can’t explain this to new users. sorry, but I have to disagree… this is an important problem, I agree. But fix that will need (AFAIK) a lot of work and probably a revamp of the keybindings in system. Also… this problem was (again, AFAIK) present since pharo2 and we have been able to continue working even with that annoyance. We will always have problems to fix. And we still have many *really important* problem to fix. But if we do not release even with some bugs, we will never release. Show stopper” IMO, is a bug that prevents the system to continue working. Explain to students an annoyance in the system is bad, but not show stopper. so… I’m with Marcus. We can delay this fix. But I also believe this kind of problems are a “shoot in the foot”, not good for attract newcomers. That’s why we are suggesting that Pharo4 should centred on the tooling: we have the feeling that out tools are one (or several) step(s) behind the power that pharo has. Esteban The question is do we hold up the release for it? That is: is not releasing better than releasing with this? How long do we stop releasing, considering that we will not find anyone to fix it? Marcus -- www.tudorgirba.comhttp://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] 13102
Ok, I have been carrying around a fix to that for what? More than a year, in my code. It's a very simple fix. It does require agreement on the fact this is a problem and that a solution is needed, that's all :) (i.e. I see two problems: 1) collision between exactly same shortcuts at global and local level, and 2) collision between single key shortcut and start of multikey shortcut. 1), I have, it's two lines in KMDispatcher. 2) is a bit more complex). Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Tudor Girba [tu...@tudorgirba.com] Envoyé : lundi 14 avril 2014 15:31 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 Hi, I agree that the behavior is not ideal, but it only occurs when you have collisions. And of course it would be great to have everything working perfectly, but at this point it is more important to release. That is why, in my book, it is more important to reduce the impact (fast) than it is to solve it properly (slow). The problem was noticed in few cases. I for one only noticed it after the global shortcuts were introduced in the image. Hence, it is very likely to achieve a good enough state with little effort by removing the shortcuts. Of course, if someone else does have a better solution, he can propose it, but it has to be concrete and doubled by the effort that comes with developing and testing it :) Doru On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Tudor, an implementation which randomly determines which shortcut will match is a bug to me, and one worthy of being solved before release. Why wouldn't Moose alone desactivate the global shortcuts if that seems the solution? Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de Tudor Girba [tu...@tudorgirba.commailto:tu...@tudorgirba.com] Envoyé : lundi 14 avril 2014 15:15 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 Hi, Sorry for not replying before but I was offline. This issue is not to fix Keymapping at this point. The current solution was designed with intent to work in the current way. We can certainly discuss about fixing it, but the solution is not for Pharo 3. The current discussion is about disabling the global shortcuts for opening the Workspace and other tools. In the Moose image, we disable those shortcuts because with the current implementation of Keymapping having complicated global keybindings simply leads to problems (for example, we cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an excellent contribution that simplified a lot an important area. My suggestion is to remove the global mappings for Pharo 3.0, and then continue to work on getting Keymappings to an even better state. Doru On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry thierry.goub...@cea.frmailto:thierry.goub...@cea.fr wrote: Hi Esteban, Marcus, in that particular case, I would propose the following simple fix which could solve the first impression. - Document global shortcuts, ensure that they are single key. - Document an overload (or not) effect when your app redefines a global shortcut. - Change a bit Keymapping so that single key shortcuts match first. This would solve the immediate problem and let us time to consider a more complex solution for Pharo 4. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.orgmailto:pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.commailto:esteba...@gmail.com] Envoyé : lundi 14 avril 2014 14:39 À : Pharo Development List Objet : Re: [Pharo-dev] 13102 On 14 Apr 2014, at 14:28, Marcus Denker marcus.den...@inria.frmailto:marcus.den...@inria.fr wrote: On 13 Apr 2014, at 11:26, Stephan Eggermont step...@stack.nlmailto:step...@stack.nl wrote: Hi Marcus, I think 13102 is a showstopper. Can’t explain this to new users. sorry, but I have to disagree… this is an important problem, I agree. But fix that will need (AFAIK) a lot of work and probably a revamp of the keybindings in system. Also… this problem was (again, AFAIK) present since pharo2 and we have been able to continue working even with that annoyance. We will always have problems to fix. And we still have many *really important* problem to fix. But if we do not release even with some bugs, we will never release. Show stopper” IMO, is a bug that prevents the system to continue working. Explain to students an annoyance in the system is bad, but not show stopper. so… I’m with Marcus. We can delay this fix. But I also believe this kind of problems are a “shoot in the foot”, not good for attract newcomers. That’s why we are suggesting that Pharo4 should centred on the tooling: we have the feeling that out tools are one (or several) step(s) behind the power that pharo
Re: [Pharo-dev] Projects trapped on Github?
Hi Sean, normally, a github hosted project should provide a configuration either using github:// urls (which is in Pharo 3) or a configuration which has an ensure gitfiletree (so as to ensure that OSProcess and all are loaded before activating the configuration). First case is ConfigurationOfSmaCC in MetaRepoForPharo30, second case is ConfigurationOfAltBrowser in MetaRepoForPharo30. You can also ask for a git clone to be made beforehand, but that doesn't seems very successfull if the github hosted project is a dependency of the one you are loading. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sean P. DeNigris [s...@clipperadams.com] Envoyé : jeudi 10 avril 2014 05:05 À : pharo-dev@lists.pharo.org Objet : [Pharo-dev] Projects trapped on Github? Last week, we were trying to load pharo-webdoc (https://github.com/camillobruni/pharo-webdoc) from github to fix a bug. We ran into a problem that I will attempt to recreate from memory... a configuration needed to load a dependent project from github (since it was moved there from sthub iirc), but we couldn't do that because gitfiletree is not loaded in Pharo 3.0 by default because it depends on OSProcess. Does that sound like a known problem and is there a solution? Sorry to be so vague, but I was a bit shocked that we hit a dead end, since it seems that people are using git/github successfully. - Cheers, Sean -- View this message in context: http://forum.world.st/Projects-trapped-on-Github-tp4753786.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Package tags for extensions
Hi Esteban, Yuri, It's really nice to hide extensions as objects and not anymore as protocols. I have been working with that for more than a year now, and it's very nice not to have to write anymore *Name-Of-Package to create extensions. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban Lorenzano [esteba...@gmail.com] Envoyé : lundi 7 avril 2014 13:21 À : Pharo Development List Objet : Re: [Pharo-dev] Package tags for extensions one of the things we need to continue improving is protocols… now they are objects (before they were just strings), but extensions are still name matching conventions, and they should be also objects (like ExtensionProtocol) or something like that. but well… future stuff. Esteban On 07 Apr 2014, at 05:54, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi guys, Now we have tags for packages in Pharo 3, and it’s very cool. So if I select a tag ‘A’ in ‘MyPackage’ I will see all classes from category ‘MyPackage-A’. On the other hand if I’m extending another class with a protocol ‘*MyPackage-B’ I can’t see that class under the ‘B’ tag. Is this some kind of issue or it’s still a work in progress. Cheers. Uko
[Pharo-dev] Syntax Visualisation in the C# infrastructure
It seems that Microsoft has opened interesting parts of the C# compilation infrastructure, including syntax visualisation. http://roslyn.codeplex.com/wikipage?title=Syntax%20VisualizerreferringTitle=Home Ideas for Opal+Roassal2 ? 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] [Inspiration] Toward a better programming
Le 02/04/2014 22:51, Pharo4Stef a écrit : On 02 Apr 2014, at 13:31, Goubier Thierry thierry.goub...@cea.fr wrote: Le 02/04/2014 08:12, Tudor Girba a écrit : The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable. I see two barriers in the current Pharo to be able to reach that: - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to this is the way Nautilus does it, and no worry about changing it, Nautilus developpers are the same guy which ends up being very painful for someone outside that core group. I agree but who is writing doc beside me and sven? Not me :( Do you think that this is easy to write doc on something that you did not write. For Rpackage this is not that complex and you do not want to document the part that glue inside announcement and other. Well, yes and no. Any exposure to RPackage and you understand that you have to know about the glue. Trust me on that one ;) - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that conservatism in GUI. You cannot clean Morphic without removing experimental stuff. Once we will have a better morphic then we can be more adventurous. You probably did not spend enough time in morphic if you do not think that I’m right. :) Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that. Morphic itself is still (how many years since Self we are at now?) experimental. Big chunks of what made Morphic what it is are gone from Pharo. Even Pharo by example requires loading extensions. And in normal, business GUI stuff, Morphic capabilities are underused and get in the way. Now, there is Alain Plantec work. That will be interesting... 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] quote author=Sean P. DeNigris I think the tree nodes should be based on name-matching and not only per-package. For example: /quote In 4.0, let's query the Metacello configuratio
Le 03/04/2014 01:03, Igor Stasenko a écrit : cool +1 but that means we need a resident configs in image, which IMO is a plus. right now we don't. You can cope with a pre-existing classification for stuff already in the image, and configs for the additional stuff. Works. A touch is the ability to customize and save your classification. It would be very nice to see it working from one of the unloaded images (with configs to reload all the additional stuff). 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] Strange left-over in 30804
Ok, doing: (RPackageOrganizer default packageNamed: #'FloatArray-dot.st') unregister removes it. Thierry Le 27/03/2014 16:42, Marcus Denker a écrit : On 27 Mar 2014, at 16:31, Goubier Thierry thierry.goub...@cea.fr wrote: Hi All, has anybody noticed a strange new RPackage in 30804 named: FloatArray-dot.st ? I can't miss it with AltBrowser, and it's visible in Nautilus, but not in Browser. Strange, I just filed in that .st file when integrating. This should normally not create any package…. Marcus -- 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] [Inspiration] Toward a better programming
Le 02/04/2014 08:12, Tudor Girba a écrit : The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable. I see two barriers in the current Pharo to be able to reach that: - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to this is the way Nautilus does it, and no worry about changing it, Nautilus developpers are the same guy which ends up being very painful for someone outside that core group. - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that conservatism in GUI. Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals. I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much. For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;) There is so much to build. Let's be bold. +100 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] [Inspiration] Toward a better programming
Le 02/04/2014 13:58, p...@highoctane.be a écrit : Yes, RB would immensely benefit from some doc. +100. SmaCC makes use of RB, and there are a few things I'd need help with. See other thread on that. I've seen it. Try to do a RB environment selecting what you want and loop on all classes over it, renaming them one by one. I will start something pnce I get it wotking for my case. By the way, is there any news about Gisela Decuzzi work on a GUI for RB? 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] quote author=Sean P. DeNigris I think the tree nodes should be based on name-matching and not only per-package. For example: /quote In 4.0, let's query the Metacello configuratio
Hi Sean, I got a simple version of your configuration querying idea working. Regards, Thierry Le 24/01/2014 03:11, Sean DeNigris a écrit : I think the tree nodes should be based on name-matching and not only per-package I should've appended: as a compromise for the time being... In 4.0, imagine this killer combination: - Declare high-level logical categories a la AltBrowser (e.g. UI). This really nails the 7+/-2 sweet spot - For external projects, query the Metacello configurations to find out exactly what packages belong to which project and group accordingly; -- 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] Don't do this X(
Le 02/04/2014 15:59, Sebastian Sastre a écrit : Advice: Never save a “big package using monticello (lets say ~2000 classes) and then save the image Why? Because while you don’t have feedback of saving progress* it will be doing something on background (forked save?) and if for any reason you are tempted to do an image save or save and quit, it will save in a state that will prevent the image from opening again You have no option but to go to your previous image version or something of the kind :( *saving a package actually provides /some/ feedback on progress but when the progress bar finishes, the saving doesn’t actually finish and it still have something going on, so you get silence” (no-feedback) until you get the little monticello window with your new package version I'll profile that to see what's happening. 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] Don't do this X(
Le 02/04/2014 16:33, p...@highoctane.be a écrit : On Wed, Apr 2, 2014 at 4:06 PM, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 02/04/2014 15:59, Sebastian Sastre a écrit : Advice: Never save a “big package using monticello (lets say ~2000 classes) and then save the image Why? Because while you don’t have feedback of saving progress* it will be doing something on background (forked save?) and if for any reason you are tempted to do an image save or save and quit, it will save in a state that will prevent the image from opening again You have no option but to go to your previous image version or something of the kind :( *saving a package actually provides /some/ feedback on progress but when the progress bar finishes, the saving doesn’t actually finish and it still have something going on, so you get silence” (no-feedback) until you get the little monticello window with your new package version Does this mean that once we get the little window, we are safe? I am saving a package with containing a lot of Pack-XXX Pack-YYY Pack-ZZZ in a 2.0 image as a single Pack-PhilippeBack-nn.mcz thing. What is the moves to make to be safe? I already got my image locked at some points in a way that resembles what you describe. I'm looking at the code and I don't understand everything, but, yes, it seems there are a few ways to keep doing things while saving the package (and maybe locking up things). MCWorkingCopyBrowserbasicSaveVersionIn: basicSaveVersionIn: aRepository | newVersion waitForVersion | waitForVersion := Semaphore new. UIManager default defer: [ newVersion := workingCopy newVersionIn: aRepository. waitForVersion signal ]. Processor activeProcess == UIManager default uiProcess ifFalse: [ waitForVersion wait ]. newVersion ifNil: [ ^ self ]. Cursor wait showWhile: [[ self storeVersion: newVersion in: aRepository; storeDependencies: newVersion in: aRepository.] ensure: [ (MCVersionInspector new version: newVersion) show ]] It seems asynchronous, but I'm unsure of what it is doing. Progress bar is only displayed when doing newVersionIn:, but this is sent to the UIManager. And this is done in a fork (see saveVersion), so it's probably allways possible to interrupt the thing half-way (or save). Anybody to explain what is the objective when writing code like that? Thierry Phil I'll profile that to see what's happening. 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 tel:%2B33%20%280%29%201%2069%2008%2032%2092 / 83 95 -- 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] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
Cool, you're giving me hope that one day I'll switch to the Pharo3 theme :) Thierry Le 26/03/2014 11:58, Philippe Back a écrit : And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil *From:*Philippe Back [mailto:p...@highoctane.be] *Sent:* mercredi 26 mars 2014 10:51 *To:* 'pharo-dev@lists.pharo.org' *Subject:* Fixing inconsistent buttons look in PharoUI I’ve made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border-PhilippeBack.1 Phil http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- 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] Use Spotlight to quickly evaluate and inspect short expressions
What about doing it that way? Shift-enter1500*1.25Alt-i ? Like that, you keep the same shortcut and behavior everywhere, and you don't have to answer questions such as: Why typing :42enter doesn't work in a workspace? Thierry Le 25/03/2014 14:30, Sven Van Caekenberghe a écrit : I had this idea: https://pharo.fogbugz.com/f/cases/13128/Use-Spotlight-to-quickly-evaluate-and-inspect-short-expressions now you can do shift-Enter:42Enter to inspect the magic number 42 shift-Enter:1500*1.25Enter to quickly compute your 25% raise shift-Enter:Float piEnter to see how many decimals you still remember shift-Enter:ZnClient new get: 'http://zn.stfx.eu/zn/small.html'Enter and so on. The interaction with the completion menu is not 100% perfect, but pressing Space at the end before Enter solves that. Feedback ? Sven PS: I know that many Smalltalk greybeards type everywhere to the same effect, and that is cool to, but it leaves around dirty windows. Opening a workspace for a single expression often is overkill. This feature is totally keyboard driven and very clean. PS2: Yes it resembles Emacs' M-: (evaluate-expression), but Pharo is much cooler, right ;-) -- 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] FileSystem-Git status update 2
Le 19/03/2014 08:46, Max Leske a écrit : - I moved all the code to the FileSystemGitDev team on Smalltalkhub - we now have a working LibGit2 build (tests fail but that will be fixed in the coming days) - we got simple fetch working yesterday (yay!) - we (which means Stefan) started rewriting our tests with SUnit, moving away from Phexample (for several reasons) Today’s program: - migrate more tests - fix initialization and setup issues - try to perform a complete fetch + merge (without conflicts) - implement clone - try to get push working Have a great day! With such news, it is a great day :) Thanks for the effort, 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] WhatsUp from: 2014-03-17 until: 2014-03-31
Le 17/03/2014 22:49, Max Leske a écrit : - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION - annoy Esteban some more with libgit2 - get other people to work on LibGit This is the project we should look at? http://smalltalkhub.com/#!/~StefanMarr/LibGit/commits - move the repository to the FileSystem-Git-Dev team - get fetch / pull working - try to get the LibGit build working with Moose 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] Looking for a project reloader tool
Le 18/03/2014 15:10, Ben Coman a écrit : Maybe the Configuration Browser could tag configurations to be loaded in every new image. If the Startup scripts set a shared global package cache directory [1], that information could be stored there. Hum, then this means that if you work on multiple projects in separate images, all of them will load the same configurations? btw, How common is it to have a shared global package cache directory. Should that be default? What would detract from that? I don't know but it seems that recent Pharo3 build have a tendency to create (or to share) a common cache. Or does that happens when you export settings? 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] FileSystem-Git status update
Le 14/03/2014 11:11, Max Leske a écrit : Hi everyone I promised to keep you posted about the progress, so here goes: - Esteban and I worked together yesterday and we got callbacks working - I will now do some cleanup so that its actually possible to work on libgit2 (some bindings have changed between versions 0.18 and 0.20 and I need to find out which) - Esteban and I will sit together again on Monday and prepare work for others / implement the object model on top of libgit2. I hope that we can separate tasks so that multiple people can work in parallel In my opinion we should be able to create local repositories, perform commits, switch branches and do checkouts by tuesday next week. Optimistically, fetch and push should also work by the end of the week. But that’s really just conjecture and I’ll keep you all posted. Just a reminder: at the moment we are working to get Git running with NativeBoost *at all*. Plans for abstraction, Monticello - Git, Github etc. should certainly be discussed, but don’t expect those things to be there at the end of next week. Thanks for the update. I'll be in at the object model stage... And with uses cases. 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] Making Git and Pharo More Accessible
Le 12/03/2014 08:12, Max Leske a écrit : Hi Sean I’m in Lille at the moment where we’ve set up a plan of action for Git yesterday. I will be working with the guys from RMoD for the next two weeks and hope that by the end we can unify all the different workflows that currently exist to something that we can all more or less agree on. I don’t think it makes sense to set up a CI job for only two weeks, so you’ll have to be patient a little longer (unless someone else feels that it *does* make sense and creates a job nonetheless :) ). Hi Max, Please keep us posted about the progress so that we're able to coordinate and integrate. For now, all options apart from mine are visible to me as: 'will be ready in the future' (but that was also the case more than a year ago). 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] Git MS Windows path length restriction
Thanks Ben for that info about long file names in Windows, of importance when discussing file formats for smalltalk packages and git. Just that your link only describe how to get a significant diff display when dealing with zip files stored as-is inside a Git repository, not automagically zipping and unzipping in and out of git storage. Too bad :(. However, searching around that info points out that git will do a binary delta on a versionned zip file [1], which means storing zip files inside git is not that bad. [1] http://stackoverflow.com/questions/9973151/does-git-smartly-handle-a-zip-archive-in-which-only-one-of-the-files-changes-reg Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de b...@openinworld.com [b...@openinworld.com] Envoyé : dimanche 9 mars 2014 16:43 À : metace...@googlegroups.com; Discusses Development of Pharo; Squeak Virtual Machine Development Discussion Objet : [Pharo-dev] Git MS Windows path length restriction I started looking into Pharo Case 13030 Many tests failing in MetacelloValidation Job on Jenkins and even before getting into it, I've hit a stumbling block on Windows 7 with its pathName length restriction of 259 characters. I managed to isolate the problem as follows... MetacelloPlatform current downloadFile: 'https://github.com/dalehenrich/metacello-work/zipball/master' to: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip := ZipArchive new readFrom: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip extractAllTo: 'C:\tmp\unzippedByPharo' asFileReference. which produces the error FileDoesNotExist: File @ C:\tmp\unzippedByPharo\dalehenrich-metacello-work-96e07b1\repository\Metacello-TestsMCB.package\MetacelloScriptingStandardTestHarness.class\instance\validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st where the #size of that filename is 354 characters. Trying to drill into github-dalehenrichmetacelloworkmaster.zip from Windows Explorer produces error The Compresses (zipped) file is invalid. However using 7Zip [1] I can extract the file so that _all_ files appear in the hierarchy, so it seems 259 is not a hard limit, and indeed that limit is imposed by the Windows Shell, since NTFS can have a path length of ~32K [2]. Operation of 7Zip was verified by: * From Pharo: zip members size -- 6007 * For cmd.exe:dir /b /s dir.txt Open dir.txt into Notepad++ -- 6007 (after dir.txt line removed) Also Windows Explorer Properties reports (5277 files + 730 folders) = 6007 [1] www.7-zip.org [2] http://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-windows-xp-and-windows-vista Now presuming its reasonable for the working directory to have 30 characters, using... histogram := (zip members collect: [ :member | | mySize | mySize := member fileName size. (mySize =230) ifTrue: [Transcript crShow: mySize printString , '--' , member fileName printString ]. mySize. ]) asBag. produces... 306--'dalehenrich-metacello-work-96e07b1/repository/Metacello-TestsMCB.package/MetacelloScriptingStandardTestHarness.class/instance/validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st' 252--'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/createBaseline.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 257--'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyBaselineVersionIn.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 259--'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyVersion.section.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 262--'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/addSection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' 265--'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st'
Re: [Pharo-dev] Support for git in Pharo
Le 06/03/2014 17:30, Max Leske a écrit : That is only partly true: - packs will be generated when objects are transferred over the network (this may be partial packs) - packs can be force generated by using ‘git gc’ - packs will be periodically created / updated to reduce size on disk Are you free, when fetching a git repository, to decide whether to pack or not or is the source repository in charge of that? Past a certain point, you can expect all/most of your small files (and small deltas) to be packed, no? But: the main storage form (and the fastest for access) are loose objects (i.e. single files) But you have to support both storage form to be able to read a git repository. Just for completeness :) You known certainly more about that than I do :) 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] Support for git in Pharo
Le 06/03/2014 23:01, Max Leske a écrit : On 06.03.2014, at 22:14, Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com wrote: the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk. But why do you need command-line diff tools? We don’t. Diffing has nothing to do with this (or only little). But if a method has its own file, then the hash of that method will be stable as long as it is unchanged, regardless of the number of commits it is referenced by. This makes it very easy to identify the changes that have been made to a particular method. How these changes are *visualized* is a different matter (and I would like to have a nice GUI for that too). I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. 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] Support for git in Pharo
Le 07/03/2014 09:25, Max Leske a écrit : I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. Is it on Smalltalkhub? I’d like to take a look if you let me. It's on github :) https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.package/AltVersionBrowser.class and the git interface lives inside gitfiletree, at: https://github.com/dalehenrich/filetree/blob/issue_124/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/instance/gitVersionsForDefinition.in..st Also available via ConfigurationOfGitFileTree. I'd be especially interested to know if, the way you're planning to do it, will allow to: - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. 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] Support for git in Pharo
Le 07/03/2014 09:52, Max Leske a écrit : - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. Yes, that is something that should be possible. To be honest, those thoughts are a bit too far in the future at the moment. First, I want to have Git plumbing running, then I’ll see about the rest. That was certainly the advantage of my solution: easy plumbing, left me the time to: use it, and plan good uses of it. 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] Metacello-github + filetree-git async
Le 06/03/2014 09:32, Yuriy Tymchuk a écrit : Hi guys. My workflow is like this: I load a configuration on CI with github:// magic in metacello conf. Then on local machine I add a local gitfiletree repo to the project packages. The thing is that the last version if loaded, but gitfiletree repo is showing that second last is loaded. And yes, diffs with last one (not loaded by gitfiletree opinion) show no changes and diffs with second last (current one by gitfiletree opinion) show changes that were mede in last version. Say version .5 on CI, and gitfiletree is showing you only .1, .2, .3, and .4 , like that? Any clue what can be the problem? A few possibilities: a) A missing pull or push on the gitfiletree repository (one more commit on the central repository not seen locally, or the reverse) b) Incoherent versions between the 'version' metadata of the package and the git-extracted version metadata; but this would not show changes visible (unless combined with a), where it's possible for the older version to have a bigger version number. Ways to test: - When opening the repository on the local machine, is the Push button greyed out or not. If not, there are local changes not visible to the global repository. - Check that the top most commit visible in your local gitfiletree repository (git log on the command line) is the same as the one listed on github. 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] Metacello-github + filetree-git async
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 09:48, Goubier Thierry thierry.goub...@cea.fr wrote: Le 06/03/2014 09:32, Yuriy Tymchuk a écrit : Hi guys. My workflow is like this: I load a configuration on CI with github:// magic in metacello conf. Then on local machine I add a local gitfiletree repo to the project packages. The thing is that the last version if loaded, but gitfiletree repo is showing that second last is loaded. And yes, diffs with last one (not loaded by gitfiletree opinion) show no changes and diffs with second last (current one by gitfiletree opinion) show changes that were mede in last version. Say version .5 on CI, and gitfiletree is showing you only .1, .2, .3, and .4 , like that? I also see the .5 version, but it’s bold i.e. “not loaded. Are changes shown when you click on the .5 version in gitfiletree? on the .4 version in gitfiletree as well? Remember that github: and filetree: do not read versions in the same way as gitfiletree:; they are usually in sync, but may be desynchronized. 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] Metacello-github + filetree-git async
Ok, I see now. I don't think this can be avoided; it's inherent in the way both github: and gitfiletree: understand repositories. The explanation will go a bit into git and gitfiletree design and FileTree; in the mean time, you may either change a bit the config to clean that (force a load of the last version from gitfiletree, since they are effectively the same) or don't bother, gitfiletree: when saving a new package version will clear that (sort of). The explanation is a bit long. version metadata for FileTree (the format used to write packages for git and others version control systems) is stored in a file under PackageName.package/monticello.meta/versions. This file is often a problem, at least under git: it's a magnet for git merge conflicts. It is also slow to parse[1], especially if you want to know all the versions of the package stored by the git repository (as gitfiletree does), and sometimes is corrupted (git conflicts). So, in the design of gitfiletree:, I decided that I would not read this file, but, instead, recreate its contents from the git log history[2]. This is what you see when you open a gitfiletree: repository. And particularly, versions UUIDs are generated from the git commit ID[3]. Now, when saving a package in a gitfiletree: repository, the versions file will be written, with an UUID generated for it... except that, on rereading, gitfiletree will generate another UUID from the git commitID (which is known, of course, after committing the versions file :() For example, in gitfiletree:, Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 Whereas the file Renraku.package/monticello.meta/versions has Renraku-YuriyTymchuk.4 with id '60141668-a324-4c9d-8938-db82ed2e57de' Older versions are regenerated from the git data, and this is why, in that file, you see Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) [1] Yes, and I tried long and hard to accelerate reading and parsing 200 times the versions file for a moderatly complex project, including the fact that it's easy to find a corrupted versions file in a git repo. Generating ended up a lot cleaner, as well as garanteeing than the history would be browsable. [2] And filtering the git history to keep only the commits significant for the package, and nothing else. [3] Constant mapping: a given git commitID will allways generate the same UUID. Le 06/03/2014 11:41, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 11:35, Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@me.com wrote: On 06 Mar 2014, at 11:17, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 11:09, Yuriy Tymchuk a écrit : Sent from my iPhone On 06 Mar 2014, at 10:28, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 10:08, Yuriy Tymchuk a écrit : On 06 Mar 2014, at 09:48, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Le 06/03/2014 09:32, Yuriy Tymchuk a écrit : Hi guys. My workflow is like this: I load a configuration on CI with github:// magic in metacello conf. Then on local machine I add a local gitfiletree repo to the project packages. The thing is that the last version if loaded, but gitfiletree repo is showing that second last is loaded. And yes, diffs with last one (not loaded by gitfiletree opinion) show no changes and diffs with second last (current one by gitfiletree opinion) show changes that were mede in last version. Say version .5 on CI, and gitfiletree is showing you only .1, .2, .3, and .4 , like that? I also see the .5 version, but it’s bold i.e. “not loaded. Are changes shown when you click on the .5 version in gitfiletree? on the .4 version in gitfiletree as well? Version 5 does not have changes with working copy. While version 4 has. So from my point of view it seams like version 5 is loaded but gitfiletree thinks that only version 4 is loaded. Understood. Is it a problem if I have a look at the image or at the git repository? When I look in the monticello browser in the image. And with applies to the both packages I have in that repo 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 -- 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] Support for git in Pharo
Le 06/03/2014 13:59, Stephan Eggermont a écrit : How is git support for Pharo going to work? Because currently it takes extra effort. I noticed some Pharo users moving their code to github, making it less accessible. I know a few different ways to get git installed on a mac: (finkproject, brew, macports, xcode, git-osx-installer, git-scm.com) and they result in git not always being /usr/bin/git. Then there are the differences between system wide installs and installs for specific users, and the different OS versions. gitfiletree: does not depend on /usr/bin/git; it requires a git command somewhere on $PATH. 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] Support for git in Pharo
Le 06/03/2014 14:15, Max Leske a écrit : I’m working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a Git installation. I’ll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where we can start doing something with it. Yes, this is interesting. I've also considered bundling a static version of the git command line. For people interested, there is a Smalltalk-Git mailing list on google groups: https://groups.google.com/forum/?hl=de#!forum/smalltalk-git Thanks, I registered :) 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
