- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nitpick: Launcher Colors

by Damien Cassou

"Sean P. DeNigris" <sean(a)clipperadams.com> writes: > I don't get the addition of alternating row colors to Launcher. As I > understand this, it's value is in a table-like situation where one wants to > track across the row in the same record. Since both panes have only one cell > per row, I don't get the purpose, and it looks really funky to me in the > dark theme. I don't care, if others agree, you can change it :-). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 28, 2016

Re: [Pharo-dev] Nitpick: Launcher Colors

by Esteban A. Maringolo

2016-01-28 16:20 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I don't get the addition of alternating row colors to Launcher. As I > understand this, it's value is in a table-like situation where one wants to > track across the row in the same record. Since both panes have only one cell > per row, I don't get the purpose, and it looks really funky to me in the > dark theme. I share the same appreciation. The stripes are unnecessary. Esteban A. Maringolo

Jan. 28, 2016

Nitpick: Launcher Colors

by Sean P. DeNigris

I don't get the addition of alternating row colors to Launcher. As I understand this, it's value is in a table-like situation where one wants to track across the row in the same record. Since both panes have only one cell per row, I don't get the purpose, and it looks really funky to me in the dark theme. My 2c. Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/Nitpick-Launcher-Colors-tp4874592.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/28/2016 12:34 AM, Sven Van Caekenberghe wrote: >> On 28 Jan 2016, at 09:23, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> I read too fast. >> But my comment is still true. >> We also want a new version browser. Monticello browser is too tied to ... Monticello. We would like a better approach for both git and monticello. > It is totally wrong to put Git and Monticello at the same level, they are related but different things. > > Monticello models our code and your changes to it. It also has a way of putting a package into a persistent representation that can be copied around. An MC server is nothing more than storage. > > Filetree is another way of doing that, using a different representation, but it still needs MC for the high level stuff. Git is versioned storage. And there is a conflict there, yes. > > But throwing away the MC code and changes model would leave you with file outs. You do not want to go there, really. Never, ever. > Sven, If you look at my presentation on "Practical Git for Smalltalk"[1] from 2012, I take pains to differentiate between the Monticello package model (definitions and snapshots) and the Monticello repository model (mcz files). Noone is proposing to throw away the Monticello package model (to my knowledge). So in these discussions about supporting git we are talking about a model where Filetree is still being used for Monticello packages on top of a git storage strata ... I have brought up the point about a "Metacello Project Browser" because both git-based and mcz-based projects can benefit from a higher level of management: - commit all dirty packages, then update and commit the ConfigurationOf for mcz-based projects, OR - save all dirty packages and perform a git commit for git-based projects - perform a diff on all dirty packages in a project ... - etc. Dale [1] http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git…

Jan. 28, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Dale Henrichs

On 01/27/2016 06:01 PM, Ben Coman wrote: > > > On Thu, Jan 28, 2016 at 9:41 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > > On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > The git repository is not tightly coupled to the image like > the changes file (you can delete a git repository without > impacting the functionality of an image), but if you are > making changes in the image, then you _are_ coupled to a > particular git commit identified by its SHA. > > Metacello will record the SHA of the git repository at the > time that packages are loaded from a git repository (to enable > this feature in Pharo, some methods need to be implemented in > the MetacelloPlatform for Pharo) and this information is > stored along with the Metacello registration for the project. > > Since the git repository can be independently manipulated from > the shell or an image can be saved that references a SHA that > is no longer "current" .... it is very important that the SHA > be recorded and made visible to users via the tools. > > > By "current", do you mean the currently checked out directory as > seen from the shell command line? > > Slightly off topic... > I wonder if we could avoid needing a currently checked out > directory as seen from the command line and have the Image work > directly with the git repository (within the .git folder - is this > what libgit integration may give us?) thus making the Image the > equivalent of the current checked out directory? Then lets dump > the .changes file by... rather than a method's source reference > being a (fragile) hardcoded index into the .changes file, make > each method an SHA key into the git (or mercurial) repository. > * Git is fundamentally a content-addressable filesystem with a VCS > user interface written on top of it. Youâll learn more about what > this means in a bit. [2] > * Git is a simple key-value data store. You can insert any kind of > content into it, and it will give you back a key that you can use > to retrieve the content again at any time. [3] > * [In Mercurial...] each revision of a file is identified by a > 'NodeID', which is a SHA hash of its contents (combined with the > position of that node in the history). [4] > > > * The baseline data structures for Fossil and Git are the same (modulo > formatting details). Both systems store check-ins as immutable objects > referencing their immediate ancestors and named by their SHA1 hash. [5] > > So to firm up this idea, while we might not want to tie ourselves too > tightly to git, rather than try working with *all* types of source > code management, would it be reasonable to concentrate on an > abstraction layer focused on *content-addressable* source code? That > is, would this provide flexibility for sufficient backend options, but > a better experience with those than a totally generic source code > management. (btw, Could EPICEA be made to work with SHAs?) > Yes I read the paper on "An Abstraction for Version Control Systems"[1] and if I recall correctly SVN is lacking in a few of the features that had to be "simulated" ... so an abstraction layer that did not have to "fake features out" makes a lot of sense ... with that said, it also makes a lot of sense to not exclude SVN, so an abstraction layer that had provision for unsupported features would be useful ... Dale [1] https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEw…

Jan. 28, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a7c782: 50553

by Esteban Lorenzano

no idea, but integrations are not happening (not just GTools) I will check tomorrow :) > On 28 Jan 2016, at 19:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > What is the problem? > > Doru > > >> On Jan 28, 2016, at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> this didnât work :( >> >>> On 28 Jan 2016, at 18:16, GitHub <noreply(a)github.com> wrote: >>> >>> Branch: refs/heads/5.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: a7c782bf85e2fd1905cf9834fc8782040096060f >>> https://github.com/pharo-project/pharo-core/commit/a7c782bf85e2fd1905cf9834… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2016-01-28 (Thu, 28 Jan 2016) >>> >>> Changed paths: >>> M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st >>> A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version16_.st >>> M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st >>> A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version08_.st >>> M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st >>> A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version29_.st >>> M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st >>> M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version210_.st >>> M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st >>> A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version112_.st >>> M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st >>> A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version310_.st >>> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st >>> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version314Moose51_.st >>> A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version40_.st >>> M GTInspector-Help.package/GTInspectorHelp.class/README.md >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50552.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50553.st >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50552.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50553.st >>> M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> >>> Log Message: >>> ----------- >>> 50553 >>> GTInspector-Help >>> >>> http://files.pharo.org/image/50/50553.zip >>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > >

Jan. 28, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a7c782: 50553

by Tudor Girba

What is the problem? Doru > On Jan 28, 2016, at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > this didnât work :( > >> On 28 Jan 2016, at 18:16, GitHub <noreply(a)github.com> wrote: >> >> Branch: refs/heads/5.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: a7c782bf85e2fd1905cf9834fc8782040096060f >> https://github.com/pharo-project/pharo-core/commit/a7c782bf85e2fd1905cf9834… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-01-28 (Thu, 28 Jan 2016) >> >> Changed paths: >> M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version16_.st >> M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version08_.st >> M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version29_.st >> M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st >> M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version210_.st >> M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version112_.st >> M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version310_.st >> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st >> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version314Moose51_.st >> A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version40_.st >> M GTInspector-Help.package/GTInspectorHelp.class/README.md >> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50552.st >> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50553.st >> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50552.st >> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50553.st >> M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >> Log Message: >> ----------- >> 50553 >> GTInspector-Help >> >> http://files.pharo.org/image/50/50553.zip >> >> > > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Jan. 28, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Dale Henrichs

On 01/27/2016 05:41 PM, Ben Coman wrote: > > > On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > The git repository is not tightly coupled to the image like the > changes file (you can delete a git repository without impacting > the functionality of an image), but if you are making changes in > the image, then you _are_ coupled to a particular git commit > identified by its SHA. > > Metacello will record the SHA of the git repository at the time > that packages are loaded from a git repository (to enable this > feature in Pharo, some methods need to be implemented in the > MetacelloPlatform for Pharo) and this information is stored along > with the Metacello registration for the project. > > Since the git repository can be independently manipulated from the > shell or an image can be saved that references a SHA that is no > longer "current" .... it is very important that the SHA be > recorded and made visible to users via the tools. > > > By "current", do you mean the currently checked out directory as seen > from the shell command line? Yes, the shell command line, and the directory that filtree:// repo in the image references ... > > Slightly off topic... > I wonder if we could avoid needing a currently checked out directory > as seen from the command line and have the Image work directly with > the git repository (within the .git folder - is this what libgit > integration may give us?) thus making the Image the equivalent of the > current checked out directory? Then lets dump the .changes file by... > rather than a method's source reference being a (fragile) hardcoded > index into the .changes file, make each method an SHA key into the git > (or mercurial) repository. > * Git is fundamentally a content-addressable filesystem with a VCS > user interface written on top of it. Youâll learn more about what this > means in a bit. [2] > * Git is a simple key-value data store. You can insert any kind of > content into it, and it will give you back a key that you can use to > retrieve the content again at any time. [3] > * [In Mercurial...] each revision of a file is identified by a > 'NodeID', which is a SHA hash of its contents (combined with the > position of that node in the history). [4] > > In short, should our source code indexing be "content-addressable" > with the possibility to use *any* key-value repository. Each method > SHA would be calculated from its own source code and parent class > SHA. Each class would calculate its SHA from its definition and > superclass' SHA. A package/project SHA would be calculated from all > its component class and method SHAs. > Well, this is a direction that could be taken, but there some advantages to sharing the actual checkouts ... in my workflow, I have a collection of git repos that represent my current base system and I have a number of stones (images) that share this same base system and when I make a bugfix in one, I am interested in being able to easily load the bugfix into the other stones before starting work in that particular stone so having a shared "current directory" amongst a set of stones is actually convenient .... this "convenience" also extends to building a new stone (image) since the build scripts only need to load from the currently checkout versions without having to know the specific SHA of interest ... Dale

Jan. 28, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 770605: 50554

by Esteban Lorenzano

this one also didnât work :( > On 28 Jan 2016, at 18:58, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 7706057c37f925a319931cc3c5f3ef0f3fcbab62 > https://github.com/pharo-project/pharo-core/commit/7706057c37f925a319931cc3… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-01-28 (Thu, 28 Jan 2016) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50553.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50554.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50553.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50554.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50554 > 17487 SlotClassBuilder>>#update:to: outdated > https://pharo.fogbugz.com/f/cases/17487 > > http://files.pharo.org/image/50/50554.zip > >

Jan. 28, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50554 Home: https://github.com/pharo-project/pharo-core

Jan. 28, 2016