- Pharo-users - lists.pharo.org

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

But this add a serious indirection layer. In Java, since there is no image, doing a pull update your code. In Pharo, it would simply update the git repo, without updating the code in your image. Whatâs happens if I modify the code in my image and do a git pull? I will have conflict between my image and the git repo. That was the very first scenario I did when I tried Git. No no no, that is completely broken. Alexandre > On Sep 11, 2015, at 10:38 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > Le 11 septembre 2015 15:33, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > [ answer in the mailing list since it may interest other ] > > Another problem would be the synchronization between the image and the source code stored on disk. For example, I should never do a git pull within a xterm command, because the image will not be sync. > > No, this is not an issue. By design, the state of your code in your image is not kept in sync with a repository; you can be n versions behind the latest in the repository, if you like. This is the case with Smalltalkhub. A pull in git only amounts to a more extensive refresh in a Smalltalkhub repository. > > Thierry > > > Alexandre > > > > > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > Salut Alexandre, > > > > je creuse encore un peu l'idÃ©e de l'autre format et... > > > > - Le format "chunk/fileout" de Pharo ne comporte pas les infos nÃ©cessaires Ã Monticello; le mÃªme fichier "version" si embÃªtant sous git est dans le mcz (et s'il Ã©tait mis dans le .st, on aurait les mÃªmes conflits sous git merge, mais sans doute plus compliquÃ©). > > - Si on passe sur un format n'ayant pas cette info de version, il faut absolument passer par git pour la rÃ©cupÃ©rer. Or git et windows Ã§a ne marche pas encore correctement. Ãa limiterait le nouveau format Ã Mac et Linux :( > > > > Bienvenue dans ce bazar trÃ¨s dÃ©sagrÃ©able Ã contempler. > > > > Thierry > > . > > > > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > > moi je me demanderais juste une chose, du point de vue que j'ai quand je discute transfert de technologie : est-ce que Ã§a sert Ã quelque chose d'investir lÃ -dedans ? > > > > Ben jâaimerai pouvoir utiliser Git au lieu de SmalltalkHub. > > > > > En gros, FileTree marche trÃ¨s bien (avec des ratÃ©s sous windows en cours de rÃ©solution), GitFileTree marche trÃ¨s bien (avec des ratÃ©s sous windows), le merge driver marche trÃ¨s bien. Pourquoi veux-tu changer de format ? > > > > Pour ne pas Ã avoir Ã modifier le .gitconfig et le .gitattributes. > > > > Jâai un nouveau cours oÃ¹ jâenseigne Pharo. Mais je ne me vois pas vraiment leur dire de suivre la procÃ©dure sur https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche mais câest particuliÃ¨rement complexe. > > > > Alexandre > > > > > > > > > > L'investissement qui fait sens pour moi est: > > > - Corriger ProcessWrapper sous Windows > > > ou > > > - Travailler sur l'intÃ©gration de libcgit > > > et > > > - Travailler sur un outil de rÃ©solution de conflit git sous Pharo (pour Ã©viter d'avoir Ã utiliser meld et compagnie). > > > > > > Tu sais, je peux te vendre* ce que serait la chaÃ®ne git parfaite pour Pharo, et je ne te parlerais pas du format ou d'en changer. > > > > > > * te faire le pitch investisseur / VC > > > > > > ** C'est vraiment la merde de rajouter des types supplÃ©mentaires de repository dans Pharo, donc c'est aussi pour Ã§a que je ne l'encourage pas trop. > > > > > > *** Mais en mÃªme temps, c'est un sujet trÃ¨s important, donc c'est bien qu'on en discute. > > > > > > Thierry > > > > > > Le 10/09/2015 23:11, Alexandre Bergel a Ã©crit : > > >> [ This is a private message ] > > >> > > >> This is a topic very important for me. Would you like to guide an > > >> engineer if I get one? Milton is a very competent engineer. I really > > >> would like this topic move on. > > >> > > >> Cheers, > > >> Alexandre > > >> > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >>> On Sep 10, 2015, at 4:04 PM, Thierry Goubier > > >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > >>> > > >>> Le 10/09/2015 20:29, Alexandre Bergel a Ã©crit : > > >>>>>>> But, all well considered, relying only on the underlying vcs for > > >>>>>>> versions, but writing chunk files, could it work? With the > > >>>>>>> gitfiletree framework, all version / meta information is external > > >>>>>>> to the source files, so Metacello could use that and have > > >>>>>>> everything it needs. Would someone be interested by that? > > >>>> > > >>>> Are you suggesting to have a different format, which could be .mcs that > > >>>> is like .mcz but without all the metadata? > > >>> > > >>> That would be that. The mcs would be the chunk format that Pharo and > > >>> all Smalltalks have (i.e. fileouts). > > >>> > > >>>> This means that we will need > > >>>> another UI since Monticello will not work. > > >>> > > >>> No, it would simply be another type of repository for Monticello. I > > >>> have already done the work for GitFileTree (recreate a MC-like API > > >>> even if the metadata comes from git instead of the mcz), and you would > > >>> reuse that. > > >>> > > >>> It would be totally transparent to you. Metacello, Gofer, > > >>> Configurations would work. > > >>> > > >>>> Can you estimate the amount of work to do? > > >>> > > >>> I'd start from GitFileTree, isolate the git commands and the MC API > > >>> and copy them to the new repository type, add a chunk reader over a > > >>> zip archive, and add the chunk writer. I'd reuse the GitFileTree > > >>> repository inspector because it is already designed for that. > > >>> > > >>> For someone who knows a bit the internals of a MC repository, it > > >>> wouldn't take long. > > >>> > > >>> Shouldn't forget to have a good chunk of tests cases and sample > > >>> repositories: filetree would be my reference there. > > >>> > > >>> Thierry > > >>> > > >>>> Alexandre > > >>> > > >>> > > >> > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

But making sure that people for a given project can commit either to a git repo to a smalltalkhub significantly complexify the thing. And at the end, we will always have people who stay in smalltalkhub because it is much simpler than git. Several times I wanted to migrate to git, but the burden of Monticello metadata make me stay with SmalltalkHub. We are missing a big trainâ¦ Alexandre > On Sep 11, 2015, at 10:35 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-09-11 15:28 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > >> Do I need to modify .gitattributes and .gitconfig? > > > > Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed. > > Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git. > > Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree). > > More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data. > > I agree on the target, but. > > git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment. > > I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only). > > Thierry > > > Alexandre > > > > > > > Thierry > > > >> > >> Alexandre > >> > >>> On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou(a)inria.fr> wrote: > >>> > >>> Hi, > >>> > >>> today I wanted to have a look at how git integrates with Pharo. This is > >>> what I found (mostly done by Thierry Goubier, thank you very much) and > >>> what I didn't find: > >>> > >>> - there is some documentation here: > >>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > >>> But this is largely unfinished material. I contributed by adding a few > >>> things here and there but not much. If you have some experience, > >>> please share it there > >>> (https://github.com/SquareBracketAssociates/PharoInProgress) Missing > >>> things include: > >>> > >>> - a discussion about which process to follow in which conditions > >>> (should I use GitFileTree or FileTree?) > >>> > >>> - a discussion about moving a smalltalkhub repository to git while > >>> preserving history > >>> > >>> - a discussion on how to write Metacello configurations for a project > >>> on git and for a project which depends on a project on git. > >>> > >>> - there is a nice git merge driver > >>> (https://github.com/ThierryGoubier/GitFileTree-MergeDriver) It seems > >>> to work fine. I sent 3 minor pull requests. > >>> > >>> - a list of tools missing before everyone uses git. For example: > >>> > >>> - A tool to resolve merge conflicts in Pharo. We should reuse the diff > >>> widget we have. > >>> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Success is the ability to go from one failure to another without > >>> losing enthusiasm." --Winston Churchill > >>> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Thierry Goubier

Le 11 septembre 2015 15:33, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > [ answer in the mailing list since it may interest other ] > > Another problem would be the synchronization between the image and the > source code stored on disk. For example, I should never do a git pull > within a xterm command, because the image will not be sync. > No, this is not an issue. By design, the state of your code in your image is not kept in sync with a repository; you can be n versions behind the latest in the repository, if you like. This is the case with Smalltalkhub. A pull in git only amounts to a more extensive refresh in a Smalltalkhub repository. Thierry > > Alexandre > > > > > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Salut Alexandre, > > > > je creuse encore un peu l'idÃ©e de l'autre format et... > > > > - Le format "chunk/fileout" de Pharo ne comporte pas les infos > nÃ©cessaires Ã Monticello; le mÃªme fichier "version" si embÃªtant sous git > est dans le mcz (et s'il Ã©tait mis dans le .st, on aurait les mÃªmes > conflits sous git merge, mais sans doute plus compliquÃ©). > > - Si on passe sur un format n'ayant pas cette info de version, il faut > absolument passer par git pour la rÃ©cupÃ©rer. Or git et windows Ã§a ne marche > pas encore correctement. Ãa limiterait le nouveau format Ã Mac et Linux :( > > > > Bienvenue dans ce bazar trÃ¨s dÃ©sagrÃ©able Ã contempler. > > > > Thierry > > . > > > > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > > moi je me demanderais juste une chose, du point de vue que j'ai quand > je discute transfert de technologie : est-ce que Ã§a sert Ã quelque chose > d'investir lÃ -dedans ? > > > > Ben jâaimerai pouvoir utiliser Git au lieu de SmalltalkHub. > > > > > En gros, FileTree marche trÃ¨s bien (avec des ratÃ©s sous windows en > cours de rÃ©solution), GitFileTree marche trÃ¨s bien (avec des ratÃ©s sous > windows), le merge driver marche trÃ¨s bien. Pourquoi veux-tu changer de > format ? > > > > Pour ne pas Ã avoir Ã modifier le .gitconfig et le .gitattributes. > > > > Jâai un nouveau cours oÃ¹ jâenseigne Pharo. Mais je ne me vois pas > vraiment leur dire de suivre la procÃ©dure sur > https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche > mais câest particuliÃ¨rement complexe. > > > > Alexandre > > > > > > > > > > L'investissement qui fait sens pour moi est: > > > - Corriger ProcessWrapper sous Windows > > > ou > > > - Travailler sur l'intÃ©gration de libcgit > > > et > > > - Travailler sur un outil de rÃ©solution de conflit git sous Pharo > (pour Ã©viter d'avoir Ã utiliser meld et compagnie). > > > > > > Tu sais, je peux te vendre* ce que serait la chaÃ®ne git parfaite pour > Pharo, et je ne te parlerais pas du format ou d'en changer. > > > > > > * te faire le pitch investisseur / VC > > > > > > ** C'est vraiment la merde de rajouter des types supplÃ©mentaires de > repository dans Pharo, donc c'est aussi pour Ã§a que je ne l'encourage pas > trop. > > > > > > *** Mais en mÃªme temps, c'est un sujet trÃ¨s important, donc c'est bien > qu'on en discute. > > > > > > Thierry > > > > > > Le 10/09/2015 23:11, Alexandre Bergel a Ã©crit : > > >> [ This is a private message ] > > >> > > >> This is a topic very important for me. Would you like to guide an > > >> engineer if I get one? Milton is a very competent engineer. I really > > >> would like this topic move on. > > >> > > >> Cheers, > > >> Alexandre > > >> > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >>> On Sep 10, 2015, at 4:04 PM, Thierry Goubier > > >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > > >>> > > >>> Le 10/09/2015 20:29, Alexandre Bergel a Ã©crit : > > >>>>>>> But, all well considered, relying only on the underlying vcs for > > >>>>>>> versions, but writing chunk files, could it work? With the > > >>>>>>> gitfiletree framework, all version / meta information is external > > >>>>>>> to the source files, so Metacello could use that and have > > >>>>>>> everything it needs. Would someone be interested by that? > > >>>> > > >>>> Are you suggesting to have a different format, which could be .mcs > that > > >>>> is like .mcz but without all the metadata? > > >>> > > >>> That would be that. The mcs would be the chunk format that Pharo and > > >>> all Smalltalks have (i.e. fileouts). > > >>> > > >>>> This means that we will need > > >>>> another UI since Monticello will not work. > > >>> > > >>> No, it would simply be another type of repository for Monticello. I > > >>> have already done the work for GitFileTree (recreate a MC-like API > > >>> even if the metadata comes from git instead of the mcz), and you > would > > >>> reuse that. > > >>> > > >>> It would be totally transparent to you. Metacello, Gofer, > > >>> Configurations would work. > > >>> > > >>>> Can you estimate the amount of work to do? > > >>> > > >>> I'd start from GitFileTree, isolate the git commands and the MC API > > >>> and copy them to the new repository type, add a chunk reader over a > > >>> zip archive, and add the chunk writer. I'd reuse the GitFileTree > > >>> repository inspector because it is already designed for that. > > >>> > > >>> For someone who knows a bit the internals of a MC repository, it > > >>> wouldn't take long. > > >>> > > >>> Shouldn't forget to have a good chunk of tests cases and sample > > >>> repositories: filetree would be my reference there. > > >>> > > >>> Thierry > > >>> > > >>>> Alexandre > > >>> > > >>> > > >> > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Sept. 11, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Thierry Goubier

2015-09-11 15:28 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > >> Do I need to modify .gitattributes and .gitconfig? > > > > Just the .gitattributes. The .gitconfig stuff will be taken care of when > the merge driver is installed. > > Ok, but why do we need this ? What I understand is to merge conflicts with > metadata of .mcz, which are useless in Git. > Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree). > More I think about it, more I think that we need to go toward a lighter > version of .mcz file, without the meta-data. > I agree on the target, but. git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment. I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only). Thierry > > Alexandre > > > > > > > Thierry > > > >> > >> Alexandre > >> > >>> On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou(a)inria.fr> > wrote: > >>> > >>> Hi, > >>> > >>> today I wanted to have a look at how git integrates with Pharo. This is > >>> what I found (mostly done by Thierry Goubier, thank you very much) and > >>> what I didn't find: > >>> > >>> - there is some documentation here: > >>> > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > >>> But this is largely unfinished material. I contributed by adding a few > >>> things here and there but not much. If you have some experience, > >>> please share it there > >>> (https://github.com/SquareBracketAssociates/PharoInProgress) Missing > >>> things include: > >>> > >>> - a discussion about which process to follow in which conditions > >>> (should I use GitFileTree or FileTree?) > >>> > >>> - a discussion about moving a smalltalkhub repository to git while > >>> preserving history > >>> > >>> - a discussion on how to write Metacello configurations for a project > >>> on git and for a project which depends on a project on git. > >>> > >>> - there is a nice git merge driver > >>> (https://github.com/ThierryGoubier/GitFileTree-MergeDriver) It seems > >>> to work fine. I sent 3 minor pull requests. > >>> > >>> - a list of tools missing before everyone uses git. For example: > >>> > >>> - A tool to resolve merge conflicts in Pharo. We should reuse the diff > >>> widget we have. > >>> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Success is the ability to go from one failure to another without > >>> losing enthusiasm." --Winston Churchill > >>> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Sept. 11, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

[ answer in the mailing list since it may interest other ] Another problem would be the synchronization between the image and the source code stored on disk. For example, I should never do a git pull within a xterm command, because the image will not be sync. Alexandre > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Salut Alexandre, > > je creuse encore un peu l'idÃ©e de l'autre format et... > > - Le format "chunk/fileout" de Pharo ne comporte pas les infos nÃ©cessaires Ã Monticello; le mÃªme fichier "version" si embÃªtant sous git est dans le mcz (et s'il Ã©tait mis dans le .st, on aurait les mÃªmes conflits sous git merge, mais sans doute plus compliquÃ©). > - Si on passe sur un format n'ayant pas cette info de version, il faut absolument passer par git pour la rÃ©cupÃ©rer. Or git et windows Ã§a ne marche pas encore correctement. Ãa limiterait le nouveau format Ã Mac et Linux :( > > Bienvenue dans ce bazar trÃ¨s dÃ©sagrÃ©able Ã contempler. > > Thierry > . > > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > moi je me demanderais juste une chose, du point de vue que j'ai quand je discute transfert de technologie : est-ce que Ã§a sert Ã quelque chose d'investir lÃ -dedans ? > > Ben jâaimerai pouvoir utiliser Git au lieu de SmalltalkHub. > > > En gros, FileTree marche trÃ¨s bien (avec des ratÃ©s sous windows en cours de rÃ©solution), GitFileTree marche trÃ¨s bien (avec des ratÃ©s sous windows), le merge driver marche trÃ¨s bien. Pourquoi veux-tu changer de format ? > > Pour ne pas Ã avoir Ã modifier le .gitconfig et le .gitattributes. > > Jâai un nouveau cours oÃ¹ jâenseigne Pharo. Mais je ne me vois pas vraiment leur dire de suivre la procÃ©dure sur https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche mais câest particuliÃ¨rement complexe. > > Alexandre > > > > > > L'investissement qui fait sens pour moi est: > > - Corriger ProcessWrapper sous Windows > > ou > > - Travailler sur l'intÃ©gration de libcgit > > et > > - Travailler sur un outil de rÃ©solution de conflit git sous Pharo (pour Ã©viter d'avoir Ã utiliser meld et compagnie). > > > > Tu sais, je peux te vendre* ce que serait la chaÃ®ne git parfaite pour Pharo, et je ne te parlerais pas du format ou d'en changer. > > > > * te faire le pitch investisseur / VC > > > > ** C'est vraiment la merde de rajouter des types supplÃ©mentaires de repository dans Pharo, donc c'est aussi pour Ã§a que je ne l'encourage pas trop. > > > > *** Mais en mÃªme temps, c'est un sujet trÃ¨s important, donc c'est bien qu'on en discute. > > > > Thierry > > > > Le 10/09/2015 23:11, Alexandre Bergel a Ã©crit : > >> [ This is a private message ] > >> > >> This is a topic very important for me. Would you like to guide an > >> engineer if I get one? Milton is a very competent engineer. I really > >> would like this topic move on. > >> > >> Cheers, > >> Alexandre > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Sep 10, 2015, at 4:04 PM, Thierry Goubier > >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >>> > >>> Le 10/09/2015 20:29, Alexandre Bergel a Ã©crit : > >>>>>>> But, all well considered, relying only on the underlying vcs for > >>>>>>> versions, but writing chunk files, could it work? With the > >>>>>>> gitfiletree framework, all version / meta information is external > >>>>>>> to the source files, so Metacello could use that and have > >>>>>>> everything it needs. Would someone be interested by that? > >>>> > >>>> Are you suggesting to have a different format, which could be .mcs that > >>>> is like .mcz but without all the metadata? > >>> > >>> That would be that. The mcs would be the chunk format that Pharo and > >>> all Smalltalks have (i.e. fileouts). > >>> > >>>> This means that we will need > >>>> another UI since Monticello will not work. > >>> > >>> No, it would simply be another type of repository for Monticello. I > >>> have already done the work for GitFileTree (recreate a MC-like API > >>> even if the metadata comes from git instead of the mcz), and you would > >>> reuse that. > >>> > >>> It would be totally transparent to you. Metacello, Gofer, > >>> Configurations would work. > >>> > >>>> Can you estimate the amount of work to do? > >>> > >>> I'd start from GitFileTree, isolate the git commands and the MC API > >>> and copy them to the new repository type, add a chunk reader over a > >>> zip archive, and add the chunk writer. I'd reuse the GitFileTree > >>> repository inspector because it is already designed for that. > >>> > >>> For someone who knows a bit the internals of a MC repository, it > >>> wouldn't take long. > >>> > >>> Shouldn't forget to have a good chunk of tests cases and sample > >>> repositories: filetree would be my reference there. > >>> > >>> Thierry > >>> > >>>> Alexandre > >>> > >>> > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

>> Do I need to modify .gitattributes and .gitconfig? > > Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed. Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git. More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data. Alexandre > > Thierry > >> >> Alexandre >> >>> On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou(a)inria.fr> wrote: >>> >>> Hi, >>> >>> today I wanted to have a look at how git integrates with Pharo. This is >>> what I found (mostly done by Thierry Goubier, thank you very much) and >>> what I didn't find: >>> >>> - there is some documentation here: >>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >>> But this is largely unfinished material. I contributed by adding a few >>> things here and there but not much. If you have some experience, >>> please share it there >>> (https://github.com/SquareBracketAssociates/PharoInProgress) Missing >>> things include: >>> >>> - a discussion about which process to follow in which conditions >>> (should I use GitFileTree or FileTree?) >>> >>> - a discussion about moving a smalltalkhub repository to git while >>> preserving history >>> >>> - a discussion on how to write Metacello configurations for a project >>> on git and for a project which depends on a project on git. >>> >>> - there is a nice git merge driver >>> (https://github.com/ThierryGoubier/GitFileTree-MergeDriver) It seems >>> to work fine. I sent 3 minor pull requests. >>> >>> - a list of tools missing before everyone uses git. For example: >>> >>> - A tool to resolve merge conflicts in Pharo. We should reuse the diff >>> widget we have. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015

Pillar 2.0.0: Introduction of PetitPillar

by Ferlicot D. Cyril

Hi everyone! Yes, a new version of Pillar, again! With this version we removed the old parser of Pillar to introduce PetitPillar base on PetitParser. This parser is slower than the previous one but we will be able to improve his speed. We will also be able to improve Pillar at the parser level, which was impossible before. So we will be able to remove some hacks and improve the experience of the users. If you are good in parser and you want to contribute to his improvement, feel free to help, we have a lot of tests to help. This is my first parser so I am sure it have a lot of rooms for improvement. -- Cheers Cyril

Sept. 11, 2015

Re: [Pharo-users] Spec: Where to find an example using a TreeModel

by Offray Vladimir Luna CÃ¡rdenas

Hi Peter, On 10/09/15 21:27, Peter UhnÃ¡k wrote: > Hi, > > are you looking for something in particular? > Because in TreeModel class-side there are four examples ready to go. Je je, silly me. I made a newbie mistake and I didn't look the class side... I'll take a look of them. > > [*] Peter, the problem about running out of space while loading > icons with IconFactory was solved if I don't use cache. Still is > strange because icons are small and few in my test, but this > approach worked. > > > Would you mind sharing the icons somewhere please? (Or just send a zip > with the icons.) Because this is a problem that should be resolved. Sure thing. Look at the file repository of the project here: http://mutabit.com/deltas/repos.fossil/grafoscopio/dir?name=Common/Icons&ci… You will find two icons families FontAwesome and Menda with two directories on each one "Svg" and "Png". They contain my custom selection of icons from this families for this project. I'm using the files contained in the "Png" folders. Cheers, Offray

Sept. 11, 2015

Connecting Ephemeric Cloud instances to other cloud provides (like Digital Ocean)

by Mike Filonov

Hello, Good news everyone! :) Today I have successfully connected an application published in Ephemeric Cloud to a MongoDB hosted at Digital Ocean! http://eph-f2e2bcac.swarm.pharocloud.com/todo It became possible due to a stunnel support implemented in Ephemeric Cloud runtime â the utility allows to create secure tunnels between applications. Thus the communication between an ephemeric instance and a droplet is encrypted and safe. Configuration is extremely simple â just put a stunnel.conf and the certificate files to your Image archive before publishing it. This approach is universal and it allows to connect Pharo Images to any service providers or dedicated servers. Therefore Ephemeric cloud becomes more than just Pharocloud but an universal tool to develop and publish Pharo web applications. Another good thing is that it has a free tier :) Please try it out and tell me what you think. You can find some documentation here: https://www.pharocloud.com/kb/tutorial/connect_ephemeric_to_digital_ocean Cheers, Mike

Sept. 11, 2015

Re: [Pharo-users] load directive

by Usman Bhatti

Tx for looking. I did: (ConfigurationOfGlamour project version: #stable) record loadDirective in Moose 5.0 (pharo3) and Moose5.1(pharo4). Here is the difference in the output. And the first (with Pharo3) is much more helpful because with a single command one can understand ALL the packages loaded. Whereas, in Pharo4, we don't get the complete tree and hence one has to see the list of the individual configurations to understand. Pharo3 linear load : linear load : 2.1 [ConfigurationOfGlamour] load : ConfigurationOfGrease atomic load : 2.1 [ConfigurationOfGlamour] load : Glamour-Announcements-tg.5 load : Glamour-Helpers-TudorGirba.25 --------long list continues-------------- linear load : 2.162 [ConfigurationOfMondrian] load : ConfigurationOfHealthReportProducer linear load : 2.162 [ConfigurationOfMondrian] load : ConfigurationOfShapeST80 atomic load : 2.162 [ConfigurationOfMondrian] linear load : 1.7 [ConfigurationOfHealthReportProducer] load : ConfigurationOfXMLSupport atomic load : 1.7 [ConfigurationOfHealthReportProducer] explicit load : XMLSupport load : ConfigurationOfXMLSupport-monty.75 load : HealthReportProducer-Ivan_Rojas.13 load : Nile-Base-DamienCassou.81 load : Mondrian-ComplexShape-AlexandreBergel.33 --------long list continues-------------- Pharo4 linear load : linear load : 3.3.0 [ConfigurationOfGlamour] load : ConfigurationOfMagritte3 atomic load : 3.3.0 [ConfigurationOfGlamour] linear load : 1.14 [ConfigurationOfRoassal2] linear load : 11 [ConfigurationOfNeoJSON] load : Neo-JSON-Tests-SvenVanCaekenberghe.29 linear load : 3.5.0 [ConfigurationOfMagritte3] load : Magritte-Pharo3-Model load : CollectionExtensions-TudorGirba.41 load : Glamour-Roassal2-Presentations-TudorGirba.38 regards. On Thu, Sep 10, 2015 at 8:53 PM, stepharo <stepharo(a)free.fr> wrote: > (ConfigurationOfStore project version: #stable) record loadDirective > > linear load : > linear load : 0.10 [ConfigurationOfStore] > linear load : 0.2 [ConfigurationOfGarage] > load : ConfigurationOfTalkFFI > linear load : 0.2 [ConfigurationOfGarage] > load : Store-StephaneDucasse.13 > >

Sept. 11, 2015