SqueakSource down... again

>
> Michael
>
> Am 21.02.2011 um 19:21 schrieb Hernán Morales Durand <[hidden email]>:
>
> > Discussing alternatives is a start for a solution, and as I've seen
> > from the posts above we have alternatives, we do not have consensus.
> >
> > 2011/2/21 Guillermo Polito <[hidden email]>:
> >> But the problem is that we have no alternatives, and if we want some, we
> >> have to build them :).  It's not just about complaining and waiting for the
> >> others to solve our problems.
> >>
> >> On Mon, Feb 21, 2011 at 3:00 PM, Hernán Morales Durand
> >> <[hidden email]> wrote:
> >>>
> >>> You're right, we should continue expecting a human-robot volunteer to
> >>> press the button every time the machine is broken, and that's very
> >>> kind attitude.
> >>>
> >>> Hernán
> >>>
> >>> 2011/2/21 Frank Shearar <[hidden email]>:
> >>>> On 2011/02/21 15:31, Hernán Morales Durand wrote:
> >>>>>
> >>>>> Thanks,
> >>>>> do nothing, just wait and see until SqueakSource turns completely
> >>>>> unusable.
> >>>>
> >>>> Maybe cut out the sarcasm. You waited an entire 29 minutes to complain
> >>>> that
> >>>> volunteers who might not be in your timezone aren't responding quickly
> >>>> enough for your tastes.
> >>>>
> >>>> By the way, it looks rather unbroken from here.
> >>>>
> >>>> frank
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> >
> > --
> > Hernán Morales
> > Information Technology Manager,
> > Institute of Veterinary Genetics.
> > National Scientific and Technical Research Council (CONICET).
> > La Plata (1900), Buenos Aires, Argentina.
> > Telephone: +54 (0221) 421-1799.
> > Internal: 422
> > Fax: 425-7980 or 421-1799.
> >
>

>
> -Steven
>
> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <[hidden email]> wrote:
> > Hi Esteban,
> >
> > I look forward to testing it :)
> >
> > BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much...
> >
> > Cheers,
> > Adrian
> >
> > On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote:
> >
> >> Hi,
> >> I'm already working in a file based solution... it will be ready for test next one or two months :)
> >>
> >> There are some advantages I want to point:
> >> - Better for newcomers
> >> - Better for customers who "want to see the sources" (yes, I have some of them, time to time)
> >> - We don't need to take care about infrastructure anymore, just use one already existing (like Github)
> >> - Increases Pharo visibility in the web (this is really important, IMHO)
> >> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository).
> >> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :)
> >> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it)
> >>
> >> On the disadvantages...
> >> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's  not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking)
> >> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging).
> >>
> >> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :)
> >> So... well... stay in touch ;)
> >>
> >> cheers,
> >> Esteban
> >>
> >> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :)
> >>
> >> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribió:
> >>
> >>> I don't know if we have to change to another kind of service.  But we MUST have alternatives.
> >>>
> >>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <[hidden email]> wrote:
> >>> Come on. We are talking about quality of service here, or about
> >>> changing the service?
> >>> I don't think that after migrating to (put your favorite here), we
> >>> won't have any new problems. And then same, lack of people who can
> >>> address them.
> >>>
> >>> On 21 February 2011 17:39, Adrian Lienhard <[hidden email]> wrote:
> >>>>
> >>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
> >>>>
> >>>>> how about a file based system and git?
> >>>>
> >>>> yea, just discussed this very idea an hour ago...
> >>>>
> >>>> The simplest thing that could work:
> >>>> - Write out changes to files (for each method and class)
> >>>> - Use git to commit, push, pull, merge, etc.
> >>>> - After git actions, load changed files and compile
> >>>>
> >>>> Advantage:
> >>>> - can reuse good existing tools and infrastructure: git, github, etc.
> >>>> - probably faster than MC + SqueakSource
> >>>> - lower entry barrier for new people
> >>>>
> >>>> Disadvantage:
> >>>> - source control tools not integrated anymore
> >>>> - resolving merge conflicts may be tedious
> >>>> - we don't have our own solution for everything anymore ;)
> >>>>
> >>>> Adrian
> >>>>
> >>>>>
> >>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote:
> >>>>>
> >>>>>> Well more or less every 10 days i need to restart it. This discussion happen
> >>>>>> already in different threads but again the problems are:
> >>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine
> >>>>>> running linux it could be better.
> >>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not
> >>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more
> >>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite
> >>>>>> entirely squaeksource.
> >>>>>>
> >>>>>> Now, this is a well know problem and a lot of people is already moving to
> >>>>>> solve it (surely you can find lots of email from Stephan talking about
> >>>>>> this). I'm trying to keep the system alive.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Fabrizio
> >>>>>>
> >>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable.
> >>>>>>>
> >>>>>>> I don't know if people won't noticed or don't want to admit it, but
> >>>>>>> SqueakSource is down very often lately..
> >>>>>>>
> >>>>>>> 2011/2/21 Fabrizio Perin <[hidden email]>:
> >>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i
> >>>>>>> don't
> >>>>>>>> know how i can help you.
> >>>>>>>>
> >>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
> >>>>>>>>>
> >>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any
> >>>>>>>>> alternative "free" repository?
> >>>>>>>>> Cheers,
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Hernán Morales
> >>>>>>>>> Information Technology Manager,
> >>>>>>>>> Institute of Veterinary Genetics.
> >>>>>>>>> National Scientific and Technical Research Council (CONICET).
> >>>>>>>>> La Plata (1900), Buenos Aires, Argentina.
> >>>>>>>>> Telephone: +54 (0221) 421-1799.
> >>>>>>>>> Internal: 422
> >>>>>>>>> Fax: 425-7980 or 421-1799.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Igor Stasenko AKA sig.
> >>>
> >>>
> >>
> >
> >
> >
>

> FWIW, Git is a very generic system. There's no reason we couldn't
> write a storage adapter for MC that puts the repo in Git. Git only
> knows about objects, and the versions thereof. We could easily have
> Monticello on top of git.
>
> I'm not sure I think it's a good solution, but it sounds like
> something fun to hack on, if someone wants to join me. (I'm not doing
> a project I only peripherally care about all by my lonesome.)
>
> -Steven
>
> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <[hidden email]> wrote:
>> Hi Esteban,
>>
>> I look forward to testing it :)
>>
>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much...
>>
>> Cheers,
>> Adrian
>>
>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote:
>>
>>> Hi,
>>> I'm already working in a file based solution... it will be ready for test next one or two months :)
>>>
>>> There are some advantages I want to point:
>>> - Better for newcomers
>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time)
>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github)
>>> - Increases Pharo visibility in the web (this is really important, IMHO)
>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository).
>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :)
>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it)
>>>
>>> On the disadvantages...
>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's  not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking)
>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging).
>>>
>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :)
>>> So... well... stay in touch ;)
>>>
>>> cheers,
>>> Esteban
>>>
>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :)
>>>
>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribió:
>>>
>>>> I don't know if we have to change to another kind of service.  But we MUST have alternatives.
>>>>
>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <[hidden email]> wrote:
>>>> Come on. We are talking about quality of service here, or about
>>>> changing the service?
>>>> I don't think that after migrating to (put your favorite here), we
>>>> won't have any new problems. And then same, lack of people who can
>>>> address them.
>>>>
>>>> On 21 February 2011 17:39, Adrian Lienhard <[hidden email]> wrote:
>>>>>
>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>>>>
>>>>>> how about a file based system and git?
>>>>>
>>>>> yea, just discussed this very idea an hour ago...
>>>>>
>>>>> The simplest thing that could work:
>>>>> - Write out changes to files (for each method and class)
>>>>> - Use git to commit, push, pull, merge, etc.
>>>>> - After git actions, load changed files and compile
>>>>>
>>>>> Advantage:
>>>>> - can reuse good existing tools and infrastructure: git, github, etc.
>>>>> - probably faster than MC + SqueakSource
>>>>> - lower entry barrier for new people
>>>>>
>>>>> Disadvantage:
>>>>> - source control tools not integrated anymore
>>>>> - resolving merge conflicts may be tedious
>>>>> - we don't have our own solution for everything anymore ;)
>>>>>
>>>>> Adrian
>>>>>
>>>>>>
>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote:
>>>>>>
>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen
>>>>>>> already in different threads but again the problems are:
>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine
>>>>>>> running linux it could be better.
>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not
>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more
>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite
>>>>>>> entirely squaeksource.
>>>>>>>
>>>>>>> Now, this is a well know problem and a lot of people is already moving to
>>>>>>> solve it (surely you can find lots of email from Stephan talking about
>>>>>>> this). I'm trying to keep the system alive.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Fabrizio
>>>>>>>
>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable.
>>>>>>>>
>>>>>>>> I don't know if people won't noticed or don't want to admit it, but
>>>>>>>> SqueakSource is down very often lately..
>>>>>>>>
>>>>>>>> 2011/2/21 Fabrizio Perin <[hidden email]>:
>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i
>>>>>>>> don't
>>>>>>>>> know how i can help you.
>>>>>>>>>
>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>>
>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any
>>>>>>>>>> alternative "free" repository?
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Hernán Morales
>>>>>>>>>> Information Technology Manager,
>>>>>>>>>> Institute of Veterinary Genetics.
>>>>>>>>>> National Scientific and Technical Research Council (CONICET).
>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina.
>>>>>>>>>> Telephone: +54 (0221) 421-1799.
>>>>>>>>>> Internal: 422
>>>>>>>>>> Fax: 425-7980 or 421-1799.
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>>
>>>
>>
>>
>>
>

>
> personally I would really appreciate that (also for other versioning tools).
>
> - I like to choose my own tools
> - I don't like to stick in a image-based world, but I certainly want to stay compatible
> - I want quality!! and sending fileouts via mail is NOT
>
> And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future.
>
> Some links I will further follow tomorrow to address this issue:
>
> - gitfs: http://buildinggitfs.blogspot.com/
> http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C
> - gitocello: https://github.com/timfel/gitocello
> - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/mercurial/proposal
> - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K
>
>
> m(^_-)m
> camillo
>
> On 2011-02-21, at 19:28, Steven Baker wrote:
>
>> FWIW, Git is a very generic system. There's no reason we couldn't
>> write a storage adapter for MC that puts the repo in Git. Git only
>> knows about objects, and the versions thereof. We could easily have
>> Monticello on top of git.
>>
>> I'm not sure I think it's a good solution, but it sounds like
>> something fun to hack on, if someone wants to join me. (I'm not doing
>> a project I only peripherally care about all by my lonesome.)
>>
>> -Steven
>>
>> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <[hidden email]> wrote:
>>> Hi Esteban,
>>>
>>> I look forward to testing it :)
>>>
>>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much...
>>>
>>> Cheers,
>>> Adrian
>>>
>>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote:
>>>
>>>> Hi,
>>>> I'm already working in a file based solution... it will be ready for test next one or two months :)
>>>>
>>>> There are some advantages I want to point:
>>>> - Better for newcomers
>>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time)
>>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github)
>>>> - Increases Pharo visibility in the web (this is really important, IMHO)
>>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository).
>>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :)
>>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it)
>>>>
>>>> On the disadvantages...
>>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's  not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking)
>>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging).
>>>>
>>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :)
>>>> So... well... stay in touch ;)
>>>>
>>>> cheers,
>>>> Esteban
>>>>
>>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :)
>>>>
>>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribió:
>>>>
>>>>> I don't know if we have to change to another kind of service.  But we MUST have alternatives.
>>>>>
>>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <[hidden email]> wrote:
>>>>> Come on. We are talking about quality of service here, or about
>>>>> changing the service?
>>>>> I don't think that after migrating to (put your favorite here), we
>>>>> won't have any new problems. And then same, lack of people who can
>>>>> address them.
>>>>>
>>>>> On 21 February 2011 17:39, Adrian Lienhard <[hidden email]> wrote:
>>>>>>
>>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>>>>>
>>>>>>> how about a file based system and git?
>>>>>>
>>>>>> yea, just discussed this very idea an hour ago...
>>>>>>
>>>>>> The simplest thing that could work:
>>>>>> - Write out changes to files (for each method and class)
>>>>>> - Use git to commit, push, pull, merge, etc.
>>>>>> - After git actions, load changed files and compile
>>>>>>
>>>>>> Advantage:
>>>>>> - can reuse good existing tools and infrastructure: git, github, etc.
>>>>>> - probably faster than MC + SqueakSource
>>>>>> - lower entry barrier for new people
>>>>>>
>>>>>> Disadvantage:
>>>>>> - source control tools not integrated anymore
>>>>>> - resolving merge conflicts may be tedious
>>>>>> - we don't have our own solution for everything anymore ;)
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>>
>>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote:
>>>>>>>
>>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen
>>>>>>>> already in different threads but again the problems are:
>>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine
>>>>>>>> running linux it could be better.
>>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not
>>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more
>>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite
>>>>>>>> entirely squaeksource.
>>>>>>>>
>>>>>>>> Now, this is a well know problem and a lot of people is already moving to
>>>>>>>> solve it (surely you can find lots of email from Stephan talking about
>>>>>>>> this). I'm trying to keep the system alive.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Fabrizio
>>>>>>>>
>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable.
>>>>>>>>>
>>>>>>>>> I don't know if people won't noticed or don't want to admit it, but
>>>>>>>>> SqueakSource is down very often lately..
>>>>>>>>>
>>>>>>>>> 2011/2/21 Fabrizio Perin <[hidden email]>:
>>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i
>>>>>>>>> don't
>>>>>>>>>> know how i can help you.
>>>>>>>>>>
>>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>>>
>>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any
>>>>>>>>>>> alternative "free" repository?
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Hernán Morales
>>>>>>>>>>> Information Technology Manager,
>>>>>>>>>>> Institute of Veterinary Genetics.
>>>>>>>>>>> National Scientific and Technical Research Council (CONICET).
>>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina.
>>>>>>>>>>> Telephone: +54 (0221) 421-1799.
>>>>>>>>>>> Internal: 422
>>>>>>>>>>> Fax: 425-7980 or 421-1799.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>

>> personally I would really appreciate that (also for other versioning tools).
>>
>> - I like to choose my own tools
>> - I don't like to stick in a image-based world, but I certainly want to stay compatible
>> - I want quality!! and sending fileouts via mail is NOT
>>
>> And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future.
>>
>> Some links I will further follow tomorrow to address this issue:
>>
>> - gitfs: http://buildinggitfs.blogspot.com/
>> http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C
>> - gitocello: https://github.com/timfel/gitocello
>> - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/mercurial/proposal
>> - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K
>>
>>
>> m(^_-)m
>> camillo
>>
>> On 2011-02-21, at 19:28, Steven Baker wrote:
>>
>>> FWIW, Git is a very generic system. There's no reason we couldn't
>>> write a storage adapter for MC that puts the repo in Git. Git only
>>> knows about objects, and the versions thereof. We could easily have
>>> Monticello on top of git.
>>>
>>> I'm not sure I think it's a good solution, but it sounds like
>>> something fun to hack on, if someone wants to join me. (I'm not doing
>>> a project I only peripherally care about all by my lonesome.)
>>>
>>> -Steven
>>>
>>> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <[hidden email]> wrote:
>>>> Hi Esteban,
>>>>
>>>> I look forward to testing it :)
>>>>
>>>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much...
>>>>
>>>> Cheers,
>>>> Adrian
>>>>
>>>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote:
>>>>
>>>>> Hi,
>>>>> I'm already working in a file based solution... it will be ready for test next one or two months :)
>>>>>
>>>>> There are some advantages I want to point:
>>>>> - Better for newcomers
>>>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time)
>>>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github)
>>>>> - Increases Pharo visibility in the web (this is really important, IMHO)
>>>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository).
>>>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :)
>>>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it)
>>>>>
>>>>> On the disadvantages...
>>>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's  not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking)
>>>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging).
>>>>>
>>>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :)
>>>>> So... well... stay in touch ;)
>>>>>
>>>>> cheers,
>>>>> Esteban
>>>>>
>>>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :)
>>>>>
>>>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribió:
>>>>>
>>>>>> I don't know if we have to change to another kind of service.  But we MUST have alternatives.
>>>>>>
>>>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <[hidden email]> wrote:
>>>>>> Come on. We are talking about quality of service here, or about
>>>>>> changing the service?
>>>>>> I don't think that after migrating to (put your favorite here), we
>>>>>> won't have any new problems. And then same, lack of people who can
>>>>>> address them.
>>>>>>
>>>>>> On 21 February 2011 17:39, Adrian Lienhard <[hidden email]> wrote:
>>>>>>>
>>>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>>>>>>
>>>>>>>> how about a file based system and git?
>>>>>>>
>>>>>>> yea, just discussed this very idea an hour ago...
>>>>>>>
>>>>>>> The simplest thing that could work:
>>>>>>> - Write out changes to files (for each method and class)
>>>>>>> - Use git to commit, push, pull, merge, etc.
>>>>>>> - After git actions, load changed files and compile
>>>>>>>
>>>>>>> Advantage:
>>>>>>> - can reuse good existing tools and infrastructure: git, github, etc.
>>>>>>> - probably faster than MC + SqueakSource
>>>>>>> - lower entry barrier for new people
>>>>>>>
>>>>>>> Disadvantage:
>>>>>>> - source control tools not integrated anymore
>>>>>>> - resolving merge conflicts may be tedious
>>>>>>> - we don't have our own solution for everything anymore ;)
>>>>>>>
>>>>>>> Adrian
>>>>>>>
>>>>>>>>
>>>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote:
>>>>>>>>
>>>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen
>>>>>>>>> already in different threads but again the problems are:
>>>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine
>>>>>>>>> running linux it could be better.
>>>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not
>>>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more
>>>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite
>>>>>>>>> entirely squaeksource.
>>>>>>>>>
>>>>>>>>> Now, this is a well know problem and a lot of people is already moving to
>>>>>>>>> solve it (surely you can find lots of email from Stephan talking about
>>>>>>>>> this). I'm trying to keep the system alive.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Fabrizio
>>>>>>>>>
>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable.
>>>>>>>>>>
>>>>>>>>>> I don't know if people won't noticed or don't want to admit it, but
>>>>>>>>>> SqueakSource is down very often lately..
>>>>>>>>>>
>>>>>>>>>> 2011/2/21 Fabrizio Perin <[hidden email]>:
>>>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i
>>>>>>>>>> don't
>>>>>>>>>>> know how i can help you.
>>>>>>>>>>>
>>>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>>>>
>>>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any
>>>>>>>>>>>> alternative "free" repository?
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Hernán Morales
>>>>>>>>>>>> Information Technology Manager,
>>>>>>>>>>>> Institute of Veterinary Genetics.
>>>>>>>>>>>> National Scientific and Technical Research Council (CONICET).
>>>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina.
>>>>>>>>>>>> Telephone: +54 (0221) 421-1799.
>>>>>>>>>>>> Internal: 422
>>>>>>>>>>>> Fax: 425-7980 or 421-1799.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>

> On 2011-02-21, at 22:52, Alexandre Bergel wrote:
>
>>> Max Leske, a student in bern started to write a git library for smalltalk. so there should be already quite some stuff available.
>>> but AFAIK there is no MC adapter yet.
>>
>> I do not have much experience with Git, but do you think it is feasible to have such adapter?
>>
>> Alexandre
>
> Actually I have no clue of the MC internals ;), so I will have to go deep there. At least there has been an approach using svn:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131436.html
>
> Although I have no clue how much this is still in use, or if it even works. But combined with the git communication libraries available it should be possible to patch them together.
>
> I would like to see that happen, not just for me, but also to see more smalltalk sources on the web. The current google hit-ratio is a nightmare :D. And maybe it even helps to share some code with GNU smalltalkses or so.
>
> m(^_-)m
> camillo
>
>>> personally I would really appreciate that (also for other versioning tools).
>>>
>>> - I like to choose my own tools
>>> - I don't like to stick in a image-based world, but I certainly want to stay compatible
>>> - I want quality!! and sending fileouts via mail is NOT
>>>
>>> And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future.
>>>
>>> Some links I will further follow tomorrow to address this issue:
>>>
>>> - gitfs: http://buildinggitfs.blogspot.com/
>>> http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C
>>> - gitocello: https://github.com/timfel/gitocello
>>> - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/mercurial/proposal
>>> - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K
>>>
>>>
>>> m(^_-)m
>>> camillo
>>>
>>> On 2011-02-21, at 19:28, Steven Baker wrote:
>>>
>>>> FWIW, Git is a very generic system. There's no reason we couldn't
>>>> write a storage adapter for MC that puts the repo in Git. Git only
>>>> knows about objects, and the versions thereof. We could easily have
>>>> Monticello on top of git.
>>>>
>>>> I'm not sure I think it's a good solution, but it sounds like
>>>> something fun to hack on, if someone wants to join me. (I'm not doing
>>>> a project I only peripherally care about all by my lonesome.)
>>>>
>>>> -Steven
>>>>
>>>> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <[hidden email]> wrote:
>>>>> Hi Esteban,
>>>>>
>>>>> I look forward to testing it :)
>>>>>
>>>>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much...
>>>>>
>>>>> Cheers,
>>>>> Adrian
>>>>>
>>>>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote:
>>>>>
>>>>>> Hi,
>>>>>> I'm already working in a file based solution... it will be ready for test next one or two months :)
>>>>>>
>>>>>> There are some advantages I want to point:
>>>>>> - Better for newcomers
>>>>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time)
>>>>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github)
>>>>>> - Increases Pharo visibility in the web (this is really important, IMHO)
>>>>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository).
>>>>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :)
>>>>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it)
>>>>>>
>>>>>> On the disadvantages...
>>>>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's  not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking)
>>>>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging).
>>>>>>
>>>>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :)
>>>>>> So... well... stay in touch ;)
>>>>>>
>>>>>> cheers,
>>>>>> Esteban
>>>>>>
>>>>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :)
>>>>>>
>>>>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribió:
>>>>>>
>>>>>>> I don't know if we have to change to another kind of service.  But we MUST have alternatives.
>>>>>>>
>>>>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <[hidden email]> wrote:
>>>>>>> Come on. We are talking about quality of service here, or about
>>>>>>> changing the service?
>>>>>>> I don't think that after migrating to (put your favorite here), we
>>>>>>> won't have any new problems. And then same, lack of people who can
>>>>>>> address them.
>>>>>>>
>>>>>>> On 21 February 2011 17:39, Adrian Lienhard <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>>>>>>>
>>>>>>>>> how about a file based system and git?
>>>>>>>>
>>>>>>>> yea, just discussed this very idea an hour ago...
>>>>>>>>
>>>>>>>> The simplest thing that could work:
>>>>>>>> - Write out changes to files (for each method and class)
>>>>>>>> - Use git to commit, push, pull, merge, etc.
>>>>>>>> - After git actions, load changed files and compile
>>>>>>>>
>>>>>>>> Advantage:
>>>>>>>> - can reuse good existing tools and infrastructure: git, github, etc.
>>>>>>>> - probably faster than MC + SqueakSource
>>>>>>>> - lower entry barrier for new people
>>>>>>>>
>>>>>>>> Disadvantage:
>>>>>>>> - source control tools not integrated anymore
>>>>>>>> - resolving merge conflicts may be tedious
>>>>>>>> - we don't have our own solution for everything anymore ;)
>>>>>>>>
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote:
>>>>>>>>>
>>>>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen
>>>>>>>>>> already in different threads but again the problems are:
>>>>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine
>>>>>>>>>> running linux it could be better.
>>>>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not
>>>>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more
>>>>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite
>>>>>>>>>> entirely squaeksource.
>>>>>>>>>>
>>>>>>>>>> Now, this is a well know problem and a lot of people is already moving to
>>>>>>>>>> solve it (surely you can find lots of email from Stephan talking about
>>>>>>>>>> this). I'm trying to keep the system alive.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Fabrizio
>>>>>>>>>>
>>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable.
>>>>>>>>>>>
>>>>>>>>>>> I don't know if people won't noticed or don't want to admit it, but
>>>>>>>>>>> SqueakSource is down very often lately..
>>>>>>>>>>>
>>>>>>>>>>> 2011/2/21 Fabrizio Perin <[hidden email]>:
>>>>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i
>>>>>>>>>>> don't
>>>>>>>>>>>> know how i can help you.
>>>>>>>>>>>>
>>>>>>>>>>>> 2011/2/21 Hernán Morales Durand <[hidden email]>
>>>>>>>>>>>>>
>>>>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any
>>>>>>>>>>>>> alternative "free" repository?
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Hernán Morales
>>>>>>>>>>>>> Information Technology Manager,
>>>>>>>>>>>>> Institute of Veterinary Genetics.
>>>>>>>>>>>>> National Scientific and Technical Research Council (CONICET).
>>>>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina.
>>>>>>>>>>>>> Telephone: +54 (0221) 421-1799.
>>>>>>>>>>>>> Internal: 422
>>>>>>>>>>>>> Fax: 425-7980 or 421-1799.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Igor Stasenko AKA sig.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>
>

>
> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>
>> how about a file based system and git?
>
> yea, just discussed this very idea an hour ago...
>
> The simplest thing that could work:
> - Write out changes to files (for each method and class)
> - Use git to commit, push, pull, merge, etc.
> - After git actions, load changed files and compile

> On 02/21/2011 05:39 PM, Adrian Lienhard wrote:
>>
>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>
>>> how about a file based system and git?
>>
>> yea, just discussed this very idea an hour ago...
>>
>> The simplest thing that could work:
>> - Write out changes to files (for each method and class)
>> - Use git to commit, push, pull, merge, etc.
>> - After git actions, load changed files and compile
>
> Been there, done that. Was called DVS, the predecessor of Monticello. It
> sucked.
>

> On 22 February 2011 08:21, Philippe Marschall
> <[hidden email]>  wrote:
>> On 02/21/2011 05:39 PM, Adrian Lienhard wrote:
>>>
>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote:
>>>
>>>> how about a file based system and git?
>>>
>>> yea, just discussed this very idea an hour ago...
>>>
>>> The simplest thing that could work:
>>> - Write out changes to files (for each method and class)
>>> - Use git to commit, push, pull, merge, etc.
>>> - After git actions, load changed files and compile
>>
>> Been there, done that. Was called DVS, the predecessor of Monticello. It
>> sucked.
>>
>
> Can you give some details?
> What were deliverables (if any)?
> What was gone wrong?

> Hi,
>
> Am 21.02.2011 um 19:31 schrieb Miguel Cobá <[hidden email]>:
>>> at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
>>
>> I think the number of users that hit squeaksource.com vs HPS's own
>> everyday is a key factor in the perceived performance and net uptime of each installation.
>
> Those SqueakSource standstills *never* occurred after we transitioned to the now-running installation. Before switching, we often experienced standstills as well. That's two simple facts, and the number of users does not play a role in this observation.
>
> I do not know the precise number of accesses per day, but around the end of the semester, when students are supposed to deliver their projects, it gets "hot". (I believe that, this term, we had some 80 students in 16 teams.)
>
> No freezes.
>
> Best,
>
> Michael

> Hi michael
>
> where can we find the code for such a GemStone backend source?
>
> Stef
> On Feb 21, 2011, at 8:43 PM, Michael Haupt wrote:
>
>> Hi,
>>
>> Am 21.02.2011 um 19:31 schrieb Miguel Cobá <[hidden email]>:
>>>> at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
>>>
>>> I think the number of users that hit squeaksource.com vs HPS's own
>>> everyday is a key factor in the perceived performance and net uptime of each installation.
>>
>> Those SqueakSource standstills *never* occurred after we transitioned to the now-running installation. Before switching, we often experienced standstills as well. That's two simple facts, and the number of users does not play a role in this observation.
>>
>> I do not know the precise number of accesses per day, but around the end of the semester, when students are supposed to deliver their projects, it gets "hot". (I believe that, this term, we had some 80 students in 16 teams.)
>>
>> No freezes.
>>
>> Best,
>>
>> Michael
>
>