- Pharo-dev - lists.pharo.org

[Pharo-project] Fonts related from OLPC / rome also
by StÃ©phane Ducasse Oct. 3, 2008

Oct. 3, 2008

I started to go over http://tinlizzie.org/updates/etoys/updates to see if some of the fixes of yoshiki for unicode and others were there. Here is a list of names that may be should be further investigated - 1622fontFix-sw.cs - 1626FontNameGlitch-y.. - 1711UTF8Clipboard.cs - 1712utf8toSqueakFix-. - 1713UnicodeInput1-yo.cs - 1714UnicodeInput2-yo.cs - 1715utf8toSqueakFix2..> - 1725SystemFont-yo.cs - 1726SystemFont2-yo.cs - 1731UpdBtnFontFix-KR.cs - 1813macPasteUTF8-bf.cs - 1815latin1Chars-yo.cs - 1821UnicodeFntLoadin..> - 1826TTCFontSetRework..> - 1826TTCFontSetRework..> - 1827sketchColor-sw.cs - 1832TTCFontSetFix-yo.cs -1834FontRegFix-yo.cs - 1862TTCFontObjStream..> - 1869latin1PathEncodi..> - 1884TTObjForStream-y.. - 1907crlfFix-bf.cs - 1918UTF8InputFix-ar.cs - 1925unixLatin1Input-..> - 1935unicodeFallback-. - 2143macEnc-bf.cs about the rome canvas 1932romepango-base.cs 1933romepango.cs 1934romepango2-yo.cs 24

2 3

[Pharo-project] Fwd: Yet another Objective-C bridge
by John M McIntosh Oct. 3, 2008

Oct. 3, 2008

Begin forwarded message: > From: John M McIntosh <jmmcintosh(a)gmail.com> > Date: October 2, 2008 11:50:56 PM PDT (CA) > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Cc: iSqueak(a)isqueak.org > Subject: Yet another Objective-C bridge > Reply-To: johnmci(a)smalltalkconsulting.com > > As part of my iPhone work I've built yet another Objective-C bridge. > > It can be found within ftp://ftp.smalltalkconsulting.com/experimental/ > The required Smalltalk code for the basic logic, the SUnits, and the > Plugin generation can be loaded from http://www.squeaksource.com/ObjectiveCBridge2.html > The additional pieces required to build the plugin are found within > the iSqueak SVN tree. http://svn.isqueak.org/vm/ > > Using aregular 3.8.18b4U macintosh carbon VM with the > ObjectiveCBridge installed means you can invoke. > > testRetainCount > | classOop instance1 count | > > classOop := ObjectiveCObject findClassName: 'NSObject'. > instance1 := classOop new. > count := instance1 retainCount. > self should: [count = 1]. > instance1 retain. > count := instance1 retainCount. > self should: [count = 2]. > instance1 release. > count := instance1 retainCount. > self should: [count = 1]. > > > People are welcome to confirm that it works, although it is compiled > for ppc and i386 (32bit) I have not yet tested on ppc. > > This plugin was also installed for the currently shipping iPhone VM > 1.05b3, however there seems to be a problem > where resolving the method signature object isEqualTo: for usage > between two instances of NSObject returns nil. > But only on an ipod touch or iPhone not in the Simulator, or running > as an os-x application. > > > >

1 0

[Pharo-project] How to integrate Kernel-Extensions
by Damien Pollet Oct. 3, 2008

Oct. 3, 2008

Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo. Null and Split-Join could be packaged on their own since they are well-defined features. Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ? AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete]. Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues. Behavior >> sourceMatchesBytecodeAt: Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries] Collection >> contains: should probably be standardized as part of the STEPS project Collection >> reject:thenDo: and select:thenDo: should be included and similar enumerations reimplemented in this way too SystemDictionary >> forgetClass: aClass logged: aBool badly named but interesting "Delete the class, aClass, from the system. Note that this doesn't do everything required to dispose of a class - to do that use Class>>removeFromSystem." aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: aClass fromCategory: aClass category]. SystemOrganization removeElement: aClass name. self removeFromStartUpList: aClass. self removeFromShutDownList: aClass. self removeKey: aClass name ifAbsent: []. DataStream classRemoved: aClass. self flushClassNameCache SystemDictionary >> globals needs to pay attention that compiled methods share the associations Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last === To discuss: Collection >> removeAll: comment should explain in which cases it is useful "the slow way" ^ self removeAllSuchThat: [ :each | true ] SequenceableCollection >> <= smells funnyâ¦ what is it useful for ? SequenceableCollection >> replacing:with: replaces in place, not obvious from the name the stream methods like putOn: â¦ convenience ? are they coherent ? 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." === Useless: ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method SequenceableCollection >> copyReplacing:with: just to type one space less ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

8 12

[Pharo-project] Did you harvest Kernel-dc.198
by StÃ©phane Ducasse Oct. 3, 2008

Oct. 3, 2008

Hi marcus did you harvest ? Name: Kernel-dc.198 Author: dc Time: 28 September 2008, 4:00:03 pm UUID: 3b2eeec4-6461-4d22-94d1-e7f692e7e177 Ancestors: Kernel-marcus.denker.197 - M7166: speedup allSelectors add allSelectorsBelow:. Firstly #allSelectors inefficiently creates multiple intermediate collections. Refactoring this yields a 27% speed improvement. Secondly many users of #allSelectors forget that when applied to the class side it doesnt stop at ProtoObject class, it continues to Class ClassDescription, Behavior, Object and ProtoObject. This is catered for by adding #allSelectorsBelow: Magritte and SUnit are heavy users which benefit. I imagine not so I will.

2 2

[Pharo-project] Exupery's VMMaker on SqueakSource now has closures
by bryce＠kampjes.demon.co.uk Oct. 3, 2008

Oct. 3, 2008

I can supply a built VM if anyone wants to try it immediately. If not I'll package one up after finishing tidying up. Looking at the bytecodes, they're suppressing context recycling whenever a closure is created. The only reason that closures refer to their surrounding contexts is to support ^ returns from blocks. With two more context creation bytecodes we should allow all contexts to be recycled except the outer method context when there's a block that ^ returns. Such optimisation can wait though, especially as it would involve removing some of Eliot's sanity checking which may be useful when adapting the image to use these bytecodes. Bryce

2 2

[Pharo-project] Changes from COG
by Mathieu Suen Oct. 2, 2008

Oct. 2, 2008

Hi, If you don't mind Eliot, I have taken a changeset from COG to Pharo. You can integrate it. It should work fine This change is for having a better CompiledMethod explorer. See attached file. Mth

2 1

[Pharo-project] Fwd: [squeak-dev] re: Squeak 4
by StÃ©phane Ducasse Oct. 2, 2008

Oct. 2, 2008

for information. I will continue to harvest etoy removals and gary/simon enh. Stef > From: Craig Latta <craig(a)netjam.org> > Date: October 1, 2008 10:49:14 PM CEDT > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] re: Squeak 4 > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > Hi Stef-- > > > Just out of curiosity on which version is based Squeak 4. > > Squeak 3.2? > > Well, that question is mostly meaningless when so much is > removed. :) The most recent significant thing in there is support > for weak references, which I think comes from 3.2. The VMs are all > the latest, though. > > > -C

1 0

Re: [Pharo-project] How to integrate Kernel-Extensions
by Bill Schwab Oct. 2, 2008

Oct. 2, 2008

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

2 1

[Pharo-project] Cleanup - a concern
by Bill Schwab Oct. 2, 2008

Oct. 2, 2008

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

1 0

[Pharo-project] Space tally
by Bill Schwab Oct. 1, 2008

Oct. 1, 2008

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

1 0