rich@inmet.inmet.com (12/07/89)
I am writing a programming environment (a smalltalk that is derived from
Tim Budd's Little Smalltalk, but faster) for Ami. I have some questions
about the windowing/event interface:
Normally, a program skeleton looks like this:
w = OpenWindow(...);
for (;;)
{
if (!(msg = GetMsg(w->UserPort)))
WaitPort(w->UserPort);
else if (handleEvent(msg))
break;
}
What happen if a program opens multiple windows and each one ants to wait
for some events? How does one code that?
In my situation, windows are created dynamically. For example, by the
system interface functions (or by user programs). Does the answer(s) to
the previous question work in this situation too?
Finally, I am using ConMan's feature of opening a window as a file handle
by calling Open() with file name "con:wXXXX" where XXXX is the address of
the opened window. I found that if I call CloseWindow() and not Close(),
the program loses some bytes each time it executes. If the program calls
both, then it Gurus. Looks like the solution is to call Close() only. Is
this a ConMan feature? or Is this a bug?
Thanks for any info.
Richard Man
!uunet!inmet!richjellson@stsusa.com (12/07/89)
In article <4688@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > In article <29800002@inmet> rich@inmet.inmet.com writes: >> I am writing a programming environment (a smalltalk that is derived from >> Tim Budd's Little Smalltalk, but faster) for Ami. > > Cool. Seconded. [useful looking code fragments deleted] > >> Finally, I am using ConMan's feature of opening a window as a file handle >> by calling Open() with file name "con:wXXXX" where XXXX is the address of >> the opened window. > > Please don't do this. There are ways of attaching a console device to a window, > and I'm sure that someone will come up with one for you. If you depend on > ConMan, you'll be unable to run your program on any system that doesn't have > it. For something like Smalltalk, that'd be too bad. > -- Ok, so don't depend on ConMan, but if it is there please support it. I really miss ConMans line editing and history functions in the XLISP environment. --- John Ellson ellson@ontap.stsusa.com
peter@sugar.hackercorp.com (Peter da Silva) (12/07/89)
In article <29800002@inmet> rich@inmet.inmet.com writes: > I am writing a programming environment (a smalltalk that is derived from > Tim Budd's Little Smalltalk, but faster) for Ami. Cool. > w = OpenWindow(...); > for (;;) > { > if (!(msg = GetMsg(w->UserPort))) > WaitPort(w->UserPort); > else if (handleEvent(msg)) > break; > } First of all, do this: for(;;) { if(msg = GetMsg(w->UserPort)) if(handleEvent(msg)) break; if(!msg) Wait(1<<w->UserPort->mp_SigBit); } > What happen if a program opens multiple windows and each one ants to wait > for some events? How does one code that? Say you have a null-terminated array of windows, w: bits = 0; for(i = 0; w[i]; i++) bits |= 1<<w->UserPort->mp_SigBit; for(;;) { for(i = 0; w[i]; i++) if(msg = GetMsg(w->UserPort)) { if(handleEvent(msg)) goto break2; break; } if(!msg) wait(bits); } break2: /* So sue me for using a goto. I wanted to make it match his code * pretty closely. This was the cleanest way. */ > Finally, I am using ConMan's feature of opening a window as a file handle > by calling Open() with file name "con:wXXXX" where XXXX is the address of > the opened window. Please don't do this. There are ways of attaching a console device to a window, and I'm sure that someone will come up with one for you. If you depend on ConMan, you'll be unable to run your program on any system that doesn't have it. For something like Smalltalk, that'd be too bad. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
waggoner@dtg.nsc.com (Mark Waggoner) (12/08/89)
In article <4688@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <29800002@inmet> rich@inmet.inmet.com writes: (among other things) >> I am writing a programming environment (a smalltalk that is derived from >> Tim Budd's Little Smalltalk, but faster) for Ami. ... >> What happen if a program opens multiple windows and each one ants to wait >> for some events? How does one code that? > >Say you have a null-terminated array of windows, w: > > bits = 0; > for(i = 0; w[i]; i++) > bits |= 1<<w->UserPort->mp_SigBit; > for(;;) > { > for(i = 0; w[i]; i++) > if(msg = GetMsg(w->UserPort)) { > if(handleEvent(msg)) > goto break2; > break; > } > if(!msg) > wait(bits); > } >break2: /* So sue me for using a goto. I wanted to make it match his code > * pretty closely. This was the cleanest way. > */ You can also use just one signal bit for all the windows you open. This is fairly well documented in the old intuition manual and the newer (blue) rom kernal manual. You basically open each new window with NO IDCMP flags. Then, copy the w->UserPort from an already open window, or from a port you have already opened, to the UserPort of the new window. Now, use ModifyIDCMP to set the flags you want. Then, before closing the window, NULL the UserPort so it doesn't get closed and deallocated by CloseWindow. This is the only way to support an arbitrarily large number of windows. You must use the WindowPtr field of the IDCMP messages to distinguish which window the message came from and process it accordingly. These posters that make you write more than you include are a pain. -- ,------------------------------------------------------------------. | Mark Waggoner (408) 721-6306 waggoner@dtg.nsc.com | `------------------------------------------------------------------'
peter@sugar.hackercorp.com (Peter da Silva) (12/08/89)
In article <375@icebox.nsc.com> waggoner@icebox.UUCP (Mark Waggoner) writes: > You can also use just one signal bit for all the windows you open. Yes, but that's more complex. I've done that, but there are quite a few ways you can go wrong and GURU yourself. For a first cut, it's not needed. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
peter@sugar.hackercorp.com (Peter da Silva) (12/08/89)
In article <6377@stsusa.com> jellson@stsusa.com writes: > Ok, so don't depend on ConMan, but if it is there please support it. I really > miss ConMans line editing and history functions in the XLISP environment. I thought ConMan was a straight drop in for CON:, just like NEWCON: is. If that's the case, why wouldn't you have access to it from Xlisp? -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
jellson@stsusa.com (12/08/89)
In article <4699@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > In article <6377@stsusa.com> jellson@stsusa.com writes: >> Ok, so don't depend on ConMan, but if it is there please support it. I really >> miss ConMans line editing and history functions in the XLISP environment. > > I thought ConMan was a straight drop in for CON:, just like NEWCON: is. If > that's the case, why wouldn't you have access to it from Xlisp? > -- > Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> > `-_-' > 'U` "Really, a video game is nothing more than a Skinner box." > -- Peter Merel <pete@basser.oz> -- Peter, You clearly know much more than I do about this topic so forgive me if I am all screwed up here. I messed around with XLISP (can't remember version number) for some time trying unsuccessfully to get CONMAN to work with it and I thought the reason it didn't work was because it used the RAW: device for console I/O. Since I posted the last comment somebody sent me a replacement source fragment for XLISP that uses NEWCON: instead so possibly there are versions of XLISP out there that do support ConMan. The purpose of my posting though wasn't really to discuss XLISP, it was more a plea to build on the capabilities of ConMan rather to replace it. IMHO ConMan provides the most useful and flexible command line environment that I have ever used - which includes Unix, VMS, and VM/CMS, but not I must admit, Smalltalk. You seemed to suggest in your later posting that Smalltalk would be built on a full-screen editing user interface. If that's so then I can see how some features of ConMan would get in the way, the arrow keys for instance. ----- John Ellson ellson@ontap.stsusa.com 602-395-5281 Siemens Transmission Systems, 8620 N 22nd Ave, Phoenix AZ 85021 /// "Are you insinuating that my brain consists /// If my employers had my of, at bottom, just a bunch of ants running \\\/// opinions then they wouldn't around?" Douglas R. Hofstadter. \XX/ need me, would they?
33014-18@sjsumcs.sjsu.edu (Eduardo Horvath) (12/08/89)
In article <4688@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <29800002@inmet> rich@inmet.inmet.com writes: >> I am writing a programming environment (a smalltalk that is derived from >> Tim Budd's Little Smalltalk, but faster) for Ami. >Cool. [gulp...] >> Finally, I am using ConMan's feature of opening a window as a file handle >> by calling Open() with file name "con:wXXXX" where XXXX is the address of >> the opened window. > >Please don't do this. There are ways of attaching a console device to a window, >and I'm sure that someone will come up with one for you. If you depend on >ConMan, you'll be unable to run your program on any system that doesn't have >it. For something like Smalltalk, that'd be too bad. The Open() function is an AmigaDos function, as opposed to an Intuition function. It tries to open a file. When it asks the console device for the file, the console device opens the window and attatches the current console handler to it, whether the handler is the old con:, the arp con:, or conman's con:. The program will run either with or without conman, but the interface will change. Generic, unadulterated console handlers are such a pain! There is also a technique for opening an Intuition window, and attatching a console device to it (I think I saw it in the Intuition manual v1.1). This will also give you the resident console handler. It is debatable whether you want to use a console handler at all. Remember that relying on it will cause unpredictable changes in the environment you are creating. You might want to just write your own, if you want to support cut/paste, the clipboard, or "full screen editing", because you will be forced to deal with the window as a file, and will not be able to cursor up to edit parts of a program. ( I am make an assumption here that may not be accurate. If the con: is just for program I/O please ignore this part.) >-- >Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> >`-_-' > 'U` "Really, a video game is nothing more than a Skinner box." > -- Peter Merel <pete@basser.oz> --- Eduardo Horvath | Director, Campaign to Free Doctor Science Send your contributions to: 33014-18@sjsumcs.SJSU.EDU "Why don't you stop your whining, and get back to work!" - Doctor Science
usenet@cps3xx.UUCP (Usenet file owner) (12/09/89)
In article <4697@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <375@icebox.nsc.com> waggoner@icebox.UUCP (Mark Waggoner) writes: >> You can also use just one signal bit for all the windows you open. > >Yes, but that's more complex. I've done that, but there are quite a few ways >you can go wrong and GURU yourself. For a first cut, it's not needed. Ok Peter, that is the second time you have said this. I did exactly this and found it to be quite easy, and I never had any gurus directly related to sharing SIGBITS. You just have to be careful to not depend on 1-signal per event. Of course you must use CloseWindowSafely() if you share a MsgPort between windows or other things. Please explain what you do to make it GURU. Joe Porkka porkka@frith.egr.msu.edu
waggoner@dtg.nsc.com (Mark Waggoner) (12/09/89)
In article <4699@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I thought ConMan was a straight drop in for CON:, just like NEWCON: is. If >that's the case, why wouldn't you have access to it from Xlisp? The method he was using to connect ConMan to the window is supported only by ConMan, not by CON: or NEWCON:. It is much easier than the methods you would need to use to connect a console handler to a window. It would mean, however, that you would HAVE to be using ConMan. -- Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com Unofficialy representing National Semiconductor Local Area Networks Group Officially misrepresenting myself.
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (12/09/89)
In article <6447@stsusa.com> jellson@stsusa.com writes: >In article <4699@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >> I thought ConMan was a straight drop in for CON:, just like NEWCON: is. If >> that's the case, why wouldn't you have access to it from Xlisp? > You clearly know much more than I do about this topic so forgive me if >I am all screwed up here. I messed around with XLISP (can't remember version >number) for some time trying unsuccessfully to get CONMAN to work with it and >I thought the reason it didn't work was because it used the RAW: device for >console I/O. This is true. Back in the XLISP days, David Betz was into processing raw keyboard events himself. XLISP opened its own raw: window, did all the keyboard processing for line editting, and periodically polled the keyboard for input to see if any interrupt characters had arrived. Since then, judging from the XSCHEME code, he's decided that at least on some systems (e.g. Unix), it's ok to let the system worry about those things. I don't know if the amiga interface for XSCHEME uses raw:, since I've never seen the amiga code--I use the unix code, which doesn't do anything strange, and is trivial to port to any C compiler that has a decent io library and signal(). -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
peter@sugar.hackercorp.com (Peter da Silva) (12/11/89)
In article <377@icebox.nsc.com> waggoner@icebox.UUCP (Mark Waggoner) writes: > In article <4699@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >I thought ConMan was a straight drop in for CON:, just like NEWCON: is. If > >that's the case, why wouldn't you have access to it from Xlisp? > The method he was using to connect ConMan to the window is supported > only by ConMan, not by CON: or NEWCON:... I *know* that much. However he implied that he couldn't use ConMan from Xlisp for some reason. I'm inquiring as to what that reason might be. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
peter@sugar.hackercorp.com (Peter da Silva) (12/11/89)
In article <6447@stsusa.com> jellson@stsusa.com writes: > The purpose of my posting though wasn't really to discuss XLISP, it was > more a plea to build on the capabilities of ConMan rather to replace it. The problem is that ConMan isn't universally available. If your Smalltalk depends on having ConMan available it will reduce its utility. The ultimate console device has yet to be written. I've been thinking about doing something along those lines, but I really don't want to figure out all the details of writing a console handler myself. I know there are several out there... howcome none have been made publically available? > You seemed to suggest in your later posting that Smalltalk would be built > on a full-screen editing user interface. That wasn't me. Really, though, a Smalltalk UI should bear some relation to the *real* Smalltalk UI. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"