Squeak-dev August 1998

squeak-dev@lists.squeakfoundation.org

99 participants
188 discussions

Re: Squeaking the Web
by Lex Spoon 06 Aug '98

06 Aug '98

Ahh, yes. I find those kinds of organizations faintly frustrating, myself, even when ethernet is available. Despite all the links, they are still a bit of a pain to browse around. If it's going to have that huge table of contents in the front, the whole document may as well be sent as a single HTML file. A better scheme might be an abbreviated table of contents, with just the section headings. Then you can still browse pretty quickly.... This all seems like a situation of bad layout despite good intentions. The only thing that leeps out as a bad point of HTML design, is that once you get to one of the sub-pages, your browser loses all concept that that page you are viewing is just one part of a larger document. It would be nice, for instance, to be able to get to the end of a "page", and keep scrolling on down to the next page. With better meta-information, the browser could do things like that without making you wait for the download. It could keep enough of the larger document in cache that you can scroll several pages without having to hit hte network. But there is no serious notion of multi-page constructs in HTML today. Even one of the simplest of such constructs, a linear sequence akin to the pages of a book, is not available. Lex William Barnett-Lewis writes: > Just as an FYI, the book analogy comes from sitting on the wrong end of > a 14.4 modem and having a TOC page and then having to link out to each > "chapter" and the ensuing wait. The saddest part of it is that it isn't > much better these days with a T1 here at work. Most of the time I simply > end up printing everything out because it's too annoying to try and read > the document on-line. (and don't even get me started on html "Help" or > "Documentation"... grrrr) > > W. > > Lex Spoon wrote: > (snip) > > > The biggest problem is that the whole web paradigm is such a poor way of > > > navigating through information in the first place. Using a web browser > > > is much like having to read a book by owning a whole copy of the book > > > for each page; you read the first page in the first book, then set it > > > down and pick up the next copy to read the second page, and so on. HTML > > > was designed to provide static text; nothing more. > > > > Could you explain this? Many web pages DO have a nice layout of > > textual information, and it seems to work pretty well. What are the > > kinds of pages you think are the worst? I've got my ideas, but you > > seem to have something more general in mind.... > (more snippage) > > Lex > > -- > Live without fear; your Creator loves you > as a mother. Go in peace to follow the good > road and may God's blessing be with you always. > St. Claire

1 0

Re: Native Widgets - Squeak - Cheese
by Boris G. Chr. Shingarov 06 Aug '98

06 Aug '98

Hi Joerg; I believe this subject would be of interest to the other guys so I reply in the list, ok? > 1. You strip the image from everything which does BitBlt. > ... I'm sorry my explanation of the 'dual interface' was not clear. 1. My starting point was a normal BitBlt image + UNIX VM. That compiles/runs fine on OS/2. One can use a physically separate X terminal, or use an X session in the OS/2 box. (In OS/2, sessions are much like Virtual Consoles in Linux). Normally, you always have the Presentation Manager session running. The Presentation Manager uses the same API paradigm as Windows: on Win*, you dynamically link to GDI.EXE/USER.EXE and call certain functions like CreateWindow(). In OS/2, you dynamically link to PMWIN.DLL and call WinCreateWindow() and other functions. At this stage, however, Squeak does not know anything about the Presentation Manager or DLLs. 2. So the first step was to teach Squeak what a DLL was. The design is much like VA's PlatformFunctions. When this was done, I might test it by calling int DosBeep (int freq, int duration) from the OS/2 kernel (DOSCALLS.DLL). (Here of course I'm using the original Squeak interface and tools(BitBlt)). 3. Now that I can link to whatever I want in OS/2 from the Smalltalk image, I write some Smalltalk code to call WinCreateWindow() and the other nice functions which display stuff in the native PM session. So at this moment we have a running Smalltalk with two interfaces: an X one and a PM one: +-------------------+ +----------------------+ | | | Native OS/2 | | X Screen | | Presentation Manager | | | | Screen | +-------------------+ +----------------------+ ^ ^ X Connection| | Local (TCP/IP or XSHM)+-------------+ +---------------+ API calls | | +---------------+ | Squeak | +---------------+ This is Cheese4 or BiCheese. 4. The next step was to design some platform-isolation level; that is, some widgets who may use some lower-level OS/2-specific widgets but who are themselves platform-neutral. 5. Once we have those platform-neutral widgets, we can use the descent Squeak development tools to create the Cheese Browser, the Cheese Inspector and so on. 6. Now we strip everything which is BitBlt-related. This is Cheese5; the public alpha was released on Jun 10. Now we have the question, what do we do with this Cheese5 image. All the other guys besides CheeseVM/2 are headless there. The more I think about this the more I want to design something I would call Cheese 4+5. Well of course I have my last Bi image containing all the stuff like the browsers I developed, but the stripping itself was nontrivial and brought in a lot of stuff necessary to run the C5 image alone; so 4+5 will be non-trivial but doable, and that's what I think I should pay my attention in the next week. --- > That implies that it is impossible to use a "normal" Squeak VM to > modifiy the image or changes for the native widget Squeak. Absolutely. > I wonder if it is possible to use HTTP update mechanism which ships > with Squeak 2.0. I was thinking on that. While this is definitely _possible_, I rather doubt it would be much _practical_. > Also: I always thought that if you want native widgets in a Smalltalk > environment than most of the work must be done in the VM. After reading > your comments I get the impression that most of the work is done in the > image. Absolutely right. Here is the point where Cheese deviates radically from the whole Squeak VM philosophy. In Squeak, the VM provides for a 'full virtualization' of any aspect of the hardware. You have a standard notion of the display as a two-dimensional array of pixels, and a standard set of Squeak primitives which deal with that display; it's the job of the VM to map that to whatever you actually have in your machine. Same for sound; same for networking. In contrast, the Cheese VM doesn't even suspect of any display or network at all. It provides access to 'the hardware' - the underlying OS services. So to display something on the screen or react to the mouse, or make noise with your soundcard, you need a 'driver' installed in your image. All other parts of the image rely on some standard functions described in CheeseDoc-I and implemented in the driver. For example, if you look at Cheese5, you see that each instance of Window is stuffed with a reference to an 'implementation widget'. When you say Window new you ask the VM what type of underlying host UI ('video hardware') is there (Utilities>>uiType), and the instance of the corresponding implementation class is created. > But I can't see any content in that directory [ftp.create.ucsb.edu/incoming/squeak] ftp.create.ucsb.edu/pub/Squeak/Goodies Regards, Boris

1 0

Announcement: New port of Squeak
by vuletich＠ar.ibm.com 06 Aug '98

06 Aug '98

To: squeak(a)cs.uiuc.edu cc: From: Hi Folks. HOT NEWS!!!! I have just released a new, native OS/2 port of Squeak. It can be found in our pages at SUGAR Smalltalk Users Group ARgentina. There was already a way to run Squeak in OS/2. For version 1.2 of Squeak, Boris Shingarov had done a small modification to allow OS/2 run the UNIX version, under XWindows emulation. But XWindows support isn't installed in OS/2 by default, and I haven't tried it, but I think the screen redraw speed shouldn't be good. So I thought that something better was nedded. I first tried the IBM's Open32 API, which is a Win32 API emulator. I could compile the Windows version of Squeak, but again the screen redraw speed was too slow. So I wrote an all new Squeak port, made especifically for OS/2. I used a game oriented display API from IBM called DIVE, that uses hardware acceleration to achieve fast display updates. (It somewhat similar to DirectX in Windows.) The result is a perfectly usable Squeak on my 486 machine without the need for the 'Defer Display Update' trick. I included a practical mapping of several keys. Delete behaves like Shift-Backspace (forward delete), Ctrl-Break and Esc are the interrupt keys and, Ctrl-Ins, Shft-Ins and Shft-Del manage the clipboard (emulating Alt-c, Alt-v and Alt-x). Besides all Squeak color depth are supported from 1 to 32 bit. If you select a Squeak color mode with more colors that your OS/2 desktop, color dithering will occur. This first version doesn't still have support for sound, MIDI, serial port, networking or joystick. It just has the minimum functionality for running. I will later add the rest. System requeriments: + Long file name support (install Squeak on a HPFS drive) + DIVE video dlls (Installed by default by OS/2 4, but can be added to any OS/2) + Video mode with at least 256 colors, and support for DIVE (most drivers should work) Read about it and download it from http://www.sugarweb.com/squeak/ports/os2native/os2english.htm Write me with bug reports, suggestions and comments. Enjoy! Juan Manuel Vuletich jvuletic(a)dc.uba.ar

2 1

Re: Squeaking the Web
by Roland Jesse 06 Aug '98

06 Aug '98

Lex Spoon wrote: > 2) Having other kinds of links is also quite useful! It's a nice > blend of structure and freedom. Random links should definately stick > around in a newer system. What are these supposed to do? Can you elaborate that a bit further, please? > Thus the web today has less accessible > information content than it could if all the flashy pages were cleaned > up. IMHO it is not mutually exclusive to have both - some good and fancy design and a wide accessibility (even to disabled people). The style sheets as they are in the HTML 4.0 Specification (http://www.w3.org/TR/REC-html40/) are a good step in the right direction. There is not always a need to reinvent the wheel just to make this world and its web a better place. ;-) > 6) Surfing is possible. People can end up reading things only > tentatively related to where they started. This is much like creative > thought in general.... You read Jay David Bolter's "Writing Space. The Computer, Hypertext, and the History of Writing", did you? ;) > Do links *really* need to be all that human readable? Of course not. I do not have the source at hand right now, but Tim Berners-Lee said once that when he designed the web he did not imagine people writing HTML code by hand and having a need of nice and fancy URLs. All this was supposed to be hidden information that a user does not need to care about. Roland

2 1

Re: Squeaking the Web
by O'NEEL Bruce 05 Aug '98

05 Aug '98

[I've kept this on the list because this, in spite of the topic drift, it still seems relevent to the design discussion] Well, you're probably right. There needs to be a very careful balance between too complex and too simple. The URL is bloody simple and therefore everyone and their brother can hack together some HTML with URLs and volia, they are a web publisher. This has helped the web grow... I still can't get the RFC, so, this is from my past (faulty and failing memory) but the URN concept requires a bit of support structure. You need "official" sources for your URNs and you need URN servers, etc. That works well for DNS, but, you end up needing quite a mgmt structure to support it. With URLs you, the publisher are the offical source. I had the glimmers of a clever solution here, but, I've spent the day with C++ and the brain is suffering. The problem comes up that you don't know who's linked to you, and, therefore if you change the location of anything you have no way of notifying anyone. Once you have a page that you've linked into anywhere in the web you've made that URL public. You can keep everything forever and use redirects to keep the outside links working as you update your internal structure, but, boy is that messy. Oh well. cheers bruce Mark Guzdial writes: > >Lex Spoon writes: > > > > > > 2) Links are so easily broken. Maybe *all* links should go > > > through a level of indirection on a stable server? Do links *really* > > > need to be all that human readable? > > > > > > >Actually, this was the origional idea. URLs were a quick hack until > >URNs worked. URNs were going to work a bit like DNS does with a > >distributed database so you would not have broken links and give you > >that extra level of indirection. Hmm, this was '94 or so :-) > > On the other hand, I've read some analysis (armchair quarterbacks, I admit > :-) that suggest that the Web succeeded where previous hypertext efforts > failed (e.g., Intermedia, Xanadu) explicitly because URL's were > one-direction only. All previous efforts made sure that links couldn't > break, and this analysis claims that that extra bit of engineering is what > pushed the system over the edge to overly-large and less-adoptable. > > Mark > > -------------------------- > Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 > (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu > http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html > >

1 0

Re: On the list itself
by Lex Spoon 05 Aug '98

05 Aug '98

Hmm, okay. Still, if you set your filters up otherwise, the [squeak]'s just take up extra screen space. The subject line is for the subject of the message, durnit. Even "Re:" is a tad silly--what's the difference between "Re:" and "Subject" anyway? Lex Roland Jesse writes: > Lex Spoon wrote: > > On the other hand, one can end up with nasty subjects like > > > > [squeak] Re: [squeak] re: [squeak] some topic > > Nope. Majordomo only inserts the subject_prefix string (here: [squeak]) > when it is not already in the subject line. > > Roland >

2 1

On the list itself
by PerHenning.Isaksen＠marintek.sintef.no 05 Aug '98

05 Aug '98

I have just subscribed to the squeak list, and would really like a change, if the rest of you agree. Due to the amount of junk mail, I like all my mail to be easy to classify. It is very difficult with the squeak list as the From: field contain the real sender. It would be much easier if it was set to 'squeak(a)cs.uiuc.edu'. That I can recognize immedeately, and this is also done on other lists. (if I do not recognize the sender or the subjet, that e-mail is _defined_ as junk, and it is deleted unread) What do you think? pH

5 4

Re: Bug tracking
by Mark Wai 04 Aug '98

04 Aug '98

At 10:49 PM 8/3/98 -0700, Dan Ingalls wrote: >If a method has a bug, add the line > self flag: #knownBug. "Brief comment about the problem" > > self flag: #noteToJohn. "Will this work OK with flexed coordinates?" > Just curious, why you need to do self flag: #knowBug instead of just put down the symbol (i.e. just have #knowBug in a line)? What is the use of >>flag: ? Thanks. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

2 1

Re: Bug tracking
by jim benson 04 Aug '98

04 Aug '98

Dan Ingalls wrote: > A long time ago, Scott Wallace came up with a simple, yet effective > way to mark methods for further attention, using the leverage of > Squeak's existing search mechanisms. > > If a method has a bug, add the line > self flag: #knownBug. "Brief comment about the problem" > I have found this thread interesting. This , and similar methodologies, seems to be the way that Smalltalk folks keep track of their bug To Do list. A simple and understandable solution. Yet, in the Smalltalk books that I have read, I have not seen any mention of this. Debugging, the hardest and most expensive part of the programming cycle, is only spoken about in private. > Finally, within our group, depending on how closely-coupled we are > working, we have used this mechanism to impute a request for > attention, by patterns such as > self flag: #noteToJohn. "Will this work OK with flexed > coordinates?" My favorite trick here is to make a typo, i.e. #notetoJohn. How do you circumvent that type of problem? Before releasing an image, do you browse all senders of flag: ? I know, Tim Rowledge would say not to put typos in my code :-P ) Thanks for the advice, Jim

1 0

Re: Bug tracking
by Mark Wai 04 Aug '98

04 Aug '98

At 11:56 AM 8/4/98 -0400, you wrote: >One reason might be to enable finding ALL flags by browsing senders of #flag:. You could also reimplement Object>>flag: (in Object or at a lower level) to record when flagged methods are actually evaluated. > Thanks and I knew that. But you could use browse references to accomplish the same thing. But no doubt that by using >>flag: you could include all the different flagged symbols easily as well as gives you more flexibility. Sorry for the dumb question. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

1 0

Jump to page: