- Pharo-dev - lists.pharo.org

Re: [Pharo-project] GitFs / MCGit

by Camillo Bruni

On 2011-04-27, at 22:37, Stefan Marr wrote: > Hi Camillo: > > > On 27 Apr 2011, at 22:09, Camillo Bruni wrote: > >> Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. >> >> The following uses a local git repos as a monticello repository: >> >> MCGitRepository directory: 'test_git' > What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image? I have no clue. It was developed in a 1.2 image. But I guess you have to try out ;) > >> Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. > If you can handle EPL licensed code, I could make our Transporter scripts available. > It is a bit more than just a file out that uses one file per class, and a folder per package. > Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts. I'd certainly be interested in having a look at this. Since I am not yet sure how to split it up. Since I want to make it compatible with Monticello again I will try to keep enough meta data around to reassemble a sources.st file. > Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you.. Personally this is no problem, and since I am not obliged to commit it to squeaksource this should be not a problem. > Best regards > Stefan > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

April 27, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Casimiro de Almeida Barreto

Em 27-04-2011 17:13, Tudor Girba escreveu: > Thanks for reporting. I guess it is because the new Transcript is not yet 100% compatible with the old one. If you still want to try Moose, please just comment the Transcript open part and let us know what happens. That was what I did. Hence "not clean installation". But purpose of e-mail was to post a "trouble ticket"... That's why sometimes I put posts like this. > Cheers, > Doru > > > On 27 Apr 2011, at 21:56, Casimiro de Almeida Barreto wrote: > >> In PharoDev-1.3.-13173 >> >> While loading Moose there's a 'Transcript open' in loadDefault. This >> image's Transcript does not understand #open. It's preventing clear >> installation of moose. >> >> Best regards, >> >> CdAB >> > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > >

April 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Stefan Marr

Hi Camillo: On 27 Apr 2011, at 22:09, Camillo Bruni wrote: > Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. > > The following uses a local git repos as a monticello repository: > > MCGitRepository directory: 'test_git' What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image? > Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. If you can handle EPL licensed code, I could make our Transporter scripts available. It is a bit more than just a file out that uses one file per class, and a folder per package. Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts. Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 27, 2011

Re: [Pharo-project] SqueakSource

by Tobias Pape

Am 2011-04-27 um 19:26 schrieb StÃ©phane Ducasse: > argh this is bad. > Agony of squeaksource. > > May be could set up a mirror and use a gofer script to publish in the two systematically. > Now I do not know the requirement for SS3 and no time to check. So. Seaside3, Magritte2 on Pharo1.2/Squeak4.2/GemStone 2.4.4.x Didn't I state that clearly enough? Oh, my bad. So. So Long, -Tobias

April 27, 2011

Re: [Pharo-project] squeaksource is down - a different perspective

by Dale Henrichs

Since you mention GemStone:) We have customers who have migrated repositories created 10+ years ago with our 32 bit product to the latest current version of our 64 bit product. We have changed our Smalltalk class-library over the years and customers have had to upgrade their own class libraries if they chose to continue taking advantage of our newer releases ... then there are some who have chosen not to migrate: I think there are still production applications running GemStone on a version 20 years old:) ... as long as their hardware holds out they are fine:) Production customers don't tend to move very fast in upgrading their hardware and software so we end up supporting older versions of oSes for quite awhile...But when the os vendor announces and end of life of an os, it becomes difficult for us to continue to support that version... For the older versions we backport critical bugfixes to the older versions as long as their are active customers (read paying maintenance dollars) using the older versions. Dale On 04/27/2011 10:23 AM, StÃ©phane Ducasse wrote: > >>> squeaksource.com is down a lot. People get frustrated at times. >> >> Yes, and unfortunately it looks like people love to be frustrated. >> >> Otherwise people would give Tobias more feedback on SqueakSource3 (see [1]) which IMHO could overtake the job in the future and replace the >> problematic image? > > I do not know. > Do SS3 has a migration process? > How easy is it to install on an old machine? > Does gemstone run on a old mac g3? > Should we install glass? > I do not know. > > You see nothing looks simple when we want to do it. > >> Or is the outage a traffic problem and may >> happen with SS3 too? >> >> Is the (daily?) restart the only option we have or is a migration >> to a newer SS version possible? > > No idea. > Do you know? > >> And yes - SmalltalkHub is on the way, but we still dont know >> how well it fits our needs/works/scales. Yes, this sounds negative but >> I think it can replace Squeaksource only in a long term... > > we will see and learn. > >> Bye >> T. >> >> >> [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-April/047780.html >> -- >> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >> Jetzt informieren: http://www.gmx.net/de/go/freephone >> > >

April 27, 2011

Re: [Pharo-project] ConfigurationOfMagma with support for Magma 1.2 and symbolic versions

by StÃ©phane Ducasse

cool miguel may be we should publish this information on the collabactive book. stef On Apr 27, 2011, at 6:35 PM, Miguel CobÃ¡ wrote: > Hi all, > > I'm glad to announce a new version of ConfigurationOfMagma with support > for Magma 1.2. This configuration has been tested on > > PharoCore 1.1.x > PharoCore 1.2.x > > Thank you very much to Chris Muller who, as always, is working hard to > keep Magma running on Squeak and Pharo. I used the same versions of > packages he used in his scripts for Squeak in order to update the > configuration. > > You must download the latest PharoCore image or update a existing one > before installing Magma, as Magma needs some changes that were applied > to Pharo post-release and are available in the update stream. > > > Pharo 1.1.x > ------------ > > Download PharoCore 1.1.2 from: > > https://gforge.inria.fr/frs/download.php/28341/PharoCore-1.1.2.zip > > Update it if necessary and save it. > > > Pharo 1.2.x > ------------ > > You have two options: > > 1. Take a released 1.2.1 from: > > http://www.pharo-project.org/pharo-download/stable-core > > This is actually image update 12345. Evaluate: > > SystemVersion newVersion: 'Pharo1.2.2a'. > > update the image (it will update to 12350, at this time) and save it. > > 2. Take a snapshot of the upcoming 1.2.2 release of Pharo 1.2.x line > from: > > https://gforge.inria.fr/frs/download.php/28436/PharoCore-1.2.2a-12345.zip > > update the image (it will update to 12350, at this time) and save it. > > > Install Magma > -------------- > > Ok, now you have an updated image. Load the configuration by evaluating: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > > And depending on which of client, server or the full suite of Magma do > you want, evaluate: > > - Magma client > > ((Smalltalk at: #ConfigurationOfMagma) > project version: #stable) load: 'Client'. > > > - Magma server > > ((Smalltalk at: #ConfigurationOfMagma) > project version: #stable) load: 'Server'. > > - Magma tester > > ((Smalltalk at: #ConfigurationOfMagma) > project version: #stable) load: 'Tester'. > > For example, to load the full magma suite evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > ((Smalltalk at: #ConfigurationOfMagma) > project version: #stable) load: 'Tester'. > > This will load client, server and test of Magma. > > > Running tests > ------------- > To run the tests evaluate: > > MagmaTestCase allowWriteBarrier: false. > MagmaTestCase fullSuite maDebug. > > > Stable versions > --------------- > > This release of ConfigurationOfMagma includes support for Metacello's > symbolic versions. Currently the #stable version of Magma is configured > like this: > > Pharo version #stable version > ------------- --------------- > Pharo 1.1.x 1.2 > Pharo 1.2.x 1.2 > Pharo 1.3.x 1.2 > > That is, Magma 1.2 is the #stable version for Pharo 1.1, Pharo 1.2 and > Pharo 1.3. > > Known issues > -------------- > > Magma 1.2 loads correctly and appears to work for the basic things > (create a repo, add data, commit, etc) in PharoCore 1.3 and Pharo 1.3, > but the full suite hasn't ran correctly in the current unstable Pharo. > So use Magma 1.2 on Pharo 1.3 on your own risk and not for production > yet. When the issues (including the Transcript revert that should happen > in Pharo soon) are addressed, a new announce will be made for Magma on > Pharo 1.3 > > Any feedback welcome. > > Enjoy. > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > >

April 27, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Tudor Girba

Thanks for reporting. I guess it is because the new Transcript is not yet 100% compatible with the old one. If you still want to try Moose, please just comment the Transcript open part and let us know what happens. Cheers, Doru On 27 Apr 2011, at 21:56, Casimiro de Almeida Barreto wrote: > In PharoDev-1.3.-13173 > > While loading Moose there's a 'Transcript open' in loadDefault. This > image's Transcript does not understand #open. It's preventing clear > installation of moose. > > Best regards, > > CdAB > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

April 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Camillo Bruni

Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. The following uses a local git repos as a monticello repository: MCGitRepository directory: 'test_git' Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. In short, I will use github and share my code with the rest of the world ;). camillo On 2011-04-27, at 21:50, Tudor Girba wrote: > Hi, > > I am not sure I understand the implication. Could you explain, please? :) > > Cheers, > Doru > > > On 27 Apr 2011, at 21:37, Camillo Bruni wrote: > >> Thanks for your help :) >> >> So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;) >> >> On 2011-04-27, at 19:14, Max Leske wrote: >> >>> Concerning 2: >>> No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil. >>> >>> I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug... >>> >>> >>> On 27.04.2011, at 16:21, Camillo Bruni wrote: >>> >>>> Hi Max, >>>> >>>> I took another effort to work on the git bindings of MC. >>>> However I ran into troubles with FSGitFilesystem on commiting. >>>> >>>> 1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet... >>>> >>>> 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature >>>> does not throw an exception but simply returns nil? does this make sense? >>>> >>>> >>>> maybe you have a clue how to solve this faster than I do :-) >>>> >>>> camillo >>> >>> >> >> > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > >

April 27, 2011

Re: [Pharo-project] squeaksource is down - a different perspective

by Marcus Denker

On Apr 27, 2011, at 10:00 PM, StÃ©phane Ducasse wrote: > >>> squeaksource.com is down a lot. People get frustrated at times. >> >> Yes, and unfortunately it looks like people love to be frustrated. >> >> Otherwise people would give Tobias more feedback on SqueakSource3 (see [1]) which IMHO could overtake the job in the future and replace the >> problematic image? > > I do not know. > Do SS3 has a migration process? > How easy is it to install on an old machine? > Does gemstone run on a old mac g3? I think we could ask SCG for running it on one of the newer machines (64bit Linux). > Should we install glass? > I do not know. > Migration of existing data is the largest problem... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Sven Van Caekenberghe

On 27 Apr 2011, at 20:35, Henrik Sperre Johansen wrote: > Implementing use of CLDR data is the way to go if you want something that is > both reliable and works. This was mentioned by others too ( http://cldr.unicode.org/ ). That would indeed be a nice project, and no ugly plugins would be needed, pure Smalltalk only, that we all can understand and debug. Sven

April 27, 2011