Re: [Pharo-project] Squeaksource down again
No problem, I'm sorry i cannot do anything until tomorrow. Cheers, Fabrizio 2012/1/16 Frank Shearar > Thanks, Fabrizio. It did indeed look more serious than SS being > difficult: I was getting No Route to Host errors, so looked more > network related than SS. > > frank > > On 16 January 2012 16:54, Fabrizio Perin wrote: > > Well, all our servers are down. Try tommorow. > > > > > > > > 2012/1/16 Frank Shearar > >> > >> http://www.downforeveryoneorjustme.com/www.squeaksource.com > >> > >> Hooray for ss3.gemstone.com! > >> > >> frank > >> > > > >
Re: [Pharo-project] Squeaksource down again
Thanks, Fabrizio. It did indeed look more serious than SS being difficult: I was getting No Route to Host errors, so looked more network related than SS. frank On 16 January 2012 16:54, Fabrizio Perin wrote: > Well, all our servers are down. Try tommorow. > > > > 2012/1/16 Frank Shearar >> >> http://www.downforeveryoneorjustme.com/www.squeaksource.com >> >> Hooray for ss3.gemstone.com! >> >> frank >> >
Re: [Pharo-project] Squeaksource down again
Well, all our servers are down. Try tommorow. 2012/1/16 Frank Shearar > http://www.downforeveryoneorjustme.com/www.squeaksource.com > > Hooray for ss3.gemstone.com! > > frank > >
[Pharo-project] Squeaksource down again
http://www.downforeveryoneorjustme.com/www.squeaksource.com Hooray for ss3.gemstone.com! frank
Re: [Pharo-project] SqueakSource down... again
2011/2/22 Yanni Chiu > On 22/02/11 6:34 AM, Sven Van Caekenberghe wrote: > >> Anyway, putting it on a newer Linux based server (shouldn't have to >> cost that much) and adding some of the standard tools to monitor the >> process and reboot it if necessary will probably already help a lot. >> > > But simply rebooting the image may not be enough. IIUC, due to the image > based per persistence, some manual recovery is necessary in some cases. > > > Recently Tudor "missed" some commit (don't know what happened) so a script have to be run to ensure them again. So yes, is not just a matter of restart the image when is down
Re: [Pharo-project] SqueakSource down... again
On 22 Feb 2011, at 13:54, Yanni Chiu wrote: > On 22/02/11 6:34 AM, Sven Van Caekenberghe wrote: >> Anyway, putting it on a newer Linux based server (shouldn't have to >> cost that much) and adding some of the standard tools to monitor the >> process and reboot it if necessary will probably already help a lot. > > But simply rebooting the image may not be enough. IIUC, due to the image > based per persistence, some manual recovery is necessary in some cases. I read that too, but I can't imagine that the person doing the reboot does a lot of manual interventions regarding the data. The actual use of SqueakSource must be so massive that it is next to impossible to see if things are OK. But I am just guessing here.
Re: [Pharo-project] SqueakSource down... again
On 22/02/11 6:34 AM, Sven Van Caekenberghe wrote: Anyway, putting it on a newer Linux based server (shouldn't have to cost that much) and adding some of the standard tools to monitor the process and reboot it if necessary will probably already help a lot. But simply rebooting the image may not be enough. IIUC, due to the image based per persistence, some manual recovery is necessary in some cases.
[Pharo-project] SqueakSource down... again
>I think that Monticello as it is today is pretty good. I remember working in >>Smalltalk without something like Monticello and it was a PITA. +1 >My first experiences with Envy I used Envy, Monticello, Store, DVS, Changesets, ST/MT XML Project files with VisualSourceSafe, Smallscript scripts in Subversion and others in the past (when in Smalltalk land). If I could choose among them I would vote for Monticello! >Anyway, putting it on a newer Linux based server (shouldn't have to cost >that >much) and adding some of the standard tools to monitor the process and >reboot >it if necessary will probably already help a lot Squeaksource could be improved (google indexing, ...), no doubt about it. But we should'nt confuse a "squeaksource.com" (server problem) with a squeaksource (the program) problem. Other Squeaksource instances like http://source.squeak.org run stable AFAIK. So the real question is: is anyone able to provide a backuped server that is reachable from the web and that could be used for a fresh setup of squeaksource (the program)? Tx Torsten -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
Re: [Pharo-project] SqueakSource down... again
Le 21/02/2011 16:48, Fabrizio Perin a écrit : > to solve it (surely you can find lots of email from Stephan talking > about this). I'm trying to keep the system alive. > Thanks ;) Hilaire
Re: [Pharo-project] SqueakSource down... again
I think that Monticello as it is today is pretty good. I remember working in Smalltalk without something like Monticello and it was a PITA. My first experiences with Envy were that it was very complex, hard to use and hugely overpriced. The fact that we all hate it so much when SqueakSource is down means one thing: we use it a lot and we've come to depend on it. That is a good thing. Now as some others have said many times on this list: this is free open-source software, nothing or very little will change by complaining, you have to do something yourself. Anyway, putting it on a newer Linux based server (shouldn't have to cost that much) and adding some of the standard tools to monitor the process and reboot it if necessary will probably already help a lot. Sven
Re: [Pharo-project] SqueakSource down... again
On 02/22/2011 10:21 AM, Igor Stasenko wrote: On 22 February 2011 08:21, Philippe Marschall 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? Yes, Avi wrote DVS first, and then MC after that. DVS was the first attempt to bring the "CVS style" update-with-automerge-fixconflicts-commit cycle to Squeak. Now, Colin could probably describe this better - I don't think I ever used DVS - but my guess would be that the hassle of doing the merge outside of Squeak was the biggest drawback. You will either spend a LOT of code to try to reflect the merge into Squeak - or you will end up sitting in a text editor doing conflict resolution on a "line by line" basis in your fileout format of choice. I don't want to put a damper on any kind of SCM efforts being made, but I do think that it is quite hard (not impossible, but hard) to gain real benefits of using outside infrastructure like for example git. regards, Göran
Re: [Pharo-project] SqueakSource down... again
On 22 February 2011 08:21, Philippe Marschall 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? > Cheers > Philippe > > > -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] SqueakSource down... again
Chris Muller-3 wrote: > >>> how about a file based system and git? > > -1. > Hang on, I think we may be missing the point here. There is no need to all agree or come to a consensus as someone else mentioned here. I would like to think that Pharo is open minded enough to accept other alternatives. Alternatives are for everyones benefit because; e.g. if one repository goes down, there will be one or more alternatives. So, it should not be an either-or question. Wouldn't it be great if Smalltalk projects could be hosted on Squeaksource (new version will be called SmalltalkSource I believe) and/or e.g Github etc? So, if you have an idea or gut feeling, just go for it, let your creative juices flow and innovate :) Chris Muller-3 wrote: > >> - lower entry barrier for new people > SqueakSource is not the "barrier" keeping droves of people from Pharo is > it? > It may not be "the" barrier but it probably would help for new people to see that at least they are already familiar with the version control system before trying to grasp the whole image and build-in IDE concept :) -- View this message in context: http://forum.world.st/SqueakSource-down-again-tp3317484p3318722.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] SqueakSource down... again
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. Cheers Philippe
Re: [Pharo-project] SqueakSource down... again
Camillo, actually Lukas did something with Monticello and my GitFS package called "MonticelloGit". There's only one version so far and I haven't looked at it but if anyone's interested, you can find the package on SqueakSouce: http://www.squeaksource.com/GitFS.html Max On 21.02.2011, at 23:35, Camillo Bruni wrote: > 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 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 >
Re: [Pharo-project] SqueakSource down... again
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 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
Re: [Pharo-project] SqueakSource down... again
> 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 > > 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 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 altern
Re: [Pharo-project] SqueakSource down... again
I'm in! 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. 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 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 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)
Re: [Pharo-project] SqueakSource down... again
El lun, 21-02-2011 a las 10:28 -0800, Steven Baker escribió: > 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.) But they work very differently. Git is a complete different beast that MC is. They have distinct paradigms in how to deal with data in the repo. They have in common that are distributed VCS but that is all. In order to use git to its full potential (cheap branching, a branch-per-feature development workflow, easy forking, security auditable history, fast merging) it would be necessary to completly forget about MC and to start from zero with a solution for smalltalk but using git model/workflow in mind. A simple adaptor won't be using smalltalk capabilities nor Git ones to its full potential and will not get enough traction to survive. Cheers > > -Steven > > On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard 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 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 wrote: > > On Feb 21, 2011, at 17:22 , Camillo Bruni wrote: > > > how about a file based system and git? > >
Re: [Pharo-project] SqueakSource down... again
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 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 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 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
Re: [Pharo-project] SqueakSource down... again
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 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 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 syst
Re: [Pharo-project] SqueakSource down... again
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 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 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 > >>> > 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 : > > 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 > >> > >> SqueakSource is down again. I'm tired of this situation, there is any > >> alternative "free" repository? > >> Cheers, > >> > >> -- > >> Hernán Morales
Re: [Pharo-project] SqueakSource down... again
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 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 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 > >>> > 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 : > > 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 > >> > >> 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. > >
Re: [Pharo-project] SqueakSource down... again
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 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 >>> 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 : > 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 >> >> 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.
Re: [Pharo-project] SqueakSource down... again
>> how about a file based system and git? -1. > 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 Doesn't seem simpler than what is already written and working... Did someone say it is a hardware issue (old Mac)? Perhaps we should ask, _why_ is Squeaksource going down before addressing solutions. > Advantage: > - can reuse good existing tools and infrastructure: git, github, etc. SqueakSource is an existing tool. > - probably faster than MC + SqueakSource "Faster" for the computer to copy files, but slow and tedious for me to merge? > - lower entry barrier for new people SqueakSource is not the "barrier" keeping droves of people from Pharo is it?
Re: [Pharo-project] SqueakSource down... again
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 >> >>> 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 : 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 > > 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. > >>> >>> > >
Re: [Pharo-project] SqueakSource down... again
how about a file based system and git? 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 > >> 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 : >>> 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 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. >> >>
Re: [Pharo-project] SqueakSource down... again
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 > 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 : > > 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 > >> > >> 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. > >> > >
Re: [Pharo-project] SqueakSource down... again
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 : > 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 >> >> 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. >>
Re: [Pharo-project] SqueakSource down... again
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 > 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. > >
Re: [Pharo-project] SqueakSource down... again
I mean repository *server*, Thanks 2011/2/21 Henrik Johansen : > + Repository > directory > > Cheers, > Henry > > On Feb 21, 2011, at 4:02 46PM, Hernán Morales Durand wrote: > >> 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. >> > > >
Re: [Pharo-project] SqueakSource down... again
An FTP repo is a good alternative for private projects. Esteban uses that I think. On Mon, Feb 21, 2011 at 12:06 PM, Henrik Johansen < henrik.s.johan...@veloxit.no> wrote: > + Repository > directory > > Cheers, > Henry > > On Feb 21, 2011, at 4:02 46PM, Hernán Morales Durand wrote: > > > 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. > > > > >
Re: [Pharo-project] SqueakSource down... again
+ Repository directory Cheers, Henry On Feb 21, 2011, at 4:02 46PM, Hernán Morales Durand wrote: > 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. >
[Pharo-project] SqueakSource down... again
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.