Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

Polymorphism and language
by Adam Bridge 02 Aug '00

02 Aug '00

I wonder if we're not asking the wrong question here. Language, it seems to me, is for expression. If we design a language (as opposed to allowing it to evolve) then we should have a goal for that language. What's the goal here? Although polymorphism is certainly an interesting capability shouldn't we be looking at the kinds of tasks we wish to perform? Would we demand an artist work in tempra when water color is what expresses the mood best? Personally I like the idea of small languages that do some things very very well. They are easy to learn because their concepts are clear. If languages can agree on ways to intermingle so I can write my image manipulation in one language and my text in another and my GUI in yet another -- and have them work together intimately and EASILY -- then I think we have a software system which is about expression first and language second. I'd love to easily, trivially, combine Smalltalk, Perl, Fortran, Obj-C and be able to easily explore other languages in this same context: it becomes easy to grow. Adam Bridge

2 1

unsubscribe
by Alek 09 Jun '00

09 Jun '00

2 1

Re: Re: Float bug toolkit: what the hash is this?
by Tim Olson 31 Aug '99

31 Aug '99

>>"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800) "alt-p" >>These are equal since both expressions end up answering a float with a >>special value indicating positive infinity. Positive infinities are always >>equal. > >Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if >finished correctly) is aFloat. Correct. The problem occurs when the #= message is sent to the LargePositiveInteger with the argument a Float (+Infinity). This causes the LargePositiveInteger to be adapted to a Float (resulting in +Infinity, as well). >If aFloat turns out to be infinite, an error >should be posted. This would have to be tested in the Float primitives in the VM whenever an overflow (or NaN, I suppose) is generated. However, I *think* (VM experts correct me, here) that all they can do is fail rather than returning a succesful value, so all of the Float code that invokes primitives would have to be rewritten to test and reflect this overflow/exception failure. The IEEE "default" operation is to silently return the default values (Inf or NaN), rather than generating an exception. What should the standard for Squeak be? -- tim

3 2

Re: CrLfFileStream as default?
by lex＠cc.gatech.edu 06 Nov '98

06 Nov '98

"R. A. Harmon" <harmonra(a)webname.com> wrote: > >This sounds basically like what CrLfFileStream does > [snip] > >So in my opinion, the only things stopping adoption of CrLfFileStream as a > default are: > > > > 1. a decision on the file positions issue (I vote for "it's illegal", > > migrating towards "it's expensive and unadvised") > > 2. automatically choosing output line endings based on what the current > > platform is. This could be done by putting a "CrLfFileStream > > guessLineEndConvention" in SystemDictionary.processStartupList. > [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. 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. 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. Now in the CrLfFileStream in the standard image, this second guess is also used when reading. If the convention was guessed to be CR, then any LF's read in will be left as is. This is also debatable, and in fact I think that LF's should be converted to CR's no matter what convention has been guessed. So I sent a patch around a few days ago that did just this. 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.... Lex

2 1

CrLfFileStream as default?
by Lex Spoon 06 Nov '98

06 Nov '98

If a file has a CRLF pair in it, and CrLfFileStream converts that to a CR, then the idea of "position" gets messed up. It looks like 1 character, but "file position" will act like 2 characters have gone by. For CrLfFileStream to go the final mile, it should probably have some code to make positions truly transparent to the user. Other than that, CrLfFileStream seems very nice. I've been using it as the default for several months now and found it nothing but convenient. Lex "Pennell" <pennell(a)tiac.net> wrote: > Dan - thanks for adding this in 2.2. Is there any reason not to make this > the default? > If you don't change the default for 2.2, can you add it as a preference? > > - david

4 3

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

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

Re: CrLfFileStream as default?
by R. A. Harmon 31 Oct '98

31 Oct '98

At 04:23 PM 10/29/98 -0500, Lex wrote: >"R. A. Harmon" <harmonra(a)webname.com> wrote: > >> I think with the following proposed set of conventions that PILT could be >> effectively achieved and the odd "bite" handled on a case by case basis in >> some standard way. [snip] > > >This sounds basically like what CrLfFileStream does [snip] >So in my opinion, the only things stopping adoption of CrLfFileStream as a default are: > > 1. a decision on the file positions issue (I vote for "it's illegal", > migrating towards "it's expensive and unadvised") > 2. automatically choosing output line endings based on what the current > platform is. This could be done by putting a "CrLfFileStream > guessLineEndConvention" in SystemDictionary.processStartupList. [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 native platform line termination conventions I know of are as follows: DOS/Windows on x86 CrLf UNIX Lf Mac Cr So when reading external text, all interline spacing (carriage return, form feed, line feed, and vertical tab) characters are handled as follows: Cr - add Cr to internal collection, if followed by Lf then read and ignore Lf. Lf - if proceeded by Cr then ignore Lf else add Cr to internal collection. Ff and VT - ignore. This does require reading external text a character at a time, but doesn't seem prohibitively expensive. CrLfFileStream also doesn't deal with the problems like that of runs breaking in Text instances. It seemed to me that a lot of this kind of anomaly exists when just about any of the classes start reading and writing to external devices -- ports, disks, etc. I didn't really dig into the code to see for certain, so I could be wrong. The more I looked, the more things looked a little shaky in a number of classes. At 03:15 PM 10/30/98 -0800, Michael S. Klein wrote: >>At 03:15 PM 10/30/98 -0800, Hans-Martin Mosner wrote: >> I'd support the first alternative with the reasoning that file positions >> for ASCII files should be treated as opaque 'cookies', that is, you can >> get the file position and set it to get back to a point where you were >> before, but you should not do arithmetic with them. > >[other less pleasurable options deleted] > >You have to do something like this, anyway, to support multi-byte characters, >so you may as well do lineEndConvention this way, as well. I've also been thinking about how to handle multi-byte character support. I agree with Hans-Martin Mosner and Michael S. Klein. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

2 1

Re: Floats to Bytes and back again
by Dan Ingalls 31 Oct '98

31 Oct '98

>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 I bet you forgot to use Float new: 2 instead of just Float new (which defaults to new: 1). [This should probably be fixed] Try the following example: | r | r := Float new: 2. r basicAt: 1 put: (Float pi basicAt: 1). r basicAt: 2 put: (Float pi basicAt: 2). r - Dan

3 2

Wavelets Live in Squeak!
by Dan Ingalls 31 Oct '98

31 Oct '98

Folks - I now have a compact and reasonably efficient implementation of wavelet transforms in Squeak. I based it on Mac Cody's article in Dr. Dobb's Journal, so as to be able to leverage off his documentation and examples. Those can be found at... http://www.dfw.net/~mcody/fwt/fwt.html I will issue it as a squeak update in a week or so, but if you want an advance copy, send me a message offline. - Dan

2 1

Jump to page: