Github and Sourceforge are businesses and that's why they stay around. Without that, well, why not get some resources/space paid by the upcoming "loi 1901 association" in a couple of dedicated servers and set them up with your system? Sven, I am willing to work with you on this, financially included. If Pharo is going to be thriving, an ecosystem has to blossom anyway. I am about to be on holidays in 2 weeks, and you are welcome to come over for a beer and some setup fun! Phil 2012/7/4 Sven Van Caekenberghe <sven@beta9.be>

On 04 Jul 2012, at 09:28, phil@highoctane.be wrote:

...

There must be a business behind all this to take care of the funding and the daily operations.

More than a year ago I did this:

MCHttpRepository location: ' http://mc-mirror.s3-website-eu-west-1.amazonaws.com/ZincHTTPComponents/' user: '' password: ''

It is a proof of concept, a (now no longer up to date) copy of a repository DIRECTLY hosted by Amazon S3 (works only for public, read-only repositories). It would not be a lot of work to set up a copy process that keeps the mirror up to date for the top 100 projects or so. I would cost some monthly resources though.

I also did this:

http://mc.stfx.eu

which is a full MC repo (storage only) that is also backed by S3.

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

Yet more impetus to push the marketing sliders a couple of notches up. I'll ask around if I can get some support from my corporate clients to host this as they do have a ton of data centers. Phil 2012/7/4 Stéphane Ducasse <stephane.ducasse@inria.fr>

On Jul 4, 2012, at 9:49 AM, phil@highoctane.be wrote:

...

Github and Sourceforge are businesses and that's why they stay around.

Without that, well, why not get some resources/space paid by the upcoming "loi 1901 association" in a couple of dedicated servers and set them up with your system?

About S3 we want to control the cost. Now phil the problem is that so far we should check if we can pay somebody after that all the rest is a bonus. So this means that so far, somebody will do it on his free time. Marcus administrates the ESUG part during years and he can continue and we could add one SmalltalkHub Server

Our biggest concerns so far is that INRIA got staff reduction and the servers went really unstable. So may be we will roll our own.

Stef

...

Sven, I am willing to work with you on this, financially included. If

Pharo is going to be thriving, an ecosystem has to blossom anyway. I am about to be on holidays in 2 weeks, and you are welcome to come over for a beer and some setup fun!

...

Phil

2012/7/4 Sven Van Caekenberghe <sven@beta9.be>

On 04 Jul 2012, at 09:28, phil@highoctane.be wrote:

...

There must be a business behind all this to take care of the funding

and the daily operations.

...

More than a year ago I did this:

MCHttpRepository location: '

http://mc-mirror.s3-website-eu-west-1.amazonaws.com/ZincHTTPComponents/'

...

user: '' password: ''

It is a proof of concept, a (now no longer up to date) copy of a

repository DIRECTLY hosted by Amazon S3 (works only for public, read-only repositories). It would not be a lot of work to set up a copy process that keeps the mirror up to date for the top 100 projects or so. I would cost some monthly resources though.

...

I also did this:

http://mc.stfx.eu

which is a full MC repo (storage only) that is also backed by S3.

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:

phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be

...

High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

Hi guys, I volunteer for replicate hosting of basic community infractructure like forthcomming SmalltalkHub on my server located at Hetzner in Germany. Going just recently through old server crash and being able to restore main functionality back on new server in few hours, you can expect for me to have some experience running with all needed reliability and high availability in mind. By the way, dedicated server at Hetzner costs me just 50 EUR/month, and this is 4 core 16GB RAM 2x3TB disk machine. Prices are therefore so low that everyone can afford such a server now, ESUG and/or Pharo consortium at least :) Best regards Janko On 04. 07. 2012 10:23, Stéphane Ducasse wrote:

On Jul 4, 2012, at 9:28 AM, phil@highoctane.be wrote:

...

There must be a business behind all this to take care of the funding and the daily operations.

Is the consortium going to be taking care of these aspects?

It is already as a fireman.

Esteban is payed by INRIA for helping to set up the consortium and he is losing time with such issues.

Indeed we should think about how to replicate information. About smalltalkHub one deal was that INRIA will host it and replicate on three hosts. Now since smalltalkHub was delayed for more than 8 months the people changed agenda.

We will check that again with nicolas and christophe because right now it is hosted at object fusion. Now we were thinking that ESUG could help there because ESUG has also several servers to run and marcus does not have the time to deal with multiple and different servers. So one central one to manage ESUG and SmalltalkHub would make sense but nothing was acted so far.

Stef

...

Phil

2012/7/4 Torsten Bergmann <astares@gmx.de>

Norbert wrote:

...

Ok, nothing to do here. Thank you, Captain Hindsight!

While I enjoy your humor and politeness on one side I really doubt that there is nothing to do here.

How often do we face the outage of SqS. And now a private server is yet again gone without an easy restore/access to the backup. It's nice that we can all check our caches to find the mcz's - but is this the backup strategy to go for the future?

I provided the ConfigurationBrowser in Pharo to easily load Metacello packages directly from within the image and spend a lot of time checking appropriate configs for the various Pharo versions. On one side we invest in making it easier for people to load packages on the other side it often did not work due to this brickle hosting we currently have.

Don't we need a serious discussion and actions on how to get a reliable infrastructure with official mirrors?

By providing a prebuilt SqueakSource in the past [1] I hoped the SqS situation will get better when people may setup own servers and we have more and more mirrors on the net. It did not happen. We now know that SqS is the "old way".

We currently face decisions what servers to use (SS3, SmalltalkHub, ...) see issue #6093 [2]

Now we move to SS3 and SmalltalkHub. Can we answer the question how reliable they are?

I like SmalltalkHub a lot. But still it is centralized and if it is down it is down for all. Dont we need answers to the question how independent our infrastructure will be in the future? If it is backuped, mirrored or restorable?

Dale proposed mirroring for Metacello [3]. We also have filetree [4] for directory-based Monticello packages enabling the use of Git, SVN, ... allowing us to use more reliable infrastructure like GitHub, ... Should we care?

But maybe I should shut up and wait until someone reboots Squeaksource again (which is down today yet again)

Bye T.

[1] http://astares.blogspot.de/2005/12/squeaksource-server-image.html [1] http://code.google.com/p/pharo/issues/detail?id=6093 [2] http://code.google.com/p/metacello/issues/detail?id=152 [3] https://github.com/dalehenrich/filetree

-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

camillo we are not ready and we do not want to rush. Stef On Jul 4, 2012, at 1:30 PM, Camillo Bruni wrote:

IT'S CALLED GIT!!! ++++++++++++++++++

Or like any other service that is also used by non smalltalkers!

It's incredible how much effort goes into improving something like Monticello, where there are stable wide spread solutions out there that work since years.

- We have an alpha implementation of FS-Git - We have a quite stable implementation of Filetree - We have a quite stable implementation of Cypress

I really like Smalltalkhub, but if we could focus such an effort on these 3 tools here, we can have a nice solution that outperforms MC in **EVERY** aspect.

I do not have much time on my side right now, but I am working towards a fully git based solution in pharo, and everybody else should too.

cami

Frustration is a good thing. Especially as a strong motivation factor :-D All Smalltalk is nice but I doubt Freetype and Cairo are very Smalltalkish. And Git itself is quite a couple a moving parts on the client side. That kind of argument is moot. As long as you are able to make it run properly, and it is useful, why not becoming our Git-hero ? :-p 2012/7/4 Camillo Bruni <camillobruni@gmail.com>

On 2012-07-04, at 13:50, Stéphane Ducasse wrote:

...

camillo

we are not ready and we do not want to rush.

you're kidding me... FS-Git is out there since 2 damn years!

- I did a 1 week sprint to improve the performance on it and fix some bugs - I wrote in 1 day a tiny wrapper around it so a git repos can be directly used with MC

=> So I recycle 100% of the UI AKA being backwards compatible from MC VersionInfo on

Captain Hindsight speeking:

If we'd invested the time gone into Smalltalk into that project we would already be done!

But somebody had to push that smalltalkhub thing right?

I remember I already had a hard fight here on the mailing list in favor of git. So I am particularly frustrated.

...

On Jul 4, 2012, at 1:30 PM, Camillo Bruni wrote:

...

IT'S CALLED GIT!!! ++++++++++++++++++

Or like any other service that is also used by non smalltalkers!

It's incredible how much effort goes into improving something like Monticello, where there are stable wide spread solutions out there that work since years.

- We have an alpha implementation of FS-Git - We have a quite stable implementation of Filetree - We have a quite stable implementation of Cypress

I really like Smalltalkhub, but if we could focus such an effort on these 3 tools here, we can have a nice solution that outperforms MC in **EVERY** aspect.

I do not have much time on my side right now, but I am working towards a fully git based solution in pharo, and everybody else should too.

cami

On 04 Jul 2012, at 14:41, Goubier Thierry wrote:

I'm using filetree, which works, but requires that double work flow : Save in monticello, and a quite complex sequence of git commands so that all the changes are taken in account.

That is my point exactly: it is not that it is difficult, but you have to work in two environments (image/terminal/git-app) and be extra careful not to make mistakes (like saving two versions locally without committing). I would also like to have the list of MC package versions inside the image and compare things there. Moving to files and even using github to compare versions is way less useful than comparing things in Smalltalk.

Sven, It's actually Cami and Max that are doing the work ... The sequence of events as I seem them are: 1. git compatible package format (Cypress/FileTree) ... DONE 2. Metacello support for git/github (in progress) 3. in-image support for git operations (in progress) There are a handful of folks who have already started using FileTree/git/github for their projects. I am a week or so away from a preview release of Metacello support for git/github (including the Metacello scripting api). I frankly haven't had the time to work with the Fs-Git stuff. but once I've got Metacello git/github aware I will be able to raise my head up and look around:) Dale ----- Original Message ----- | From: "Sean P. DeNigris" <sean@clipperadams.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 7:44:18 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | | Sven Van Caekenberghe wrote | > | > That is my point exactly: it is not that it is difficult, but you | > have to | > work in two environments (image/terminal/git-app) and be extra | > careful not | > to make mistakes (like saving two versions locally without | > committing). | > | | This is just a temporary situation. Dale is working on git | integration with | the image... | | -- | View this message in context: | http://forum.world.st/renggli-mirror-created-on-smalltalkhub-tp4638011p46382... | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | |

On 04 Jul 2012, at 13:50, phil@highoctane.be wrote:

I am using Mercurial for all of the other projects and technologies.

With a full copy of everything locally, it helps indeed when we get crashes...

But GIT/Hg isn't giving you the change sorter.

I have used/tried FileTree/Git(hub) a bit and it is cool and it works. But I do miss (tools) integration in the image. The workflow also changes a bit, it is no longer all Smalltalk. IMHO it is not yet quite ready. Sven

On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin <chaetal@gmail.com> wrote:

Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a give up on hopes for a real object-oriented source control/management as it could and should be in Smalltalk?

can you think of any feature we could have now we couldn't with Git? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

On Wed, Jul 4, 2012 at 3:29 PM, Dennis Schetinin <chaetal@gmail.com> wrote:

I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No?

I think using git or another VCS would prevent us from having this bright future :-). Git for example won't store diffs or patches, it saves the end result. Nothing prevent us from adding meta-data to a commit to remember we did a refactoring at this point. I don't see how the situation could be any better with object-oriented VCS. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

What can you do else than storing text?

I think of storing objects that represent operations I applied to my program: an ivar was renamed, a piece of code was extracted as a method, a method was moved to another class, etc. And those *live objects* can have a behavior that allows them to be applied to another program. This way I can think of applying other users' modifications to the code I've already modified: e.g., I've just renamed the same ivar (among other changes I don't want to loose), but the name my coworker invented was better and I want to apply that *particular* change. In short, I would like to avoid treating source code as a text (which is just one possible way of representation) and keep it as live objects. Does it sound absolutely incapable? Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 4 July 2012 г. at 17:37, Camillo Bruni wrote:

On 2012-07-04, at 15:30, Dennis Schetinin wrote:

...

On Wednesday, 4 July 2012 г. at 16:11, Damien Cassou wrote:

...

On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin <chaetal@gmail.com (mailto:chaetal@gmail.com)> wrote:

...

Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a give up on hopes for a real object-oriented source control/management as it could and should be in Smalltalk?

can you think of any feature we could have now we couldn't with Git? I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No?

that has nothing to do with versioning per se.

You can always hook in a different merger for git (that's already a built in feature) which simply redirects over a Pharo image and applies some more ST logic there.

Going for something that is even more st specific is a waste of time IMO. What can you do else than storing text? ASTs? besides being incompatible with the whole world of text editable things you won't win much :/. Besides source code is quite a compact representation of ast's itself...

cami

Le 04/07/2012 15:58, Damien Cassou a écrit :

On Wed, Jul 4, 2012 at 3:54 PM, Dennis Schetinin <chaetal@gmail.com> wrote:

...

I think of storing objects that represent operations I applied to my program: an ivar was renamed, a piece of code was extracted as a method, a method was moved to another class, etc. And those *live objects* can have a behavior that allows them to be applied to another program. This way I can think of applying other users' modifications to the code I've already modified: e.g., I've just renamed the same ivar (among other changes I don't want to loose), but the name my coworker invented was better and I want to apply that *particular* change.

you have semantic patches for that. See coccinelle http://coccinelle.lip6.fr/sp.php

Have you really tried to write patches in Smpl for Coccinelle to say that ? Smpl is great, but for a broken developement model. How do you think you manage conditional code (#ifdef and friends) with tools like that ? It's a lot easier to do semantic actions on source code when you have a nice semantic layer on top of it (as Smalltalk provides). I don't think you will find equivalents. You will find work-arounds on text-based systems which may fit. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Stef, I agree ... my intent is to make it possible for individual projects to make the "git/github or not decision". Git/github support will be built into the next release of Metacello and will make it possible for folks who don't have the time to learn git to still use projects hosted by github. Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 7:10:40 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | Guys | | I'm sorry to tell you that but I personally do not have 5 min of | energy for GIT for pharo 2.0 | I want to focus my energy on finishing the tasks we decided a while | ago. | Personally a working Squeaksource is good enough for now. | | Stef | | |

Regarding .json vs .ston, it's in the works, if only STON had been available when we agreed upon the original implementation ... the next version of the format (there are a couple more tweaks that are being queued up) will very likely use STON ... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 11:36:42 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | I know :) | Now I have so many dreams that I just do not want to start any of | them before I finish. finish what should be finished. | | About cypress if we could replace .json but .ston I would be happier | And if we could save coral syntax for method even better. | | Stef | | On Jul 4, 2012, at 6:43 PM, Dale Henrichs wrote: | | > Stef, | > | > I agree ... my intent is to make it possible for individual | > projects to make the "git/github or not decision". Git/github | > support will be built into the next release of Metacello and will | > make it possible for folks who don't have the time to learn git to | > still use projects hosted by github. | > | > Dale | > | > ----- Original Message ----- | > | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Wednesday, July 4, 2012 7:10:40 AM | > | Subject: Re: [Pharo-project] renggli mirror created on | > | smalltalkhub | > | | > | Guys | > | | > | I'm sorry to tell you that but I personally do not have 5 min of | > | energy for GIT for pharo 2.0 | > | I want to focus my energy on finishing the tasks we decided a | > | while | > | ago. | > | Personally a working Squeaksource is good enough for now. | > | | > | Stef | > | | > | | > | | > | | |

On Wed, Jul 4, 2012 at 4:08 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Have you really tried to write patches in Smpl for Coccinelle to say that ?

Smpl is great, but for a broken developement model. How do you think you manage conditional code (#ifdef and friends) with tools like that ?

I was just saying that semantic patches already exist for text files so we don't have to reinvent the wheel. What we want, for sure, is that these files are generated automatically :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dennis, If you look at the Cypress format[1] (used by FileTree), it is the Monticello package structure "serialized to disk". Reading the Cypress format from disk is no different than materializing the Monticello package structure from an .mcz file. So any program that an reason about the definitions from an .mcz file can reason about the definitions from the Cypress format. Cypress format may look like text, but to me I see Smalltalk objects:) Dale [1] https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-ST... ----- Original Message ----- | From: "Dennis Schetinin" <chaetal@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 6:29:40 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | | On Wednesday, 4 July 2012 г. at 16:11, Damien Cassou wrote: | | | | | On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin < chaetal@gmail.com | > wrote: | | | | Am I wrong considering migration to Git-or-AnythingElseTextOriented | to be a | give up on hopes for a real object-oriented source control/management | as it | could and should be in Smalltalk? | | | can you think of any feature we could have now we couldn't with Git? | I didn't say "now", I talked about "hopes". E.g. hopes for "Source" | Control Tool being aware of refactorings and other *operations* I | apply to my program, instead of treating it as a plain text with | some changes of unknown nature. I'm not sure it's possible right now | (I know it's not, better to say?). But with a Smalltalk-based source | control we can have it on one splendid day in the future. And I | think on the Git way we'll finish with just some advanced | text-comparison algorithms. No? | | | | Best regards, | Dennis Schetinin | Sent with Sparrow

Dale, Thank you for all (this and other) explanations you provided on the topic. When the topic is to provide another backend for storing Smalltalk code, it's absolutely ok and all the advantages are understood. But when some people say something like "source code is text and nothing more" (at least that's what I hear, though I can be mistaking) and we shouldn't reinvent the wheel… and I see it in context of "Smalltalk is so unpopular"… and the logic is something like: we should popularize it — hence we should use (preferably, only) git for source-code control — and we should abandon images because most developers do not like them, etc, etc. Well, it's a bit scaring, because when I try to extrapolate and understand where it is leading us, I wonder where's Smalltalk there? Do we need it at all?! :) Once again, I just feel this tendency in our society, and it's very likely I'm misunderstanding and absolutely wrong. I'll be glad to know I am, so I just wanted to clarify. Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 4 July 2012 г. at 20:30, Dale Henrichs wrote:

Dennis,

If you look at the Cypress format[1] (used by FileTree), it is the Monticello package structure "serialized to disk". Reading the Cypress format from disk is no different than materializing the Monticello package structure from an .mcz file. So any program that an reason about the definitions from an .mcz file can reason about the definitions from the Cypress format.

Cypress format may look like text, but to me I see Smalltalk objects:)

Dale

[1] https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-ST... ----- Original Message ----- | From: "Dennis Schetinin" <chaetal@gmail.com (mailto:chaetal@gmail.com)> | To: Pharo-project@lists.gforge.inria.fr (mailto:Pharo-project@lists.gforge.inria.fr) | Sent: Wednesday, July 4, 2012 6:29:40 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | | On Wednesday, 4 July 2012 г. at 16:11, Damien Cassou wrote: | | | | | On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin < chaetal@gmail.com (mailto:chaetal@gmail.com) | > wrote: | | | | Am I wrong considering migration to Git-or-AnythingElseTextOriented | to be a | give up on hopes for a real object-oriented source control/management | as it | could and should be in Smalltalk? | | | can you think of any feature we could have now we couldn't with Git? | I didn't say "now", I talked about "hopes". E.g. hopes for "Source" | Control Tool being aware of refactorings and other *operations* I | apply to my program, instead of treating it as a plain text with | some changes of unknown nature. I'm not sure it's possible right now | (I know it's not, better to say?). But with a Smalltalk-based source | control we can have it on one splendid day in the future. And I | think on the Git way we'll finish with just some advanced | text-comparison algorithms. No? | | | | Best regards, | Dennis Schetinin | Sent with Sparrow

Hi, No, what is wrong is considering monticello itself an object oriented control management system. Right now MC does not provides anything that can be thought as that... even more, MC does not provides anything better than current CMS around... So, what we have now is an old CMS, and a lot of tools trying to be compatible with that old system. Imagine if GIT would tried to be compatible with CVS... and to create an object control management is a considerable effort, no one want to do, and probably pointless... at least right now. best, Esteban On Jul 4, 2012, at 2:09 PM, Dennis Schetinin wrote:

Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a give up on hopes for a real object-oriented source control/management as it could and should be in Smalltalk?

Best regards, Dennis Schetinin Sent with Sparrow

On Wednesday, 4 July 2012 г. at 16:02, Sven Van Caekenberghe wrote:

...

On 04 Jul 2012, at 13:50, phil@highoctane.be wrote:

...

I am using Mercurial for all of the other projects and technologies.

With a full copy of everything locally, it helps indeed when we get crashes...

But GIT/Hg isn't giving you the change sorter.

I have used/tried FileTree/Git(hub) a bit and it is cool and it works. But I do miss (tools) integration in the image. The workflow also changes a bit, it is no longer all Smalltalk.

IMHO it is not yet quite ready.

Sven

On 2012-07-04, at 15:34, Dennis Schetinin wrote:

"MC is not good enough" and "We should use Git" are a bit different thoughts.

MC's model of versioning stuff / changes representation is fairly ok However everything that leaves the image is deadly broken :D So the main issue here is the MC backends which are horribly inefficient and do not scale very well. Then there are of course issues in the image itself: - a merge browser that doesn't allow me to merge manually (that has to be improved) - a complete parallel structure for describing methods / classes ... - UI tools that literally are from the last century

If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why.

Git is a storage mechanism which scales and opens up smalltalk to people which don't like images.

On Jul 4, 2012, at 4:02 PM, Goubier Thierry wrote:

Le 04/07/2012 15:40, Camillo Bruni a écrit :

...

On 2012-07-04, at 15:34, Dennis Schetinin wrote:

...

"MC is not good enough" and "We should use Git" are a bit different thoughts.

MC's model of versioning stuff / changes representation is fairly ok

...

However everything that leaves the image is deadly broken :D So the main issue here is the MC backends which are horribly inefficient and do not scale very well.

Then there are of course issues in the image itself: - a merge browser that doesn't allow me to merge manually (that has to be improved) - a complete parallel structure for describing methods / classes ... - UI tools that literally are from the last century

...

If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why.

Git is a storage mechanism which scales and opens up smalltalk to people which don't like images.

Would it really opens up Smalltalk to people which don't like images ? Should Pharo be like Eclipse then ?

Each time I come back to Smalltalk (and it happened me a few times over the last, what, 15 years) I do feel like coming back to the future : no more mess of long, unmanageable source files, a well structured code model (and adequate GUI, even if it looks old, but this is a lot a matter of finish). And on that, the feeling of performance given by Pharo (ah! instant startup times) is great, thanks.

Writing thousands of lines of C code under a mess of files, headers, dependencies, bad or overly complex source code management systems (cvs, svn, git), bad, messy and not-working package and build systems (autoconf, maven, make, cmake, shell scripts, python scripts, perl scripts, you name it!), a hundred different editors all missing one feature you really like, and you want to drag me back into that ?

Sorry, but I don't think I want that.

+100

A MC backend which would allow me to use a git central repository without touching one line of git, yes.

amen (but it *does not* has to be MC... just an equivalent tool)

Remember that some programmers are using tools such as bazaar to work with git repos so that they don't have to deal with git directly.

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dennis, The work that Cami, Max and I are doing leverages Monticello - Monticello is beautiful... only the external storage format is being replaced ... swapping out .mcz files for Cypress package structure.... by replacing a zip file with git we are gaining the power of git (distributed scm ... the whole repository copied when you 'clone') without giving up the advantages of the Monticello package structure. Once we are using git, we can leverage the power of GitHub ... Dale ----- Original Message ----- | From: "Dennis Schetinin" <chaetal@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 6:34:39 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | | "MC is not good enough" and "We should use Git" are a bit different | thoughts. If MC is not good enough we should improve it or create | better tools, but (for me) Git seems to be a wrong direction for | that. I've tried to explain in another message why. | | | | | | Best regards, | Dennis Schetinin | Sent with Sparrow | | | | On Wednesday, 4 July 2012 г. at 16:17, Esteban Lorenzano wrote: | | | | | Hi, | | No, what is wrong is considering monticello itself an object oriented | control management system. Right now MC does not provides anything | that can be thought as that... even more, MC does not provides | anything better than current CMS around... | So, what we have now is an old CMS, and a lot of tools trying to be | compatible with that old system. Imagine if GIT would tried to be | compatible with CVS... and to create an object control management is | a considerable effort, no one want to do, and probably pointless... | at least right now. | | | best, | Esteban | | | | | | On Jul 4, 2012, at 2:09 PM, Dennis Schetinin wrote: | | | | | Am I wrong considering migration to Git-or-AnythingElseTextOriented | to be a give up on hopes for a real object-oriented source | control/management as it could and should be in Smalltalk? | | | | Best regards, | Dennis Schetinin | Sent with Sparrow | | | | On Wednesday, 4 July 2012 г. at 16:02, Sven Van Caekenberghe wrote: | | | | | | | | On 04 Jul 2012, at 13:50, phil@highoctane.be wrote: | | | | | | I am using Mercurial for all of the other projects and technologies. | | | With a full copy of everything locally, it helps indeed when we get | crashes... | | | But GIT/Hg isn't giving you the change sorter. | | | I have used/tried FileTree/Git(hub) a bit and it is cool and it | works. | But I do miss (tools) integration in the image. | The workflow also changes a bit, it is no longer all Smalltalk. | | | IMHO it is not yet quite ready. | | | Sven | | | | |

Dale, thanks. I'd be happy to be able to use that; I'll have a look to test that. Thierry Le 04/07/2012 17:21, Dale Henrichs a écrit :

Dennis,

Of course not ... There are tons of resources that we Smalltalkers use that are not "turtles all the way down" ... What issue tracker is used by Pharo? When you download your pharo image and changes file is that web-site a Smalltalk site?

Right now, the combination of git/github is superior to anything written in Smalltalk. Have you taken a look at the most excellent collaboration features available on github? GitHub is used by over a million developers and they are constantly adding new features/capabilities ...

Do I think that everyone should drop what they are doing and move to git/github? NO!

If you want to provide a Smalltalk-based solution that is superior to git/github, I say "get cracking"! We've been in need of a replacement for SqueakSource for at 2-3 years now, but github sets the bar pretty high:)

I and a few others (Cami and Max Leske) are working on opening up the world of git/github to the Smalltalk community. The work we are doing is firmly grounded in Monticello and when it is done, you should have an experience that isn't much different than using the MonticelloBrowser and SqueakSource today ...

As Stef and Sven have indicated it's not quite ready...

FileTree[1] is ready right now, but to use it you must do your git operations from the command line ... Also, if you want other developers to have easy access to your Monticello packages, you still have to publish them as .mcz files. A bit painful, but I've been doing most of my development since January this way...

I am currently working on a release of Metacello[2] that will be git/github aware. When ready, you will be able to use git/github for your development and publish a Metacello configuration referencing your project on GitHub without having to publish separate .mcz files. And developers using your project won't have to understand git/github as the Monticello packages will be downloaded by Metacello.

I've created a sample project[3] that you can load into your image, if you want to get an idea what the GitHub support will look like.

The FSGit project[4] that Cami referred to will provide image-level support for manipulating git and github.

The Cypress project[5] is a project for sharing Smalltalk source code across multiple Smalltalk dialects. Currently there are 6 Smalltalk dialects that can not only share Smalltalk source code, but use git/github as the common SCM:

- Pharo - Squeak - GemStone - VW - Amber - Cuis

I encourage you to take a look at my STIC presentation on "Practical Git for Smalltalk"[6] for some more background info (sorry the video isn't available yet).

If you interested in following the progress of the projects, keep an eye on the Metacello mailing list[7]. I should have a preview version of Metacello available within a couple of weeks...Contributors are also welcome!

Dale

[1] https://github.com/dalehenrich/filetree/blob/pharo1.3/README.md [2] https://github.com/dalehenrich/metacello-work [3] https://github.com/dalehenrich/sample/blob/master/README.md [4] https://github.com/dalehenrich/FSGit [5] https://github.com/CampSmalltalk/Cypress/blob/master/README.md [6] http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk [7] http://forum.world.st/Monticello-Metacello-f1460836.html ----- Original Message ----- | From: "Dennis Schetinin" <chaetal@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 5:09:54 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | | Am I wrong considering migration to Git-or-AnythingElseTextOriented | to be a give up on hopes for a real object-oriented source | control/management as it could and should be in Smalltalk? | | | | Best regards, | Dennis Schetinin | Sent with Sparrow | | | | On Wednesday, 4 July 2012 г. at 16:02, Sven Van Caekenberghe wrote: | | | | | | | On 04 Jul 2012, at 13:50, phil@highoctane.be wrote: | | | | | | I am using Mercurial for all of the other projects and technologies. | | | With a full copy of everything locally, it helps indeed when we get | crashes... | | | But GIT/Hg isn't giving you the change sorter. | | | I have used/tried FileTree/Git(hub) a bit and it is cool and it | works. | But I do miss (tools) integration in the image. | The workflow also changes a bit, it is no longer all Smalltalk. | | | IMHO it is not yet quite ready. | | | Sven | |

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Camillo Bruni wrote:

On 2012-07-04, at 14:02, Sven Van Caekenberghe wrote:

...

On 04 Jul 2012, at 13:50, phil@highoctane.be wrote:

...

I am using Mercurial for all of the other projects and technologies.

With a full copy of everything locally, it helps indeed when we get crashes...

But GIT/Hg isn't giving you the change sorter. I have used/tried FileTree/Git(hub) a bit and it is cool and it works. But I do miss (tools) integration in the image. The workflow also changes a bit, it is no longer all Smalltalk.

IMHO it is not yet quite ready.

indeed. I remember that my solution didn't change a thing from the image side experience. It was "simply" a git backend for MC.

But, well, you should then do something with near-zero obstacle experience, like mirroring all included-by-default packages on github or butbucket, uploading your wrapper/backend with ConfigurationOf and all bells and whistles into some MC repository (SmalltalkHub?), include with it the code that automatically re-assigns repository paths from SqueakSource/whatever into github, so people can just load it and get in. That way, more or them could actually try. Herby

On 04 Jul 2012, at 14:23, Camillo Bruni wrote:

On 2012-07-04, at 14:02, Sven Van Caekenberghe wrote:

...

On 04 Jul 2012, at 13:50, phil@highoctane.be wrote:

...

I am using Mercurial for all of the other projects and technologies.

With a full copy of everything locally, it helps indeed when we get crashes...

But GIT/Hg isn't giving you the change sorter.

I have used/tried FileTree/Git(hub) a bit and it is cool and it works. But I do miss (tools) integration in the image. The workflow also changes a bit, it is no longer all Smalltalk.

IMHO it is not yet quite ready.

indeed. I remember that my solution didn't change a thing from the image side experience. It was "simply" a git backend for MC.

But maybe we are talking about different things ? I used Dale's stuff ( http://github.com/svenvc ), is your FS-Git different ? Where can we read about it ? (a.k.a. documentation ;-) Sven

On 4 July 2012 13:23, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2012-07-04, at 14:02, Sven Van Caekenberghe wrote:

...

On 04 Jul 2012, at 13:50, phil@highoctane.be wrote:

...

I am using Mercurial for all of the other projects and technologies.

With a full copy of everything locally, it helps indeed when we get crashes...

But GIT/Hg isn't giving you the change sorter.

I have used/tried FileTree/Git(hub) a bit and it is cool and it works. But I do miss (tools) integration in the image. The workflow also changes a bit, it is no longer all Smalltalk.

IMHO it is not yet quite ready.

indeed. I remember that my solution didn't change a thing from the image side experience. It was "simply" a git backend for MC.

Gitocello [1] takes this approach. While Tim Felgentreff started it to ease porting between Squeak and GNU Smalltalk, it works just fine as a new MC backend. I use it a fair bit [2][3][4]. Mind you I _haven't_ tried collaboration with it. If you had conflicts you would need to use git to address the conflicts, and you can have "inter-method" conflicts which are impossible with FileTree. (In other words, conflict markers could start in one method and end in another.) Probably the chunk format's date stuff would get annoying, as well. [1] https://github.com/timfel/gitocello [2] https://github.com/frankshearar/Unification [3] https://github.com/frankshearar/PersistentUnionFind [4] https://github.com/frankshearar/Zippers frank

different things, Camillo, probably need different answers :) sources can be replaced by file-per-class, changes (since is a delta, not a class), cannot. Let's don't try to replace a silver bullet with another silver bullet... better an arsenal of good fitted answers. Esteban On Jul 4, 2012, at 2:52 PM, Camillo Bruni wrote:

...

Gitocello [1] takes this approach. While Tim Felgentreff started it to ease porting between Squeak and GNU Smalltalk, it works just fine as a new MC backend. I use it a fair bit [2][3][4].

Mind you I _haven't_ tried collaboration with it. If you had conflicts you would need to use git to address the conflicts, and you can have "inter-method" conflicts which are impossible with FileTree. (In other words, conflict markers could start in one method and end in another.) Probably the chunk format's date stuff would get annoying, as well.

[1] https://github.com/timfel/gitocello [2] https://github.com/frankshearar/Unification [3] https://github.com/frankshearar/PersistentUnionFind [4] https://github.com/frankshearar/Zippers

frank

ah nice, though you went for the one file per class approach.

Which I think is not the best solution for pharo. For instance I want to replace the .changes / .sources file with one git repository which allows you to simply load new changes on demand and find methods with a minimal effort :)

On 2012-07-04, at 15:01, Frank Shearar wrote:

On 4 July 2012 13:52, Camillo Bruni <camillobruni@gmail.com> wrote:

...

...

Gitocello [1] takes this approach. While Tim Felgentreff started it to ease porting between Squeak and GNU Smalltalk, it works just fine as a new MC backend. I use it a fair bit [2][3][4].

Mind you I _haven't_ tried collaboration with it. If you had conflicts you would need to use git to address the conflicts, and you can have "inter-method" conflicts which are impossible with FileTree. (In other words, conflict markers could start in one method and end in another.) Probably the chunk format's date stuff would get annoying, as well.

[1] https://github.com/timfel/gitocello [2] https://github.com/frankshearar/Unification [3] https://github.com/frankshearar/PersistentUnionFind [4] https://github.com/frankshearar/Zippers

frank

ah nice, though you went for the one file per class approach.

Which I think is not the best solution for pharo. For instance I want to replace the .changes / .sources file with one git repository which allows you to simply load new changes on demand and find methods with a minimal effort :)

Well, "you" is "Tim", but sure. Yes. I like Gitocello's approach because I can use GitHub without having 1000 mini files.

I know that doesn't sound super tempting :P

I also like FileTree's approach of method-per-file, because that's the natural granularity of Smalltalk code. I seem to recall Sean DeNigris showing a screenshot of vim that "stitched" multiple files together to solve the "FileTree problem".

I guess one could write a small vim / emacs plugin to ease development with tons of tiny files :) (and here we go, #sendersOf for vim, anyone?)

And I'd say that yes, if you changed the .changes file into a repo (which is an awesome idea), you'd definitely want method-per-file. You get method history for free!

YES! :) plus one that actually scales!

Yes, FileTree is actually modeling the Monticello definition structure on disk ... git does a very good job of tracking changes at the method level when methods are stored in separate files (it recognizes method renames) ... multiple files makes reading source on disk a bit awkward, but that's what we've got the Smalltalk image for ... how many people out there unzip their .mcz files to read Smalltalk source? Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 6:01:19 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | On 4 July 2012 13:52, Camillo Bruni <camillobruni@gmail.com> wrote: | >> Gitocello [1] takes this approach. While Tim Felgentreff started | >> it to | >> ease porting between Squeak and GNU Smalltalk, it works just fine | >> as a | >> new MC backend. I use it a fair bit [2][3][4]. | >> | >> Mind you I _haven't_ tried collaboration with it. If you had | >> conflicts | >> you would need to use git to address the conflicts, and you can | >> have | >> "inter-method" conflicts which are impossible with FileTree. (In | >> other | >> words, conflict markers could start in one method and end in | >> another.) | >> Probably the chunk format's date stuff would get annoying, as | >> well. | >> | >> | >> [1] https://github.com/timfel/gitocello | >> [2] https://github.com/frankshearar/Unification | >> [3] https://github.com/frankshearar/PersistentUnionFind | >> [4] https://github.com/frankshearar/Zippers | >> | >> frank | > | > ah nice, though you went for the one file per class approach. | > | > Which I think is not the best solution for pharo. | > For instance I want to replace the .changes / .sources file with | > one git repository which allows you to simply load new changes on | > demand and find methods with a minimal effort :) | | Well, "you" is "Tim", but sure. Yes. I like Gitocello's approach | because I can use GitHub without having 1000 mini files. I also like | FileTree's approach of method-per-file, because that's the natural | granularity of Smalltalk code. I seem to recall Sean DeNigris showing | a screenshot of vim that "stitched" multiple files together to solve | the "FileTree problem". And I'd say that yes, if you changed the | .changes file into a repo (which is an awesome idea), you'd | definitely | want method-per-file. You get method history for free! | | frank | |

embedded reply ----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier@cea.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, July 5, 2012 1:32:13 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | Le 04/07/2012 17:50, Dale Henrichs a écrit : | > Yes, | > | > FileTree is actually modeling the Monticello definition structure | > on disk ... git does a very good job of tracking changes at the | > method level when methods are stored in separate files (it | > recognizes method renames) ... | | Well, there is still the fact that : | | - One version of Filetree over the past months changed the name of | the | directory from PackageName to PackageName.package; kind of messed up | the | git history tracking... | | - And git really likes to do git add for all the new files that | appears | on a regular basis. Changing package structure as opposed to changing package content does unnecessarily perturb the git history. I think that since I've started working with FileTree I've gone through 5 different disk formats:) With multiple dialects on board the rate of change will be slower (a good thing). | | It still shows that the Smalltalk/via Filetree model isn't the one | git | expects, but we do benefit from it. I'm also not certain git would | follow class renames. There aren't really any files outside of the properties file that are associated with a class in this model, so there's nothing explicit to track ... the methods in the class will be tracked nicely (as a rename). | | > multiple files makes reading source on disk a bit awkward, but | > that's what we've got the Smalltalk image for ... how many people | > out there unzip their .mcz files to read Smalltalk source? | | Me! | | I do open .mcz files at times; I appreciate the fact it's as easy as | clicking on it and then search into the produced files. | | The fact that Linux recognize them as zip archives helps, too. Haha...well the directory structure is searchable, too .. just a more complicated incantation:) Dale

----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier@cea.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, July 5, 2012 7:37:18 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | Le 05/07/2012 15:59, Dale Henrichs a écrit : | > | It still shows that the Smalltalk/via Filetree model isn't the | > | one | > | git | > | expects, but we do benefit from it. I'm also not certain git | > | would | > | follow class renames. | > | > There aren't really any files outside of the properties file that | > are associated with a class in this model, so there's nothing | > explicit to track ... the methods in the class will be tracked | > nicely (as a rename). | | So that's different from the current FileTree format then ? The | FileTree | I do use has .class directories. Not different. .class directories are used, but directories aren't objects in git ... only files are managed ... directory structure is simply reflected in the "name" of the file ... so changing a directory name (rename class) shows up as renaming all of the files under that directory. There isn't an explicit file that represents the class itself other than the properties file in .class directory ... | | > | | > | > multiple files makes reading source on disk a bit awkward, but | > | > that's what we've got the Smalltalk image for ... how many | > | > people | > | > out there unzip their .mcz files to read Smalltalk source? | > | | > | Me! | > | | > | I do open .mcz files at times; I appreciate the fact it's as | > | easy as | > | clicking on it and then search into the produced files. | > | | > | The fact that Linux recognize them as zip archives helps, too. | > | > Haha...well the directory structure is searchable, too .. just a | > more complicated incantation:) | | Yes, that's true. Both formats are nice in my opinion: mcz since they | can easily be carried around and have a nice way of showing version | and | developper; and the a file per method, a directory for a class is ok | too. Agreed, not perfect, but the current structure is navigable. | | So far, in my experience, all version control systems have to be | "encaged" in a set of rules of use to fit the work culture of the | team, | group or lab. At the moment, I'm not entirely sure of the rules | followed | in the Pharo culture, so I'm a bit hesitant to raise issues (and tend | to | bring along a small set of changes to be made each time I restart | from a | fresh Pharo image, including a few gophers to get the packages I | need). Right now we are in the very early stages of learning how to use git with Smalltalk ... FileTree is the first step, but it is clear that we need more work ... FileTree is perfectly usable for folks that are comfortable with git and the command line, but it's not for everyone. We need a bit more tools support ... and development is under way, but not yet fully integrated into the development environment ... we are still gaining experience and in the process of discovering best practices for Smalltalk. | | Maybe a small documentation about how to keep an image up-to-date? | How | to deal with slices? A way to extract all the changes on a package as | a | change set? Once we have Metacello support for git/github, then I'll write some documentation ... right now I have a workspace that looks like the following: Metacello new baseline: 'Metacello'; repository: 'filetree:///opt/git/metacello-work/repository'; load. Metacello new baseline: 'FileTree'; repository: 'filetree:///opt/git/filetree/repository'; load. for refreshing my image from the git repositories, but I also may do something a bit more automatic[1], but I haven't quite gotten to that point in my development:) [1] https://github.com/dalehenrich/metacello-work/issues/33 | | In a way, Monticello is very convincing and powerfull (maybe just | because it works as it is and is integrated), and in others, it's | annoying to see how more powerfull and better it could be. There's always room for improvement, but there's not always the time:) Dale

yes we discussed about that with marcus. Now our concern was more about the people maintaining it. Stef On Jul 4, 2012, at 11:30 AM, Janko Mivšek wrote:

Hi guys,

I volunteer for replicate hosting of basic community infractructure like forthcomming SmalltalkHub on my server located at Hetzner in Germany.

Going just recently through old server crash and being able to restore main functionality back on new server in few hours, you can expect for me to have some experience running with all needed reliability and high availability in mind.

By the way, dedicated server at Hetzner costs me just 50 EUR/month, and this is 4 core 16GB RAM 2x3TB disk machine. Prices are therefore so low that everyone can afford such a server now, ESUG and/or Pharo consortium at least :)

Best regards Janko

On 04. 07. 2012 10:23, Stéphane Ducasse wrote:

...

On Jul 4, 2012, at 9:28 AM, phil@highoctane.be wrote:

...

There must be a business behind all this to take care of the funding and the daily operations.

Is the consortium going to be taking care of these aspects?

It is already as a fireman.

Esteban is payed by INRIA for helping to set up the consortium and he is losing time with such issues.

Indeed we should think about how to replicate information. About smalltalkHub one deal was that INRIA will host it and replicate on three hosts. Now since smalltalkHub was delayed for more than 8 months the people changed agenda.

We will check that again with nicolas and christophe because right now it is hosted at object fusion. Now we were thinking that ESUG could help there because ESUG has also several servers to run and marcus does not have the time to deal with multiple and different servers. So one central one to manage ESUG and SmalltalkHub would make sense but nothing was acted so far.

Stef

...

Phil

2012/7/4 Torsten Bergmann <astares@gmx.de>

Norbert wrote:

...

Ok, nothing to do here. Thank you, Captain Hindsight!

While I enjoy your humor and politeness on one side I really doubt that there is nothing to do here.

How often do we face the outage of SqS. And now a private server is yet again gone without an easy restore/access to the backup. It's nice that we can all check our caches to find the mcz's - but is this the backup strategy to go for the future?

I provided the ConfigurationBrowser in Pharo to easily load Metacello packages directly from within the image and spend a lot of time checking appropriate configs for the various Pharo versions. On one side we invest in making it easier for people to load packages on the other side it often did not work due to this brickle hosting we currently have.

Don't we need a serious discussion and actions on how to get a reliable infrastructure with official mirrors?

By providing a prebuilt SqueakSource in the past [1] I hoped the SqS situation will get better when people may setup own servers and we have more and more mirrors on the net. It did not happen. We now know that SqS is the "old way".

We currently face decisions what servers to use (SS3, SmalltalkHub, ...) see issue #6093 [2]

Now we move to SS3 and SmalltalkHub. Can we answer the question how reliable they are?

I like SmalltalkHub a lot. But still it is centralized and if it is down it is down for all. Dont we need answers to the question how independent our infrastructure will be in the future? If it is backuped, mirrored or restorable?

Dale proposed mirroring for Metacello [3]. We also have filetree [4] for directory-based Monticello packages enabling the use of Git, SVN, ... allowing us to use more reliable infrastructure like GitHub, ... Should we care?

But maybe I should shut up and wait until someone reboots Squeaksource again (which is down today yet again)

Bye T.

[1] http://astares.blogspot.de/2005/12/squeaksource-server-image.html [1] http://code.google.com/p/pharo/issues/detail?id=6093 [2] http://code.google.com/p/metacello/issues/detail?id=152 [3] https://github.com/dalehenrich/filetree

-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

On 2012-07-04, at 15:13, Friedrich Dominicus wrote:

Well I can not follow this completely. I can not find an answer of why text-based solutions won't cut it and I have also no idea what an object-oriented revision control might have other than a very good way of handling text. I guess I wil have to find some older threads to get an idea.

Anyway what I can't understand is that we can not simply switch from fone repository to another. It does not even have to be always up-to-date.

Let me just ask you, how much time do you need if squeacksource is gone to get a new image filled up and running. No I do not know how often you do that but I for my part do it with nearly every Pharo version there is.

I'm now trying to get some stuff installed in Pharo 2.0 (I guess you want this stuff to be used) and it takes me hours over hours and I still do not get anywhere.

So I simply do not get why we just have a register of places where we can find this stuff and are not "forced" to code that into the monticello packages.

Well if I have to than at least Pharo should be able to easily allow me to run a kind of grep/replace in the ConfigurationOfFiles. AFAIKt I have the Extended search but this does just searching and not replacing. So I'm suposed to manually change all the ConfigurationOf to look in my local cache first. This is at least odd.

Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. I do not know how many copies I have around here with the same "information". I can not see why this should make sens in the "standard" case....

you're absolutely right :) Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :)

I'm sorry but I simply do not understand a few things really. And well I can also not see an advantage of not treating sources as text-files for easier handling. This stupid text-files work since decades....

oh so true.

On 2012-07-04, at 16:55, Sean P. DeNigris wrote:

Camillo Bruni-3 wrote

...

...

Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. I do not know how many copies I have around here with the same "information". I can not see why this should make sens in the "standard" case....

you're absolutely right :)

Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :)

Really?! I haven't gone this route yet because I read that the performance was really slow. Is that no longer the case? How about on 1.4?

no! I patched MC's caching behavior in many places, plus with the new FS primitives you're pretty fast. For instance, browsing the commit history is fluent once you have all the packages in your cache. AFAIK under 1.4 I added most of the optimizations as well, but I cannot guarantee anything :P

this does not works anymore in Mac because Camillo changed to match the Mac standards. The new default directory is: ~/Library/Preferences/pharo best, Esteban On Jul 4, 2012, at 3:28 PM, Damien Cassou wrote:

On Wed, Jul 4, 2012 at 3:13 PM, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

...

Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. I do not know how many copies I have around here with the same "information". I can not see why this should make sens in the "standard" case....

http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-sc... http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/

Add this to ~/.config/pharo/2.0/monticello.st

StartupLoader default executeAtomicItems: { StartupAction name: 'Monticello related stuff' code: [| sharedPackageCacheDirectory | FileStream stdout lf; nextPutAll: 'Executing Monticello related stuff'; lf. sharedPackageCacheDirectory := (FileDirectory on: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX') assureExistence; yourself. MCCacheRepository default directory: sharedPackageCacheDirectory. MCDirectoryRepository defaultDirectoryName: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX'. (MCRepositoryGroup default repositories select: [:each | (each isKindOf: MCHttpRepository) and: [(each locationWithTrailingSlash includesSubString: 'www.squeaksource.com') or: [each locationWithTrailingSlash includesSubString: 'http://ss3.gemstone.com/ss/']]]) do: [:each | each user: 'XXXXXXXXXXXXX'; password: 'XXXXXXXXXXXX']. FileStream stdout lf; nextPutAll: 'Finished'; lf]. }.

-- Damien Cassou http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry