Squeak-dev November 1998

squeak-dev@lists.squeakfoundation.org

128 participants
265 discussions

Re: Re: Method names
by sqrmax＠cvtci.com.ar 03 Nov '98

03 Nov '98

Hi. >> >or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits). >First, it already says aBitStream, so the second pseudo-selector-noop-bits >is just stuttering reminicent of programming in java. I.E. > > BitStream bitStream = BitStream.newBits(...) Unfortunately, bitStreams also know how to read themselves by bytes and by bitChunks... the problem I get is that I have the pair #next and #next: for bits, #nextByte and #nextBytes: for bytes, and #nextChunk: amountOfBitsInTheResultingChunk for bitChunks. The issue with the units is that it wouldn't be desirable in such low level stuff. Andres.

1 0

bugs (a suggestion)
by Ryan Davis 03 Nov '98

03 Nov '98

I love the update feature... Tre Cool. One more very nice feature would be a bug reporting mechanism... I'm less concerned about having nice forms as I am having a quick and easy way to pop something up, fill out necessary info, possibly grab some diag info automatically, and email it off... It would help us all if this existed... P.S. I seem to have frozen in mid-update. Can't tell you which filestream as they don't have names or numbers... Ryan Davis -=- Zen Spider Software -=- mailto:zss@ZenSpider.com -=- http://www.ZenSpider.com/ -=- I know that you believe you understand what you think I said but, I'm not sure you realize that what you heard is not what I meant.

4 3

Re: Method names
by Matthew McDonald 02 Nov '98

02 Nov '98

Andreas Raab writes: > > Messages usually have the arguments last. Wouldn't it be nice to have > > messages that could have arguments between a phrase? > No. [...] > > aBitStream next: 40 bits [...] > The above should be written as > > aBitStream next: 40 "bits" I thought the trailing no-op in the message selector was a nice idea. Comments aren't as good as the message selector syntax. Comments get out of date and people leave them out. If it's really worth mentioning in a comment, that you're expecting with 40 _bits_, then it's worth making this explict/mandatory using the method selector. Also, the trailing no-op in the method-selector allows you to have a similar method you invoke like this: aBitStream next: 40 bytes. It looks like the main difficulty would be that the resulting language couldn't be parsed without extra information - you'd need to know whether or not there was a message called #next:bits to decide whether or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits). -- Matthew McDonald <mafm(a)cs.uwa.edu.au>

4 3

Re: Method names
by Alan Kay 02 Nov '98

02 Nov '98

Reinier -- We've talked a lot over the years of adding "units" (centimeters, feet, grams, ounces, bits, bytes, etc.) to Smalltalk. They are very useful in science for knowing what you are talking about, and in Smalltalk would be a set of unarys (as you suggest) that help conversions to be made. (They also could be symbolically executed to just get the dimensions of the quantity .....). Any interest out there in making a great units package for Squeak? Cheers, Alan At 7:08 PM -0000 11/2/98, Reinier wrote: >> >> aBitStream next: 40 bits >> >In resolving such issues, I always try to think like a human ;-). >What would you say as human? Problably something like: "dear bit stream >please give me the next 40 bits". So, it seems that 'bits' is ok to use. >But..., 'bits' tells us something about 40. In this case 'bits' defines the >unit of 40. This would lead me to rephrase like: "dear bit stream please >give me the next 40 elements where the unit is bits". Back to Smalltalk: > > aBitStream next: 40 unit: #bits > >Or, maybe even better: > > aBitStream next: ( 40 bits ) > >where '40 bits' would yield an instance of Quantity *1. > >I think Quantity is one of the most important classes anyway. Oddly enough >*2, you don't see it around much. > >Reinier. > >*1 >Object subclass: #Quantity instanceVariableNames: ' unit value '... > >*2 >Well, not really, all Smalltalk's offer technical classes only. No real >world classes. >

1 0

printOut(AsHTML)
by Gerardo Richarte 02 Nov '98

02 Nov '98

Hi! In order to make printOut(AsHtml) work properly we needed to add #verbatim: and to change #nextPut: in HtmlFileStream, here are our versions, there may be better, as ussual... nextPut: char "Put a character on the file, but translate it first. 4/6/96 tk" char = $< ifTrue: [^ super nextPutAll: '<']. char = $> ifTrue: [^ super nextPutAll: '>']. char = $& ifTrue: [^ super nextPutAll: '&']. char asciiValue = 13 "return" ifTrue: [ self command: 'br']. char = $ "tab" ifTrue: [self verbatim: '    ']. "this line changed" ^ super nextPut: char verbatim: aString "Write the whole string, without translating it. r++ 11/2/1998 14:46" "Needed here so printOutAsHtml works ok" aString do: [:each | super nextPut: each]. I hope you have a nice printing... Printed Bye! Richie++

1 0

some not-so-random questions
by Jason Karney 02 Nov '98

02 Nov '98

Hi, I had a couple of misc. questions about Squeak, your answers are appreciated. First, what is the latest and "official" version of the Win32 port of the VM? My first download of Squeak 2.2 (as a complete zip archive) included a VM called "SqueakBeta.exe." Then I got a distribution whose VM binaries are "Squeak.exe" and the jitter version, "SqueakJ.exe" Then while browsing the Swikis this morning, I saw a notice that Squeak for Win32 was going back to a single VM. So you can understand my confusion... (and incidentally, SqueakBeta *seemed* to run a little faster than SqueakJ) Second, does anybody have any suggestions for optimizing Squeak running on a 90Mhz pentium laptop with 8M ram? Some operations (and morhpic in general) bog the system down. I thought perhaps the vm has options to control initial memory allocation, or some such things. Thanks! -- Jason Karney <- Advanced Technology Scientist NetGenics, Inc. [jason(a)netgenics.com] [STOP] Okay, you were there yesterday, but Where do you want to go tomorrow?

3 3

Re[2]: Method names
by Jerome.Garcia＠wj.com 02 Nov '98

02 Nov '98

Sorry to jump in but parse trees again! As this message and the others in this thread mentioning parse trees indicate, having to parse text has its bad points. I think the problems with the more readable forms mentioned all go away if you edit the parse tree directly using an editor that displays the parse tree as text with appropriate visuals to indicate "types" of elements displayed. A comment is just another node in the tree and is visually identifiable as such. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Re: Method names Author: Vassili Bykov <vassili(a)objectpeople.com> at INTERNET Date: 11/2/98 2:45 PM At 01:37 PM 11/2/98 +0800, Matthew McDonald <mafm(a)cs.uwa.edu.au> wrote: >It looks like the main difficulty would be that the resulting language >couldn't be parsed without extra information - you'd need to know >whether or not there was a message called #next:bits to decide whether >or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits). [Incidentally, that would be (aBitStream next: (40 bits))] Knowing what method selectors exist in the image would not be enough. If there existed #next:bits, #next:, and #bits, you would not be able to tell which interpretation of "<expr1> next: <expr2> bits" was the proper one without knowing (and you can't) the types of the expression results. What's even worse, in a dynamic environment where selectors come and go, adding or removing a selector would mean potentially changing the parse tree of some of the already compiled methods. --Vassili -- Vassili Bykov vassili(a)objectpeople.com The Object People http://www.objectpeople.com +1(613)225-8812 "Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." -- Greenspun's Tenth Rule of Programming

1 0

Re: Floats to Bytes and back again
by David N. Smith 02 Nov '98

02 Nov '98

At 1:59 -0500 10/31/98, Travis or Kerrin Griggs wrote: >I'm trying to create a typed FloatArray. There's not a lot in the system >for converting floats to bytes, so I hacked up something where I use >basicAt: to extract the first and second dwords, and then strip the >dwords down a byte at a time (a bit more complex then VW where >changeClassToThatOf: #[] works handily). But now that I've got it ripped >down into 8 bytes, I can't figure out how to get the float back again. I >put the 4 byte chunks back together (via bitShift: and +), but can't use >basicAt:put: on an instance of a float. Feature, bug,...? Is there a >better way to do this anyway? > >Travis Griggs Look at Float>>asTrueFraction; it tears apart a float and builds a fraction out of the same bits. Reverse conversion is done by sending #asFloat to the fraction; an identical float is produced. _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.

1 0

Re: CrLfFileStream as default?
by R. A. Harmon 02 Nov '98

02 Nov '98

At 03:32 PM 10/31/98 -0500, Lex wrote: >"R. A. Harmon" <harmonra(a)webname.com> wrote: [snip] >> I don't think there is any reason for "guessLineEndConvention" in the >> approach I propose and if it guesses wrong (especially on an already >> anomalous file), CrLfFileStream, seems to produce anomalies that I don't >> think are caused just by cut-and-paste. >> > >The purpose of this method is to pick a convention for *new* files. > The idea being if you create a text file on Windows, it should have >CRLF line endings, and if you create a file on Unix, it should have >LF line endings. That way you can view Squeak files using other >applications on your operating system, without having to convert the files first. >If you don't do this method during startup, then CrLfFileStream won't notice > it is operating on a new platform. It will continue using whatever convention >it was using when the image was saved, even if it was saved on a different platform. Yes, I agree a default should be set at start up. I think all that is needed is a defaultLineTermString class variable set at start up for the platform it's running on, and a stream instance lineTermString that is set to the default and can be reset to something else manually if you want. This is how Smalltalk Express (SE) does it, if I remember correctly. I assume Squeak can determine at start up what platform it's on, or should be changed to do so, because it's useful in other areas also. I think the CrLfFileStream approach to append applies only to files, and not streams which my be ports, sockets, or something equally as exotic (means I don't understand it). >Now, there's a second "guess" going on in CrLfFileStream, and that's when a >specific file is opened. This guess is to ensure that new data written to >the file will have the same convention as the data that's already in the file. I think this will produce a mixed convention file if it gets a mixed convention file. >If you have a CRLF-delimitted file on Unix, then you should keep writing CRLF >endings, and not start appeding lines with LF endings. The point is debatable, >I suppose, but that's the purpose of this one. [snip] I can see where this would be quite useful, especially for someone working in both UNIX and Windows (dual boot). I propose it be an option that one can select as the default append, new, or both behavior. I think the convention I propose works in all the following cases: - Writing a new file, Crs are appropriately transformed to Cr, CrLf, or Lf according to lineTermString. - Append an exiting file, Crs are appropriately transformed to Cr, CrLf, or Lf according to the lineTermString. - Reading an exiting file, Cr, CrLf, Lf, or a mixture of these, are appropriately transformed internally to Crs. On Windows, some applications gracefully handle Cr, CrLf, Lf, or a mixture of these, while others, make it difficult to work with any file that doesn't conform to its line termination convention. A mixture of conventions makes no difference to the later, so I would prefer a Squeak default that produced mixed convention on append. This approach doesn't require exceptional handling for append. >So I sent a patch around a few days ago that did just this. Yes, I saw it. >Now, I've been using this setup for a week or so now with no troubles. > However, I've not messed with any *really* strange files.... I'm not sure why I did. Somebody else said they were getting strange stuff too. Have you tried cut-and-paste operations. I think these might confuse CrLfFileStream. I think they are valid operations that the fix to line termination should handle. I appreciate that you did CrLfFileStream. I would have probably spent a fair amount of time trying out the same idea, but not doing it as well. At 03:28 PM 10/31/98 -0800, Michael S. Klein wrote: >> I don't think there is any reason for "guessLineEndConvention" in the >> approach I propose and if it guesses wrong (especially on an already >> anomalous file), CrLfFileStream, seems to produce anomalies that I don't >> think are caused just by cut-and-paste. > >Sometimes you may want to guess, sometimes you may want a rigid line end >policy. After some reflection, I agree (see above). >> The native platform line termination conventions I know of are as follows: >> >> DOS/Windows on x86 CrLf >> UNIX Lf >> Mac Cr > >Smalltalks use cr. There is also Unicode which has explicitly different >line separators and paragraph separators ( U+2028 and U+2029 ). [snip] Adding Unicode (same as double-byte characters?) will require overriding some behavior I suspect. The line termination will be one of them. I don't no enough to join in that conversation. >This works sometimes, but there are some of us who actually use ff & vt's >placed in text by other people. My question is what do the Ff and Vt characters in Text instances mean? If it means line termination, I suggest the code that uses them be changed to reflect the convention if adopted. If they are used as for some other purpose, say optimization because of the sorting order (simple-minded example), I think that is one of those case-by-case exceptions. If the Text instance has Ff put in, something done with the instance, then it's thrown away then that seems reasonable and won't break any code. If the instance is used by other code then this additional Ff behavior instance should probably be in a new subclass of Text (or new wrapper class, etc.), and conversation methods added. External strings terminated with a binary zero are good examples of why one might want a string like object that breaks the convention. SE has conversation methods to add and remove the trailing zero. I envision the line termination convention not as coercive, but as liberating us a little bit. One doesn't need to code for all the odd cases everywhere. I think this is especially important in a cooperative endeavor like Squeak. That's why I add the last rule: - You run into something that doesn't follow the convention, send in a fix or at least point it out. I think we need to backstop each other like baseball players do. One player will get behind another play trying to catch a ball, so if he misses it the second player is there to help. Someone might not know of the convention, or ported code from another platform and didn't get around to changing to convention (it happen to me, anyway). I'd appreciate any back-stopping I could get. I guess I approach the Squeak community as a team rather than a group of "rugged individuals". >> This does require reading external text a character at a time, but doesn't >> seem prohibitively expensive. > >First make it work.... then make it fast [snip] I heartily agree. >As far as line end convention goes, I think the important thing to do is >to factor out the handling into a Policy object. Otherwise the streaming >code just gets all krufted up with different cases. > >If somebody wants a different policy, they add a new class instead of >futzing with the convoluted code. Would this be similar to the External Stream Decorator suggestion I copped from the preview of the book "The Design Patterns Smalltalk Companion"? Your idea sounds promising, could you explain it a little more concretely for me. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

2.2 VM for FreeBSD 3.0
by Roland Jesse 02 Nov '98

02 Nov '98

Hello, Just in case that anybody is interested - I put a Squeak 2.2 VM for the latest FreeBSD (3.0-RELEASE) into ftp://alix.inria.fr/pub/incoming/. In addition, I placed a copy in http://www.apfel.de/~jesse/squeak/. Both directories also contain the diff file for GNUmakefile.conf that I used. Regards, Roland

2 1

Jump to page: