- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Impressed, overwhelmed, and a little confused

by Igor Stasenko

2008/12/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I do not understand what you mean. > I think that universe = a dsitribution is a good idea. > which have no guarantees that any package in it will work in your image :) > Stef > > On Dec 3, 2008, at 10:16 PM, Keith Hodges wrote: > >> StÃ©phane Ducasse wrote: >>> >>> There will be a pharo universe I imagine. >>> >>> Stef >> >> please no... let the suffering end >> >> Keith >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 3, 2008

[Pharo-project] Fwd: [squeak-dev] Rio: exceptions documentation

by David Pennell

Should we add an item on the tracker to remove CrLfFileStream? ---------- Forwarded message ---------- From: Keith Hodges <keith_hodges(a)yahoo.co.uk> Date: Wed, Dec 3, 2008 at 8:04 AM Subject: Re: [squeak-dev] Rio: exceptions documentation To: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> [snip] CrLfStream has been replaced by MultiByteFileStream and this can be set to read in various modes, it is also supposed to detect the line ending convention. Unfortunately this was disabled by default. Rio was explicitly telling binary streams that they were binary streams, but was omitting to tell ascii streams to enable lineEndingdetection. thanks for the feedback. Keith

Dec. 3, 2008

Re: [Pharo-project] Polymorph password dialog enhancement

by Marcus Denker

On 03.12.2008, at 22:10, StÃ©phane Ducasse wrote: >> >> >> The problem is that removing etoys is not a clean thing. We have >> first methods >> that are needed to be changed for both removing etoys *and* >> polymorph. So that's >> why the packages need to be in the pharo repository. >> >> In general, if you think about code quality or modularity in the >> context of Squeak: >> Think about the worst you can think of, then multiply it by a >> factor of 100. Then >> you get to what the current state is in Squeak. It's a mess of epic >> proportions... > > Not that quite :) :-) > > It is getting better every day. :) > And I will really get better. > Now this is true that etoy is a great idea Yes! > with a bad implementation. Maybe it's not even the implementation... every implementation has it's problems. I think in hindsight, the problem is that they just never cleaned up. And with that, they just stopped to invest in the future. It was always "the two week prototype that will be replaced soon". And 10 years later, it was a mess (and there was no replacement, of course). There is a lot that one can learn from that. (And I hope that viewpoints did a good postmortem analysis of the etoys project so that they can incorporate these lessons into the things that they are working on right now...) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Dec. 3, 2008

Re: [Pharo-project] Monticello configuration still broken

by StÃ©phane Ducasse

Because we did not have the time (and nobody took the time to look at the code and write a report for us on the extensions and status of MC1.5 and MC1.6) This is on the pipeline like SUnit+ and KernelExtensions. Now december is a ***terrible*** for researchers in France and I cannot cut myself in more slices than already done. Stef On Dec 3, 2008, at 10:20 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Yes but when we load a package we load the package and its extensions >> and in Pharo >> we take care about that. >> >> Stef > So why do you stick with a broken MC then? > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 3, 2008

Re: [Pharo-project] Impressed, overwhelmed, and a little confused

by StÃ©phane Ducasse

I do not understand what you mean. I think that universe = a dsitribution is a good idea. Stef On Dec 3, 2008, at 10:16 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> There will be a pharo universe I imagine. >> >> Stef > please no... let the suffering end > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 3, 2008

Re: [Pharo-project] some new issues for unimplemented calls

by StÃ©phane Ducasse

thanks pavel We will go over the list and integrates what should be. On Dec 3, 2008, at 10:15 PM, Pavel Krivanek wrote: > Hi, > > I added several new simple issues for removing few unimplemented > calls: > http://code.google.com/p/pharo/issues/detail?id=373 > http://code.google.com/p/pharo/issues/detail?id=374 > http://code.google.com/p/pharo/issues/detail?id=375 > http://code.google.com/p/pharo/issues/detail?id=376 > http://code.google.com/p/pharo/issues/detail?id=377 > http://code.google.com/p/pharo/issues/detail?id=378 > http://code.google.com/p/pharo/issues/detail?id=379 > > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 3, 2008

Re: [Pharo-project] Monticello configuration still broken

by Keith Hodges

StÃ©phane Ducasse wrote: > Yes but when we load a package we load the package and its extensions > and in Pharo > we take care about that. > > Stef So why do you stick with a broken MC then? Keith

Dec. 3, 2008

Re: [Pharo-project] Impressed, overwhelmed, and a little confused

by Keith Hodges

Dec. 3, 2008

[Pharo-project] 10183 freeze on Gatesware

by Bill Schwab

I just downloaded 10183 to an XP machine, copied a VM and changes and dragged the image to the vm. It starts just fine, but the GUI is frozen. The VM system menu opens up and works. Unfortunately, the thread dump shows only the current thread, which appears to be the idle process: 155872232 >idleProcess 155871568 [] in >startUp 155871660 [] in BlockContext>newProcess Any ideas? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Dec. 3, 2008

[Pharo-project] some new issues for unimplemented calls

by Pavel Krivanek

Hi, I added several new simple issues for removing few unimplemented calls: http://code.google.com/p/pharo/issues/detail?id=373 http://code.google.com/p/pharo/issues/detail?id=374 http://code.google.com/p/pharo/issues/detail?id=375 http://code.google.com/p/pharo/issues/detail?id=376 http://code.google.com/p/pharo/issues/detail?id=377 http://code.google.com/p/pharo/issues/detail?id=378 http://code.google.com/p/pharo/issues/detail?id=379 -- Pavel

Dec. 3, 2008