April 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] LocalePlugin (was: new Cog VMs uploaded)

by David T. Lewis

On Wed, Apr 27, 2011 at 08:43:06PM +0200, Henrik Sperre Johansen wrote: > On 27.04.2011 20:35, Henrik Sperre Johansen wrote: > >Also note, primShortDateFormat does nothing with the Locale you specify. > > > >All the primitives return values for the current process locale. (Set at > >startup to system locale rather than C) > > > >You'd need to forcibly change the process locale with primSetLocale from > >ImmX11Plugin (which isn't available in the image, thank God), and hope your > >linux has that locale installed > >(Ubuntu f.ex. only comes with a single one installed by default, and > >switching to anything but that or C will fail) > > > >Can't use primGetLocale (not accessible from image either :D ) to check if > >it's been successful though, as that resets the locale to system locale :) > > > >TLDR; What you want to do is impossible with the current implementation. > >Correcting it is really a waste of time, as something which works correct > >would be shabby at best. > >Implementing use of CLDR data is the way to go if you want something that > >is > >both reliable and works. > > > >The only bits the Locale plugin is good at (should be used for), is getting > >the system defined country/language. > > > >Cheers, > >Henry > > > > > Oh wait, I forgot. > LocalePlugin caches the values for the current locale at startup, so it > wouldn't work changing it later anyways. > > Sorry for the noise (except the TLDR part). If anyone is interested in learning about the VM, writing your own plugin or improving an existing plugin is a great way to get started. The LocalePlugin does not get much attention, so if someone has an interest in improving it, this might make a good small project. Dave

April 28, 2011

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

by Miguel CobÃ¡

Yes is in the to-do list. Some weeks ago Mariano created an account on the book site for me in order to update the relevant sections but only until now the configuration is working. I will update it ASAP. Cheers El miÃ©, 27-04-2011 a las 22:13 +0200, StÃ©phane Ducasse escribiÃ³: > 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 > > > > > > > > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 27, 2011

Re: [Pharo-project] [Moose-dev] Re: roeltyper problem

by Tudor Girba

Hi FrÃ©dÃ©ric, It looks like RoelTyper does not work with the latest Pharo. Would you have time to take a look at the problem listed below? Cheers, Doru On 26 Apr 2011, at 23:20, Lukas Renggli wrote: > Indeed, the same here. I didn't read your code and expected to see a debugger. > > Ask Frederic Pluquet, I think he added the support for the new blocks. > There seems to be something wrong with the remote temp vectors that is > beyond my scope. > > In the meantime you might want to try RBRefactoryTyper. It is much > slower, as it is runs on the AST and thus needs to parse all methods. > I think it is comparable in quality, the code can be understood quite > easily, and it can even type things in collections. > > Lukas > > On 26 April 2011 22:44, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> Strange that it works for you. I just loaded your version in 1.2.1 and I still get the same problem (actually now I have only 28 classes with problems). >> >> What version of Pharo did you try it in? >> >> Cheers, >> Doru >> >> >> On 26 Apr 2011, at 21:03, Lukas Renggli wrote: >> >>> It works for me, please try the version here: >>> http://source.lukas-renggli.ch/unsorted >>> >>> Lukas >>> >>> On 26 April 2011 20:31, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>> Hi, >>>> >>>> I am trying to use RoelTyper, but I encountered subscript out of bounds and empty collection errors. It looks like this problem can be reproduced on 29 classes from Pharo 1.2.1. You can test it using: >>>> >>>> classes := Dictionary new. >>>> Object withAllSubclassesDo: [:each | >>>> [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. >>>> classes inspect >>>> >>>> I am not knowledgeable enough to dive into this. Can anyone help? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Value is always contextual." >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Obvious things are difficult to teach."

April 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Tudor Girba

Hi, On 27 Apr 2011, at 23:20, Camillo Bruni wrote: > > 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. Just a note: If this code is to have the possibility of being used in a Pharo-distribution, it would need to be MIT. Cheers, Doru > >> 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 >> >> > > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

April 27, 2011

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