- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Stephane Ducasse

Tx esteban The situation is better than I thought. Near perfect in fact! Well done. Now I think that as a community we should deprecate mcz packages. This is why we should migrate our projects to git and tonel. S. On Sun, Sep 30, 2018 at 11:01 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > > > > > On 29 Sep 2018, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > > > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? > > In absence of Iceberg, Tonel can be used as any other MCRepository. You can save and read your packages as it would be with a âmetadataless filetreeâ. > That means, in Pharo without iceberg you need to save/read from your cloned repository. > Saving to your cloned repository will write files to disk. Which means you need to go there and do a regular git commit/push cycle. > > While this is annoying compared with the usage of Iceberg, is perfectly doable: it is the same as while using metadataless filetree. > > Tonel is tested to work up to Pharo 3. Older Pharos may work (there is no reason why not) but maybe some minor adjustments are needed. > > I designed Tonel to be easily portable. I didnât used a lot of Pharo elements that would have done my life a lot easier (like using RBParser instead parsing manual). This way other dialects can take it and make it work. Now, making it work, is a problem of other dialects users (Iâm willing to help, but that work will fall in other persons). > I know it is already ported to Gemstone and it was being ported to Squeak. > > > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. > > You can save your packages as you want. > You can save a package with Iceberg and then read it with Monticello., > And viceversa. > Now, it you want to "transferâ the history from git to an mcz, you will need to do some migration tool. > > Esteban > > > > > Thx, > > > > Sven > > > > > >

Sept. 30, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Esteban Lorenzano

Hi, > On 29 Sep 2018, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? In absence of Iceberg, Tonel can be used as any other MCRepository. You can save and read your packages as it would be with a âmetadataless filetreeâ. That means, in Pharo without iceberg you need to save/read from your cloned repository. Saving to your cloned repository will write files to disk. Which means you need to go there and do a regular git commit/push cycle. While this is annoying compared with the usage of Iceberg, is perfectly doable: it is the same as while using metadataless filetree. Tonel is tested to work up to Pharo 3. Older Pharos may work (there is no reason why not) but maybe some minor adjustments are needed. I designed Tonel to be easily portable. I didnât used a lot of Pharo elements that would have done my life a lot easier (like using RBParser instead parsing manual). This way other dialects can take it and make it work. Now, making it work, is a problem of other dialects users (Iâm willing to help, but that work will fall in other persons). I know it is already ported to Gemstone and it was being ported to Squeak. > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. You can save your packages as you want. You can save a package with Iceberg and then read it with Monticello., And viceversa. Now, it you want to "transferâ the history from git to an mcz, you will need to do some migration tool. Esteban > > Thx, > > Sven > >

Sept. 30, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Gabriel Cotelli

I don't know if something changed with tonel support but with filetree if you copy a package into a Monticello repo it get converted to mcz. So I think you can have a copy of each release in a Monticello repo if you want. On Sat, Sep 29, 2018, 09:40 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new > format, what is the reach of this new technology ? Can people still load > code in older versions of Pharo ? I think 6.x is no problem, but what about > earlier versions ? What about other Smalltalk implementations ? What is the > official answer here ? > > A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > > Thx, > > Sven > > >

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Stephane Ducasse

Hi Sven > So the future for Pharo is Iceberg/git/tonel and that is fine. I'm waiting for Tonel since 2002. I should have done it. Now what was blocking me stupidly was that I wanted to have a support for Snippets (doit) and this was more in that sense a scripting syntax biais. This format will give to all the community a lot of exposure. > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Everybody in the world will be able to read your code. Which is not the case right now. > Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? I do not know. Loading a new version in an old system is always a challenge because some libraries will improve. Now if they pay us for that we can do something. Can I latex my papers about 5 years ago, clearly not. Can I run my old app on my new iphone not really. So if this is not working for paid software why should it be for free one? > What about other Smalltalk implementations ? What is the official answer here ? They are lucky Tonel is MIT and we are not against them. I would not expect other people would expect that they port freely their code to Pharo without me giving a hand. So the inverse is true. > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? No this is not possible with filetree and I do not see why it would be possible for Tonel > Just to keep it in sync. I do not know. May be somehow with time and energy can do it. One could hack MC to include Tonel inside. Now I think that there are many other things to do. Iceberg is using some part of MC now do not expect our engineers to do this for free. After people will complain that they do not work on the real value. > > Thx, > > Sven > >

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Stephane Ducasse

Hi Peter Just a note to say that I appretiate your attitude and we know it each other. I will try to use your tool when I will migrate my projects. Stef On Sat, Sep 29, 2018 at 2:32 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> - you're stealing > > > Sorry, I absolutely did not intend the evoke the notion of "stealing". > My perspective is... I am spending time to migrate someone else's code, so the last thing I want is someone burning my energy and complaining that I voided their contribution. > > I don't give a fuck if someone migrates my contribution and strips the authorship (and when I do care I don't need to rely on others to prove it). > But I want to cover my ass from backlash from other people, because I know it will happen and I know that people will complain (which is exactly what happened to you). > > So preventing the appropriation of code is not about you taking credit for other person's code, but you being covered from them accusing you of it. (It probably sounds like I am pathologically defensive, but dealing with people is exhausting for me.) > >> >>> * it is sending bad signals to potential contributors that we can scrub them anytime we want >>> >>> as you yourself have said: >>> > @People try to avoid to piss on good will of others. >>> Yet this is what it feels like to some when traces of their contributions are voided. >> >> >> And this is my third point. This "stealing" idea is mainly a matter of manners. > > > Again, I didn't intend "stealing". It's about preventing people from thinking "They don't give a fuck about their contributors, so why I should give a fuck about contributing?". It can be dispiriting for them, even if they don't care about the code itself. And they will complain... and who needs that? > >> If instead of bashing on people, we wanted to discuss on how to actually FIX the thing, here are my 2 cents: >> - From a copyright perspective it should have been enough to check the licence file and name the contributors there > > > But nobody uses the license file for that, usually there's only the original author(s) / main maintainer(s). That's why the (git) history is relevant. > >> >> - The history could have been retrieved in a separate branch and then merged (and look, we had the best of the two worlds!) >> >> - both of the things could have been then integrated through a pull request (luckily in less than one hour :)) > > > Yep. > >> >> And at the end, with the apport of everybody we could have got a repository with history, baseline and working on pharo 7. >> >> Now, from a human perspective, please let's try everybody to assume the best of the other by default. >> That will just make all interactions much more healthy. >> >> And please, this is not particularly directed to anybody, I've seen such remarks many times. Let's just think positive. >> Problems can be fixed if we talk about them, but more specifically if we are looking for solutions. > > > I will see how I can streamline the tool even further... maybe a service that will migrate entire smalltalkhub :) > > Peter

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Ben Coman

On Sat, 29 Sep 2018 at 20:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new > format, what is the reach of this new technology ? Can people still load > code in older versions of Pharo ? I think 6.x is no problem, but what about > earlier versions ? What about other Smalltalk implementations ? What is the > official answer here ? > > A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > Just to throw an idea into the mix, perhaps a read-only option for older Pharo and alternate Smalltalk implementations is to use ZIP downloads from github. https://github.com/svenvc/ston/archive/master.zip There would still be a requirement to parse Tonel, but that might be a smaller mission than supporting Iceberg or other full-Git implementation. A Metacello baseline might bootstrap Tonel to parse the unzipped file. cheers -ben

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Peter Uhnak

Hi, Can people still load code in older versions of Pharo ? I think 6.x is no > problem, but what about earlier versions ? You will need to update Metacello in older versions of Pharo to use Tonel. But Pharo <6.1 is officially not supported anyway. > What about other Smalltalk implementations ? What is the official answer > here ? > If they use Metacello, then you should be able to use Tonel. A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > As long as Iceberg uses internally a Metacello repository for Tonel, you should be able to copy a _snapshot_. If you want to keep a "in sync" history with ancestry and stuff, then I would advise against it. The history model is quite different between git and MC and you need to make compromises going in each direction. Peter

Sept. 29, 2018

Reach of Iceberg/git/tonel ?

by Sven Van Caekenberghe

Hi, So the future for Pharo is Iceberg/git/tonel and that is fine. My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. Thx, Sven

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Peter Uhnak

> > - you're stealing > Sorry, I absolutely did not intend the evoke the notion of "stealing". My perspective is... I am spending time to migrate someone else's code, so the last thing I want is someone burning my energy and complaining that I voided their contribution. I don't give a fuck if someone migrates my contribution and strips the authorship (and when I do care I don't need to rely on others to prove it). But I want to cover my ass from backlash from other people, because I know it will happen and I know that people will complain (which is exactly what happened to you). So preventing the appropriation of code is not about you taking credit for other person's code, but you being covered from them accusing you of it. (It probably sounds like I am pathologically defensive, but dealing with people is exhausting for me.) > * it is sending bad signals to potential contributors that we can scrub >> them anytime we want >> >> as you yourself have said: >> > @People try to avoid to piss on good will of others. >> Yet this is what it feels like to some when traces of their contributions >> are voided. >> > > And this is my third point. This "stealing" idea is mainly a matter of > manners. > Again, I didn't intend "stealing". It's about preventing people from thinking "They don't give a fuck about their contributors, so why I should give a fuck about contributing?". It can be dispiriting for them, even if they don't care about the code itself. And they will complain... and who needs that? If instead of bashing on people, we wanted to discuss on how to actually > FIX the thing, here are my 2 cents: > - From a copyright perspective it should have been enough to check the > licence file and name the contributors there > But nobody uses the license file for that, usually there's only the original author(s) / main maintainer(s). That's why the (git) history is relevant. > - The history could have been retrieved in a separate branch and then > merged (and look, we had the best of the two worlds!) > - both of the things could have been then integrated through a pull > request (luckily in less than one hour :)) > Yep. > And at the end, with the apport of everybody we could have got a > repository with history, baseline and working on pharo 7. > > Now, from a human perspective, please let's try everybody to assume the > best of the other by default. > That will just make all interactions much more healthy. > > And please, this is not particularly directed to anybody, I've seen such > remarks many times. Let's just think positive. > Problems can be fixed if we talk about them, but more specifically if we > are looking for solutions. > I will see how I can streamline the tool even further... maybe a service that will migrate entire smalltalkhub :) Peter

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Guillermo Polito

On Sat, Sep 29, 2018 at 12:41 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi Stef, > > I understand that everyone is short on time, but I consider not preserving > the history problematic for two reasons > > * it is appropriating someone else's work as one's own -- this seems > borderline illegal, or at the very least in violation of MIT license > Not really. If the contributors are specified in the copyright, is it stealing? Now, my point is manners. I got in 4/5 emails: - you're stupid because you did not use Peter's tool - you're inefficient because you took one hour to do it - you're stealing The first two points show first one big problem that I've seem many times with people and software: missing context. People think most of the time that "I would have done it better". But usually they don't take into account - the time constraints (I had one hour, and one hour I had) - the knowledge (where is the Artefact Repo?, why is it failing for Milton?, Do I know enough about metacello/streams/artefact to do it well?) - the working environment (does the person that did it have all the tools to work properly? does he have a healthy working environment? For example, I've worked on several big companies where you can find really bad environments...) - technical and not technical problems that are sometimes independent of the problem itself (take into account that for example, fighting against a metacello baseline is completely orthogonal to your tool or even iceberg, good internet connection) All these details are important also at the end, and they should be put into the balance too when we make a judgement. > * it is sending bad signals to potential contributors that we can scrub > them anytime we want > > as you yourself have said: > > @People try to avoid to piss on good will of others. > Yet this is what it feels like to some when traces of their contributions > are voided. > And this is my third point. This "stealing" idea is mainly a matter of manners. I really hope nobody here really thinks I wanted to take credit for Olivier, Guillaume or any of the other contributors. Still I preserved pointers to the original authors and their original website in google sites. But in the case somebody did think that, I removed the repository to remove any doubt. So again, I apologize if somebody felt offended, but I also prefer to not be called a thief. Now, when I do stuff I'm not thinking about "oh yes, I'm getting famous", that would be pretty sad for me :/. I do stuff because I just think it's useful. I DON'T CARE personally about artefact, and I don't want to take credit for it. I don't even care about the fu***ng 2 commits I did to port it to Pharo 7, I can tell anybody what I did so she/he can re-doit. Because I don't use Artefact. Now, Somebody wants the "credit"? I could have even amended a commit and put anybody else as author. My problem here is people assuming stealing by default, instead of assuming, for example, mistake. Imagine an alternative scenario: - X: "Hey Guille, could you add in the copyright X, and Y and Z? They also contributed to the project, you should take them into account..." - Guille: "Ah sure, sorry, this was not my intention, I'm so stupid, I forgot about Z. Commit push, done". If instead of bashing on people, we wanted to discuss on how to actually FIX the thing, here are my 2 cents: - From a copyright perspective it should have been enough to check the licence file and name the contributors there - The history could have been retrieved in a separate branch and then merged (and look, we had the best of the two worlds!) - both of the things could have been then integrated through a pull request (luckily in less than one hour :)) And at the end, with the apport of everybody we could have got a repository with history, baseline and working on pharo 7. Now, from a human perspective, please let's try everybody to assume the best of the other by default. That will just make all interactions much more healthy. And please, this is not particularly directed to anybody, I've seen such remarks many times. Let's just think positive. Problems can be fixed if we talk about them, but more specifically if we are looking for solutions.

Sept. 29, 2018