Squeak-dev May 1999

squeak-dev@lists.squeakfoundation.org

126 participants
289 discussions

Start a nNew thread

FileDirectory>>fileExists: case-sensitive on Mac
by Bob Arning 05 May '99

05 May '99

It seems that the latest updates do change this for DOS, but leave the Mac case-sensitive. Cheers, Bob

1 0

[UPDATES] one more
by Dan Ingalls 05 May '99

05 May '99

Folks - Just added one more update. This was supposed to have been included long ago in #1176. It's the class comment fix suggested by Mark Guzdial. Thanks also to Mark Schwenk for pointing out its absence. - Dan

1 0

[UPDATES] 14 new ones
by Dan Ingalls 05 May '99

05 May '99

Folks - Here is a summary of 14 new updates now on the servers. Enjoy - Dan -------------------- 1177FDfix-ar -- Andreas Raab -- 1 May 1999 Fixes a problem in FileDirectory's testing methods on systems that don't have case sensitive file names. 1178UDPSockets -- Andreas Raab -- 30 April 1999 Adds the missing image support for UDP sockets (based on the fileIn from alix.inria.fr 1179FastReframe-di -- Dan Ingalls -- 30 April 1999 A first pass at fast reframe for morphic. 1180Wnld-LghtBrt-jsp -- Jeff Pierce -- 30 April 1999 Adds verification to light creation, and adds the set/getBrightness functionality to lights." 1181BrowserAddCatFix-LS -- Lex Spoon -- 30 April 1999 Fixes a minor problem in Bert Freudenberg's neat 'add category' feature introduced when Chris Norton's '-- all --' feature was added. 1182selFinder-tkJR -- Ted Kaehler -- 30 April 1999 Puts a bottom pane on the Selector Finder window. In this pane, you can use examples to find a method in the system. Also fixes many minor bugs. 1183WeakSymbols -- Andreas Raab -- 1 May 1999 Changes symbols to be stored in weak arrays. 1184TranscriptFix-di -- Dan Ingalls -- 3 May 1999 Fixes the problem that deleting any one of multiple transcripts in morphic causes the remaining views to get removed from thir model. 1185holder-sw -- Scott Wallace -- 3 May 1999 Adds a holder to the standard parts bin and to the supplies tab of the prebuilt scripting template. Fixes a bug in the pasteup in the supplies tab of the prebuilt scripting template. Adds a mechanism for replacing individual parts prototypes in flaps with new versions without needing to do the wholesale clobbering of flaps formerly necessary. 1186scrollingPrefs-gg Georg's very nice scrolling preferences window. 1187ReframeTweak-di -- Dan Ingalls -- 4 May 1999 A second pass at fast reframe for morphic. 1188browseAllRefsFix Similar fix to that proposed by Ohshima Yoshiki 1189dismissWorkaround-sw -- Scott Wallace -- 4 May 1999 Provides a workaround for the bug introduced in update 1184TranscriptFix which raises an error when you try to dismiss a parts bin window." 1190NewReframeTweak-di -- Dan Ingalls -- 4 May 1999 A third pass at fast reframe for morphic. Eliminates multiple resize handles for both fast and normal reframing. Also cures age-old interference of fast reframe with dragging internal objects.

1 0

Putting Wonderlands in Books
by Mark Guzdial 05 May '99

05 May '99

Is there a way of putting Wonderlands into BookMorphs? I tried the obvious thing of dragging the camera window into a page then saving it. When it came back, it couldn't find WonderlandActor24. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

2 2

RE: [PWS] PWS only meant for Swiki?
by agree＠carltonfields.com 04 May '99

04 May '99

> I think that Bolot's new PWS implementation is all stream-based > rather than passing strings around -- both for speed and for memory > hits. streamContents rules! Indeed, avoding unnecessary concatenations and non-linear appends is one of the easiest and most direct ways to speed up string-intensive code. Moreover, I have discovered that doing this properly has a tendency to make code clearer and more readable (although it does have the unfortunate tendency to look more like traditional imperative code). > (Try to serve a 25M QuickTime Star Wars Trailer in the current > PWS :-) This was one of the tests that Bolot did of the current > system. You will be more likely to get to the front of a line to see the film before the file is served. Moreover, LucasArts is a notoriously agressive intellectual property plaintiff. > Hmm, I just wrote a tiny-and-still-incomplete HTML tag scanner for my > class as a demonstration > A hand-built scanner will probably be faster than a regular > expression system. In the case of NFA-style re systems, this is almost certainly correct. The re-based scanner might be more readily malleable, however. A linear, DFA-based table scanner can be breathtakingly fast and is hard to beat, but like the hand-based scanner is unlikely to be easily malleable by general users of the code. And, of course, depends upon whose hands are building the hand-built scanner. :-) Some thought might be given, however, to consider where inner loop speedups will result in substantial improvement to the system as a whole, whether reducing these byte-pushing syntactic operations to a plugin primitive that can be interpreted or compiled as needed, might not be the best compromise between hard-coded complexity-for-speed and ease-of-reuse. Perhaps a first step would be to isolate a general byte-pushing syntactic operations strategies class that admits a variety of implementations -- some tight and hand-coded for speed, others less speedy, but clear, concise and readily capable of being reused. (Pluggability rules).

1 0

RE: [PWS] PWS only meant for Swiki?
by Lex Spoon 04 May '99

04 May '99

I don't think either the Swiki file format, or the <> check in itself, are inherently slow. It's just that the current implementations that deal with those things are slow: 1. The SwikiPage>>text routine does things similar to upTo: on a FileStream, which results in character-by-character processing. One of these days, someone should fix all that stuff up on FileStream to use buffers, but it's not in place right now. (And who has the time to work on it?). In particular, I think reading in a Squeak string with the doubled ' marks is the biggest hit. 2. The <> check currently works by doing an initial scan to find all ranges of <> pairs, and then checks at each line end whether the current text position falls within one of those ranges. If there are 20 HTML tags on this page, then this means going through 20 calls to between:and: and 20 block invocations AT EACH LINE END. A better way is simply to keep a flag which reflects whether the current position is within a <> pair or not; seeing a < turns it on, and seeing a > turns it off; the check at each end of line then becomes extremely cheap. Lex Bijan Parsia <bparsia(a)email.unc.edu> wrote: > On Mon, 3 May 1999, Lex Spoon wrote: > > > > > > >I am curious how, in practice, a Swiki performs. In particular, how > > > >practical are these things for communities of several hundred people? > > > > > > > The current Swikis haven't been optimized much at all, but as Mark > > Guzdial posted earlier, they are handling his ~100 student sophomore > > class without trouble. > > I've used swiki's for 25-40 person classes for, gosh, over a year. It does > ok. I have my own swikifying routine which avoids some of the speed hit > Lex pointed out. > > > I can quantify this a little more. We did some quick tests on a Mac > > (Bolot, Je77, do you know what kind of Mac it is?), and found two things > > that are bottlenecks right now: > > > > 1. Reading a Swiki's source text, ie SwikiPage>>text, takes over > > 100 milliseconds by itself. This could obviously be improved: > > contentsOfEntireFile on the samy file took like 15-20 milliseconds. > > I'm going to change that tomorrow! Whoa. This must absolutely *kill* on > searchs. And it certainly explains the interminable restore times. > > > 2. "swikifying" a page is currently dominated by the check for > > whether a particular line break is in between < and >. This check is > > needed, but it could be made more efficient. With the check, the time > > taken is about 200 milliseconds. Without the check, the time is down in > > the 10-20 millisecond range, if I remember right. It was definately a > > LOT less. > > Wow. I didn't realize the check was *that* painful. And here I thought it > was my clever parser that made mine so much quicker. <wince/> Good to know > though. > > However, there seems to be other places where Swiki's can be a tad > problematic: If someone else is accessing a page and PWS is processing > (like doing a search) I get a "server unavailable". This is with Squeak > 2.1. If this has been fixed (via threading?) in later versions I'd be > happy except for the weird slowdowns I experience :( > > One thing I think would nice is if the text and the "metadata" of a > Swikipage were stored in separate files. Right now, you only save things > like name, edit time, etc. when you edit the page. Thus, if your server > crashes you lose all metadata since the last edit or image save. > > On the other hand, I'm eager to see some sort of PWS connection to > MinneStore. Now *that* will be interesting. > > Cheers, > Bijan

3 2

RE: [PWS] PWS only meant for Swiki?
by agree＠carltonfields.com 04 May '99

04 May '99

Perhaps some combination of the changes to FileStream and using the regular expressions plugin might improve performance substantially? I'm inclined to start looking at this more carefully once I get a handle on Swiki use. -----Original Message----- From: PC :lex@cc.gatech.edu Sent: Tuesday, May 04, 1999 11:32 AM To: squeak(a)cs.uiuc.edu Subject: RE: [PWS] PWS only meant for Swiki? I don't think either the Swiki file format, or the <> check in itself, are inherently slow. It's just that the current implementations that deal with those things are slow: 1. The SwikiPage>>text routine does things similar to upTo: on a FileStream, which results in character-by-character processing. One of these days, someone should fix all that stuff up on FileStream to use buffers, but it's not in place right now. (And who has the time to work on it?). In particular, I think reading in a Squeak string with the doubled ' marks is the biggest hit. 2. The <> check currently works by doing an initial scan to find all ranges of <> pairs, and then checks at each line end whether the current text position falls within one of those ranges. If there are 20 HTML tags on this page, then this means going through 20 calls to between:and: and 20 block invocations AT EACH LINE END. A better way is simply to keep a flag which reflects whether the current position is within a <> pair or not; seeing a < turns it on, and seeing a > turns it off; the check at each end of line then becomes extremely cheap. Lex Bijan Parsia <bparsia(a)email.unc.edu> wrote: > On Mon, 3 May 1999, Lex Spoon wrote: > > > > > > >I am curious how, in practice, a Swiki performs. In particular, how > > > >practical are these things for communities of several hundred people? > > > > > > > The current Swikis haven't been optimized much at all, but as Mark > > Guzdial posted earlier, they are handling his ~100 student sophomore > > class without trouble. > > I've used swiki's for 25-40 person classes for, gosh, over a year. It does > ok. I have my own swikifying routine which avoids some of the speed hit > Lex pointed out. > > > I can quantify this a little more. We did some quick tests on a Mac > > (Bolot, Je77, do you know what kind of Mac it is?), and found two things > > that are bottlenecks right now: > > > > 1. Reading a Swiki's source text, ie SwikiPage>>text, takes over > > 100 milliseconds by itself. This could obviously be improved: > > contentsOfEntireFile on the samy file took like 15-20 milliseconds. > > I'm going to change that tomorrow! Whoa. This must absolutely *kill* on > searchs. And it certainly explains the interminable restore times. > > > 2. "swikifying" a page is currently dominated by the check for > > whether a particular line break is in between < and >. This check is > > needed, but it could be made more efficient. With the check, the time > > taken is about 200 milliseconds. Without the check, the time is down in > > the 10-20 millisecond range, if I remember right. It was definately a > > LOT less. > > Wow. I didn't realize the check was *that* painful. And here I thought it > was my clever parser that made mine so much quicker. <wince/> Good to know > though. > > However, there seems to be other places where Swiki's can be a tad > problematic: If someone else is accessing a page and PWS is processing > (like doing a search) I get a "server unavailable". This is with Squeak > 2.1. If this has been fixed (via threading?) in later versions I'd be > happy except for the weird slowdowns I experience :( > > One thing I think would nice is if the text and the "metadata" of a > Swikipage were stored in separate files. Right now, you only save things > like name, edit time, etc. when you edit the page. Thus, if your server > crashes you lose all metadata since the last edit or image save. > > On the other hand, I'm eager to see some sort of PWS connection to > MinneStore. Now *that* will be interesting. > > Cheers, > Bijan << File: ENVELOPE.TXT >>

1 0

RE: [PWS] PWS only meant for Swiki?
by Lex Spoon 04 May '99

04 May '99

Mark Guzdial <guzdial(a)cc.gatech.edu> wrote: > > 2. The <> check currently works by doing an initial scan to find > >all ranges of <> pairs, and then checks at each line end whether the > >current text position falls within one of those ranges. If there are 20 > >HTML tags on this page, then this means going through 20 calls to > >between:and: and 20 block invocations AT EACH LINE END. A better way is > >simply to keep a flag which reflects whether the current position is > >within a <> pair or not; seeing a < turns it on, and seeing a > turns it > >off; the check at each end of line then becomes extremely cheap. > > Hmm, I just wrote a tiny-and-still-incomplete HTML tag scanner for my class > as a demonstration > (http://www.cc.gatech.edu/classes/cs2390_99_spring/slides/parse/outline.html). > Maybe I can modify that for this purpose. A hand-built scanner will > probably be faster than a regular expression system. > To help write scanners by hand, there is an indexOfAnyOf: primitive in the standard VM. This method is just like indexOf: except that you can specify a set of characters to look for instead of just one character. It is more limitted than scanning regular expressions, but it turns out to be sufficient in most cases. (most computer languages don't seem to have tokens that are all THAT complicated) There are a couple of examples of such scanners already in the system: HtmlTokenizer and MailAddressTokenizer. Lex

1 0

[FIX] yet another 'nil size' buglet
by ohshima＠is.titech.ac.jp 04 May '99

04 May '99

StandardFileStream>>name sometimes returns nil. As long as I *roughly* checked the (over 400) call sites of #name method, I found SystemDictionary>>browseAllObjectReferencesTo:except:ifNone: is a place where the execution would result in sending #size to nil object. The following is the patch for the method, but making StandardFileStream>>name return non-nil object could be another solution. OHSHIMA Yoshiki Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology !SystemDictionary methodsFor: 'browsing' stamp: 'yo 5/4/1999 16:37' prior: 21723495! browseAllObjectReferencesTo: anObject except: objectsToExclude ifNone: aBlock "Bring up a list inspector on the objects that point to anObject. If there are none, then evaluate aBlock on anObject. " | aList shortName | aList _ Smalltalk pointersTo: anObject except: objectsToExclude. aList size > 0 ifFalse: [^ aBlock value: anObject]. shortName _ anObject name. shortName ifNil: [shortName _ '']. shortName size > 12 ifTrue: [ shortName _ (shortName truncateTo: 12), '...'. ]. OrderedCollectionInspector openOn: aList withEvalPane: false withLabel: 'Objects pointing to ', shortName. ! !

1 0

[? Windows] CR instead of CR/LF (was: RE: update 1164)
by Norton, Chris 04 May '99

04 May '99

Hi Folks. [update problem snipped...] > >Why was CR chosen for Squeak instead of CR LF? > [Dan Ingalls replied:] "For the same kind of reason its syntax is not the same as C. > We thought, when we started playing this game in 1972, that the separate > line-feed character, used to advance the platten of a teletype machine, > was an anachronism, and that modern software would be designed > intelligently enough to handle the entire ascii character set (in fact of > all 256 characters) without getting confused." > [Norton, Chris] OK. I don't have a problem with the reasons, but I have had some (minor) difficulties with this representation under Windoze. When I open some Squeak changes files, they come up nicely formatted and presentable, but others come up as a big blob of text. I suppose this is because my tools of choice weren't "designed intelligently" as Dan suggested. I've tried Notepad, WordPad and MS Word 98 so far. NotePad and WordPad fail miserably, but MS Word seems to work. Do any of you Windoze Squeakers have a better tool for reading these files from the File Manager or from the Explorer (besides Squeak itself)? Also - I recently sent a change set to a friend at Squeak central who indicated that my code had the dreaded LF characters in it (using Squeak 2.3 + fixes). If it hasn't been done already, shouldn't the file in / file out routines be "bullet proofed" to keep this from happening? (wish I had the time to surf that code right now ;-) ---==> Chris

5 4

Jump to page: