July 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 3af8b8: 40081

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3af8b8b3f8f6c59bfdf452bdb2b6bd8526120f26 https://github.com/pharo-project/pharo-core/commit/3af8b8b3f8f6c59bfdf452bd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-11 (Fri, 11 Jul 2014) Changed paths: R Deprecated40.package/SimpleSwitchMorph.class/README.md R Deprecated40.package/SimpleSwitchMorph.class/definition.st R Deprecated40.package/SimpleSwitchMorph.class/instance/button/doButtonAction.st R Deprecated40.package/SimpleSwitchMorph.class/instance/event handling/mouseDown_.st R Deprecated40.package/SimpleSwitchMorph.class/instance/event handling/mouseMove_.st R Deprecated40.package/SimpleSwitchMorph.class/instance/event handling/mouseUp_.st R Deprecated40.package/SimpleSwitchMorph.class/instance/initialization/initialize.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/isOn.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/offColor_.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/setSwitchState_.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/toggleState.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/turnOff.st R Deprecated40.package/SimpleSwitchMorph.class/instance/switching/turnOn.st A Deprecated40.package/extension/PluggableTextMorphWithLimits/instance/ifLocked_.st A Deprecated40.package/extension/PluggableTextMorphWithLimits/instance/ifLocked_ifUnlocked_.st A Morphic-Base.package/SimpleSwitchMorph.class/README.md A Morphic-Base.package/SimpleSwitchMorph.class/definition.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/button/doButtonAction.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/event handling/mouseDown_.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/event handling/mouseMove_.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/event handling/mouseUp_.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/initialization/initialize.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/isOn.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/offColor_.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/setSwitchState_.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/toggleState.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/turnOff.st A Morphic-Base.package/SimpleSwitchMorph.class/instance/switching/turnOn.st R Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/as yet unclassified/buildPluggableButtonShortcutsOn_.st R Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/as yet unclassified/gradientButtonLook.st R Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/as yet unclassified/gradientButtonLook_.st A Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/settings/gradientButtonLook.st A Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/settings/gradientButtonLook_.st A Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/class/shortcuts/buildPluggableButtonShortcutsOn_.st M Morphic-Widgets-Pluggable.package/PluggableButtonMorph.class/instance/accessing/borderStyleToUse.st M Morphic-Widgets-Pluggable.package/PluggableListMorph.class/definition.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/getEnabledSelector.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/getEnabledSelector_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/getIndexSelector_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/getSelectionListSelector_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/mouseDownRow.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/selectionColor.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/selectionColorToUse.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/selectionColorToUse_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/selectionColor_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/setIndexSelector_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/setMultipleSelection_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/setSelectionListSelector_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/configuration/disable.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/configuration/enable.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/configuration/enabled.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/configuration/enabled_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/drawing/adoptPaneColor_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/event handling/handleFocusEvent_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/events/mouseDownRow_.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/geometry/borderStyleToUse.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/geometry/fillStyleToUse.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/geometry/focusBounds.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/geometry/optimalExtent.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/initialization/initialize.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/scrolling/vExtraScrollRange.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/updating/themeChanged.st A Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/updating/updateEnabled.st M Morphic-Widgets-Pluggable.package/PluggableTabBarMorph.class/class/instance creation/on_.st M Morphic-Widgets-Pluggable.package/PluggableTabButtonMorph.class/class/instance creation/on_label_.st M Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/icon/colorize.st M Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/icon/decolorize.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/protocol/ifLocked_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/protocol/ifLocked_ifUnlocked_.st M Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/protocol/toggleLock.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/contentSelectionFor_.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/sourceCodeFrom_.st M Polymorph-Widgets.package/PluggableTextFieldMorph.class/definition.st A Polymorph-Widgets.package/PluggableTextFieldMorph.class/instance/accessing/textFont.st A Polymorph-Widgets.package/PluggableTextFieldMorph.class/instance/accessing/textFont_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/adoptPaneColor_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/borderStyleToUse.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/disable.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/enable.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/enabled.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/enabled_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/fillStyleToUse.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/focusBounds.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/getEnabledSelector.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/getEnabledSelector_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/handleFocusEvent_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/mouseDownRow.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/mouseDownRow_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/optimalExtent.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/selectionColor.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/selectionColorToUse.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/selectionColorToUse_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/selectionColor_.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/themeChanged.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/updateEnabled.st R Polymorph-Widgets.package/extension/PluggableListMorph/instance/vExtraScrollRange.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script81.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40081.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Spec-Core.package/extension/PluggableListMorph/instance/getIndexSelector_.st R Spec-Core.package/extension/PluggableListMorph/instance/getSelectionListSelector_.st R Spec-Core.package/extension/PluggableListMorph/instance/initialize.st R Spec-Core.package/extension/PluggableListMorph/instance/setIndexSelector_.st R Spec-Core.package/extension/PluggableListMorph/instance/setMultipleSelection_.st R Spec-Core.package/extension/PluggableListMorph/instance/setSelectionListSelector_.st Log Message: ----------- 40081 13537 Merging some polymorph and spec to PluggableListMorph https://pharo.fogbugz.com/f/cases/13537 13495 deprecate #ifLocked: in PluggableTextMoprh https://pharo.fogbugz.com/f/cases/13495/ 13522 Add Back SimpleSwicthMorph https://pharo.fogbugz.com/f/cases/13522 http://files.pharo.org/image/40/40081.zip

July 11, 2014

Re: [Pharo-dev] DBXTalk > OpenDBX > MySQL and OSX Lion : working on 2.0

by harshit

Hello Following Phil's post I could get it working till here. mysql -usodbxtest -psodbxtest sodbxtest When I enter ./odbxtest -b mysql -h localhost -p 3306 -d sodbxtest -u sodbxtest -w sodbxtest from stable-1.4/test I get following ODBX_CAP_BASIC: 1 ODBX_CAP_LO: 0 ODBX_OPT_API_VERSION: 10200 ODBX_OPT_THREAD_SAFE: 1 ODBX_OPT_TLS: 1 ODBX_OPT_CONNECT_TIMEOUT: 1 (using) ODBX_OPT_MULTI_STATEMENTS: 1 (using) ODBX_OPT_PAGED_RESULTS: 1 (using) ODBX_OPT_COMPRESS: 1 (using) ODBX_CAP_BASIC: 1 ODBX_CAP_LO: 0 ODBX_OPT_API_VERSION: 10200 ODBX_OPT_THREAD_SAFE: 1 ODBX_OPT_TLS: 1 ODBX_OPT_CONNECT_TIMEOUT: 1 (using) ODBX_OPT_MULTI_STATEMENTS: 1 (using) ODBX_OPT_PAGED_RESULTS: 1 (using) ODBX_OPT_COMPRESS: 1 (using) Segmentation fault: 11 Any ideas what am I missing. Thanks, Harshit -- View this message in context: http://forum.world.st/Pharo-dev-DBXTalk-OpenDBX-MySQL-and-OSX-Lion-working-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 11, 2014

Re: [Pharo-dev] handling method/classes updartes

by GOUBIER Thierry

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-bounces(a)lists.pharo.org] de la part de Yuriy Tymchuk [yuriy.tymchuk(a)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

July 10, 2014

Re: [Pharo-dev] Handling side-scrolls

by stepharo

This is not that we do not care. This is that we are busy. If you want to make some step in that direction try to OSWindow bug tracker issue and see if it is working for you. Because probably that the solution will be using OSWindow Stef > Dear Pharo developers, > > can we deal somehow with this issue: https://pharo.fogbugz.com/f/cases/5296/Fast-Scroll-Down-produces-weird-even… ? > > Or at least please tell me if someone needs this functionality. Maybe we can just ignore that? > > Uko > >

July 10, 2014

handling method/classes updartes

by Yuriy Tymchuk

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

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by GOUBIER Thierry

________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Damien Pollet [damien.pollet(a)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-td474… 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, phil(a)highoctane.be <phil(a)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.pollet(a)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.goubier(a)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.tymchuk(a)me.com >> >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >> >>> >> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >> >>> <mailto:thierry.goubier@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.goubier(a)cea.fr >> >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >> >>>>>>> >> >>>>>>> >> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>>> <mailto:thierry.goubier@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 >> > >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Dale Henrichs

Damien On Thu, Jul 10, 2014 at 9:59 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > 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) > Thierry's MergeDriver has made the monticello meta data conflicts a non-issue ... since using his merge driver they've gone away as far as I am concerned ... I don't think the meta data can go away until a firm break with mcz files has been made and this cannot really happen until the image has full tool support for working with pure git repos and even then there will be a transition period ... - gitfiletree is a pain because it insists on using a file browser > that shows all dotfiles and starts in the stupidest of places > - 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 I cannot comment on the other things, but for GemStone I am building git support into tODE and have created a `project list` that I think supports git work flow in the "right way" (I am doing a pre-alpha release shortly, I will find out:) ... but the point of this is that I think you almost have to build a new tool suite for managing projects and git repos together and that just takes time ... the old package-base tools are not quite at right level, since with git it is possible to look at method history, class history, package history and project history and when you do a commit, you should be committing all of the packages in the project at the same time (or at least have the option of doing so)... Dale

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Dale Henrichs

Damien, Yes it was by design to just snapshot ... At the time, git was not necessarily familiar to most smalltalkers and I didn't want to require that git be installed or that a user understand how to use git, just to download and _use_ the code of a project that was hosted on github. A clone can be much larger than a simple snapshot and with the snapshot, I was able to create a git-cache directory that could be blown away at any time (much like the package-cache). Finally, if you wanted to save your changes you had to do these things outside the image. So _at the time_ the snapshot seemed to be a good compromise ... In my work flow, I tend to share most of my git repositories and I in this case I don't want N different git repositories for the same project on my disk... For that reason, the Metacello Preview has a feature for 'locking' a project. When you lock a project, you are telling Metacello that no matter what version or repository a project references always use the (in my case) local git repository... I pre-emptively lock the repositories that I am managing as local repositories and then I don't have to mess with reloading the version from my local repo ... If you have referenced a github repo and you do want to make a contribution to, then you should probably fork the project up on github and then clone a copy of your fork to the local disk and then "hook" the local clone into your image ... I have written some commands for tODE that automate this task ... and I'm willing to share:) Dale On Thu, Jul 10, 2014 at 9:28 AM, Damien Pollet <damien.pollet(a)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.goubier(a)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.tymchuk(a)me.com > >> <mailto:yuriy.tymchuk@me.com>> wrote: > >> > >>> > >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr > >>> <mailto:thierry.goubier@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.goubier(a)cea.fr > >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : > >>>>>>> > >>>>>>> > >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>>> <mailto:thierry.goubier@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 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Damien Pollet

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 - 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, phil(a)highoctane.be <phil(a)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.pollet(a)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.goubier(a)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.tymchuk(a)me.com >> >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >> >>> >> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >> >>> <mailto:thierry.goubier@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.goubier(a)cea.fr >> >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >> >>>>>>> >> >>>>>>> >> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>>> <mailto:thierry.goubier@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 >> > >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by phil＠highoctane.be

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.pollet(a)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.goubier(a)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.tymchuk(a)me.com > >> <mailto:yuriy.tymchuk@me.com>> wrote: > >> > >>> > >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr > >>> <mailto:thierry.goubier@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.goubier(a)cea.fr > >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : > >>>>>>> > >>>>>>> > >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>>> <mailto:thierry.goubier@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 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

July 10, 2014