Squeak-dev December 1997

squeak-dev@lists.squeakfoundation.org

21 participants
21 discussions

Re: New comment delimiter?
by gr＠fuzzy.uba.ar 25 Dec '97

25 Dec '97

Just an idea: What if we use the color and/or size of the text to show if it's a comment for programers, a comment for users, just a comment, or anything else? It has some problemas like storing all that information as text (HTML may help?), and it also makes you learn some color codes to understand what's written (size can help for this problem), but it has a very nice pro: You can write a book in this way, with titles, subtitles, superscripts (?), etc. and of course embedded examples! What do you think? Writer Bye! Richie++ PS: I have a one day delay to get my mail back from the list, 'couse neither my mail server nor me are on-line...

1 0

Re: v1.23 corrupting images
by Ian Piumarta 25 Dec '97

25 Dec '97

> every 20 to 40 min I end up with image 24 bytes length after an image save. > Anyone on Unix noticed similar behavior? No, never. The image save (along with the other file i/o primitives) appears to be working fine. The only time I've seen an image saved incorrectly was when the filesystem was full, and the snapshot primitive failed silently (this really aught to be fixed sometime). The only difference in the file primitives between 1.18 and 1.23 is that the POSIX "b" options to the fopen() mode are present in the latter -- although this is unlikely to be affecting you since #writeImageFile: uses "self cCode:" to to call "fwrite()" directly, and does not rely significantly on the file primitives to save the image. Ian PS: I'm afraid I have no insights about how this could be debugged. The only thing I could suggest is that you alter image save so that it prints the arguments that it's passing to fopen(), fseek(), fwrite() and fclose(), and the next time that you see a truncated image check what it printed in the terminal. (The value _returned_ by fwrite(), when called to write both the header words and the memory image, would also be a useful thing to check.)

1 0

Re: Official support
by Randal Schwartz 24 Dec '97

24 Dec '97

>>>>> "Dan" == Dan Ingalls <DanI(a)wdi.disney.com> writes: Dan> I once read a derogatory reference in comp.lang.smalltalk to Dan> Squeak's dependence on the whimsical enthusiasm of a couple of Dan> wizards. Who could ever make product plans upon such shifting Dan> sands? The same has been said about Larry "Perl" Wall or Guido "Python" von Rossum or Jon "TCL" Ousterhout getting hit by their respective busses. Funny how that doesn't seem to stop millions of people from using this free software for mission-critical applications all over the world. Dan> The answer is simple: A Squeak release includes everything about Dan> itself, and probably 25% of the folks on this distribution list Dan> could maintain the any given version single-handedly for the next Dan> 20 years. It's better than being supported. It's having control Dan> over your destiny. Exactly! Open/free software *is* power over your own destiny. It's only scary to people that are accustomed^Wprogrammed to calling an 800/900 number every time they can't figure out where the "any" key is. :-) I cringe whenever I have to use poorly-documented probably-buggy proprietary vendor products. I'm too used to Perl and GNU Emacs, I guess. :-) Just another guy hoping to get proficient with Squeak after abandonding QKS Smalltalk's futures markets, -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)ora.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

1 0

Re: User primitives in Squeak
by Ian Piumarta 24 Dec '97

24 Dec '97

Boris, > I found that there are some things which make > 1.23 MUCH less pleasant to develop such stuff on than v1.18. You can always ignore the user primitive stuff entirely, and just carry your primitives forward from 1.18 to 1.23 if you prefer. The mechanism for "intrinsic" primitives numbered from 1 to 600 (or 700, I can't remember) has not changed since 1.18. The UP support is unofficial, unsupported, and (originally) specific to Unix (and maybe some versions of Andreas's Win32 ports -- since I originally did it speficially to help Andreas make faster progress with his GL stuff), and nobody is suggesting that you use it if you don't like it. > 1) User primitive fail code doesn't seem to work. > > myMethod > <primitive: 1500> > ^'hello there!' > > If the primitive fails, I get the usual <error: primitiveFailed> > instead of hello there. A bug -- I'll look into it. > 2) I can pass only 7 parameters to the primitive. This is > completely unacceptable for my tasks. This is an arbitrary limit that is trivial to increase. Look at the Interpreter method #userPrimitiveResponse and it should be obvious how to increase the number of arguments that can be passed. > 3) In 1.18, where I write my own primitive code, I can analyse > the arg count myself and thus develop a primitive to take variable > number of parameters; can I do anything similar here? Like I said, the original primitive stuff has not changed. You can still use precisely the same mechanism in 1.23. For the UPs, the above could only be done by changing the way user primitives expect to receive their arguments. For example, if they were prepared to be passed an argument count and a pointer to the first argument, and then to pick up their arguments by indirecting through this pointer with an index, then yes -- it would be easy. On the other hand, if the UPs want to receive arguments in a C-like fashion then it's much harder to do in a portable manner. I'm not particularly attached to the UP facility, implementation, philosphy, or anything else. If it should be done differently, or even not at all, then change it. > P.S.: At the time you will be about to publish the next Unix > release, could you send it to me just before announcing it so > I can verify if it compiles/runs on OS/2, so you can announce > it as a release "for Unix, including OS/2"? No problem! Regards, Ian ------------------------------- projet SOR ------------------------------- Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta(a)inria.fr BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87 ----------------------- Systemes a Objets Repartis -----------------------

4 3

Re: Use for TimeZones (was: Time bug under Windows)
by Mike Klein 23 Dec '97

23 Dec '97

> From martin(a)hand2mouse.com Mon Dec 22 09:15:11 1997 > It seems like a time > without a frame of reference would be a time *interval*, probably stored as > a number of seconds, with accessors for seconds, hours, and days. These > objects wouldn't translate to dates, as the concept of 'Date' implies a > specific calendar, which in turn defines a frame of reference. This can be problematic. It is best to store intervals as "broken-down" time intervals -- i.e. years, monthes, days, hours, minutes, and seconds. For instance the time interval of one month is not the same as a constant number of days. For the *real* annoying problems, keep reading. > > - UniversalTime - a TimeEvent with a universal reference. GMT for > >all intents and purposes. (Does anyone know offhand what the differences > >are between GMT and UTC?) > > GMT and UTC are, as far as I know, the same thing for most purposes (there > may be some technical differences in definition, which I'd be interested to > know). The primary difference is terminology; the GMT label hasn't been > officially used for a number of years. GMT, technically, is a time zone that is no longer in use. It was last used in England, many decade ago. GMT is often used to be "synonomous" with UTC, and for ~ 1 second accuracy, it is. UTC, however, has this annoying detail of a leap second... a second inserted into the calendar about once every year or two. This means that in UTC not all minutes are 60 seconds long. Every now and then, one has 61 seconds. The situation is not to different then the one mentioned above with months. The problem is Nobody expects months to be the same length, and almost everybody expects minutes to be, including most of the OS's that will be hosting Squeak. For details, see: http://community.bellcore.com/mbr/gmt-explained.html Tim Rowledge wrote: > Take care for what you ask, Bill. If you have it available, take a > look at the code required in VisualWorks to handle this stuff. Beware, VisualWorks TimeZone class is a very rough implementation, and is incorrect for the US if you go to dates before 1987, the last time the US changed the DST rules. Having done quite a bit with Timestamps in Smalltalk, let me assure you: Timestamps should be based on UTC/GMT (the difference is irrelavent fo most applications). Using local time for the internal state of said stamps will cause nothing but headaches. And if you ever have to write code that deals with more than one time zone, you will be in *big* trouble. Having the OS/VM/Computer know about the "local" time zone, often causes people to write code that assumes this is the only relevant timezone. Next thing you know, this "default" time zone becomes a global variable riddled through your code. This is bad. The best approach I've found for Timestamp classes that wish to deal with UTC and leap seconds (as the X3J20 conformant application must), is to base the stamp internally on a 'minutes' instance variable, and use (possibly fractional) seconds only when necesary. Usually, for most applications, minutes resolution is all that is needed, and you dont need to worry about the difference between UTC and GMT. Forcing the application developer to explicity think about the seconds, either makes them aware of the problems, or prevents them from doing stupid things like using equality of timestamps to determine if something has changed. (Yes, in these days of fast computers, the response to a change can actually happen in the same second as the change was made). -- Mike Klein

1 0

Re: Language wars! (was:ANSI Smalltalk draft standard completed!)
by Dwight Hughes 22 Dec '97

22 Dec '97

|From: Joe Davison <jwdavison(a)lucent.com> | ...snip... | |It's probably more important to learn different programming paradigms than |particular languages. Different languages support different paradigms |better than others. The short list of languages I'd tell people to learn |would be something like: Lisp, Smalltalk, Snobol, and C. < Or, alternatively: Scheme, Smalltalk, Icon, and C -- and might I suggest adding a more or less "pure" functional language to the paradigm list, something like Concurrent Clean or Erlang. -- Dwight

1 0

Re: ANSI Smalltalk draft standard completed!
by AlumsHubby 22 Dec '97

22 Dec '97

I've heard Smalltalk described (fairly or unfairly) as a "dying" language and have been advised not to spend much time looking at it; C++ , my CompSci instructor declared, was the way to go in learning marketable OO skills. In the face of such opposition, I wonder how it is that people are investing the resources to get an ANSI standard in the pipeline. What are the advantages of Smalltalk over other languages...or is there a FAQ list I'm supposed to read for questions like that? I've noticed some international participation in the list. If ANSI gets a standard in place, will ISO follow suit, or is that another can of worms entirely? Thanx, Bill McClain (mailto:alumshubby@aol.com)

2 1

Re: ANSI Smalltalk draft standard completed!
by Bruce Boyer 22 Dec '97

22 Dec '97

At 10:52 AM 12/22/97 -0800, Ken Dickey wrote: >At 9:16 AM 97/12/22, Dwight Hughes wrote: >>I had no problem with the .doc format on MSWord 97 or the .pdf >>format on Adobe Acrobat Reader 3.01. > >I tried th e.pdf this morning and found it corrupt. [Netscape w Acrobat >reader 3] > I had to download twice. Once, right into the Netscape browser, came up corrupted. The second time I saved the file to disk (save this link) and it downloaded OK. Bruce ************ Bruce Boyer Updated email: bboyer(a)objectshare.com Lead Technical Writer ObjectShare, formerly ParcPlace-Digitalk, formerly Digitalk ************

1 0

Re: ANSI Smalltalk draft standard completed!
by KenD＠apple.com 22 Dec '97

22 Dec '97

At 9:16 AM 97/12/22, Dwight Hughes wrote: >I had no problem with the .doc format on MSWord 97 or the .pdf >format on Adobe Acrobat Reader 3.01. I tried th e.pdf this morning and found it corrupt. [Netscape w Acrobat reader 3] -Ken

1 0

Re: Use for TimeZones (was: Time bug under Windows)
by William O. Dargel 22 Dec '97

22 Dec '97

Tim Rowledge wrote: > Take care for what you ask, Bill. If you have it available, take a > look at the code required in VisualWorks to handle this stuff. I don't have VisualWorks to look at, so I don't know what you might be referring to here. > Then think if you really want it... > It turns out to be surprisingly tricky to deal with timezones and, > IMHO, surprisingly rarely useful. Everyone should stick to GMT > anyhow! But not everyone wears a watch that is set to GMT :-) Actually I would agree that for any application where it might matter, a universal time should be used internally. That would include apps that operate across multiple time zones, and those where durations are important even when they span changes to daylight savings time. Since "Time now" answers the local time, we immediately would have a need to handle time zones one way or another if we wanted to convert it to UTC. And since most users want to deal with things in local time, we have a general need to convert back and forth between local and universal time. I guess I don't follow why you think this would be "rarely useful". One suggestion might be to add 4 new classes (in addition to the current Time and Date). - TimeEvent - a Magnitude that specifies both a date and a time, though encoding of the implementation is open for debate. (Seconds from a base is one possibility). One-second accuracy would suit me. Provides for general support without being tied to any specific frame of reference. - UniversalTime - a TimeEvent with a universal reference. GMT for all intents and purposes. (Does anyone know offhand what the differences are between GMT and UTC?) - LocalTime - a UniversalTime plus the TimeZone it references. - TimeZone - name(s) plus a representation of the rules (including daylight savings time) needed to map between universal and local times. Comments? ------------------------------------------- Bill Dargel wdargel(a)shoshana.com Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA

1 0