September 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1281: 22433-Review-FloatTest-testCopySignTo-and-testSign

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1281 was: SUCCESS. The Pull Request #1835 was integrated: "22433-Review-FloatTest-testCopySignTo-and-testSign" Pull request url: https://github.com/pharo-project/pharo/pull/1835 Issue Url: https://pharo.fogbugz.com/f/cases/22433 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

[Pharo 7.0-dev] Build #1280: 22489-cleanup--CompilationContext-and-doSemanticAnalysis

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1280 was: SUCCESS. The Pull Request #1830 was integrated: "22489-cleanup--CompilationContext-and-doSemanticAnalysis" Pull request url: https://github.com/pharo-project/pharo/pull/1830 Issue Url: https://pharo.fogbugz.com/f/cases/22489 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

[Pharo 7.0-dev] Build #1279: 22498-TextEditorsaveContentsInFile-should-not-use-FileStream

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1279 was: FAILURE. The Pull Request #1839 was integrated: "22498-TextEditorsaveContentsInFile-should-not-use-FileStream" Pull request url: https://github.com/pharo-project/pharo/pull/1839 Issue Url: https://pharo.fogbugz.com/f/cases/22498 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Pierce Ng

On Wed, Sep 26, 2018 at 07:49:10PM +0200, Norbert Hartl wrote: >>> And a lot more. This is a coarse grained overview over the >>> architecture. Iâm happy to answer further questions about this. >>> [very nice writeup] Hi Norbert, Very nice write-up, thanks. What persistence mechanism are you using - Gemstone/S, Glorp, Voyage, ...? Pierce

Sept. 30, 2018

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

by Stephane Ducasse

Thanks norbert. I accept your apologies. Stef On Sat, Sep 29, 2018 at 8:39 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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. 30, 2018

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