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

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Damien Pollet

On 13 August 2011 09:05, Lukas Renggli <renggli(a)gmail.com> wrote: > I don't really see the point of PPElementParser? Why don't you just use > > Â Â aParser answer: anObject something like this ? this temp feels strangeâ¦ PPPredicateObjectParser class >> matching: elementParser message: aString | result | ^ (self on: [ :each | result := elementParser parse: each. result isPetitFailure not ] message: aString) answer: result -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

Re: [Pharo-project] is there a way I can see the PharoDebug of a hudson job?

by Lukas Renggli

builder.sh writes "PharoDebug.log" and since recently also "crash.dmp" to the error console, so that Jenkins displays them in the build log. Also you can find all build-artifacts (such as PharoDebug.log and crash.dmp) in the workspace. Lukas On 13 August 2011 14:30, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > because a test is red and I don't have enough information with the small > stack show in Hudson. > > THanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] splitting MC packages

by Damien Pollet

On 13 August 2011 09:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > A useful script for renaming a package that ensures also that extensions get renamed: argh, and you send me this just after I did the whole thing by hand :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

[Pharo-project] is there a way I can see the PharoDebug of a hudson job?

by Mariano Martinez Peck

because a test is red and I don't have enough information with the small stack show in Hudson. THanks -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2011

Re: [Pharo-project] Pharo 1.3 and Complex

by StÃ©phane Ducasse

Thanks jurgen You should have a look in the pharo archive because we got a long discussion on the squeak complex implementation (the one pharo had before) Ken Dickey proposed some other implementation. I'm not sure that this one is correct. it would be good to have a clear point on that. Please send mail to the mailing list because else I cannot reply individually and other people can comment too. Stef On Aug 12, 2011, at 7:59 PM, Juergen Dabel wrote: > Sir, > > the Complex Numbers are not included in Pharo but in Squeak, when I file out Complex in Squeak I see that some methods are missing in Number, Float, Integer and an error in Complex itself. The class comment I did format and correct some typos, some math functions are included now, so these can be deleted from the comment. I add a text file and hope I did not miss something. > > My best regards > > JÃ¼rgen Dabel > Schrobenhausen > Germany > j.dabel(a)t-online.de > > <FÃ¼r Complex benÃ¶tigt.rtf>

Aug. 13, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by Mariano Martinez Peck

Nicolas Passerini commited a '-m32' flag to the CogUnixConfiguration in order to be able to compile it on a 64bits machine. Can you check it is still there? maybe it only was added to the VM and not to plugins. On Sat, Aug 13, 2011 at 11:13 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > > Hi > > I try to build a 32bits Cog on Debian 64 bits. I do: > > apt-get install libsm-dev libasound2-dev libgl1-mesa-dev cmake g++ > libc6-dev-i386 > > git clone --depth 1 git:// > gitorious.org/~laurentlaffont/cogvm/smallharbour.git<http://gitorious.org/%7Elaurentlaffont/cogvm/smallharbour.git>shvm > cd shvm/codegen-scripts/ > export SQUEAKVM=/usr/local/bin/coglinux/squeak > sh ./buildImage.sh -headless > sh ./generate.sh -headless CogUnixConfig > cd ../build/ > sh ../codegen-scripts/extract-commit-info.sh > cmake . > make > > > I have the error: > > [ 94%] Built target CogVM > Linking C shared library /root/securedvm/results/vm-display-null > /usr/bin/ld: i386 architecture of input file > `CMakeFiles/vm-display-null.dir/root/securedvm/platforms/unix/vm-display-null/sqUnixDisplayNull.c.o' > is incompatible with i386:x86-64 output > > Any idea ? > > > > Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > > > -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2011

Re: [Pharo-project] Is Pharo 1.3 officially released?

by Marcus Denker

On Aug 12, 2011, at 11:42 PM, Sean P. DeNigris wrote: > I see there is now a link on the website to "Release 1.3" and that "stable" > points to 1.3. > Yes, but we need to provide a One-Click image and update the website before we can officially announce... This will happen next week. -- Marcus Denker -- http://marcusdenker.de

Aug. 13, 2011

[Pharo-project] building Cog on 64 bits debian

by laurent laffont

Hi I try to build a 32bits Cog on Debian 64 bits. I do: apt-get install libsm-dev libasound2-dev libgl1-mesa-dev cmake g++ libc6-dev-i386 git clone --depth 1 git:// gitorious.org/~laurentlaffont/cogvm/smallharbour.git shvm cd shvm/codegen-scripts/ export SQUEAKVM=/usr/local/bin/coglinux/squeak sh ./buildImage.sh -headless sh ./generate.sh -headless CogUnixConfig cd ../build/ sh ../codegen-scripts/extract-commit-info.sh cmake . make I have the error: [ 94%] Built target CogVM Linking C shared library /root/securedvm/results/vm-display-null /usr/bin/ld: i386 architecture of input file `CMakeFiles/vm-display-null.dir/root/securedvm/platforms/unix/vm-display-null/sqUnixDisplayNull.c.o' is incompatible with i386:x86-64 output Any idea ? Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

Aug. 13, 2011

[Pharo-project] [update 1.4] #14090

by Marcus Denker

14090 ----- Issue 4632: cleanup packages http://code.google.com/p/pharo/issues/detail?id=4632 Issue 4630: Some fixes for shout http://code.google.com/p/pharo/issues/detail?id=4630 Issue 4628: Nuking ImageSegment (Part II) http://code.google.com/p/pharo/issues/detail?id=4628 -- Marcus Denker -- http://marcusdenker.de

Aug. 13, 2011

Re: [Pharo-project] splitting MC packages

by Tudor Girba

On 13 Aug 2011, at 09:06, Lukas Renggli wrote: > On 12 August 2011 23:32, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> On 12 August 2011 22:21, Lukas Renggli <renggli(a)gmail.com> wrote: >>> The only solution is to stick with consistent and well though package >>> name scheme. Not the only possible naming strategy, but the one we >>> developed for Seaside works pretty well: >>> http://code.google.com/p/seaside/wiki/PackageNaming >> >> I know about these conventions, but how do I proceed towards them? :) > > Closing the eyes and restarting from scratch. We did that too with the > Seaside packages at some point. We did the same for Moose. We kind of followed this process: 1. create new sub-package XYZ-Sub* 2. move classes from XYZ to XYZ-Sub* 3. repeat until all classes and extensions from XYZ are moved away to subpackages 4. add the Monticello repository to XYZ-Sub* 5. commit all XYZ-Sub* packages. Make sure that there are no categories without packages left behind (in other words to not lose code) 6. save the image 7. load in a fresh image 8. if problems appear, and they always appear because it is manual work, go to the previous image and recommit A useful script for renaming a package that ensures also that extensions get renamed: renamePackage: oldPackageName to: newPackageName "self renamePackage: 'Seaside-Squeak-Development-Core' to: 'Seaside-Pharo-Development-Core'" | oldPackage newPackage oldWorkingCopy newWorkingCopy | oldPackage := PackageInfo named: oldPackageName. newPackage := PackageInfo named: newPackageName. " rename system categories " oldPackage systemCategories do: [ :oldCategory | | newCategory | newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. Smalltalk organization renameCategory: oldCategory toBe: newPackage systemCategoryPrefix , newCategory ]. " rename method categories " oldPackage extensionClasses do: [ :extensionClass | (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | | newProtocol | newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. extensionClass organization renameCategory: oldProtocol toBe: newPackage methodCategoryPrefix , newProtocol ] ]. " update monticello packages " oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. " test is all methos have been caught " oldPackage methods isEmpty ifTrue: [ oldWorkingCopy unload. PackageOrganizer default unregisterPackage: oldPackage ] ifFalse: [ self error: 'Some code entities remain in the old package, please migrate manually.' ] Cheers, Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Aug. 13, 2011