July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] MergeTool request
by Nicolas Cellier July 19, 2009

July 19, 2009

Could we have: - an indication of method timestamps (with initials) - a button to select/reject all changes at once (usefull if you merge with a distant fork and want to be very selective) Nicolas

2 3

[Pharo-project] Senders and implementors WAS: Pharo apparently slow on linux
by Mariano Martinez Peck July 19, 2009

July 19, 2009

I don't know you what I use senders and implementors everytime. Too frecuently. Frecuently enought so that to put them in the first menu and not insidethe "extended search". Don't you rather them to be in the first menu ?? ---------- Forwarded message ---------- From: Adrian Lienhard <adi(a)netstyle.ch> Date: Sat, Jul 18, 2009 at 10:13 AM Subject: Re: [Pharo-project] Pharo apparently slow on linux To: Pharo-project(a)lists.gforge.inria.fr These actions are in the submenu "extended search". HTH, Adrian On Jul 18, 2009, at 15:00 , Schwab,Wilhelm K wrote: > They might be (I'll have to use them for a while), though I would > still like to see especially the browse command along side of > evaluate/inspect/explore in the menus. > > Thanks, > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Saturday, July 18, 2009 1:46 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo apparently slow on linux > > > On Jul 18, 2009, at 08:02 , Schwab,Wilhelm K wrote: > >> Laurent, >> >> I will preface this by saying that I have had a fairly intense week >> with Pharo. I am closing in on a solution to a real problem. I >> greatly miss Dolphin's Browse-it command, and its F12 and shift-F12 >> (definitions/references to a typed selector); the message search has >> its points, but it takes some extra steps to use in comparison to the >> Dolphin features. > > Isn't Ctrl-b (browse selected class name), Ctrl-m (implementors of > selector), Ctrl-n (senders of selector), and Ctrl-shift-n (class > references) doing the same? I almost never use the message search > but always these shortcuts. > > Adrian > >> Back to the topic at hand; let's see if I am following. Start with a >> core image, run a script that installs what looks like a Pharo web >> image, makes a few changes to settings in favor of speed, and you get >> something that you find faster than Pharo?? Did you make the same >> speed selections in Pharo? If so, one wonders what happened between >> core and Pharo-dev/web that Lukas did not do to the core image. >> >> Sorry if I'm off base here - it's been a long and very good few days. >> >> Bill >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of laurent laffont >> Sent: Saturday, July 18, 2009 12:45 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pharo apparently slow on linux >> >> >> On Fri, Jul 17, 2009 at 8:31 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> Hi >> >> David shaffer reported to me in fuzzy way that pharo is slow on >> linux. >> Dear linux users can you report if you experienced the same and on >> which >> machine >> distributions >> vm >> image >> >> please compare the core and the dev (with browser usage) >> >> _______________________________________________ >> >> Hi, >> >> machine: core duo 2.0 GHz, 1 GB RAM (White Macbook, 2007) >> distribution: Archlinux >> vm: exupery pharo-vm-0.15.1b-linux.zip >> images: pharo0.1-10373dev09.07.2 and latest Pharo-Core >> >> Pharo-Core: (System Browser) >> - startup time: instantaneous >> - navigate randomly in browser: 3% - 8% CPU usage >> - find class OrderedCollection: ~10% CPU >> - browse senders of add: time to open 1s, 21% CPU >> >> Pharo-Dev: (Package Browser) >> - statup time: 3s (cold start 5s) >> - navigate randomly in browser: 9% - 15% CPU usage >> - find class OrderedCollection: ~13% CPU >> - browse senders of add: time to open 19s, 48% CPU >> >> Now I'm using Pharo-Core with Luka's scripts >> (http://code.google.com/p/pharo/wiki/ImageBuildScripts >> ) as it's far more pleasant to use for me. >> >> Laurent >> _______________________________________________ >> 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 > > _______________________________________________ > 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

5 8

[Pharo-project] Fwd: feedback on Issue 860: Accelerate MulitByteFileStream
by StÃ©phane Ducasse July 19, 2009

July 19, 2009

Hi would be good to have feedback on http://code.google.com/p/pharo/issues/detail?id=860 Stef

1 0

[Pharo-project] Bug in MCAddition>>#shortSummary
by Nicolas Cellier July 19, 2009

July 19, 2009

To trigger this, just try to merge http://source.squeak.org/trunk/Kernel-nice.193 -> MCPreambleDefinition doesNotUnderstand: #selector

1 0

[Pharo-project] Fwd: about merging some CUIS changes into pharo
by StÃ©phane Ducasse July 19, 2009

July 19, 2009

juan words :) Begin forwarded message: > From: Juan Vuletich <juan(a)jvuletich.org> > Date: July 19, 2009 12:11:03 AM CEDT > To: stephane ducasse <stephane.ducasse(a)gmail.com> > Cc: Adrian Lienhard <alienhard(a)netstyle.ch> > Subject: Re: about merging some CUIS changes into pharo > > Hi Stef, > > stephane ducasse wrote: >> Hi Juan >> >> What are the changes you did that you think are worth harvesting in >> other forks? >> >> http://www.jvuletich.org/Cuis/Categories.txt > > I selected the most relevant ones, and pasted them at the end of > this message. I think you'd start with them. Please keep in mind > that these changes were intended for a different code base, so many > will require tweaking for Pharo. Hopefully you can understand what > the intent of each change set was. Some of them came straight from > Mantis, or adapted for Cuis from the Squeak versions. Most of them > indicate the Mantis # in the name. > > The MessageTally enh are the most important. Current MessageTally is > seriously flawed if more than one process is running (which is > _always_ the case!). > > Also, note that I did not include any of the Morphic cleaning stuff, > because they would break compatibility with much stuff. > > I also did not include NiceFonts (AA StrikeFonts) stuff. I guess you > don't want that into Pharo... If you do want this, before loading > the changesets you'd need to load the NiceFonts package from > SqueakMap (it is not updated with numbered updates, so add them > afterwards). > > Finally, I started numbering changes about a year ago. So I don't > have changesets for things I did before. However that was mostly > removing stuff, not actual enhancements and bugfixes. > >> If I pick a topic can you give me feedback if I get problems? > > Sure! > > Cheers, > Juan Vuletich > >> Stef > > MessageTally enh > ------------------------- > 0122-MessageTallyEnh-ar-jmv.11.cs > 0191-MessageTallyNoWrap-jmv2.cs > > Nicer Cursors > ------------------- > 0046-Cursor.3.cs > > Chronology enh (just 2 changesets selected) > ------------------------- > 0099-ChronologyEnh-jmv.1.cs > 0226-DateAndTime-fromSeconds-dtl-M7356.cs > > Kernel: Semaphores, Delays, Processes, WeakReferences > ------------------------------------------------------------------------- > 0101-SafeDelay-2-ar.cs > 0102-DelayTweaks-ar.cs > 0103-DelayStartup-jmv.cs > 0104-SemaCritical-ar.cs > 0130-CreateSemaphoreTest-jmv.1.cs > 0131-DelayCleanup-ar.1.cs > 0132-AtomicProcessSuspend-ar.1.cs > 0133-ProcessTerminateFix-ar.2.cs > 0134-DelayWaitTimeout-ar.2.cs > 0135-SignalExceptionFix-ar.1.cs > 0136-assertFix-jmv.1.cs > 0137-SemaTests-ar.cs > 0173-offList-jmv.1.cs > 0187-DelayWaitTimeout-ar.3.cs > 0192-WeakMessageSendFixPart1-jmv-M7352.cs > 0193-WeakMessageSendFixPart2-jmv-M7352.1.cs > 0207-AvoidCreatingDelays-jmv.1.cs > 0212-ForkSenders-jmv.1.cs > 0213-ForkAnswersNil-jmv.5.cs > > Misc goodies and lesser tweaks > ------------------------------------------ > 0053-ensure-close.1.cs > 0058-browseUndeclared.1.cs > 0129-xorFixes-em.1.cs > 0182-RemoveLineFeedsTweak-jmv.1.cs > 0190-isShadowed-jmv.1.cs > 0196-AnalysisTools-jmv.1.cs > 0206-AnalysisToolsEnh-jmv.4.cs > 0214-nilMNU-bf-jmv.1.cs > > Morphic / LightWidgets > ------------------- > 0153-runStepMethodsIn-ar.2.cs > 0189-MenusWithPen.10.cs

1 2

[Pharo-project] MD5 in pharo?
by Esteban Lorenzano July 18, 2009

July 18, 2009

Hi, Some time ago, I read a thread about cryotography, and as far as I remember, some body says about integrate the basic algoritms (MD5 and maybe others) as part of the pharo core. Well... now I need to use MD5 and cryptography package is not working well (it opens a debugger each time I save my image). I wonder if there are another package with MD5? Cheers, Esteban

7 10

[Pharo-project] Fwd: MethodDictionary potential cleanups
by StÃ©phane Ducasse July 18, 2009

July 18, 2009

> > > > On Fri, 17 Jul 2009 22:13:33 +0200, Ralph Boland wrote: > > > MethodDictionary has a method "growNoBecome". > > It is invoked by "MethodDictionary>>fullCheckNoBecome". > > It is invoked by "MethodDictionary>>at:putNoBecome:". > > It is invoked by ????? (that is nobody). > > > > Can anybody explain this or should I generate a bug report? > > Hi Ralph, > > when I saw this the first time, it seemed that the methods without > *become* in their name, would do a #become: but they did not. > > Even if somebody tried with aMethod #become:, sooner or later > the .image > would crash: #becom:ing methods that can be in use by the VM is > always a > very bad idea. So it rather looks like the methods you listed are 100% > pure[tm] rot or crap. > > > I have no idea if any of the Squeak forks exhibit the same behavior. > > I suggest to remove them or, if you feel inclined, to deprecate them. > > /Klaus > > > I am running Squeak 3.10.2. > > > > Ralph Boland > > > > > > > >

2 1

[Pharo-project] Taking the bull by the horns - Was: Re: MD5 in pharo?
by Esteban Lorenzano July 18, 2009

July 18, 2009

Ok... I packaged a cryptography stripped version with hashed methods (MD5 and SHA1)... I'm attaching the monticello package, but I really don't know what is the license of Cryptography (squeaksource doesn't says anything about that). I hope it can be useful in order to integrate them to pharo. Cheers, Esteban

2 1

[Pharo-project] [ANN] update 10380
by Adrian Lienhard July 18, 2009

July 18, 2009

- isFontAvailable fix - Remove check for higherPerformance in doOneCycleFor: (preference to be removed in a second step) - ClosureTests expectedFailures - MethodFinder, SelectorBrowser, ThreadSafeTranscript - Move JoystickMorph to MorphicExtras package - Remove a couple of references to Squeak in strings (like 'SqueakDebug.log' -> 'PharoDebug.log') - Started implementing ScriptLoader>>#cleanUpForProduction ___________________ http://www.adrian-lienhard.ch/

1 0

July 18, 2009

2009/7/17 Andreas Raab <andreas.raab <at> gmx.de>: > Juan Vuletich wrote: >> >> Some might remember >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/124960… >> . It was a discussion about the dangers of using the result of #fork and >> friends, and the convenience of first creating the process, storing it >> somewhere and later doing #resume. In this release of Cuis, all callers of >> #fork and friends that needed the return value were changed for that >> pattern, and now #fork and friends simply return nil. This is the way to >> avoid those nasty bugs. > > I really like that solution. It's simple and ensures people know what > they're doing. > +1 Good to know that someone put that discussion fruits into a practical plane, even if in own fork :) > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig.

3 2