Squeak-dev April 2004

squeak-dev@lists.squeakfoundation.org

172 participants
488 discussions

[FIX]? HTTPRequest name conflict
by Avi Bryant 30 Apr '04

30 Apr '04

I've been playing recently with the Squeak port of the Swazoo web server, which includes a class called HTTPRequest. Unfortunately, the base Squeak image already has a class by that name, in System-Download. If we want to be able to load Swazoo into an image without crippling the HTTPClient, one or the other of these needs to change. Normally, it would make sense to change the external package rather than the image, but the whole point of Swazoo is that it's portable - if the classes have different names in different dialects, life becomes much more difficult for its users and maintainers both. And there's the additional bit of luck that System-Download's HTTPRequest is only directly referenced twice, with most references going through the indirection of #httpRequestClass. It's unlikely that it's referenced at all in code not bundled with the image. So, can/should we rename it to avoid this conflict? I'm proposing BasicHTTPRequest, to distinguish it from its subclasses PluginHTTPRequest and CachedHTTPRequest. A changeset that does this renaming is attached. Avi

2 4

[BUG][FIX]FileDirectory>directoryExists: a bit silly ( [et][su][cd][sm] first version works for me )
by Alexander＠Lazarevic.de 30 Apr '04

30 Apr '04

Even considering the danger of looking like a sleazy bootlicker after your broad hint I did a review: * the second version fails the SUnit FileDirectoryTest * first version passes the test and makes things faster without fix: Testing 2719 entries in 2 minutes with fix: Testing 2719 entries in under a second Alex

3 2

[FIX] PSPointSizeFix-nk v3
by Ned Konz 30 Apr '04

30 Apr '04

The prior version of this got into the update stream, so I'm re-posting this version in hopes that it can join its ancestor there... "Change Set: PSPointSizeFix-nk (v3) Date: 13 April 2004 Author: Ned Konz Postscript output from Squeak has been in pixel units. However, we're outputting requests for fonts in point units, making the fonts appear 3/4 as big as they should on output. This change set fixes that problem by also requesting fonts in pixel units. v3 (13 April): fixed discrepancy between (ascender+descender) and (unitsPerEm) in TTCFont. This will rename existing point sizes but keep glyphs the same size. v2 (25 March): improved decoding of font names and attributes. Factored out knowledge of font naming to TextStyle class. " "Repair bad sizes *before* installing new code (see TTCFont class>>repairBadSizes)" | description computedScale cached desiredScale newPointSize repaired | repaired _ OrderedCollection new. TTCFont allInstancesDo: [ :font | cached := (font cache copyFrom: $A asciiValue + 1 to: $z asciiValue + 1) detect: [ :f | f notNil ] ifNone: []. cached := cached ifNil: [ font formOf: $A ] ifNotNil: [ cached value ]. description _ font ttcDescription. desiredScale _ cached height asFloat / (description ascender - description descender). computedScale _ font pixelSize asFloat / font ttcDescription unitsPerEm. (((computedScale / desiredScale) - 1.0 * cached height) abs < 1.0) ifFalse: [ newPointSize _ (font pointSize * desiredScale / computedScale) rounded. font pointSize: newPointSize; flushCache. repaired add: font. font derivativeFonts do: [ :df | df ifNotNil: [ df pointSize: newPointSize; flushCache. repaired add: df. ]]. ]. ].

1 0

Re: 64 bit images(was: A plan for 3.8/4.0...)
by Richard A. O'Keefe 30 Apr '04

30 Apr '04

"Daniel Poon" <dan(a)chenvillage.com> wrote, and <Yoshiki.Ohshima(a)acm.org> forwarded: I am a Smalltalk programmer who works on numerical programs in Smalltalk [...] at least half of what we do is not linear, and involves a lot of old fashioned floating point ops to solve. It does not follow that there are lots of floats outside arrays. Personally, I don't mind sacrificing some speed for Smalltalks other benefits. But two orders of magnitude is really stretching the case. When people knock Smalltalk for its speed, they can easily point to floating point ops. Please consider implementing immediate floats in Smalltalk!! Immediate (32-bit) floats will do NOTHING to improve the performance of code working on 64-bit floats. In fact, it will make it worse. People are jumping from (A) we'd really like much better floating-point performance to (B) immediate 32-bit (or 62-bit) floats are the answer. But this is NOT a valid inference and the conclusion is almost certainly false. There are all sorts of other things one could do, none of which involve fundamental changes to the Squeak method dispatch code. Squeak floating-point performance is affected by several things: - the time it takes to discover that something IS a float - the time it takes to select the right implementation of a method for a float - the time required to fetch floats out of boxes - the time required to allocate boxes for intermediate results - the time required to reclaim that storage - the lost opportunities to keep things in floating point registers Aside from the fact that you can't have 64-bit immediate floats at all, there's *still* going to be an order-of-magnitude cost relative to optimised C or Fortran 90 due to the need to fetch floats from memory, twice, once to see if something is a float -- which will load into an integer register -- and again to get it in a floating point register. There will still be the lost opportunities to keep things in FP registers. There are several possible approaches. One is to try to reduce the cost of allocation and GC for floats by having a specially managed region just for boxed floats. (Shades of BiBoP.) A variant of that would be to have quite a small special region, treated as a stack, and have the arithmetic operations on floats return numbers in that area. Now add two new instructions: discard_number if the TOS item is the float at the top of the special region, decrement the special region's sp. Decrement the normal sp. fix_number if the TOS item is the float at the top of the special region, allocate a normal box for it. So x :=- a * x + b becomes push a; push x; send *; -- result left in special region push b; send +; -- result left in special region fix_number; -- final result boxed normally store x. Push this idea far enough and you get something like the old MacLisp SPDL. MacLisp was supposed to get quite good FP performance, compared with Fortran, although the Fortran compiler was probably quite dumb compared with today's. Another, and long-term perhaps the most effective, approach would be some sort of type inference, rather like Self. What the best approach is depends to a large extent on what the non-array-based floating-point code looks like, and some examples would help there. For what it's worth, computing dot products on my machine: 30 nsec/element in optimised C 100 nsec/element in unoptimised C 7240 nsec/element in SCM (a Scheme interpreter), of which 3420 nsec/element is GC overhead 4790 nsec/element in SCM using immediate integers, of which 1230 nsec/element is GC overhead. 1880 nsec/element in Larceny (a Scheme compiler), or which 880 nsec/element is GC overhead 93 nsec/element in Larceny using immediate integers, of which 0 nsec/element is GC overhead. Larceny/C is somewhere between 1 and 2 orders of magnitude. SCM/C is somewhere around 2 orders of magnitude. If Squeak float arithmetic ends up 2 orders of magnitude slower than C, then this is about what it looks like. I picked SCM and Larceny because I already had them. Immediate floats would clearly save a lot of allocation time, except that we wouldn't be able to use them. (Because when you compute dot products, you want to accumulate the results in double precision even if your vector elements are single precision.) But in the SCM system, that wouldn't really help *enough*; the version using immediate integers is still 2 orders of magnitude slower than the C version using doubles. SCM interprets carefully tweaked parse trees; Larceny generates native code. So I'd expect Squeak to lie somewhere between Larceny and SCM here; using immediate floats might cut the time in half, but I really wouldn't expect a decimal order of magnitude improvement.

1 0

Forward: Re: 64 bit images(was: A plan for 3.8/4.0...)
by Yoshiki Ohshima 29 Apr '04

29 Apr '04

A friend of ours sent me his comment and wanted me to forward this to squeak-dev. -- Yoshiki

1 0

[BUG] ? cannnot save using save anymore?
by stéphane ducasse 29 Apr '04

29 Apr '04

Hi I cannot save anymore image using the save menu since I updated until 5905. Is it only me? Stef

1 0

[FIX] PseudoClassAllCallsOnFix-nk ( [er][sm][et][approved] )
by tim＠sumeru.stanford.edu 29 Apr '04

29 Apr '04

Looks good to me; hardly a showstopper but a very useful fix nonetheless

1 0

[ENH] ChangeListTimeComparisionEnh-nk (v2, fixed)
by Ned Konz 29 Apr '04

29 Apr '04

This version fixes manual selection. "Change Set: ChangeListTimeComparisionEnh-nk (v2) Date: 29 April 2004 Author: Ned Konz Adds 'select newer methods' and 'select older methods' to the ChangeList menu. These compare the timestamps in the change records with those in the current versions of the corresponding methods. Also adds a Preference called #changeListSelectionsAdd that makes selections in the ChangeList additive. You can change this preference from the window menu, too. Also adds an 'invert selections' button to the optional button pane. "

1 0

[FIX] BFAVFileListOpenFix-nk
by Ned Konz 29 Apr '04

29 Apr '04

"Change Set: BFAVFileListOpenFix-nk Date: 29 April 2004 Author: Ned Konz This is the proper way to call the ServiceEntry. It should be used with the previously-posted FileListOpenFix-nk. "

1 0

[FIX] PseudoClassAllCallsOnFix-nk
by Ned Konz 29 Apr '04

29 Apr '04

"Change Set: PseudoClassAllCallsOnFix-nk Date: 29 April 2004 Author: Ned Konz Fixes browsing of class references from a code-file browser. "

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
49
Older →

Jump to page: