- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Thierry Goubier

Le 01/12/2014 21:04, Esteban Lorenzano a Ã©crit : > >> On 01 Dec 2014, at 20:25, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> >> >> On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : >> >> >> also, in a point (not now, but eventually)â¦ we will need to drop >> something. The idea of keeping anything ad eternum just does >> not scales. >> >> >> But it's a good way of delaying git integration in the Pharo >> platform by having to redesign the file format as well. >> >> >> Thierry, >> >> Not sure if you are being sarcastic here:) > > he was, donât worry :) Maybe I was :) > and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât > spend changing it until we have ready other parts of the tooling I think > is necessary (using libgit2 instead osprocess for me is a must, while > changing filetree format is just an enhancement) When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level => lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost => what, NativeBoost isn't ready? Pharo is stuck in 32bits land=>No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM. In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication. > butâ¦ in the not so far future the metadata *needs* to change, Iâm sorry. > Merging in complex project (more than one developer, in fact) can become > a pain if we do not improve thatâ¦ even with mergetools from Thierry, is > too complicated). The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;) (especially the bit about the merge of large projects/multiple developers being too complicated...) Thierry > Esteban >

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Esteban Lorenzano

> On 01 Dec 2014, at 21:15, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 01/12/2014 20:25, Dale Henrichs a Ã©crit : >> >> >> On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : >> >> >> also, in a point (not now, but eventually)â¦ we will need to drop >> something. The idea of keeping anything ad eternum just does not >> scales. >> >> >> But it's a good way of delaying git integration in the Pharo >> platform by having to redesign the file format as well. >> >> >> Thierry, >> >> Not sure if you are being sarcastic here:) > > I wish I was :( > >> I just don't see how the current FileTree format "delays git integration >> in the Pharo platform." > > This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable. > > Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names. > > However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs. > > (If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs). > >> I consider git integrated into tODE and tODE uses FileTree. >> >> Perhaps it's a matter of approach. In tODE the git support is NOT >> centered on the package browser ... the git support is built into the >> "system browser" so you can look at git history from a class, method OR >> package perspective ... Other perspectives are possible as it is >> relatively straightforward to pull up the git history of any directory >> or file ... and git integration should include the ability to view diffs >> and merge non-smalltalk files... > > I agree. But you are at the point where you just say: > > "libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it." > > Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? > > And for what? The goal is to hide git behind any package and source management tools we have in the image, after all. well, no. the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, Iâm quite happy with gitfiletree. I will just intend to make it work without OSProcess. but in other discussions. Yes, we will need to stabilise things in a point. Iâm not happy with general status ofâ¦ well, a lot of things. And not in status of stability (most of them work really well), but Iâm working to try to ensure the maintainability in the long wayâ¦ and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general) Esteban > >> A package is just one of the artifacts that is stored in a git >> repository. Monticello packages have Monticello characteristics ... >> Cypress packages without Monticello meta data[1] are another package >> format and they have slightly different characteristics than Monticello >> packages and they are equally supported by tODE. [To be fair the Cypress >> package support is still experimental but a year ago I was doing active >> development using tODE and Cypress packages in conjunction with >> Monticello packages]. >> >> FileTree intentionally supports Monticello-style packages so that the >> FileTree packages can leverage the existing Monticello-based tools like >> Metacello (I had to extend Metacello to support Cypress-based packages) >> or the Monticello Browser. >> >> So at the end of the day, I think that git integration for Pharo depends >> upon a broader approach to integrating git-based tools throughout the >> tool eco-system. >> >> Once you start looking at a chunk of versioned disk as containing more >> than just Smalltalk source code there a numerous possibilities for >> building in-image tool support for distributing, sharing and maintaining >> documentation, workspaces, plugins, deployment scripts, etc. way beyond >> the limitations of a package ... > > Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that ambitious. > > Thierry > >

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Thierry Goubier

Le 01/12/2014 20:25, Dale Henrichs a Ã©crit : > > > On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : > > > also, in a point (not now, but eventually)â¦ we will need to drop > something. The idea of keeping anything ad eternum just does not > scales. > > > But it's a good way of delaying git integration in the Pharo > platform by having to redesign the file format as well. > > > Thierry, > > Not sure if you are being sarcastic here:) I wish I was :( > I just don't see how the current FileTree format "delays git integration > in the Pharo platform." This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable. Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names. However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs. (If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs). > I consider git integrated into tODE and tODE uses FileTree. > > Perhaps it's a matter of approach. In tODE the git support is NOT > centered on the package browser ... the git support is built into the > "system browser" so you can look at git history from a class, method OR > package perspective ... Other perspectives are possible as it is > relatively straightforward to pull up the git history of any directory > or file ... and git integration should include the ability to view diffs > and merge non-smalltalk files... I agree. But you are at the point where you just say: "libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it." Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? And for what? The goal is to hide git behind any package and source management tools we have in the image, after all. > A package is just one of the artifacts that is stored in a git > repository. Monticello packages have Monticello characteristics ... > Cypress packages without Monticello meta data[1] are another package > format and they have slightly different characteristics than Monticello > packages and they are equally supported by tODE. [To be fair the Cypress > package support is still experimental but a year ago I was doing active > development using tODE and Cypress packages in conjunction with > Monticello packages]. > > FileTree intentionally supports Monticello-style packages so that the > FileTree packages can leverage the existing Monticello-based tools like > Metacello (I had to extend Metacello to support Cypress-based packages) > or the Monticello Browser. > > So at the end of the day, I think that git integration for Pharo depends > upon a broader approach to integrating git-based tools throughout the > tool eco-system. > > Once you start looking at a chunk of versioned disk as containing more > than just Smalltalk source code there a numerous possibilities for > building in-image tool support for distributing, sharing and maintaining > documentation, workspaces, plugins, deployment scripts, etc. way beyond > the limitations of a package ... Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that ambitious. Thierry

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Esteban Lorenzano

> On 01 Dec 2014, at 20:25, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : > > also, in a point (not now, but eventually)â¦ we will need to drop > something. The idea of keeping anything ad eternum just does not scales. > > But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. > > > Thierry, > > Not sure if you are being sarcastic here:) he was, donât worry :) and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement) butâ¦ in the not so far future the metadata *needs* to change, Iâm sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve thatâ¦ even with mergetools from Thierry, is too complicated). Esteban > > I just don't see how the current FileTree format "delays git integration in the Pharo platform." > > I consider git integrated into tODE and tODE uses FileTree. > > Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... > > A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. > > FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. > > So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. > > Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... > > Dale > > [1] https://github.com/rjsargent/CypressReferenceImplementation <https://github.com/rjsargent/CypressReferenceImplementation> > > >

Dec. 1, 2014

Re: [Pharo-dev] ubuntu vm build

by Markus Fritsche

Hello Norbert, I tried using the copy feature - can you check if it worked? Kind regards Markus On 01.12.2014 19:36, Norbert Hartl wrote: > Hi, > > I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? > > thanks, > > Norbert > >

Dec. 1, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban A. Maringolo

> > > My comment was not about discussing the pros and cons of closed versus > open source software. My concerns are more about reliability. > For me it's totally Ok to use git for versioning IF the tools are there. > Squak and Pharo have decent versioning systems that suit their internal > needs. There is room for improvements, that's for sure. > For me Smalltalk is a system and not a simple language with some arbitrary > tools that can be replaced easily. > > The problem is whether the tools you choose for "commoditized" tasks (e.g. SCM) limit the amount of manpower that could contribute to your open source project. Forks and pull-requests are the way most open source projects fix bugs and integrates enhancements. You can't do branching with current tooling (read: Monticello) without suffering proportional to its complexity. No one said tools can be replaced easily, and that's the reason we still use Monticello, some of us backed by old mcz files, others already using some git behind it. Regards,

Dec. 1, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Andreas Wacknitz

Am 01.12.14 um 19:56 schrieb kilon alios: > "It's not a matter of SourceTree or other program, it's about your git > GUI app of preference. You can use plain git from the command line if > you prefer. > > The git repo is portable, the client is up to you." > > +1000 > > exactly and that is something I advocate. > > You cant use Sourcetree on linux ? no problemo use SmartGit > > you prefer using Emacs ? no problemo use magit. > > you prefer the terminal ? no problemo use the terminal. I prefer the Smalltalk environment. > > The cool thing is that it does not really matter what you choose > because all tools follow the git workflow, the rest is just a matter > of preference. > > The disadvantage of sticking just with Pharo ? you will be lucky to be > able to use a single tool and you will be also lucky if that tool has > a substantial fraction of the features of some of the external tools. > > Bigger community , bigger competition and cooperation. Quantity > brings quality. > Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality. > "Non-portable programs die with their system." > > Good luck waiting for MacOS and Windows to die. Why shouldn't they be able to die? There have been other successful companies before. Do you remember Netware? The market leader in networking, almost gone. What about DEC? Gone. Windows is already declining and the Microsoft desparately tries to find new ways to get back. Regarding Apple: They seem to be more interested in iPhone and iPad than in Macs. Obviously they earn a lot more in this field. IMO Apple and Microsoft have one thing in common these days: they make their products life style products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some... Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day. > > "Closed source programs die with their company." > > a) if something "dies" that does not make it useless > > b) The beauty of capitalism is that as long there is demand there is > going to be supply. So you will never run out of options. Aint working > like that with open source I am afraid. That is not quite true. Look at what Oracle did with Solaris: They are not interested in the mass market. If you don't have millions (better billions) to spend they don't care about you. That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it or you can deny to sell a product. You don't even need a good explanation for it. > > I am all for open source, I am a huge fan and if I could I would use > 100% open source if it satisfied me but you cant just push under the > carpet the advantages of closed source software even if you are > Richard Stallman. Plus we are MIT not GPL ;) My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily. Andreas

Dec. 1, 2014

Re: [Pharo-dev] ubuntu vm build

by Markus Fritsche

Hello Norbert, the ubuntu vm build is in the process of being switched from Damien Cassou to me. I will update the PPA asap. Markus On 01.12.2014 19:36, Norbert Hartl wrote: > Hi, > > I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? > > thanks, > > Norbert > >

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Dale Henrichs

On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : > >> >> also, in a point (not now, but eventually)â¦ we will need to drop >> something. The idea of keeping anything ad eternum just does not scales. >> > > But it's a good way of delaying git integration in the Pharo platform by > having to redesign the file format as well. > > Thierry, Not sure if you are being sarcastic here:) I just don't see how the current FileTree format "delays git integration in the Pharo platform." I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Dale [1] https://github.com/rjsargent/CypressReferenceImplementation

Dec. 1, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by kilon alios

"It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you." +1000 exactly and that is something I advocate. You cant use Sourcetree on linux ? no problemo use SmartGit you prefer using Emacs ? no problemo use magit. you prefer the terminal ? no problemo use the terminal. The cool thing is that it does not really matter what you choose because all tools follow the git workflow, the rest is just a matter of preference. The disadvantage of sticking just with Pharo ? you will be lucky to be able to use a single tool and you will be also lucky if that tool has a substantial fraction of the features of some of the external tools. Bigger community , bigger competition and cooperation. Quantity brings quality. "Non-portable programs die with their system." Good luck waiting for MacOS and Windows to die. "Closed source programs die with their company." a) if something "dies" that does not make it useless b) The beauty of capitalism is that as long there is demand there is going to be supply. So you will never run out of options. Aint working like that with open source I am afraid. I am all for open source, I am a huge fan and if I could I would use 100% open source if it satisfied me but you cant just push under the carpet the advantages of closed source software even if you are Richard Stallman. Plus we are MIT not GPL ;)

Dec. 1, 2014