Squeak-dev June 2000

squeak-dev@lists.squeakfoundation.org

134 participants
686 discussions

[BUG] vmTable:at:
by Stefan Matthias Aust 01 Jun '00

01 Jun '00

Can be remove vmTable:at:, yes? It's identical to vmParameterAt: and has no sender. I just ask because perhaps somebody relays on this method. bye -- Stefan Matthias Aust \\ Truth Until Paradox

1 0

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

OWHY :- or what have you
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

For your morning entertainment-- Concerning OWHY, the first on-the-fly-acronym (which we will neologize as OTFA, a FLA), the great-grandfather to 'IMHO', 'FWIW', OWHY (self application before definition here. See below). "A Type-Theoretic Alternative to CUCH, ISWIM, and OWHY*" Dana Scott This is one of Dana Scott's most famous unpublished (but widely distributed {it had on the cover page: "Dana Scott no longer subscribes to the ideas in this paper. DO NOT REDISTRIBUTE" in bold print} -- if you ever want to get a massive distribution of difficult material, use this on your paper). He had quite a number of unpublished papers making the rounds as Xerox copies, as I recall. A post-Doc (whose name evades me at the moment) from Penn State visiting for the summer at IBM Research had dutifully collected the whole bunch. What I saw and what I copied shall remain unmentioned (to protect the anonymity of the guilty). The paper is essentially typed Combinatory Logic. As I recall, Dana tried to dip his toe into typing here, but didn't go the whole way. John Reynolds once told me, "If you're going to type, you're going to have to type everything." Smalltalk does it beautifully [typing everything] (for what some aboriginal programmers refer to as a "type-less" language) in a semi-functional format. This is not a good paper from which to learn Combinatory Logic. Nor is 'Curry and Feys' for that matter. If you are interested (and you like 'macro processor'-like thinking), the resource to get your hands on is the book: "Introduction to Combinators ..." by Hindley, et al., unfortunately out of print. A good exercise is to build a Combinatory Logic evaluator in your favorite (owhy) programming language. Wilhelm van der Pol (Netherlands Algol 68 expert) did precisely this during a sabbatical at IBM Research; I looked over his shoulder. CUCH is Curry-Church. It had been used in the title of a paper (by ?). I think it actually was made into a programming language at one point. I've never seen it, but as I remember it was just a demonstrator for automated Combinatory Logic (untyped). ISWIM was Landin's language from "The next 700 Programming Languages." It was the genesis of functional programming as it divorced itself from LISP. I don't think Landin ever implemented ISWIM, but I might be mistaken here. Bill Burge wrote an excellent book (the thing to read after "The Next 700 Programming Languages") on functional programming which is 100% ISWIM, and is an excellent read on Combinatory Logic Programming (untyped). Both he and Burt Leavenworth (both members of the programming language lunch table gang at IBM Research) had built local (to IBM) implementations of ISWIM. *or what have you. Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ "I can't think of the author." Anon.

1 0

[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: 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 => << It's in the same directory- I just checked. ftp://st.cs.uiuc.edu/Smalltalk/Squeak/2.8/SqueakVM2.8beta.sea.bin Maybe you need to hit the refresh button on your browser. >> I think I've found the problem. It's in Internet Explorer. I think I'm working with a quite recent version. About says: Microsoft Internet Explorer 5 Version: 5.00.2614.3500 Update Versions:;q235666;q235667 but it chokes (quietly) on an ftp: URL, and just says 'The page cannot be displayed'. And I'm using AOL 5.0 (the installation of which is now suspect, I've only been using it about a month). I'm sure that, when I was previously seeing only one file in the 2.8 directory, that I was getting the cached version of the page. AOL has a mickey mouse FTP client. It reminds me a bit of video games on the TI home computer (I can't remember the model number, something like 99/4, but the one that they cleared out at 99 bucks in the early '80s <How many remember the Sinclair? Please raise your hands. How many owned one? How many tried to write a nuclear power plant welding records database in Sinclair BASIC?>). AOL's mickey mouse FTP client sees the files. So I believe MS IE should be able to see them (when you're using AOL to directly access Internet resources, it silently steps across to a mini-IE -- which is sort of strange for a company that owns Netscape). Arrrgggghhh! (Lucy pulled the football away again) They make absolutely sure that the Multi-Media stuff works right; it does, I can get Bloomberg New Radio (and many other things I haven't asked for) easily. Why in God's name would FTP URLs cease to work? !!! ARRRGGGGHHH !!! To repeat: Why in God's name would FTP URLs cease to work? !!! Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ "When all is lost, try to find something." :-o

1 0

Re: [Enough already] Re: Proposal3: Make $_ a valid identifier character
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

=> 6/1/00 12:36:59 AM EDT, ok(a)atlas.otago.ac.nz [personal communication] => << The great ideas in Smalltalk are semantic. They'll survive the new additional Squeak syntax (whatever it happens to look like). And they'll survive underscores. >> I agree completely. I tend to think of a Smalltalk program as a semantic construct associated with the parse tree for that program. The nature of this semantic construct is unfortunately ungrounded, somewhat waving the the air. The byte-code representation (the Blue Book description) is treading water very fast to be considered the standard for Smalltalk definition; I consider that it is rapidly on its way to becoming obsolete. It certain is obsolete in _my_ mental construct associated with the parse tree. At the moment, though, I don't see an alternate to the Blue Book description on the horizon. Unfortunately. Nonetheless, you are correct, Smalltalk will survive underscores. But as a practical matter, my E-mail was attempting to state, in a somewhat rough and tumble manner, that underscores are not going to be introduced in this round. IMnsHO. However, if the great ideas in Smalltalk are semantic (to which I agree), then why is there so much heat (and little light) being presented on this issue? I haven't counted them (I just did, I counted 44); why are there so many E-mail postings on this issue? And why are these E-mail postings so angst ridden? And why are these E-mail postings failing to converge (and cease and desist)? << <<Do you think WE_DONT_WRITE_ENGLISH_THIS_WAY_SO_WHY_SHOULD_WE_WRITE_PROGRAMS_THIS_WAY is an improvement?>> This is an invalid argument having the same form as "A. I think salt is better than sugar on pies. B. Oh yeah? Then you must really love salt by itself." >> I don't think it is an invalid argument. I don't think of it as an argument at all; it was a demonstration, as was your (correctly formed Smalltalk global variable) identifier preceeding it. User interface considerations associated with programming languages depend upon a common view shared by the users of the language. This common view (of the user interface considerations) comes from some rather subjective evaluations and sometimes practical admissions. There is some magic in the lexical fundamentals and syntax (as well as the semantics) of a computer language (certainly in Smalltalk) that cannot be analyzed entirely from a strictly formal perspective. Smalltalk appears to be the simplest language around (in terms of its semantic definition) that has massive computation power. FORTH, LISP in its original habitat, and Fortran (owhy) are unarguably simpler, but LISP bigots aside, Smalltalk has more descriptive power than is normally available in such a simple langauge. I want to know what they were smoking in Palo Alto in the 70's (and is there still any around) :-). Squeak seems to be what we're smoking in the 21st century, and it appears to have a fine aroma and bouquet. And besides, the price is right. Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ [owhy (for those still Dana Scott challenged) :- 'or what have you']

1 0

[ENH][Plugin] LargeIntegers division speedup
by Stephan Rudlof 01 Jun '00

01 Jun '00

"Change Set: LargeIntegersPlugin-update Date: 1 June 2000 Author: Stephan Rudlof Speeds up digitDiv:neg: at about 20%. Precondition: 2163LargeIntegersPlugin If you don't know how to compile a plugin, this changeset is probably of no interest for you. Try: | divident divisor | divident _ 1 << 1000. divisor _ 7. [10000 timesRepeat: [divident digitDiv: divisor neg: false]] timeToRun Implementation: In >>cCoreDigitDivDiv:len:rem:len:quo:len: the 'nibble' arithmetic is removed. " -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: Suggestion for distributing Large Integers (Was: DSA changes open for com...
by Andrew C. Greenberg 01 Jun '00

01 Jun '00

At 11:30 PM -0400 5/31/2000, JArchibald(a)aol.com wrote: >=> 5/31/00 9:40:43 PM EDT, werdna(a)gate.net => ><< What is more, I'd vote AGAINST having the plugin internally. >> > >I'm not sure I understand, do you think it should be taken out of the Windows >VM? Not at all, I think it should be distributed WITH the Windows VM as a DLL. The purpose of plugins is precisely that -- primitives that can be re-inserted and substituted for without recompiling the entire VM. The LargeIntegers plugin is particularly subject to change, and improvements -- this being its first release. By keeping it as a DLL, you will be able to substitute new versions simply by plugging in a new DLL, without rebuilding the VM. -- Andrew C. Greenberg acg(a)netwolves.com V.P. Eng., R&D, 813.885.2779 (office) Netwolves Corporation 813.885.2380 (facsimile) www.netwolves.com

1 0

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: Suggestion for distributing Large Integers (Was: DSA changes openfor comment)
by Raab, Andreas 01 Jun '00

01 Jun '00

Andrew, As Tim has said before, there is no problem whatsoever with having both the builtin and the external version of the LargeInt plugin. Here's how it works: The VM looks first if there's an external version of a plugin (e.g., a shared library) and if so, always uses that. Only if no external version is found it looks internally for the plugin. Meaning that the entire argument about having the plugin external or not is entirely meaningless. You can at any time just drop an updated shared library version in the VM folder and from then on your VM will use the external one. - Andreas > -----Original Message----- > From: Andrew C. Greenberg [mailto:werdna@gate.net] > Sent: Wednesday, May 31, 2000 6:31 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: Suggestion for distributing Large Integers (Was: DSA changes > openfor comment) > > > >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 > > I think Bob has this right. What is more, I'd vote AGAINST having > the plugin internally. There is much room for improvement in speed > in the straightforward (but well-executed!) implementation and I > would expect large incremental changes to be possible in the near > future. > > Since the "fast failure" routines are present, new largeintegers runs > just as fast as old squeaks largeintegers, with the plugin giving an > added boost. > > At least for 2.8, until largeintegerplugin is slamming fast and > unchanging, we probably ought to keep it as an in-image source > plugin, with DLL's and shared libraries distributed with the image. > -- > Andrew C. Greenberg acg(a)netwolves.com > V.P. Eng., R&D, 813.885.2779 (office) > Netwolves Corporation 813.885.2380 (facsimile) > www.netwolves.com >

1 0

Jump to page: