- Pharo-dev - lists.pharo.org

Re: [Pharo-project] A .mcz of Pinesoft's accumulatedfixesapplicableto Pharo

by Gary Chambers

Indeed. I've poked around a bit and it doesn't pick up stuff in image for new packages it would seem. Only changes for previous versions of the package being merged. I think it looks possible to change it to do so though! Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, October 02, 2008 11:27 AM Subject: Re: [Pharo-project] A .mcz of Pinesoft's accumulatedfixesapplicableto Pharo > Ok I think that this is a MC "bug" > > Stef > On Oct 2, 2008, at 11:12 AM, Gary Chambers wrote: > >> Though that seems to make no difference... >> >> Gary >> ----- Original Message ----- From: "Gary Chambers" >> <gazzaguru2(a)btinternet.com >> > >> To: "An open mailing list to discuss any topics related to anopen- >> sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Thursday, October 02, 2008 10:06 AM >> Subject: Re: [Pharo-project] A .mcz of Pinesoft's accumulated >> fixesapplicableto Pharo >> >> >>> Hi Stef, my fault. The override methods are not categorised properly, >>> I'll fix and send a gain if you like. >>> >>> Gary. >> >> _______________________________________________ >> 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

Oct. 2, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixesapplicableto Pharo

by StÃ©phane Ducasse

Ok I think that this is a MC "bug" Stef On Oct 2, 2008, at 11:12 AM, Gary Chambers wrote: > Though that seems to make no difference... > > Gary > ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com > > > To: "An open mailing list to discuss any topics related to anopen- > sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, October 02, 2008 10:06 AM > Subject: Re: [Pharo-project] A .mcz of Pinesoft's accumulated > fixesapplicableto Pharo > > >> Hi Stef, my fault. The override methods are not categorised >> properly, I'll fix and send a gain if you like. >> >> Gary. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 2, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixesapplicableto Pharo

by Gary Chambers

Though that seems to make no difference... Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: "An open mailing list to discuss any topics related to anopen-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, October 02, 2008 10:06 AM Subject: Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixesapplicableto Pharo > Hi Stef, my fault. The override methods are not categorised properly, I'll > fix and send a gain if you like. > > Gary. >

Oct. 2, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicableto Pharo

by Gary Chambers

Hi Stef, my fault. The override methods are not categorised properly, I'll fix and send a gain if you like. Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, September 28, 2008 8:12 AM Subject: Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicableto Pharo Hi simon This is what I meant. I wanted to understand the problem because when we merge this is important to see the diff. stef On Sep 27, 2008, at 10:07 PM, Simon Kirk wrote: > Hmm, OK, I've had a dig around. > > I tried with a Pharo0.1-10074-oneclick package, and I think I see what > you mean: viewing changes via the MC browser on the package I attached > simply shows the entire method in red - even though if I go and find the > equivalent method in the image it exists and should be showing changes > instead. > > I then tried with a Pharo0.1-PolymorphTT package, as I'm more familiar > with the diff tool from Gary's work. Again, the same problem. > > However, if I load the MCZ into the package, then pick, say, > BrowserCommentTextMorph>>#hidePane and view the versions of the method, I > can then see both the original method (sd 11/20/2005 21:26) and Gary's > new version, and the differences between the two. > > So, perhaps the problem is that the Monticello browser can't show you > differences between methods when one method is in the image under one > class category, while the one in the Monticello package to be loaded is > under a different one (the method in this case is an extension, so the > method category for #hidePane would change from "displaying" to > "*Pinesoft-Fixes-Misc" > > I hope that makes sense. I would have thought you would want to keep the > original method categories, just keeping the method source from the MCZ. > > Unfortunately my knowledge of managing such changes falls well short of > knowing how to go about that :( > > Hope this has all made sense and is helpful > Cheers, > S > > On 27 Sep 2008, at 06:58, StÃ©phane Ducasse wrote: > >> >> On Sep 26, 2008, at 10:07 PM, Simon Kirk wrote: >> >>> hi Stef. >>> >>> Hmm, strange. How are you viewing the diffs? If I browse the MCZ in a >>> Monticello browser I see extensions to these classes: >>> >>> BrowserCommentTextMorph >>> BrowserRequestor >>> CanvasCharacterScanner >>> Character >>> ConnectionQueue >>> GrafPort >>> MultiCanvasCharacterScanner >>> NaturalLanguageTranslator >>> Random >>> RemoteString >>> TranscriptStream >>> >>> Is this the diffs you're talking about? If so, I think they're correct. >>> It's possible my rough list below may have missed some changes. >> >> >> I see the same but I cannot see the diff between the changes and what is >> in the image (for example in the merge >> tools I do not (changed) and the like. >> >> Stef >> >>> >>> >>> Cheers, >>> Simon >>> >>> On 26 Sep 2008, at 20:20, StÃ©phane Ducasse wrote: >>> >>>> Simon >>>> >>>> with which machine did you create you mcz? >>>> Because apparently I can see the diffs for other packages. >>>> >>>> Can somebody else check the pinesoft package I put in the pharoInbox? >>>> >>>> Stef >>>> >>>> >>>> >>>>> Hi all. >>>>> >>>>> Gary and I decided we ought to give out an MCZ of our fixes that >>>>> we've put together over the last two years. >>>>> >>>>> Obviously some of those we found have been pulled into Pharo already, >>>>> but the attached MCZ represents those that we think are still >>>>> relevant :) >>>>> >>>>> This is a rough list of the fixes: >>>>> >>>>> 1. Fixed flaky borwser comment text area sometime not showing. >>>>> >>>>> 2. Added getArgumentPermutation to support RefactoringEngine. >>>>> >>>>> 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner to >>>>> correctly align the first line of text when centered/justifed etc. >>>>> >>>>> 4. Added more constant names to Character class. >>>>> >>>>> 5. Modified ConnectionQueue to not accept connections when queue is >>>>> full. >>>>> >>>>> 6. Changed GrafPort to answer a MultiDisplayScanner when appropriate >>>>> (allows subclasses of MultiNewParagraph). >>>>> >>>>> 7. NaturalLanguageTranslator startup postion move to after >>>>> PasteUpMorph since it will show a progress bar. >>>>> >>>>> 8. Fix to Random>>nextInt: to allow large numbers which would be out >>>>> of range if using Floats (as mentioned recently on dev, use of Floats >>>>> is dodgy anyway...) >>>>> >>>>> 9. Changed TranscriptStream>>clear to use a new buffer (was just >>>>> reset which could leave a massive collection). >>>>> >>>>> 10. Changed RemoteString to handle concurrent processes safely. This >>>>> one's particularly interesting: we were load-testing our Seaside app >>>>> here and getting lots of syntax errors when hitting the image with >>>>> around the 20 concurrent processes due to source file access. After >>>>> this change we were hitting it with approximately 500 concurrent >>>>> processes, and the failure was in the Java load tester (it timed >>>>> out). >>>>> >>>>> Hope just submitting a .mcz is OK! :) >>>>> >>>>> Cheers, >>>>> Simon and Gary >>>>> >>>>> >>>>> >>>>> ****************************************************************************************************************************************** >>>>> This email is from Pinesoft Limited. Its contents are confidential to >>>>> the intended recipient(s) at the email address(es) to which it has >>>>> been addressed. It may not be disclosed to or used by anyone other >>>>> than the addressee(s), nor may it be copied in anyway. If received in >>>>> error, please contact the sender, then delete it from your system. >>>>> Although this email and attachments are believed to be free of virus, >>>>> or any other defect which might affect any computer or IT system into >>>>> which they are received and opened, it is the responsibility of the >>>>> recipient to ensure that they are virus free and no responsibility is >>>>> accepted by Pinesoft for any loss or damage arising in any way from >>>>> receipt or use thereof. >>>>> ******************************************************************************************************************************************* >>>>> >>>>> >>>>> Pinesoft Limited are registered in England, Registered number: >>>>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>>>> Herts, EN8 7EA >>>>> <Pinesoft-Fixes-Misc-gvc.24.mcz> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> ****************************************************************************************************************************************** >>> This email is from Pinesoft Limited. Its contents are confidential to >>> the intended recipient(s) at the email address(es) to which it has been >>> addressed. It may not be disclosed to or used by anyone other than the >>> addressee(s), nor may it be copied in anyway. If received in error, >>> please contact the sender, then delete it from your system. Although >>> this email and attachments are believed to be free of virus, or any >>> other defect which might affect any computer or IT system into which >>> they are received and opened, it is the responsibility of the recipient >>> to ensure that they are virus free and no responsibility is accepted by >>> Pinesoft for any loss or damage arising in any way from receipt or use >>> thereof. >>> ******************************************************************************************************************************************* >>> >>> >>> Pinesoft Limited are registered in England, Registered number: 2914825. >>> Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA >>> >>> _______________________________________________ >>> 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 > > > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential to the > intended recipient(s) at the email address(es) to which it has been > addressed. It may not be disclosed to or used by anyone other than the > addressee(s), nor may it be copied in anyway. If received in error, > please contact the sender, then delete it from your system. Although this > email and attachments are believed to be free of virus, or any other > defect which might affect any computer or IT system into which they are > received and opened, it is the responsibility of the recipient to ensure > that they are virus free and no responsibility is accepted by Pinesoft > for any loss or damage arising in any way from receipt or use thereof. > > ******************************************************************************************************************************************* > > Pinesoft Limited are registered in England, Registered number: 2914825. > Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA > > _______________________________________________ > 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

Oct. 2, 2008

Re: [Pharo-project] How to integrate Kernel-Extensions

by Keith Hodges

> #withoutTrailing: is useful for things like, knocking the end off a url or path. url withoutTrailing: $/ Keith

Oct. 1, 2008

Re: [Pharo-project] How to integrate Kernel-Extensions

by Keith Hodges

>> Object >> log should be packaged in a logging package since it's a >> convenience method >> > > No, that's not the idea at all. Object >> log and Null provide > a very lightweight discarding logging framework. We would like > it in the kernel so that no matter where a package winds up, it > can always do logging, but it may be discarded. After the > package Logging is loaded, the user or release team can decide > where the logs go (transcript, stdout, and syslog are currently > implemented) > > See http://wiki.squeak.org/squeak/3706 for the documentation on > the logging framework. > The idea is to promote the use of logging throughout the image using the following convention. self log <subsystem> param1: value1 param2: value2. Thus removing Transcript show: from all over the kernel, and in the process provide more control (filtering, output options etc) via the chosen logging framework. Defining Object-#log ^ Null is the easiest way of implementing a NullLogger in a minimal image. However it is expected that a normal image such as Pharo would be provided with a Transcript logger as the default option. Goran's SLLog provides Transcript, File and Syslog output. Toothpick is also supported as a backend. The other complication is that I designed the logging framework with the intention of using the ProcessSpecific package whereby each process has its own buffer for the text being logged, thus avoiding any form of blocking semaphores etc. Including ProcessSpecific in the main image is another topic for discussion. Keith

Oct. 1, 2008

Re: [Pharo-project] How to integrate Kernel-Extensions

by Keith Hodges

> String >> withoutTrailing: probably makes sense but then this is > mostly useful for line breaksâ¦ why not a #trimLinebreak > > Set >> likeOrAdd: ok but then that should be available for any > collection (and renamed addIfAbsent:) > "Include newObject as one of the receiver's elements, but only if > not already present. Answer the oldObject." > > add: by convention returns the added object likeOrAdd: is primarily finding an existing object does addIfAbsent: communicate this sufficiently? Personally I think add: should return the object that is actually in the Set after the operation, whereas by default it returns the object that was potentially added. > ProtoObject >> iconOrThumbnailOfSize: > It is not useless, it enables the explorer to work with subclasses of ProtoObject, in particular MagmaProxy 's > Object >> askFor: and askFor:ifDefault: that's a workaround > Its implemented to primarily offer an alternative to adding #isThis #isThat methods to Object. Keith

Oct. 1, 2008

[Pharo-project] Cleanup - a concern

by Bill Schwab

I started Smalltalk on an educational discount copy of V-DOS, and then launched at a discounted copy of V-Win. The latter was particularly prone to crashing during a save-and-exit. To this day, I save, and then exit w/o saving. I can't get past it :) Humor aside, I would prefer to have a way to save (bloat and all), then clean, and finally see if all is happy before saving again. THEN I would exit w/o saving ;) Ideally, I would like to see such extra care supported in the IDE. 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

Oct. 1, 2008

[Pharo-project] Space tally

by Bill Schwab

Adrian, I ran the space tally, and have found, even after WARegistry clearAllHandlers. Smalltalk garbageCollect. that there are still some Seaside entrails present in the image. In particular, there are 11 instances of WAApplication, and 4 instances of WADispatcher. There are also quite a few surviving instances from the cryptography package, suggesting that I probably have some orphans from my experiments with SSL connections. I will dig around some more. It would be nice to get breakdowns by category, and I quickly ran into something that struck me as odd: is there a reason #spaceTally: answers the items and not the tally/receiver? Doing the latter would simplify slicing the results. If there is interest, I can punch it up a little and submit it for inclusion in Pharo - let me know. It won't be much, but it should be helpful in understanding what is eating up space. Thanks for calling the tally to my attention; it looks like a very useful tool. Either here or on the Pharo list (maybe both), there was some recent discussion of cleanup. IIRC, it mentioned some additional expressions to clean up Seaside; it's worth a try. I also vaguely recall some (perhaps just speculation??) mention of image growth problems with the older UI Enhancements; the image in question is months old, so that might be part of the problem. Finally, I have no baseline for how big the image should be; I just noted it was 50+MB and realized something was out of whack. I am not terribly concerned about the current image, orther than to not lose the code. I expect to build a new image once Pharo is available with PolyMorph and ideally TT integrated into the image. Depending on the timing and any deadlines that might be whooshing by, I might wait for the official release, but I am getting eager to have some of the newer refinements. 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

Oct. 1, 2008

Re: [Pharo-project] How to integrate Kernel-Extensions

by Bill Schwab

Damien, Stef, I would argue for #trimBlanks (very useful), #trimLineBreak (I do not recall needing this one, but clearl you do, so go for it), and keeping #withoutTrailing: as a separate entry point; write the others in terms of it. IIRC, #trimBlanks probably should trim leading as well as trailing nulls and spaces. The result should (of course) be a properly formatted byte string. I mention that because Dolphin uses null-terminated strings, but my recollection is that Squeak handles them more like BSTRs??? Specifically, I am NOT suggesting to reject nulls/blanks to the point of violating the storage format, only to get rid of them in the "payload." Does that make sense? 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 >>> damien.pollet(a)gmail.com 10/1/2008 3:53 PM >>> String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaks* why not a #trimLinebreak

Oct. 1, 2008