- Pharo-dev - lists.pharo.org

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

by stepharo

+ 1 Le 27/1/16 09:48, Denis Kudriashov a Ã©crit : > > 2016-01-27 3:06 GMT+01:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > It would be great for Pharo Launcher to be the default download, but > why can it not still be called "PharoLauncher.app". > > > +1

Jan. 27, 2016

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

by Damien Cassou

Ben Coman <btc(a)openinworld.com> writes: > 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. I disagree but I don't care enough to argue. If OS X users agree (and maybe the board as well), someone should make the change (that won't be me :-)). -- 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] gtdebugger debug actions buttons

by Blondeau Vincent

I agree with Christophe. Maybe put the buttons on the line under? Cheers, Vincent > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Christophe Demarey > EnvoyÃ© : mercredi 27 janvier 2016 09:07 > Ã : Pharo Development List > Objet : [Pharo-dev] gtdebugger debug actions buttons > > Hi, > > I find the new debugger quite but after using it a while, I figure out that the > placement of debug actions (into, over, etc.) buttons leads to make me > overuse the mouse and loose time. > With the spec debugger, buttons are huge and easily accessible . With > GTDebugger, there are at the top right of the window and you need to > move the mouse over the whole window to reach them. > I know there are shortcuts but I would like to see if we can find a better place > for these buttons (and maybe bigger buttons). > > Regards, > Christophe Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 27, 2016

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

by Denis Kudriashov

2016-01-27 3:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > It would be great for Pharo Launcher to be the default download, but > why can it not still be called "PharoLauncher.app". > +1

Jan. 27, 2016

gtdebugger debug actions buttons

by Christophe Demarey

Hi, I find the new debugger quite but after using it a while, I figure out that the placement of debug actions (into, over, etc.) buttons leads to make me overuse the mouse and loose time. With the spec debugger, buttons are huge and easily accessible . With GTDebugger, there are at the top right of the window and you need to move the mouse over the whole window to reach them. I know there are shortcuts but I would like to see if we can find a better place for these buttons (and maybe bigger buttons). Regards, Christophe

Jan. 27, 2016

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