Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

Re: www.squeakworld.com!
by G�ran Hultgren 31 May '00

31 May '00

Hi Mark and all others! --- Mark Guzdial <guzdial(a)cc.gatech.edu> wrote: > I'd be interested in writing -- AFTER OCTOBER. Until then, I have > Squeak-writing up to my ears :-) Super! It seems that people are lining up - very encouraging! I am collecting all responses I get (both via email and through the list) and will soon post a summary of responses + a "content proposal" + (hopefully) a team list with some proposed "roles" like for example "site administrator", "column writer", "interested in writing articles", "graphic artist" etc. So keep mailing me guys if you are interested to join the Squeakworld team from the start! :-) (feel like some political campaign manager... yuk) > Consider the possibility of Comanche Swiki with tuned templates. As > an example of what you can do, visit http://coweb.cc.gatech.edu/csl/ > This is a Comanche Swiki. In Comanche Swiki, you have > prototype-based inheritance. For this case, there is another Swiki > (csl-priv) that requires a username-password to get in. csl and > csl-priv share the exact same pages (via the inheritance mechanism), > but they have different security and different templates. Thus, csl > looks like a normal website, but when you visit it from the private > side, you can edit it just like any other Swiki. This sounds pretty perfect to me. I am already a Swiki-junkie so I have also been thinking along those lines. I was thinking of using CVS for content management - and it still might come handy for some things - but a Swiki solution would be nicer, is this a rendered Swiki or is the "public" side also served from Comanche? Is there any possibility that we could "borrow" your setup on csl as an example or something? I assume it can be quite tricky to get it configured. Comanche and Swiki-stuff does not really have a trackrecord of being over-documented... ;-) ;-) Thanks in advance, G�ran ===== G�ran Hultgren, goran.hultgren(a)bluefish.se icq#:6136722, GSM: +46 709 472152, http://www.bluefish.se "First they ignore you. Then they laugh at you. Then they fight you. Then you win." -- Gandhi __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

1 0

RE: Large array slows down Squeak
by Raab, Andreas 31 May '00

31 May '00

> And there's another interesting observation. In Morphic, the delay > because of tenuring is much larger than in MVC. This is probably > because Morphic creates much more short-lived object garbage. > > Thinking about this, could this be the reason, why Morphic > always feels a little bit slower than MVC? If yes, then the > best approach to speed up Morphic would be to reduce the number > of temporary objects... Interesting idea! Actually there's a way of playing with this - you could add a #garbageCollectMost (which does an incremental GC) to the Worlds loop cycle. That should get rid of most of the garbage extremely fast. Might be worth a try ... - Andreas

1 0

RE: Large array slows down Squeak
by Raab, Andreas 31 May '00

31 May '00

Stefan, The garbage collector's tenuring policy doesn't take the size of an object into account. It just counts the objects and will tenure them if there are enough objects. That leads to the problem that a huge array will be seen as a single object and therefore always kept in young space. The workaround is to force a full garbage collection (e.g., Smalltalk garbageCollect) to make all existing objects 'old'. - Andreas > -----Original Message----- > From: Stefan Matthias Aust [mailto:sma@baltic-online.de] > Sent: Tuesday, May 30, 2000 6:52 AM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: Large array slows down Squeak > > > Hi, > > I just noticed that an > > Array new: 10000000 "ten millions" > > noticablely slows down Squeak (open it in an inspector or assign > it to a global (or workspace) variable). Actually, it's now nearly > impossible to work with Squeak. If I do a > > ByteArray new: 40000000 > > which should take the same amount of memory, no such effect occurs > so I guess it's a garbage collector issue. Right? Is there a > workaround? > > bye > -- > Stefan Matthias Aust Projektleiter/Softwareentwicklung > Baltic Online Computer GmbH, Alter Markt 1-2, 24103 Kiel > Fon: +49 (0) 431-54003-0 Fax: -99 http://www.baltic-online.de >

2 1

Re: Proposal3: Make $_ a valid identifier character
by Richard A. O'Keefe 31 May '00

31 May '00

> Let us not lose sight of the fact that Smalltalk (like Pascal) originally > didn't include low lines because it simply _couldn't_; the first version > of ASCII just plain didn't include them. Really? Yes. This is historically correct? Yes. With all the wierd glyphs, I'm surprised. Can you give a source (or would someone form SqCentral care to comment)? CACM, 1960-something. Go to your local museum of computing and take a look at the keyboard of a Model 33 Teletype. There were quite a few papers in CACM during the early 60s about the development of ASCII. We _nearly_ got a logical negation sign (like the one now at 16rAC in ISO Latin 1). Some of the weirder characters (like ~, ^, `, and to a certain extent |) make perfect sense when you realise that it was *official* in ASCII that you could make accented letters by overstriking (either using backspaces or carriage returns). For that, see for example ECMA-6 "7-Bit coded Character Set", 6th edition, section 7 (p8): While all graphic characters specified in this International Standard are spacing characters, it is possible, by using BACKSPACE or CARRIAGE RETURN, to image two or more graphic characters at the same character position ... For example, SOLIDUS and EQUALS SIGN may be combined to image "not equals". ... Diacritical marks may be allocated ot the bit combinations specified in 6.4.3 and be available for composing accented letters. For each composition a sequence of three characters, the first or last of which is the letter to be accented and the second of which is BACKSPACE may be used. Furthermore, QUOTATION MARK, APOSTROPHE or COMMA can be associated with a letter by means of BACKSPACE for the composition of an accented letterr with a diaeresis, an acute accent, or a cedilla respectively. Strictly speaking, the set of characters which could *standardly* be encoded in ASCII was rather larger than the set which can be encoded directly in ISO Latin 1 or any other 8-bit character set. It's just that some characters (like underlined lowercase w with acute accent) might take 5 bytes (_ BS ' BS w). And characters like " had to be compromises between good-looking quotation marks (which they aren't) and good-looking umlauts (which they aren't either). Still, an imaging device _could_ have translated entire BS sequences to appropriate images. This construction was *not* included in the 8-bit ISO 8859 family, which is thus *not* an upwards-compatible extension of ECMA-6 = ISO 646 = ASCII. [snip] > Clinging to BaStudlyCaps because "that's the way it has always been done > in Smalltalk" (as another person suggested) I really presume you mean me as the "another person" No. I wouldn't have written an*other* person if I had meant that. FWIW, some means of transparently dealing with underscore scarred code would be welcome. And certainly, in non-code browsers in Squeak, having arrows where there should be underscores is annoying. I grant that there are problems to be solved. But I'd still rather deal with them then deal with loads of underscore infected identifiers. Perhaps we can both cool down our language. It is understood that some people have come to love their chains. It is also understood that some people like identifiers to be readable and pronounceable and welcome technological advances that permit this. So, let's agree that we differ, and that I exist to make your reading life a living hell ;) No, I *shan't* agree to that. You see, there is a possible middle ground. We _agree_ that the assignment arrow is a better symbol for assignment than :=. I presume that we _agree_ that the up arrow is a really neat symbol for "return" in Smalltalk. We _agree_ that it would be useful to be able to view text that uses (backspaceless) ASCII correctly (better still, ISO Latin 1 or Windows 1252). We _agree_ that people should be able to read Smalltalk code. We _agree_ that there is more than one experience of readability. We only disagree about which convention is better. As I wrote in a previous message, let's have four distinct characters left-arrow low-line up-arrow circumflex-accent, so that left arrow remains available. So have a *lexical* rule in Squeak <lower case letter> <low line> <upper case letter> => <lower case letter> <upper case letter> and a browser Preference for whether <lower case letter> <upper case letter> is displayed as is (for BaStudlyCaps lovers) or as <lower case letter> <low line> <upper case letters> (for phrases_Are_Not_Words thinkers). Then I could see (and *read) Sequenceable_Collection while others who had not enabled that option would see SequenceableCollection. Also, I could write (and *read) Multi_Word_Identifiers, but Bijan Parsia, looking at the *same* code, would see MultiWordIdentifiers. That way, everyone gets to decide for themselves what is readable, but we can still communicate and share code.

2 1

Re: [BUG] DSA failure in LargePositiveInteger in #new:<primitive:71>
by JArchibald＠aol.com 31 May '00

31 May '00

=> 5/31/00 3:20:45 AM, John.Maloney(a)disney.com => << By the way, Jerry, thank you for discovering this problem. >> John, You're welcome. Jerry.

1 0

Re: [BUG] DSA failure in LargePositiveInteger in #new:<primitive: 71>
by JArchibald＠aol.com 31 May '00

31 May '00

=> 5/30/00 5:23:25 PM EDT, sr(a)evolgo.de => << I think the problem is clear: "To normalize or not to normalize!">> Cute. However, it appears with new LargeIntegers package that normalize is essential (in some cases), where with old LargePositiveIntegers it was optional (in some cases). <<I'm not motivated to make a full rework of the DSA stuff and would like to hear John's opinion about this topic... >> It sounds like John Maloney understands the problem (see full text of following E-mail), and was taking certain liberties with LargePositiveInteger for performance reasons. => 5/30/00 7:18:42 PM EDT, John.Maloney(a)disney.com => << Incidentally, I'm about to vanish for a six week vacation in Europe. I'm afraid I won't be able to do much about this myself before I go. >> Stephan and John, John's description seems quite consistent with Stephan's. So unless someone is willing to submit a temporary fix as a standard fileIn for the DSA code (perhaps a performance hit by a factor of 2 is good enough for six weeks), I would say that it's broken and should not be used until John gets back. Other opinions? One more fox out of one more rabbit hole :-), Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

2 1

[FIX] Celeste status inst var cleanup
by Steve Elkins 31 May '00

31 May '00

Everyone, I noticed that Celeste>>messages:from: had the line self changed: status and started looking at usage of the (fairly new) 'status' instance variable. The minor changes attached remove the dead code and centralize broadcast of updates in the only method that writes the instance variable.

1 0

Re: [ENH] String repeat
by Lex Spoon 31 May '00

31 May '00

This is a neat algorithm. Why not use it to replace atAllPut:, though? This seems to be the method that new:withAll: depends on. String new: 1000000 withAll: $0 -Lex

2 1

Re: Pluginized VM on Linux?
by John.Maloney＠disney.com 31 May '00

31 May '00

At 12:45 PM -0700 5/30/00, Tim Rowledge wrote: >In message <Pine.LNX.4.10.10005302126560.11735-100000(a)balloon.cs.uni-magdeburg.de> > Bert Freudenberg <bert(a)isgnw.CS.Uni-Magdeburg.De> wrote: > >> On Tue, 30 May 2000, Tim Rowledge wrote: > >> > I don't think Ian has had time yet to build a sources package to put on >> > his site, >> >> Actually, there's a Space Cadets Release at >> http://www-sor.inria.fr/~piumarta/squeak/ >> >> > and there are a few changes that are needed that haven't made >> > it to the update stream yet >> >> I guess he has not yet included these then ... >Correct - those source build a functional VM but with everything builtin >and several of the source files incapable of being used to produce >external modules; the linker hides many small sins. Ian has my suggested >fixes. Tim, I don't think it is essential that all primitives can be externalized on all platforms. Remember, even if the primitives are linked in, when they are built using the new code, then we can: a. convert the Squeak side to using named primitives versus numbered ones, and b. when (a) is done, anyone who wishes to can build an external set of primitives to replace those built into the VM Surely it should be up to the maintainer of each platform's VM the extent to which they choose to break the VM into pieces? I greatly prefer to have all the basic primitives built right into the VM on the Mac, because that simplifies the logistics of managing multiple versions of the VM. Yet I know the Acorn OS makes it easy to manage applications packaged as sets of DLL's, so the opposite approach makes sense there. What's nice is that your collaboration with Andreas has given us the maximum freedom to choose the packaging of the VM that makes the most sense on each platform. -- John

2 1

Re: Proposal3: Make $_ a valid identifier character
by Richard A. O'Keefe 31 May '00

31 May '00

I wrote: > I already *asked* in this thread whether anyone who was there at the time > knows about this. Bijan Barsia (for whom I have the highest respect) wrote: So point me to your received answer which allows you to state, with the absolute confidence that you do, that the *original* reason for not including the underscore, *and* the reason for it not being included in Smaltalk-80, was it's original unavailibility in ASCII. All I said was that I had *asked*. I didn't ever say that I had a reply. However, as I've stated in another message, it is *certain* that the BCPL character set used on the Alto was compatible with ASCII-63 and incompatible with ASCII-67. Now the Alto system supported bitmapped fonts, indeed. it supported the first WYSIWYG editor I ever heard of: Bravo. So it would not have been beyond the powers of the Smalltalk designers to build a special Smalltalk font (or set of fonts) that was consistent with ASCII-67. Mind you, they'd still have had to contend with whatever the Alto keycaps were. Presumably it was easier to go along with the same characters that BCPL and Mesa used, and no-one can deny that the left arrow and up arrow are *useful* in programming. I think it's time for anyone who disputes this to go and find some Alto manuals for themselves. > So how come the *only* non-ASCII characters shown in > the Blue Book are *precisely* the old versions of the two ASCII characters > that are *not shown*? Presumably if they were inherited from old ASCII, > and the extensions were other characters again. Nice speculation. But, while plausible, it doesn't establish your case. Presumably only a signed testimonial from one of the Smalltalk designers would do that. But I *have* established that - *none* of the characters present in ASCII-67 but not in (October 1963) ASCII-63 are used in Smalltalk-80 (as of the Blue Book) - *all* of the characters used in Smalltalk-80 that are not in ASCII-67 *are* in ASCII-63. - other languages (BCPL, Mesa) on the Alto also appear to have been based on (October 1963) ASCII-63 (reference manual for BCPL, Mesa fragments in other documents), even in 1979. - at least for BCPL, prior coding conventions were altered to conform to the same characters as ASCII-63 rather than adapting the character set to the language. Don't forget, in 1979 at least one 6-bit character set was still (just barely) in use (BCL) and US-TTY (a 5-bit code) is still in use today. There has _never_ been a time when everyone used the same character set, even in America, and Smalltalk's designers certainly had other concerns than compatibility with C. Well, one of us must be horribly idiosyncratic. Which, regardless of issues of taste, makes us, without establishing which of our psycholinguistic structures is deviant (and they *both* could be), bad bases for determining what, rationally speaking, should be the case here. It is really frustrating having the point of my argument ignored. It is not *my* psycholinguistic structure or *my* anything which is at issue here. The Ada Quality and Style Guidelines (the most thorough style manual I've ever seen for _any_ language, would that there were a similar book for Smalltalk), other software engineering books I've checked, _all_ recommend separated_words (AQ&S recommends capitals after the low- lines as well). > mentally process multi-word identifiers as single "words", just as it's > very hard for me to hear "r" and "l" as vowels. So you have trouble with 'groundhog'? I didn't say I can't hear "r" and "l", I said I can't hear them AS VOWELS. That is, I have trouble with words like Krshna (no, I didn't leave out an "i", that's the point). > Given the existance of a free VisualWorks and a free Squeak, it might > actually be possible to _do_ such experiments. Of course. Realize that my strong opposition stems from engaging to port some Smalltalk code which made fairly heavy use of _s from VisualWorks to Squeak. The indentifiers which used _s tended to, imho, pointlessly to do so. The indentifiers were bad in themselves (imho) and the underscores merely...er..underscored that fact. I'm a wee bit baffled here. You are _opposing_ a change which would have made _your_ life easier? Most identifiers in most programs are bad. Sturgeon's Law. We've seen a low-line-less example in this mailing list recently, where someone used #rep: where #repeat: would have been better. A fully underscored set of indentifiers would not recognizably be Smalltalk. To some people it would. We're back in the area of personal taste, here. > What would be particularly interesting to know, of course, would be why > some of the more commercial (NOT the same as more valuable!) Smalltalks > have already made the transition. I'll have to see if the draft ansi spec has a rationale for this. I'll note that AFAICT, systematic underscorification doesn't seem to have occured. First question of interest: who moved first? Did the commercial systems adopt low-line first, and then the standard adopt it because it _was_ de facto standard? Or did ANSI Smalltalk adopt low-line first, and the commercial systems move to conform to the standard?

1 0

← Newer
1
2
3
4
5
6
7
8
...
68
Older →

Jump to page: