Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

RE: Large array slows down Squeak
by Parker, Mike 01 Jun '00

01 Jun '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. Umm, 'splain again why tenuring would make Morphic feel slow? If Morphic creates lots of short-lived objects, then much (most?) of those objects won't survive long enough to get tenured; besides, isn't tenuring only done every now and then, when incremental GC's get too long (too many survivors) or the root table gets full? > 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... Creating lots of temporary objects will trigger lots more minor GC's which could make it run slower. However, there are several improvements to the collector that could improve this. Dynamically adjusting the allocation threshold (currently fixed at 4000) and tenuring policy could reduce the frequency of minor GC's, giving those short-lived objects more time to die while keeping minor GC duration below the 10ms threshold. Looking at the collector, though, it looks like the reason for the 4000 object allocation threshold is because the relocation phase doesn't deal very well with the case where more than 2000 objects need to be relocated in a single minor collection, although this could be tweaked.

3 2

Re: [ENH] Minor extensions to butFirst and butLast methods
by Dan Ingalls 01 Jun '00

01 Jun '00

"David N. Smith $IBM$" <dnsmith(a)watson.ibm.com> wrote... >Here are some extensions to SequenceableCollection that I use all the time. There are a couple of similar methods, allButFirst and allButLast, but these are unforgiving in that they burp when asked for a character and it isn't there. > >These are all forgiving; asking for the last 5 characters of a 3 character string answers the last three characters. I've found this much more useable in practice, allowing me to virtually never have to write #copyFrom:to: which is all to easy to get wrong (off by one errors). > >Class SequenceableCollection: > butFirst Answer all but the first character > butFirst: n Answer all but the first n characters > butLast Answer all but the last character > butLast: n Answer all but the last n characters > first: n Answer the first n characters > last: n Answer the last n characters I agree with the convenience of extending the current first/allButFirst pattern to N items -- there are a number of places in the system already where this would help. I'm skeptical about the value of forgiveness in such code. For one thing, it often delays the appearance of bugs to where they are more confusing. For another, it often turns out that tests are needed elsewhere anyway, when results come from "forgiving" code -- ie, you don't really know how many items you actually got, whereas you do with strict code. I'm opposed to having BOTH an allButFirst family AND a butFirst family of methods in the release (but of course it's a fine distinction for maintaining this package as a goodie). My counter-proposal for the release itself would be to extend the current family to N items, using "allBut" naming and strict code. - Dan PS: Note that once you have the N-item versions, it's quite easy to write forgiving code where you really want it, as in str first: (3 min: str size).

3 2

Re: www.squeakworld.com!
by Mats Nygren 01 Jun '00

01 Jun '00

"Göran" Hultgren <gohu(a)rocketmail.com> wrote: > Hi fellow Squeakers! > > This is a call for assistance. > > I plan to launch (in all humbleness though!) an "e-zine" about Squeak and directly related > technology (Comanche, Siren etc.) - in short, a place for all us Squeakers to hang out. :-) > .. Let me be early in stating my support for this. I will happily write things once in a while when I have time, and when it gets accepted by the editors. I have some special interests as can be seen on my swiki-page, and probably will be further drveloped with time. If you want to give space to any of this your e-zine can be a good medium for that. Perhaps a good place to start is to edit material from this list into article-size pieces. That would be a good thing I believe. How do plan to draw the line between the following: - the squeak list - the squeak swiki - the squeakworld I agree with some other posting that a more structured place than the swiki and the list is a good thing. /Mats Nygren

2 1

Re: [BUG] 2.8a Environment Reorg ( Help Please )
by Lantz Rowland 01 Jun '00

01 Jun '00

On May 25th Lantz wrote: >Well, I am still lost in the Environment reorganization. >>On 2/11/00, Dan Ingalls wrote in ChangeSet 1860EnvironmentChgs1 : >> Environments and ImageSegments are back on top of the todo list >I have not spotted any changes or discussions regarding the Environment >Reorganization. > >Is anyone else wrestling with this? Does anyone have an 2.8a image after running Environment reorganizeEverything ? If not, will someone please set an image up and take a look. If there is no real issue with the code that moves core classes out of Smalltalk and I am missing something that is fine, I'll just trash this test image and move on. >My primary issue is with Objects expected to be in the Smalltalk >SystemDictionary that have now been moved into Environment sets. > >The Server updates changesets sending messages to the moved objects >stopped the updates from the server after the reorg. Messages like: > ClassChangeRecord>>methodsFor:stamp > > I changed to downloading the changes and not applying them to my image > so I could look for fixes. > >I do not believe this situation is like the concept handled by: >ImageSegmentRootStub>>doesNotUnderstand: > >It is not unloaded segment that just needs to be brought into the image. >It is also not like the situation handled by: > ProtoObject>>cannotInterpret > >The receiver has been moved out of the SystemDictionary into an >Environment set. > >I think of the Environment as an extension to SystemDictionary, so it is >the SystemDictionary that needs to be aware of it's extensions and it's >internal organization and redirect the messages. > Tools includesKey: #Debugger. "true" > Smalltalk includesKey: #Debugger. "s/b also true" > >Aside... Perhaps the server updates should always download the change >first, then attempt to update the image. If the update is successful and >if the human has stated not to keep local copies of the updates, _then_ >remove the file. > >======================================= > >SystemDictionary class () > > Smalltalk includesKey: #Debugger. "false" > Smalltalk includesKey: #ClassChangeRecord. "false" > > Environment class () > SmalltalkEnvironment class () > > ToolsEnvironment class () > Tools includesKey: #Debugger. "true" > Tools includesKey: #ClassChangeRecord. "true" > > NetworkEnvironment class () > Network includesKey: #PWS. "true" > Network includesKey: #ServerAction. "true" > > Balloon3DEnvironment class () > BalloonEnvironment class () > FFIEnvironment class () > MorphicEnvironment class () > PoohEnvironment class () > ST80Environment class () > SoundEnvironment class () > SpeechEnvironment class () > SqueakEnvironment class () > VMConstructionEnvironment class () > >======================================= >" Example walkback: " >" zLSq2-8a/Updates/2008ModProjClassHack.cs " > >" - - - - - - - -- - - - - - - - - - - " >UndefinedObject(Object)>>doesNotUnderstand: > >Message>>sentTo: >UndefinedObject(Object)>>doesNotUnderstand: >UndefinedObject>>DoIt >" - - - - - - - -- - - - - - - - - - - " > DoIt > ^ ClassChangeRecord > methodsFor: 'all changes' > stamp: 'di 4/5/2000 08:05' >" - - - - - - - -- - - - - - - - - - - " >Compiler>>evaluate:in:to:notifying:ifFail: >Compiler class>>evaluate:for:notifying:logged: >Compiler class>>evaluate:for:logged: >Compiler class>>evaluate:logged: >[] in StandardFileStream(ReadWriteStream)>>fileInAnnouncing: >String>>displayProgressAt:from:to:during: > >======================================= Thanks, Lantz >>XRef: >> 1860EnvironmentChgs1-di >> Environment reorganizeEverything >> 1899segBug-tkNL >> ImageSegmentRootStub doesNotUnderstand: >> >>Squeak2.8alpha of 27 March 2000 >> latest update: #2005 >> Current Change Set: Post Reorganization >>---------------------------------------------------------------------- -- Lantz Rowland <lantz(a)aabysgallery.com> PgpKey: 0x67E5DFA5 Think Different! Think YottaHertz! zL - Lantz's Scriptible Web <http://Lantz.EditThisPage.com/> ----------------------------------------------------------------------

2 1

[BUG] Celeste - names with non-ascii characters
by danielv＠netvision.net.il 01 Jun '00

01 Jun '00

When showing a message from "Göran" Hultgren <gohu(a)rocketmail.com>, Celeste cuts off the line in the TOC right after the $G. Anyone have any idea why? Daniel

2 1

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

01 Jun '00

Your thesis, as expressly stated and reiterated, was that Smalltalk didn't include low lines "because it simply _couldn't_. The fact that it was possible to have used Smalltalk on machines that "couldn't" in 1980 does not prove your point any more than the fact that it is equally possible to use those machines today. I *do* so wish that people would take the rather minor trouble to read carefully and think about what they read. My point about the 1980s VMS printers *of course* doesn't prove anything about Smalltalk-80, nor was it intended to. *READ IN CONTEXT* it quite obviously was intended only to rebut the claim that ASCII was everywhere in use and everywhere the same. The fact remains that the character set actually used by Smalltalk in the coloured books is suspiciously close to ASCII-63. The only characters *not* in ASCII-63 that it uses are the lower case letters, and it was obvious when ASCII-63 came out that not only were the lower case letters going to be added later but that they were going to be added where they now are. (The FIELDATA precedent for aligning the lower and upper case blocks was clear, and the reasons for doing it still applied.) So what what _was_ on the Alto keyboard? Long pause while I find an Alto BCPL manual. Annoyingly, The "BCPL Reference Manual" by James E. Curry and PARC staff, compiled on September 14, 1979 (note date!) does not list the supported character set, and does not spell out the lexical structure of the language. However, comparison with other BCPLs reveals: [ instead of { or $( ] instead of } or $) % instead of | = instead of := uparrow used in a non-standard feature baStudlyCaps identifiers (not normal BCPL at all) no SEPARATED_WORDS (which _was_ normal BCPL practice) With the exception of = for :=, the differences again point to ASCII-63, which _did_ have uparrow, but _didn't_ have { } or even | (in fact, the ACK control character was slap bang on top of where | is now). Even more interesting: I can find no characters used in Alto BCPL (other than the lower case letters) that were _not_ in ASCII-63. Now ISO apparently announced in October 1963, just four months after ASCII-63 was released, that the lower case letters were going to go where they are now. It's not without significance that Mesa, the other systems programming language for the Alto, also used left arrow for assignment. I haven't been able to get my hands on a Mesa language reference manual yet, sadly. However, we do have evidence that the Alto character set was (possibly an extension of) (October 1963) ASCII-63. What we think of as ASCII is ASCII-67, which came out in 1967. The adoption of a new standard is never instantaneous, so even in the early 70s, you could expect to find ASCII-63 around. Like on Teletypes. Like, even in 1979, on Altos.

3 2

Re: DSA changes open for comment
by Bob Arning 01 Jun '00

01 Jun '00

On Wed, 31 May 2000 22:59:33 +0200 Stephan Rudlof <sr(a)evolgo.de> wrote: >I think most people update their VMs, if there is a official (not alpha) >version number change. >Currently we are staying at VM2.7. > >Is this true or may I be wrong here? It's hard to say - who knows how many lurkers out are there and what they are doing. Personally, I tend to lag behind in getting new VM's simply because it's another step, but in this case, Dan warned us that we could see significant degradation in performance if we took all the new image updates and were missing some optional plugins. On Friday he wrote: ---- In the same 2.8 folder on UIUC where I put the interim 2.8beta VM for the Mac, there is now a "real" one, by the name of SqueakVM2.8beta.sea.bin This VM... IS built from all the latest plugin sources IS "fat" (ie it will run on a 68K) DOES NOT have the new LargeInteger primitives (but it rocks with the plugin!) DOES have fast recovery from missing primitives (so it still runs fine without the plugin) DOES support 'Smalltalk listBuiltinModules' and related functions Thanks to all the VM construction workers, and to John for compiling this VM. ---- So I got that one. The story on other platforms may vary. Cheers, Bob

2 1

Re: DSA changes open for comment
by Bob Arning 01 Jun '00

01 Jun '00

On Wed, 31 May 2000 14:56:21 EDT JArchibald(a)aol.com wrote: ><< Note: if you have a DSA plugin for your platform, but do NOT have the >LargeIntegers plugin, then you probably do not want to use this. >> > >Bob, > >I don't think this is quite correct, Bob. If you have the latest VM, at least >on Windows, you have the LargeIntegers code even without a LargeIntegers >plug-in. I haven't checked the latest VM that Dan posted, but I think that >it's probably true for that one, alse. Jerry, What I was trying to say was that if you do NOT have the LargeIntegers plugin compiled C code (either as a separate shared library/DLL/.so OR bound into the VM), then the second of these changesets may dramatically slow down DSA execution. It was not my impresssion that any of the regularly available VMs currently have the LargeIntegers plugin internally, although that is certainly a possibility with the new plugin architecture. Cheers, Bob

2 1

Current VM locations. Was: DSA changes open for comment
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

>From previous mail: => 5/31/00 4:41:54 PM EDT, JArchibald(a)aol.com => [corrected[ The latest Squeak2.7 Virtual Machines have been posted to ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/2.7/files/SqueakExe.zip for Windows (I have verified this one) and ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/2.8/Squeak_VM_2.8-NOT.sea.bin for the Macintosh (though I haven't personally tested this one -- the VM~2.8). I don't believe the Linux versions have been completed and made available yet. Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

2 1

Re: DSA changes open for comment
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

=> 5/31/00 6:52:44 PM EDT, arning(a)charm.net => << Maybe you need to hit the refresh button on your browser. >> I couldn't get anywhere on Windows (IE, Netscape, AOL). I refreshed and deleted Temporary file and flushed History, etc, etc. ... Something wierd happening in Windows'98 setup. The new file seemed to be invisible no matter what I did (Sorry, Dan). You are right. They are there. But I had to come in on the Macintosh to access the site. SqueakVM2.8beta.sea.bin Fri, May 26, 2000, 7:26 PM Squeak_VM_2.8-NOT.sea.bin Wed, May 24, 2000, 10:30 AM Thank God there are alternatives to sWindles'98 :-( Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Jump to page: