- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

>> >> >> -> some small migration guide would be nice, maybe even a Lint rule that >> checks for removed globals ;-) >> > > Yes.. now I have no time to do this. Who wants? We will start with andre to work on SmallLint rules and learn how it works. Stef

April 28, 2011

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

by StÃ©phane Ducasse

But Zinc will be soon part of core. Probably even later today :) On Apr 27, 2011, at 6:41 PM, Sven Van Caekenberghe wrote: > > On 27 Apr 2011, at 18:27, Philippe Marschall wrote: > >> - ZnServer class >> #initialize references AutoStart > > Zn is not a standard part of this image, so it must have come with Seaside ? > If so, that would be cool, that is something that I want ! > > Anyway, > > ZnServer class>>initialize > Smalltalk addToStartUpList: self after: AutoStart. > Smalltalk addToShutDownList: self > > Indeed AutoStart seems to be gone. > I just picked that code up somewhere, what should it have to be then ? > > Apart from that loading error, all Zn tests are green. > > Thx, > > Sven > >

April 28, 2011

[Pharo-project] Preallocation behavior

by jannik.laval

Hi all, I am playing with MessageTally, and I have a strange result with prealocation. Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 First of all, I spy this source code: ==== MessageTally spyOn: [ 500 timesRepeat: [ | str | str := ''. 9000 timesRepeat: [ str := str, 'A' ]]]. ==== The result appears after 24 961 ms. An optimization is to use a Stream. Here is my source code: === MessageTally spyOn: [ 500 timesRepeat: [ | str | str := WriteStream on: (String new). 9000 timesRepeat: [ str nextPut: $A ]]]. === The result appears after 812 ms, which is a large improvement. Now, we could optimize again using the preallocation. Here is my source code: ==== MessageTally spyOn: [ 500 timesRepeat: [ | str | str := WriteStream on: (String new: 10000). 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. ==== And the result is strange: it makes 2 times slower to display the result. The result appears after 1656 ms. Here is the spy result: === - 1656 tallies, 1656 msec. **Tree** -------------------------------- Process: (40s) 464519168: nil -------------------------------- **Leaves** 22.9% {380ms} UndefinedObject>>DoIt 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: 22.2% {368ms} WriteStream>>nextPutAll: === There is the call of UndefinedObject>>DoIt which is added and takes time. Does anyone know what is done during the preallocation ? Why is it slower than non-preallocation ? Thanks for your answers. Jannik

April 28, 2011

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

by StÃ©phane Ducasse

I was thinking about migration from SS to SS3 On Apr 27, 2011, at 10:16 PM, Dale Henrichs wrote: > 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 28, 2011

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

by Serge Stinckwich

On Wed, Apr 27, 2011 at 3:21 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that > doesn't happens automagically. We all need to start using and testing the > image before they are release. It is for the better of all of us. The more > we test the more stable will be the release. So...we need your help. What > you can do? > > 1) test test test test test. Use it. Take this image and use it for your > regular work. > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > 4) Fix errors/failures tests > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is > released and then ask "uuhh what happened to XXX? you removed? ohhh but I > use it". > 6) Do you maintain Metacello configurations?Â ok, if you test your project > and works correctly in Pharo 1.3, please update (or create if you don't yet > have it) the #stable, > 7) Do you maintain packages included in Pharo?Â please check we are using > the correct versions > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, DBXTalk, > Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > Pharo-1.3-13173Â should work with Interpreter VM and with Cog. For Cog I > recommend to download the last one from Eliot's page: > http://www.mirandabanda.org/files/Cog/VM/ I try with VM Squeak 4.2.5beta1U on mac os x 10.6.7 but the image is not launch at all. No problem to launch the image with last cog VM. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 28, 2011

Re: [Pharo-project] GitFs / MCGit

by Serge Stinckwich

On Thu, Apr 28, 2011 at 3:37 AM, Stefan Marr <pharo(a)stefan-marr.de> 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' Maybe you should document how do that. Some people might be interested in order to mitigate the problems related to SqueakSource unstabilities. > 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. Eclipse Public Licence (EPL) is a bit strange for Smalltalk code :-) but there is no problem if the code is not integrated in Pharo. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 28, 2011

[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