Squeak-dev May 2001

squeak-dev@lists.squeakfoundation.org

143 participants
597 discussions

Re: convincing squeak to use LF instead of CR as the line separator...
by woods＠weird.com 26 May '01

26 May '01

[ On Friday, May 25, 2001 at 11:23:31 (-0500), Lex Spoon wrote: ] > Subject: Re: convincing squeak to use LF instead of CR as the line separator... > > I like the distinction, myself. "text" is something that makes sense on > every OS, but it's done slightly differently on each one. Yes of course there's a distinction between "text" and any arbitrary opaque binary format. However the distinction is all in the reader's view and it should not involve any conversion. Text data can be treated as opaque binary data just as easily and doing so should not imply any conversion either. On unix there's no underlying distinction made between text and binary content, not in the file, nor in the kernel or system calls, and not even in most of the library routines most commonly used to read and write files. IMO this is the way it should be, though of course it puts the onus on the application to make the distinction and unfortunately it seems common for non-unix applications to have the opposite view of things (i.e. to expect the underlying system to make the distinction for them). > If Squeak is > writing text, it's very nice if it can do so in the format that's > appropriate for the underlying platform. Likewise if Squeak is > *reading* text. Indeed, thus my initial post to this thread.... :-) What's most confusing in Squeak though is that it isn't internally self-consistent. I still haven't found the reason why my second go-around at running the C translator produced some source files with LF separators and the rest with CR separators.... > Already we have to do this when talking across the Internet. Squeak > can't impose it's text format on the Internet at large, and must cope > with what the Internet is using. It's the same way with files, IMO. Wire-format protocols for communications, especially those that encapsulate other forms of data (and especially any that encapsulate opaque binary data) usually have specific definitions of their line terminators (and yes here they're usually terminators, not separators). Unfortunately most Internet protocols use the worst choice: CRLF. The difference with files is that files should be stored in the host system's native format. Squeak doesn't do that in all cases, and that's bad for the host systems which have different native formats (and only slightly good for sharing files between squeak instances on different host systems). As much as I hate to say it I think Squeak could learn lots from Emacs (and Plan 9). > By the way, I'm fairly sure that text/binary distinctions on files are > much older than MS-DOS. It's "infinitely" older, at least if you consider "cards" to be text. :-) > Blurring the distinction is something Unix > does, but it isn't necessarily good -- it means that files don't have > any kind of "class" at all, and are just dumb data. On the contrary! It's very good! I think it's even necessary if you're building small "tools" to manipulate data (i.e. following what some call the "unix philosophy"). Why should a file transfer tool make any distinction between "text" and "opaque binary" formats? It should just move the data, without ever changing it. Unix isn't perfect, but most of its fault's are not in the lack of a kernel-based file classification tool, but rather in the limiting assumptions made by programmers writing the tools that run on top of that kernel. For example why should some versions of 'tr' (which an translate characters in a stream of data, and which I use to "fix" squeak files, for example) fail when they encounter a NUL character? They shouldn't but they do because their authors assumed that they would only ever handle text files. > The big advantage > of the Unix system is that the kernel becomes simpler and smaller, which > is important if your machine has only tens of kilobytes of memory, but > isn't so important now. If you want to appreciate a small and elegant kernel that does often use "text" for even low-level systems stuff then you should look at Plan 9. Indeed within Plan 9 are the fruits of lots of man-years of experience with handling multi-lingual text too! > Also, I'm fairly sure that on some OS's putting a file in "text" mode is > a bigger deal than just translating line end characters. For example, > it might involve saving the file as a list of 80-column lines, padded > with spaces at the end. :-) > But that's history. Most OS's understand text files, and Squeak gets > confronted with "text" files all the time that were editted on foreign > OS's. It's not hard to support them, but it means that text vs. binary > must mean more than characters versus bytes. My primary concern is to find a way to convince Squeak to support my native platform with its un-typed files -- then I'll deal with managing "foreign" files after that.... Squeak already does OK with text over network communications so it's probably just local files that are an issue. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

Beyond gzip
by Dan Ingalls 26 May '01

26 May '01

Here's a challenge for anyone who knows the squeak image format, and has a little time on their hands... Gzip gets just short of 50% out of a typical squeak image. It doesn't have a clue about squeak images. What do you think is possible with a scheme that has a clue? Here's the challenge: Take a Mini image (majorShrunk and abandoned sources) or the 3.0 release image, or a 3.1 alpha image full of content, and figure how small you could squeeze it if you're clever. Things that would be useful: Run printSpaceAnalysis to find out how much is in Strings, CompiledMethods, etc. Figure how many words are pointers For the pointers, figure how many are SmallInts (what ranges?), nils and other pointers. For the other pointers, how local are they (stats on + - distances) Things you'll probably find: The strings (and symbols) should be comressible nearly 4:1 using gzip The byteArrays are probably not easily compressed since most (except for sounds) are bitmaps that have already been compressed by run-coding. The bytes of CompiledMethods are probably also hard to compress, since they are already Huffman coded in an ad-hoc sort of way. An image full of content may have lots of secondary patterns, like points and rectangles that could be encoded specially. Hint: The InterpreterSimulator is a convenient tool for looking at images as data. It can read the image format, and it has a number of methods for enumerating all the objects and all their fields. It would be nice to know what's possible. If we could get a factor of four, it might be worth implementing a special compressor. If it's not that good then gzip is probably the best bet for simplicity, speed and the fact that we already have it. - Dan

1 0

RE: running directly from RAM on wince?
by Tim Rowledge 26 May '01

26 May '01

"Raab, Andreas" <Andreas.Raab(a)disney.com> is widely believed to have written: > Dan, > > > Here's another slant on this. Suppose we always gzipped the > > images. This typically saves 50%. So we would have... > > Cool idea! Dan Lanovaz did a study on this at ParcPlace some years back (and so the relative performances of the components may very well have changed since then) and his conclusions were that some machines (typically back then PCs) were much better off using zipped images andsome were much worse off. IIRC, the typical PC of the day had relatively slow disks and poor network performance, so the decompressing saved a bunch of transfer time. The unix workstations we had available typically had fast disk and network access, so did better without compresion. I imagine these days that the disk performance is much improved on most machines and of course the disk size has massively increased. Of course, there is little chance that typical fast machines would be discommoded by using zipped images, and PDAs would benefit quite a bit, and I guess it might even be helpful to use the compression checksum/whatever data to check the integrity of the image upon loading. It might be a good idea to have some sensitivity to local filing systms though - there are instances that do compression automagically and it would potentially be quite time wasting to pass them a previously compressed data stream. How about compressing the sources & changes files, like the Digitalk systems used to? On my Acorn, the sources files seem to compress ~2.5:1 which is a useful space saving. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim There can never be a computer language in which you cannot write a bad program.

2 1

Re: [GOODIE]PixelFilterMorph
by John Hinsley 26 May '01

26 May '01

Karl, this looks interesting but I get "unexpected end of file" from gunzip. Looks like it may have been mangled in the mail. I get the compressed file size as 2060. Any chance of a resend? BTW, what did you gzip this with? Cheers John -- ****************************************************************************** Marx: "Why do Anarchists only drink herbal tea?" Proudhon: "Because all proper tea is theft." ******************************************************************************

2 1

Re: web application frameworks in Squeak?
by Michael Rueger 26 May '01

26 May '01

Jimmie Houchin wrote: > > I like others am interested in server side Squeak. > > Just curious as too why Commanche is viewed as insufficient, or as to > why Apache would be superior? The trick is to have a choice: use Apache, use Comanche, or use Squeak/Comanche as an add-on for a web site whatever works best. There is so much stuff you can use when you are running Apache (e.g. SSL). Why reinvent all that? Just try to persuade a web master to get rid of his apache server and run Comanche instead. But, you could probably persuade him to add another module (Squeak/Comanche) to his configuration. This way you don't have to fight a war, you just sneek Squeak in ;-) Michael

3 2

Re: Multiple disjoint object memory in Smalltalk
by Jon Hylands 26 May '01

26 May '01

On Fri, 25 May 2001 23:56:04 -0400, "Noel J. Bergman" <noel(a)devtech.com> wrote: > In any case, I really should have been much more clear. I know how various > garbage collection schemes work, and I am not referring to the internal > segmentation of the heap by Smalltalk, generational garbage collection, etc. > I started by referring to the fact that Squeak uses a single contiguous heap > allocation, which it subdivides for its own purposes, and there is code that > relies upon the fact that this memory is contiguous. VisualWorks 5i uses disjoint memory spaces for OldSpace allocation -- it allocates (and returns) chuhks of memory from the OS as it needs them. For instance, the server application I'm working on starts at about 20 MB, and grows the image in memory dynamically up to about 2 GB, in 25 MB chunks. VW also has the ability to release memory by removing an empty OldSpace segment. As an aside, I'm very impressed that VW can handle what we're throwing at it without puking all over the place. Smalltalk rocks :-) Later, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

1 0

RE: pending file primitives (EH?)
by Raab, Andreas 26 May '01

26 May '01

Noel, How would this work? And how would it integrate with the garbage collector (which attempts to move data blocks around)? Cheers, - Andreas > -----Original Message----- > From: Noel J. Bergman [mailto:noel@devtech.com] > Sent: Friday, May 25, 2001 8:45 AM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: RE: pending file primitives (EH?) > > > John, > > If you could consider adding memory mapping for systems which > support it, > that would be WONDERFUL. I posted, last night, the outline > for doing in on > Win32/CE, and the code is similar for *nix using mmap. > > --- Noel >

2 1

Re: Can't get past update 4058?
by Fleeberz＠aol.com 26 May '01

26 May '01

In a message dated 2001-05-25 7:50:30 PM, m.rueger(a)acm.org writes: >Fleeberz(a)aol.com wrote: > >> BTW, still wondering about filing in changesets from my local directory >> (folder). >You can that, it's equivalent to downloading the updates. No, *you* can do that, *I'm* in the middle of a ride on the Clueless Express ;-) Does anyone have a 'recipe' I can type into a workspace and "DoIt" ? >> Any clues? >Hmm, I've only seen this problem on my slightly weird Win98 machine when >the socket was connected but no data came through. >Are you connected through AOL and maybe even a proxy? Didn't you know AOL *is* a proxy? It totally shields me from the entire Internet! (jusk kidding, of course; AOL's not that bad, just kind of "overloaded" it seems) Data transfers, so to speak, were definitely "happening" though. Flee

1 0

Re: Can't get past update 4058?
by Fleeberz＠aol.com 26 May '01

26 May '01

In a message dated 2001-05-25 7:24:58 PM, Andreas.Raab(a)disney.com writes: >I *know* I've seen the problem somewhere before but I can't remember exactly >where. In any case what you can do is simply close the offending window >and try to update again. IIRC then this is some timeout issue but I'm uncertain >how we dealt with it the last time around. Tried that. Again and again. All "normal" net stuff works fine in other apps within the timeframe that I'm attempting this; also, access to the server seems stable. I'll keep trying, though. I the meantime, I hope someone can recall what's happening here. =8^) Flee

1 0

Re: Can't get past update 4058?
by Michael Rueger 26 May '01

26 May '01

Fleeberz(a)aol.com wrote: > BTW, still wondering about filing in changesets from my local directory > (folder). You can that, it's equivalent to downloading the updates. > > Any clues? Hmm, I've only seen this problem on my slightly weird Win98 machine when the socket was connected but no data came through. Are you connected through AOL and maybe even a proxy? Michael -- "To improve is to change, to be perfect is to change often." Winston Churchill +------------------------------------------------------------+ | Michael Rueger m.rueger(a)acm.org ++1 (310) 937 7196 | +------------------------------------------------------------+

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
60
Older →

Jump to page: