January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Block explained continued

by StÃ©phane Ducasse

I rewrote it. Read this version it is much better. Stef On Jan 30, 2012, at 12:15 AM, Helene Bilbo wrote: > I read your text and am confused about "returing" _from_ or _to_ the > homecontext and "escaping to" the homecontext. Do I understand it right this > way: > > - As a block is executed always in it's home-context, when there is an > explicit return statement inside the block, this return statement will also > be executed in the home-context, which means this return statement makes the > execution return *from* the home-context (*not* return from the context in > which the value message was sent *to* the home-context?)? > > - The word 'continuation' is used when there is an explicit return statement > in a block - It means the execution continues in the context "before" the > home-context? > > -- > View this message in context: http://forum.world.st/Block-explained-continued-tp4338472p4339548.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by StÃ©phane Ducasse

I will with pleasureâ¦. Stef On Jan 30, 2012, at 9:50 AM, Mariano Martinez Peck wrote: > > > On Sun, Jan 29, 2012 at 10:53 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I don't see any PseudoContext in squeak trunk, you can reasonably not > afford to be dirtier ;) > > > YES!! And this class got me crazy once because it subclass from nil !! > BTW, we should also fix the senders of #isPseudoContext if we remoev the class. > > > 2012/1/29 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On Jan 29, 2012, at 6:02 PM, StÃ©phane Ducasse wrote: > > > >> Hi > >> > >> I have the impression that PseudoContext is not used anymore. At least compact class array and special object array > >> do not use it anymore. So what is the use for this class? > >> > > I think it was only used by Ian's original Jitter... which means 10 years unused. > > We should remove it. > > > > Marcus > > > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 30, 2012

Re: [Pharo-project] loading Seaside 3.0.6.3 in Pharo 1.4

by StÃ©phane Ducasse

thanks for the effort. Stef On Jan 29, 2012, at 9:30 PM, Esteban Lorenzano wrote: > > El 29/01/2012, a las 5:23p.m., Esteban Lorenzano escribiÃ³: > >> 2) String>>#withBlanksTrimmed is deprecated, and now it should use #trimBoth > > I'm seeing this one, #trimBoth comes from grease... so I suppose seaside should use it, instead withBlanksTrimmed > > best, > Esteban > >

Jan. 30, 2012

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by Damien Pollet

On 28 January 2012 23:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > suggesting is doing a kind of âsvn co http://xxxx -r 2202â³. I checked how to do this in git, and it seems not to provide a clone of a specific version. Instead, you just clone (from the latest one) and then you checkout or revert to a previous one. Execute: > > 1cd blessed > 2git checkout f3fe94c828f66cd0e7c37cfa3434e384ff65915e Please use tags to mark which commits are safe, that's what they're here forâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by Mariano Martinez Peck

On Sun, Jan 29, 2012 at 10:53 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > I don't see any PseudoContext in squeak trunk, you can reasonably not > afford to be dirtier ;) > > YES!! And this class got me crazy once because it subclass from nil !! BTW, we should also fix the senders of #isPseudoContext if we remoev the class. > 2012/1/29 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On Jan 29, 2012, at 6:02 PM, StÃ©phane Ducasse wrote: > > > >> Hi > >> > >> I have the impression that PseudoContext is not used anymore. At least > compact class array and special object array > >> do not use it anymore. So what is the use for this class? > >> > > I think it was only used by Ian's original Jitter... which means 10 > years unused. > > We should remove it. > > > > Marcus > > > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 30, 2012

Re: [Pharo-project] [:x :y| x*x. â x + y]

by Igor Stasenko

On 29 January 2012 13:40, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > Am 2012-01-29 um 13:17 schrieb Dave Mason: > >> >> On 2012-Jan-29, at 4:22 , StÃ©phane Ducasse wrote: >> >>> is there a naming convention for such blocks. In the chapter I called them escaping block >>> but I also used continuation blocks. (I do not like continuation blocks since to me it is unclear) but >>> if this is a convention I would follow it. >> >> Continuation blocks is wrong - continuations are a particular thing and this would be confusing. >> >> Escaping blocks is fine, but I call them returning blocks. I could see an argument for either > > I think these are "blocks with non-local return" :) > (as opposed to blocks with "local return" like [:x :y| x*x. x + y]) > indeed . > Best > Â Â Â Â -Tobias -- Best regards, Igor Stasenko.

Jan. 30, 2012

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by dimitris chloupis

I am afraid that wont work XCODE no longer comes with any gcc included besides llvm-gcc (I am not near my mac to try this but I am pretty sure it will fail). Apple has abandoned gcc completely and it wont be included again in XCODE as far as I have ready from the several websites.Â Last gcc was included was XCODE 4.1. If you are like me a user with a clean install of Lion and XCODE 4.2 you are out of lack. By the way you are not the only one open source project to have this issue , seems all open source project are faced with the same issue. I am a noob with this whole thing but I think that on macos at least if you still want to depend on XCODE llvm is an one way street.Â ________________________________ From: Camillo Bruni <camillo.bruni(a)inria.fr> To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, 30 January 2012, 4:34 Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion I extended the HOWTOBUILD in the blessed repository. For me Â Â Â Â cd build Â Â Â Â export CC='/usr/bin/gcc-4.2'Â Â # as of 10.7 llvm is the incompatible default compiler Â Â Â Â export MACOSX_DEPLOYMENT_TARGET=10.5 Â Â Â Â cmake . Â Â Â Â make worked. And yeah, I wouldn't symlink it either :) too bad that we can't use clang/llvm yet for the compilation. The error handling is so much better than in gcc :P best cami On 2012-01-29, at 22:06, Esteban Lorenzano wrote: > maybe, but he can restore default gcc after trying. I asked for removing a symlink, not the llvm compiler it self. > Right now I do not have a better/faster way to doit... and he needs to compile his vm, so... > > > El 29/01/2012, a las 6:00p.m., Stefan Marr escribiÃ³: > >> >> On 29 Jan 2012, at 21:09, Esteban Lorenzano wrote: >> >>> he... connection problems... yeah, I know a lot about them :) >>> >>> well... after a successful install, I *think* you should have gcc and gcc-4.2... last one is also a symlink who points to: >>> >>> /usr/bin/i686-apple-darwin11-gcc-4.2.1 >> >> We have seen GCC 4.2 disappearing after Lion upgrades and Xcode 4.2 installs. >> >> And Esteban, I do not think that changing the systems default compiler just for a single program can be the recommended practice. >> >> "sudo rm /usr/bin/gcc" is certainly only the very last resort. >> It should not be advertised if there are other ways to use a supported compiler. >> Camillo mentioned that setting the CC environment variables correctly worked for him. >> >> >> ... sudo - With great power comes great responsibility ... >> >> 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 >> >> > >

Jan. 30, 2012

[Pharo-project] pharo vision

by StÃ©phane Ducasse

Jan. 30, 2012

Re: [Pharo-project] MCWorkingCopy>>#uniqueVersionName

by Lukas Renggli

>> Ironically this proposition would make some Monticello operations >> slower, because Monticello will need to download and open all versions >> with the same name to figure out if the ancestry matches. >> >> Furthermore, this would subtly break many tools, because most of them >> do not look at the ancestry but only at the filename (again to make it >> fast). >> >> Last but not least, the proposal will annoy people that want to >> integrate changes and that cannot because a file with that name is >> already in their repository. > > Can we then do nothing at all ? Commit speed has never been a problem to me. > What about changing the naming, like adding an extra UUID to the name ? That would have been a solution before all tools started to depend on the naming. > Don't _you_ have any ideas about speeding up Monticello ? Use Monticello 2 that addresses this and many other problems of Monticello 1. But then people also criticize Monticello 2 because it addresses this problem, and version data is not human readable anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 30, 2012

Re: [Pharo-project] MCWorkingCopy>>#uniqueVersionName

by Sven Van Caekenberghe

Lukas, On 30 Jan 2012, at 06:53, Lukas Renggli wrote: > Ironically this proposition would make some Monticello operations > slower, because Monticello will need to download and open all versions > with the same name to figure out if the ancestry matches. > > Furthermore, this would subtly break many tools, because most of them > do not look at the ancestry but only at the filename (again to make it > fast). > > Last but not least, the proposal will annoy people that want to > integrate changes and that cannot because a file with that name is > already in their repository. Can we then do nothing at all ? What about changing the naming, like adding an extra UUID to the name ? Don't _you_ have any ideas about speeding up Monticello ? Thx, Sven

Jan. 30, 2012