January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Hi Dale, then a question: how does one query a baselineOf or a configOf to retrieve the current project state (i.e. packages) loaded in the image? Thierry 2016-01-27 4:11 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > I've been wondering no-one in the Pharo community has started building a > "Project Browser" to replace the "Package Browser" .... I've had a "project > browser" in tODE for several years now and you work with a manageble list > of Metacello projects like the following: > > [image: project list] > > instead of a giant list of packages like the following (only half of the > packages loaded in the image): > > [image: package list] > > Like a package browser, the project shows up as dirty whenever a package > in the project is dirtied and all of the operations `save`, `diff`, etc. > apply equally well to projects instead of packages .... with the added > bonus of performing the action on the the project itself instead of having > to view diffs on each dirty package or save each dirty package ... for the > git-based repos, a single git commit is performed after all of the dirty > packages are committed , thus allowing git to track the moves of methods > between packages and combining all of the changes for a unit of work in a > single commit ... > > Also, in the `project list`, the loaded version and blessing (1.0.5.4 > [release]) or SHA of the git commit and branch name (b674ad0 [master]) is > displayed: > > Gofer 1.0.5.4 [release] > Grease b674ad0 [master] > > ... and this is very useful information. Metacello provides an api for > this information and a project-based workflow is just much simpler to work > in than a package-based workflow... > > I'm willing to share code from tODE and Metacello if anyone is interested > ... and I think that a tool like this is really required to properly > support a git (or any other disk-based SCM) workflow ... > > Perhaps work is already underway, but whenever I see folks talking about > the funky Monticello Browser interface, I can't help thinking about the > fact that I haven't used an interface like that for several years now and > it's time for the tooling to move forward a bit more:) > > Dale > > > On 1/22/16 9:50 AM, Sean P. DeNigris wrote: > > Ben Coman wrote > > checkbox for displaying non-dirty packages - so we only display the > short list in the usual case. (??) > > Ah! That would be very helpful. Particularly annoying is when you commit one > of your project's dirty packages, the list auto-scrolls to the package's new > location among the non-dirty packages, and you have to manually scroll back > to the top of the package list to find your next dirty package. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Contributing-to-Pharo-tp4871604p4873422.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > >

Jan. 27, 2016

Re: [Pharo-dev] Contributing to Pharo

by Christophe Demarey

Hi Dale, Le 27 janv. 2016 Ã 04:11, Dale Henrichs a Ã©crit : > I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following: Of course, we have that in mind. We would love to have it but lack of time / manpower ... We are not happy with the current browser (Nautilus). We could have something really more powerful. It will come but we have other projects to achieve before ;) If someone comes with a better browser, we would love to set it as default. Cheers, Christophe

Jan. 27, 2016

Re: [Pharo-dev] Symbolic version management with Metacello) was: OSSubprocess use

by Dale Henrichs

On 1/23/16 8:59 AM, Stephan Eggermont wrote: > We want to use Metacello to manage smalltalk dependencies in a way > that results in working software using a minimum amount of manual > work. At the moment there are several ways in which Metacello is used, > some of which result in more work and instability than others. > > An inherent conflict in managing these dependencies is the level of > repeatability that is wanted and achievable, vs. the amount of manual > work needed. On the one hand we would like perfect repeatability. That > needs an exact description of the order in which specific versions of > packages were loaded in a specific image. In Metacello, we can achieve > this by making sure all package versions are fixed and the > dependencies are fixed to numeric versions. This is one of the reasons that I have pushed for the use of git ... with git ALL of the packages are committed together so a single commit SHA is sufficient to ensure "that all package versions are fixed" without regard to numeric versions - the packages that work together are committed together. The Metacello registry records the SHA of the commit that was loaded into an image so there is absolutely no ambiguity. Dependencies are recorded in a BaselineOf that is also committed with the packages, so the dependencies are "guaranteed" to be in sync with the package versions ... a single SHA is all that is needed to exactly duplicate the formula used to load a project into an image ... > > The problem with this is that that not necessarily results in working > software. There are several reasons for this: > - Metacello only manages the smalltalk level dependencies. It does not > take into account changes in the vm necessitating image-level changes > or operating system and library changes. There is no reason that project attirbutes should be restricted to only platform and platform versions .... the attribute list is generated by the running image, so a list of attributes that included additional information like vm type and version could be included and then it would only be necessary to use these new attributes in the baseline ... > - The image itself is not fully managed with Metacello (yet). Bug > fixes made after the creation of the Metacello version might be needed > for the software to work. Yes, this is a critical point ... > - Bugs might have been found and fixed in dependencies. > In the situation of a top-level configuration, i.e. one that no other > configuration depends on, this might be acceptable. Metacello > dependencies are defined one-directional. A configuration knows on > which configuration it depends, not which configurations depend on it. > Configurations that are published should therefore always be regarded > as possibly being used by others, and not only top-level. > > If we consider the situation where others (B) are depending on > configurations (A) that are written like this, then the situation gets > worse: > - B might need an update because it is affected by an issue that does > not affect A. > - B might need a different load ordering, e.g. need to only partially > load dependencies of A, then something itself and then the other > dependencies of A. > Nevertheless, sometimes we need near-perfect repeatability. For that, > a snapshot of all loaded packages provides a reasonable alternative to > a Metacello configuration version. ... and a list of project/sha/branch like the following: project list provides near-perfect repeatability on a project by project basis --- there are ways using existing Metacello features to ensure that the exact SHA associated with each of the projects will be used to the exclusion of all others ... > On the other hand the least amount of manual updates results from > always depending on #development or #stable versions of dependencies. > This results in the following problems: > - If the API of a dependency changes, the configuration might break > silently. > - Projects might be slow to promote versions from #bleedingEdge to > #development to #stable, resulting in a slow uptake of improvements. > For configurations of simple packages that have an API that is very > stable or only expands, depending on #stable can be appropriate. The historical problem with generic symbolic versions like #development and #stable has been that the semantics of the #stable version changes over time in the beginning it meant the version that was "stable on Pharo2.0", but when the same symbolic version to imply "stable on Pharo3.0", all was lost:)... > From a modularity point of view, a configuration should be specific on > the packages in its own span of control, and as generous as possible > in what it accepts from its dependencies. In that way a high cohesion > and low coupling is achieved. We can achieve that by defining symbolic > versions that reflect observable change in behaviour. If we make > changes that should not affect users of the configuration, we create a > new numeric version and update the symbolic version in place to use > this new version. By default we only depend on these symbolic versions. > You are basically describing the principles behind semantic versioning[1] and I've always been a fan of the symbolic version scheme that the Seaside project has been using (#release3, #release3.1, etc.), because it makes it possible to express a project dependency at the appropriate semantic version level... For git repositories, one can create a tag for a particular SHA ("specific on the packages in its own span of control") and then use "tag pattern matching"[2], to provide a reasonable approximation of symbolic versions with a "git" repo. ----- 4 years ago, I was very aware of the fragility of the ConfigurationOf ecosystem and at the time, was very glad to see that responsibility for the implementation for versions, branches and tags could be off-loaded onto a disk-based SCM - leaving Metacello to continue to specify package load order and external project dependencies... In the subsequent years, I have been adding features to Metacello that I found were needed to support a "git-based" workflow (primarily the lock command[3]).... I have also been working on building a Smalltalk development environment that embraces "git" from the ground up and I consider that I've learned quite a few important lessons in this area ... I am not going to say that tODE[4] should be ported to Pharo, but I will say that tODE _is_ a proof of concept that a git-based development environment for Smalltalk can be built that preserves image-based Smalltalk development while leveraging "git" as the SCM... I should note that tODE bridges the ConfigurationOf and BaselineOf worlds with support for both .... I have been "patiently waiting" for folks to come to accept/tolerate "git" and it seems that that time is getting close enough to begin trying to share the lessons that I've learned --- but I can't "push on a rope" --- Tool support is critical at this juncture and I am willing to share my experience (and code if desired) with the folks who will be building these next generation tools --- As I mentioned in another post, the focus for the tools should shift from being package-centric to being project-centric ... a "git" repository contains all of the artifacts associated with a project, and in the "tODE model" there is a one to one mapping between a project and a git repository. Of course there is more, but I will save that for sharing with folks who are curious and interested in learning from my mistakes and my successes:) Dale [1] http://semver.org [2] https://github.com/dalehenrich/metacello-work/issues/277#issuecomment-58970… [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… [4] https://github.com/dalehenrich/tode#tode-the-object-centric-development-env…

Jan. 27, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following: project list instead of a giant list of packages like the following (only half of the packages loaded in the image): package list Like a package browser, the project shows up as dirty whenever a package in the project is dirtied and all of the operations `save`, `diff`, etc. apply equally well to projects instead of packages .... with the added bonus of performing the action on the the project itself instead of having to view diffs on each dirty package or save each dirty package ... for the git-based repos, a single git commit is performed after all of the dirty packages are committed , thus allowing git to track the moves of methods between packages and combining all of the changes for a unit of work in a single commit ... Also, in the `project list`, the loaded version and blessing (1.0.5.4 [release]) or SHA of the git commit and branch name (b674ad0 [master]) is displayed: Gofer 1.0.5.4 [release] Grease b674ad0 [master] ... and this is very useful information. Metacello provides an api for this information and a project-based workflow is just much simpler to work in than a package-based workflow... I'm willing to share code from tODE and Metacello if anyone is interested ... and I think that a tool like this is really required to properly support a git (or any other disk-based SCM) workflow ... Perhaps work is already underway, but whenever I see folks talking about the funky Monticello Browser interface, I can't help thinking about the fact that I haven't used an interface like that for several years now and it's time for the tooling to move forward a bit more:) Dale On 1/22/16 9:50 AM, Sean P. DeNigris wrote: > Ben Coman wrote >> checkbox for displaying non-dirty packages - so we only display the >> short list in the usual case. (??) > Ah! That would be very helpful. Particularly annoying is when you commit one > of your project's dirty packages, the list auto-scrolls to the package's new > location among the non-dirty packages, and you have to manually scroll back > to the top of the package list to find your next dirty package. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Contributing-to-Pharo-tp4871604p4873422.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 27, 2016

Re: [Pharo-dev] "Pharo" Name Overload

by Ben Coman

On Wed, Jan 27, 2016 at 5:27 AM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > "Sean P. DeNigris" <sean(a)clipperadams.com> writes: > >> I now have three Pharo.app files on my Mac - Launcher, Spur, and non-Spur. It >> would be great if we can agree to call one thing Pharo, and add appropriate >> modifiers to the other two names. > > I'm not an OS X user, but I have the impression that .app is reserved > for graphical applications, one you can start with a double click. For > me, no Pharo VM is a graphical application and thus none deserve its > .app file in /Applications. > > On the contrary, what we currently call the Pharo Launcher is a > graphical application so it deserves a .app file. I called it just > Pharo.app because I didn't see any concurrence on the name and some in > the Pharo board would like the launcher to be the default Pharo download > (the one behind the big Download button on the website). It would be great for Pharo Launcher to be the default download, but why can it not still be called "PharoLauncher.app". It is still just an app on top of *real* Pharo and calling the launcher Pharo.app I believe presents a cognitive dissonance for a newcomer to understand the distinction. The launcher is used to start non-/more-than-Pharo applications like Moose, so to me the launcher application is more generic than just Pharo. Seeing a launcher is generically "a computer program that helps a user to locate and start other computer programs" [1] to me it makes sense to explicitly keep "Launcher" in the app name as the default download. [1] https://en.wikipedia.org/wiki/Comparison_of_desktop_application_launchers cheers -ben > > We could improve the situation by putting all Pharo VMs inside the Pharo > Launcher's .app file. Who volunteers? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Jan. 27, 2016

Re: [Pharo-dev] "Pharo" Name Overload

by Pierce Ng

On Tue, Jan 26, 2016 at 06:24:48PM +0000, Dimitris Chloupis wrote: > Why ? We did not have Pharo-stack.app and Pharo-cog.app and none complained I've also renamed Pharo to "Pharo Cog" or whatever as the case may be using Finder. Using Terminal rename Pharo.app to "Pharo Cog.app". Pierce

Jan. 26, 2016

Re: [Pharo-dev] "Pharo" Name Overload

by Pierce Ng

On Tue, Jan 26, 2016 at 06:56:00AM -0800, Sean P. DeNigris wrote: > I now have three Pharo.app files on my Mac - Launcher, Spur, and non-Spur. It > would be great if we can agree to call one thing Pharo, and add appropriate > modifiers to the other two names. Using more Linux than OSX these days coz my MB battery is crapping out but I recall in the days of compiling source from squeakvm.org and early Cog versions that the OSX app icon has a different colour depending on version - pastel pink and light blue for squeakvm versions and gold for Cog. Perhaps the same can be done now, or make the words like Launcher, Spur etc part of the icon. Pierce

Jan. 26, 2016

Re: [Pharo-dev] The shortcuts learnability is awesome, thank you!

by Dimitris Chloupis

gave it a try, i love it, it should become a default feature :) On Tue, Jan 26, 2016 at 11:54 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > oh super cool , thanks, my connection is down for days now and it takes > time for me to download things. Thats indeed very useful feature to have. > > On Mon, Jan 25, 2016 at 5:06 PM Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Grab very last image (as of today), evaluate this code: >> >> ShortcutReminder enabled: true. >> >> (or enable that via settings) >> >> And then simply start using the image, and you will see Growl-like popups >> on the bottom left reminding you the shortcut for the action you just did :) >> >> >> >> On Mon, Jan 25, 2016 at 11:52 AM, Dimitris Chloupis < >> kilon.alios(a)gmail.com> wrote: >> >>> Any more info about this, I was sick lately and I did not understand >>> what was that about . >>> >>> On Mon, Jan 25, 2016 at 2:45 PM Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> This is just to say a big thanks to all those that contributed to the >>>> new shortcut learnability. This is awesome. I love it. >>>> >>>> Bye, >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Jan. 26, 2016

Re: [Pharo-dev] Menus are broken in diff tools pane

by Nicolai Hess

2016-01-14 16:14 GMT+01:00 stepharo <stepharo(a)free.fr>: > Alain told me that he can help. > We should give him a list of problems. > There *IS* already a apretty long list at http://forum.world.st/fixing-our-tools-tp4864859.html and many many bug reports. > > Stef > > menus are broken almost everywhere: > > I thnk, responsible for these issues are only two changes for Rubric and > the Suggestions-Menu > > http://forum.world.st/fixing-our-tools-tp4864859.html > > > > > 2016-01-14 12:54 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> >> >> > >

Jan. 26, 2016

Re: [Pharo-dev] fixing our tools

by Nicolai Hess

2015-12-03 9:16 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > Yes, I think we really need to unify both the editor (get really rid of > the old one) and > the toolsâ¦ e.g. it is strange that all the changes we did for breakpoint > visuals now have > to be redone 3 times to get them in all toolsâ¦ > > I will have a look at these, many seem to be related to the > suggestions-menu. > I added a fix to 17385 <https://pharo.fogbugz.com/f/cases/17385/DiffMorph-menus-are-broken> DiffMorph menus are broken this will fix the menu in some, but not all tools. > > > On 03 Dec 2015, at 08:47, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > please take a look at this errors: > > > > (I don't want to open 20 bug entries, and I think those issues are > related > > to two changes for Suggestions menu and one problem on rubric (the > current menu builder > > does not work for all tools where rubric is used) > > So, maybe there are only 2 or 3 "real" issues. > > > > Help appreciate, especially for the rubric issue. Every time I tried to > fix one > > tool, there is at least one other tool with a broken menu. > > > > Open Nautilus on a method: > > (Morph>>#drawOn:) browse > > without any other interaction, right click on the code pane > > -> a menu appears with embedded "why you see this menu/debug" debug menu > > caused by empty selection interval > > as soon as you select once one method entry, the right click menu works > again. > > > > Open VersionBrowser (or any other tool (MC-changes / merge) with diff > morph > > right click in one of the diff code panes > > -> error contextFor: 'Not defined context for a RubEditingArea' > > > > Open Transcript > > right click > > -> error contextFor: 'Not defined context for a RubEditingArea' > > > > Open Finder > > right click in the lower code pane > > -> 'Not defined context for a RubEditingArea' > > > > Open ProcessBrowser > > right click in the lower code pane > > -> 'Not defined context for a RubEditingArea(808452096)' > > > > Open TimeProfiler > > select an entry from the time-"tree" > > right click in the code pane > > deprecation warning -> The method SmalltalkEditor > class>>smalltalkEditorMenuOn: has been deprecated. > > > > Open a basic inspector (EyeInspector) > > right click in the workspace pane > > -> EyeIntegerInspector(Object)>>doesNotUnderstand: #selectedMessage > > > > Open ChangesBrowser > > right click in the lower code pane (regardless whether you select a > changed class and method > > or not you'll get always) > > -> ChangeSorterApplication(Object)>>doesNotUnderstand: #selectedMessage > > > > Open CriticsBrowser > > right click on the code pane > > -> SingleCodeCriticResultList(Object)>>doesNotUnderstand: > #selectedMessage > > > > Open recover lost changes > > right click on the lower code pane > > -> ExternalChangesBrowser(Object)>>doesNotUnderstand: #selectedMessage > > > > The same in external browser > > ExternalBrowser(Object)>>doesNotUnderstand: #selectedMessage > > > > Open debugger > > select a inst var or context var > > right click in the var "value"-pane > > -> MorphicTextAdapter(Object)>>doesNotUnderstand: #acceptAllowed > > > > Open VersoinBrowser > > change from "Side-by-Side" to "Source" view > > right click in the code pane > > -> UndefinedObject(Object)>>doesNotUnderstand: #ast > > > > >

Jan. 26, 2016