00:00:00 --- log: started forth/03.08.03
03:32:04 --- join: mur (murr@baana-62-165-189-186.phnet.fi) joined #forth
03:54:03 --- join: ma] (markus@lns-p19-6-81-56-102-21.adsl.proxad.net) joined #forth
03:55:03 <ma]> does isforth still use xchg with memory dst or src?
06:41:56 --- nick: mur -> murbbl
07:02:04 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth
07:20:49 --- nick: murbbl -> mur
08:36:05 --- nick: rk -> arke
08:37:17 --- nick: arke -> rk
09:17:31 --- join: gilbertdeb (gilbert@fl-nken-u2-c3b-118.miamfl.adelphia.net) joined #forth
09:50:49 <Herkamire> my colorforth editor works! weeeeeee
09:51:11 <Herkamire> except that you can't edit the first word in each block...
09:51:25 <Herkamire> time for a victory lunch. bbl
09:56:47 --- nick: mur -> mur_willbeback
09:59:53 --- quit: ma] (Read error: 60 (Operation timed out))
10:00:10 --- join: ma] (markus@lns-p19-6-81-56-102-21.adsl.proxad.net) joined #forth
10:01:04 --- join: kc5tja (~kc5tja@ip68-8-127-122.sd.sd.cox.net) joined #forth
10:01:04 --- mode: ChanServ set +o kc5tja
10:01:22 --- join: jma (jma@dialup-67.31.137.206.Dial1.Denver1.Level3.net) joined #forth
10:24:25 --- nick: mur_willbeback -> mur
12:05:08 --- quit: Herkamire ("leaving")
12:37:01 --- quit: ma] (Read error: 60 (Operation timed out))
12:42:32 --- quit: gilbertdeb ("<--- off to play in the dirt.")
12:45:15 --- join: gilbertdeb (gilbert@fl-nken-u2-c3b-118.miamfl.adelphia.net) joined #forth
12:45:26 <kc5tja> wb gilbertdeb
12:45:33 <gilbertdeb> thanks.
12:46:19 <kc5tja> All that talk yesterday about GEM and its architecture got me to thinking.
12:46:36 <gilbertdeb> whats the though?
12:46:40 <gilbertdeb> thought*
12:46:45 <kc5tja> Since I'm using SDL to write FS/Forth for Linux, I figured I might as well go ahead and implement my event-driven system from first steps.
12:47:00 <gilbertdeb> whats sdl again? 
12:47:02 <gilbertdeb> a new library?
12:47:08 <kc5tja> It's been around for years.  :)
12:47:12 <kc5tja> Remember Loki games for Linux?
12:47:13 <kc5tja> :)
12:47:16 <kc5tja> They wrote it.
12:47:17 <gilbertdeb> yes them.
12:47:19 <gilbertdeb> oh okay.
12:47:33 <kc5tja> SDL is kind of like DirectX in Windows, only easier to use.
12:47:42 <kc5tja> It makes programming in Linux fun again.
12:48:19 <kc5tja> Anyway, since I'll have my own framebuffer to play with, and an incoming event stream, it makes sense to build my Forth around an event driven model.
12:50:05 <gilbertdeb> so FS/Forth will have gui building tools just as k or java or rebol do?
12:50:21 <kc5tja> If you're willing to write them.
12:50:24 * kc5tja certainly isn't.
12:50:29 <kc5tja> I don't have any need for them.
12:50:30 <gilbertdeb> emm.
12:50:31 <kc5tja> Yet, at least.
12:50:47 <kc5tja> but the core of any GUI is an event dispatcher.
12:50:57 <kc5tja> And that's the component that I'll make available in FS/Forth first and foremost.
12:51:05 <kc5tja> I might have SOME graphics primitives, but not a whole lot.
12:51:28 <kc5tja> Although, you never know.
12:51:50 <gilbertdeb> if i ever get plan9 installed on any of these machines I'm gonna take a very good look at their graphics/gui primitives.
12:51:51 * kc5tja has always wanted to play with scene-graph-based GUIs, and scene-graphs would be relatively easy to build in Forth.
12:52:04 <gilbertdeb> from what I've seen they look straightforward.
12:52:25 <kc5tja> 8.5 (damn them for using a non-ASCII character in the name) was extremely simple, as I recall.
12:52:36 <kc5tja> Another very simple GUI (available for Linux I believe) is called MGR.
12:52:43 <kc5tja> I think Plan9 got some of its concepts from MGR.
12:52:49 <gilbertdeb> heheh. rio is its new replacement.
12:52:51 <kc5tja> err, 8.5 even
12:53:01 <gilbertdeb> MGR?
12:53:04 <kc5tja> Is rio software compatible with 8.5 software?
12:53:09 <gilbertdeb> yes.
12:53:20 <kc5tja> OK, so rio is just 8.75 then.  ;D
12:53:24 <gilbertdeb> hehehe
12:53:33 * kc5tja will use rio from now on.  It's easier to type.
12:53:39 <gilbertdeb> yes I guess you can say that.
12:53:54 <kc5tja> http://www.ibiblio.org/pub/Linux/apps/MGR/!INDEX.html
12:54:03 <gilbertdeb> there isn't such a significant difference as to have warranted a paper on it by pike et al.
12:55:11 <kc5tja> I recall liking the basic concept behind 8.5.
12:55:20 <kc5tja> What I didn't like was the actual user presentation.
12:55:46 <gilbertdeb> it is pretty simple (from a users perspective).
12:56:48 <kc5tja> I like its programming interface much more than I like its user presentation.
12:56:57 <kc5tja> Oooh, I found a HOWTO on MGR.
12:57:05 <kc5tja> http://www.linux.org/docs/ldp/howto/MGR-HOWTO.html
12:57:30 <kc5tja> There's a section on how 8.5, X11, and MGR compares to each other too.
12:57:44 <kc5tja> If 8.5 is on one end of the spectrum, and X11 on the other, then MGR fits right in the middle.
12:57:53 <gilbertdeb> MGR is kinda hard to find.
12:58:04 <gilbertdeb> if i ever create a language, I'll give it an unusual name.
12:59:07 <kc5tja> MGR appears to be the standard GUI for OS9.
12:59:18 <kc5tja> If that's so, then MGR is awfully, awfully old.  :)
12:59:27 <kc5tja> Which might explain why it's relatively hard to find (few people use it)
12:59:38 <gilbertdeb> OS9?
12:59:43 <gilbertdeb> of apple fame?
13:00:24 <gilbertdeb> heh -> requires Linux 0.99.10
13:00:36 <gilbertdeb> when in christmas past did you find MGR?
13:01:25 <mur> os9 is MACOS!
13:01:57 <mur> but it's cool anyways
13:01:58 <mur> :)
13:02:32 <kc5tja> os9 is not MacOS.
13:02:38 <mur> :P
13:02:40 <mur> :/
13:02:50 <mur> do you mean the IBM computers?
13:03:11 <kc5tja> I mean the OS/9 embedded OS that ran on TRS-80 Color Computers, among other things.
13:03:19 <mur> oh that os :)
13:05:15 <kc5tja> Yes, that OS/9.  :)
13:06:57 <gilbertdeb> there are a few on ebay.
13:07:44 <gilbertdeb> but Atari used to make one of these machines (with atari basic) that connected to the TV.
13:07:51 <gilbertdeb> kc5tja: do you know anything about those?
13:08:13 <gilbertdeb> a friend had one, and we used to play mountain king on there via cassete tape.
13:08:35 <gilbertdeb> looked just like the trs-80
13:08:49 <kc5tja> A few what?
13:08:56 <kc5tja> Atari systems never ran OS/9 as far as I know.
13:09:12 <gilbertdeb> heheh. no I mean the machines looked the trs-80 color.
13:09:42 <kc5tja> I'm sorry -- that last sentence really doesn't make any sense to me.
13:09:56 <kc5tja> Start over.  :)
13:09:58 <gilbertdeb> okay.
13:10:13 <gilbertdeb> atari made a computer with the keyboard attached to the cpu box.
13:10:29 <gilbertdeb> do you happen to know what they were called?
13:10:34 <gilbertdeb> model etc?
13:15:05 <gilbertdeb> ah I think it was an atari 800.
13:19:54 <kc5tja> There are many
13:20:07 <kc5tja> There is the 800, 800XL, 800XE, 1200, 1200XL, 1200XE, 1400, 1400XL, ...
13:20:18 <kc5tja> None of these ran OS/9 though.
13:20:30 <kc5tja> The Atari ST ran GEM though.
13:21:02 <gilbertdeb> yeah, I was referring mainly to their morphology.
13:21:32 <gilbertdeb> which reminds me. there are z80's in the TI calculators right?
13:25:02 <kc5tja> Most models, yes.
13:25:12 <kc5tja> The TI-89 and TI-92 both have 68000s.
13:39:22 <kc5tja> Hmmmm
13:39:31 * kc5tja LIKES the MGR communications model.
13:39:43 <kc5tja> I can see why they compare MGR to 8.5
13:39:59 <kc5tja> Graphics primitives and such are all performed through stdin and stdout.
13:40:38 <kc5tja> A MGR command starts with a special escape character, followed by the parameters for the command (comma deliminated), followed by a character which actually invokes the command.
13:41:18 <kc5tja> The interesting thing is that it enables an MGR command to be piped through other filters.
13:41:33 <gilbertdeb> you can do that with rio/8.5 too.
13:41:36 <gilbertdeb> plumbing etc.
13:41:38 <kc5tja> And MGR programs run in the window they're given as far as I can see.
13:42:03 * kc5tja was not happy with Plan/9's idea of plumbing.  Too complex.
13:42:20 <cleverdra> as opposed to a SGR command that starts with a special character, followed by the parameters for the command (semicolon seperated), followed by a character which actually invokes the command.
13:44:11 <gilbertdeb> SGR?
13:44:36 <gilbertdeb> programs in plan9/rio also run in the terminals they're given.
13:44:40 <cleverdra> AKA 'console codes'.  \e[31m to turn text red, \e[2J to clear all of the screen
13:45:58 <kc5tja> cleverdra: SGR codes are too complex to even fathom writing a state machine for; but the idea is similar, yes.
13:46:13 <cleverdra> hm?  They're not that complex.
13:46:27 <kc5tja> Ever write a complete VT100 console handler?  :)
13:46:35 <cleverdra> \e [ number ; number ; number ... letter
13:46:41 <kc5tja> Not always true.
13:46:56 <kc5tja> There are other command sequences that don't always require the '[' code.
13:47:27 <cleverdra> there are *input* sequences that don't match that, but I've never heard nor smelled an output sequence that was otherwise... but OK.
13:47:47 <kc5tja> Hey, don't complain to me -- complain to ANSI.
13:48:10 <cleverdra> whine: but ANSI isn't *here*!
13:48:19 <cleverdra> also, I said 'OK' =)
13:50:14 --- quit: jma (Read error: 60 (Operation timed out))
13:55:43 <kc5tja> Shoot.  MGR won't compile on my box.
13:55:45 <kc5tja> Oh well.
13:56:02 <kc5tja> Looking through the sources, it's a pretty basic system.
13:56:16 <kc5tja> In some respects, it's even more basic than GEM.  :)  And GEM is awfully basic.  :)
13:56:48 <gilbertdeb> are you serious?
14:02:08 <kc5tja> Yup.
14:03:21 <kc5tja> Just looking at the mgr.h file, it's pretty simple to reproduce most, if not all, of MGR's functionality by rewriting MGR to use more modern environments (e.g., VNC, SDL, X11, or some such)
14:36:36 <mur> terve gilbertdeb, muuten
14:36:46 <gilbertdeb> terve mur
14:45:39 --- join: Frek (~anvil@81-216-25-254.man2.calypso.net) joined #forth
15:05:31 --- quit: onetom (orwell.freenode.net irc.freenode.net)
15:05:32 --- join: onetom (~tom@novtan.bio.u-szeged.hu) joined #forth
15:27:43 <kc5tja> Doh -- that would certainly explain why it won't compile on my box.  Header files are completely missing.  >:(
15:27:53 <gilbertdeb> hehhehe
15:28:13 <gilbertdeb> kc5tja: I think you need a slow thinking assistant to do your legwork for you.
15:28:39 <kc5tja> What's that supposed to mean?
15:29:35 <gilbertdeb> it means you need an assistant.
15:30:26 <gilbertdeb> just as physical scientists need lab assistants.
15:30:30 <gilbertdeb> no different.
15:42:23 * kc5tja can't afford one unfortunately.
15:44:25 <mur> afford what?
15:44:32 <gilbertdeb> an assistant.
15:50:34 --- join: jma (jma@dialup-67.31.137.171.Dial1.Denver1.Level3.net) joined #forth
15:56:29 --- quit: Frek (orwell.freenode.net irc.freenode.net)
15:56:29 --- quit: XeF4 (orwell.freenode.net irc.freenode.net)
15:56:30 --- quit: TreyB (orwell.freenode.net irc.freenode.net)
15:57:17 --- quit: mur ("MURR! save the http://rainforest.care2.com/")
15:59:28 --- part: gilbertdeb left #forth
16:01:36 --- join: XeF4 (xef4@lowfidelity.org) joined #forth
16:01:49 --- quit: XeF4 (orwell.freenode.net irc.freenode.net)
16:01:49 --- quit: kc5tja (orwell.freenode.net irc.freenode.net)
16:01:49 --- quit: skylan (orwell.freenode.net irc.freenode.net)
16:01:49 --- quit: \\\ (orwell.freenode.net irc.freenode.net)
16:08:19 --- quit: jma (orwell.freenode.net irc.freenode.net)
16:08:20 --- quit: ian_p (orwell.freenode.net irc.freenode.net)
16:12:48 --- log: started forth/03.08.03
16:12:48 --- join: clog (nef@bespin.org) joined #forth
16:12:48 --- names: list (clog ian_p @ChanServ XeF4)
16:12:56 --- join: rk (~rk@ca-cmrilo-docsis-cmtsj-b-36.vnnyca.adelphia.net) joined #forth
16:17:36 --- join: skylan (sjh@vickesh01-4919.tbaytel.net) joined #forth
16:29:44 --- join: kc5tja (~kc5tja@ip68-8-127-122.sd.sd.cox.net) joined #forth
16:29:44 --- mode: ChanServ set +o kc5tja
17:29:58 --- join: sic (~shadow@205.247.28.94) joined #forth
18:02:32 --- join: TheBlueWizard (TheBlueWiz@pc5fdn1d.ppp.fcc.net) joined #forth
18:02:33 --- mode: ChanServ set +o TheBlueWizard
18:02:37 <TheBlueWizard> hiya all
18:03:29 --- join: TreyB (~trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth
18:03:31 <kc5tja> re
18:04:15 <TheBlueWizard> hiya kc5tja
18:04:20 <TheBlueWizard> hiya TreyB
18:04:26 <TreyB> Howdy.
18:04:35 <TreyB> !@#$% IRC server problems.
18:05:02 <TheBlueWizard> kc5tja: I forgot to ask -- how do you like Ozy and Millie strips? I suppose you read all of them by now
18:05:34 * TheBlueWizard joins TreyB in grrr'ing at the IRC servers...he likes to grr at everything ;)
18:07:29 <kc5tja> I love 'em.
18:07:39 <TheBlueWizard> :)
18:07:49 * kc5tja also caught up with Schlock Mercenary too.
18:08:03 <TheBlueWizard> never heard of it
18:08:13 <kc5tja> It's an interesting comic strip.
18:08:21 <TheBlueWizard> URL?
18:08:35 <kc5tja> Never a dull moment.  BUT, you simply must read it from the beginning if you're going to understand anything about it.
18:08:41 <kc5tja> http://www.schlockmercenary.com
18:09:17 * kc5tja was trying to get MGR to compile today, but alas, it's missing quite a number of header files from its source distribution.
18:09:26 <kc5tja> And, apparently, not a single person out there today has these header files.
18:09:36 <TheBlueWizard> ok, I will read it from beginning then.  I also enjoy Kevin and Kell
18:09:49 <TheBlueWizard> MGR?
18:10:39 <kc5tja> It's a small window manager and simple GUI system.
18:10:45 <kc5tja> Not X.
18:11:25 <kc5tja> 200K for a monochrome 1159x900 display with about 8 windows open running on a SUN Sparc box of some kind.
18:11:46 <kc5tja> Basically, it works by creating a new terminal type -- the MGR terminal.
18:11:48 <TheBlueWizard> pretty compact!
18:12:03 <kc5tja> So normal programs just print to it like any other terminal.
18:12:16 <kc5tja> But it doesn't support the ANSI control codes; it has its own set of control codes.
18:12:26 <kc5tja> These codes permit basic window management, event notification features, etc.
18:12:37 <kc5tja> Not so much compact as it is simple.
18:12:40 <TheBlueWizard> hmm...I never have heard of this MGR...where does it originated?
18:12:46 <kc5tja> MGR just sticks to its roots.
18:13:04 <kc5tja> A company called Bellcore made it.
18:13:35 <TheBlueWizard> hmm....never heard of that company...gee, I must be living inside a cave
18:14:27 <kc5tja> Bellcore is who made ATM too.  :)
18:14:43 <kc5tja> They used to be AT&T's research and development division.
18:14:49 <TheBlueWizard> hmm
18:14:50 <kc5tja> They also invented VNC too.  :D
18:16:46 <kc5tja> Anyway, I was just doing research on various GUIs in support for my FS/Forth efforts.
18:17:14 <kc5tja> Basically, I'm going to implement FS/Forth using SDL, so I may as well consider all my graphical environment options for ideas.
18:17:15 <TheBlueWizard> well, you seem to be collecting various GUI packages these days...researching / exploring /"tasting" them out, right?
18:17:23 * kc5tja nods
18:17:56 <TheBlueWizard> mmhmm...they sure come in a lot of shapes and flavors
18:17:57 <kc5tja> My favorite to date is still GEM.  But I have to admit, MGR is awfully enticing too.  :)
18:18:27 <kc5tja> MGR is neat because it is fully network transparent, and can even be used over raw serial lines.
18:18:32 <kc5tja> No networking protocol required.
18:18:44 <kc5tja> As far as applications are concerned, you talk to the MGR server using stdin and stdout.
18:19:17 <TheBlueWizard> neat
18:19:20 <kc5tja> (and stderr, but that's really not recommended, as it could interfere with the normal communications between the client and server)
18:19:30 <kc5tja> Seems to be reasonably popular with embedded systems.
18:19:50 <TheBlueWizard> stderr could be sent to a pop-up window, I imagine...
18:19:56 <kc5tja> Nope.
18:20:17 <kc5tja> stderr and stdout use the same output device in POSIX environments; the difference is that stderr is unbuffered, while stdout is buffered.
18:20:49 <kc5tja> Hence, in order to send error messages to a different pop-up window, you first need to open it, then you need to prefix all output to stderr with the commands that redirects text output to that window.
18:20:58 <kc5tja> (and append the commands that switches it back)
18:21:14 <TheBlueWizard> hmm...I don't see why that would prevent it from being redirected to a pop-up window
18:21:47 <kc5tja> Ummm
18:21:47 <TheBlueWizard> hmm...
18:22:04 <kc5tja> I guess I just don't understand what you're getting at.
18:22:54 <kc5tja> In order to function like a normal terminal, the stderr and stdout file handles write to the same "medium" -- that is, the same MGR session.
18:23:20 <kc5tja> This is what normal text applications expect.
18:23:25 <kc5tja> (ignoring file redirection)
18:24:00 <kc5tja> MGR only has one pipe to communicate with the application with.
18:24:14 <TheBlueWizard> I mean: can't MGR (or anything similar) be smart enough to dynamically create a pop-up windows if it start receiving data on stderr output, and manage that behind the scene...and the user could simply click OK to close it...I can't imagine it would be that hard
18:24:20 <kc5tja> stdout is the application-to-MGR path, and stdin is the MGR-to-application path.
18:24:28 <kc5tja> No.
18:24:29 <kc5tja> It isn't.
18:24:36 <kc5tja> And if it did, it'd break a *LOT* of tools.
18:25:09 <kc5tja> MGR tries as hard as possible to set up each terminal as closely as a normal text-mode terminal as possible.
18:25:28 <kc5tja> It even goes to the extreme of hand-updating the /var/log/utmp and /var/log/wtmp files (something which X11 doesn't do)
18:25:51 <TheBlueWizard> hmm...ok.  It'd be cool if it behaves this way, but if it breaks a zillion tools, then, have to accept the limitations :(  actually, I think FS/Forth should eschew POSIXism at some point anyway
18:25:56 <kc5tja> If you didn't care about backward compatibility, I'm sure it's quite possible to do that.
18:26:12 <kc5tja> What makes you think FS/Forth bothers with POSIXisms?
18:26:17 <kc5tja> It's Forth.
18:26:19 <kc5tja> Not Unix.
18:27:01 <kc5tja> gilbertdeb got all depressed when I told him that FS/Forth won't even have a basic compliment of graphics tools, let alone full-blown UI building tools like what k and rebol have.
18:27:38 <TheBlueWizard> never mind re: my last comment re: FS/Forth and POSIXism
18:27:58 <kc5tja> I'm just saying that MGR is burdened with this kind of behavior.
18:28:10 <kc5tja> Though, I truely wouldn't have it pop up a window for that stuff. 
18:28:22 <kc5tja> I'd rather have it log to dedicated "log window" or something, like Oberon does.
18:28:34 <kc5tja> It's so much better to have continuously available log of errors and such.
18:28:43 <TheBlueWizard> gi apparently was having a very high hope for FS/Forth, and you aim a bit too low for his taste :)  Actually, a full blown setup is a lot of work
18:29:10 * kc5tja nods
18:29:12 <TheBlueWizard> s/gi/gilbertdeb/
18:29:15 <kc5tja> And that's precisely what I'm aiming to avoid.
18:29:22 * TheBlueWizard nods
18:29:26 <kc5tja> If you want the full setup, then write it yourself.  :)
18:29:36 <kc5tja> 'cos I just don't have that kind of time.
18:29:55 <TheBlueWizard> yup :)  or recruit several saps to collaborate on developing one :)
18:30:13 * kc5tja nods
18:30:26 <kc5tja> What it will have, though, is a fully event-driven kernel.
18:30:35 <kc5tja> Especially since SDL is event-driven.
18:30:52 <kc5tja> And computers now-a-days really, really prefer to be event driven anyway.  The hardware is even optimized for it.
18:31:17 <TheBlueWizard> event driven kernel? like the one similar to old Mac OS where an app has to drive everything?
18:31:20 <kc5tja> When the computer has nothing to do, you HALT it (e.g., the CPU executes a HALT instruction), which puts the CPU to sleep, waiting for a hardware interrupt.
18:31:25 <kc5tja> While in the sleep state, it draws less power.  MUCH less.
18:31:36 <kc5tja> Yes, but the kernel drives it.
18:31:47 <TheBlueWizard> got it
18:31:49 <kc5tja> An "application" consists of three major components
18:32:10 <kc5tja> 1.  Initialization code.  This code is responsible for rendering the initial screen, and registering the appropriate event handlers with the kernel.
18:32:11 * TheBlueWizard doesn't like how old MacOS do its own things though
18:32:14 <kc5tja> 2.  The event handlers themselves.
18:32:30 <kc5tja> 3.  Shutdown code, which is just a specialized part of the event handler software.
18:32:40 <kc5tja> All modern GUIs follow that approach.
18:32:49 <kc5tja> I don't think there's anything wrong with it.
18:33:11 <kc5tja> In the case of AmigaOS, for example, the application has to wait on signal bits, for example.
18:33:17 <kc5tja> Waiting on signals is the only way to put a task to sleep.
18:33:33 <kc5tja> (everything else which can do so ultimately calls exec.library's Wait() to do it)
18:34:15 <kc5tja> BUT...
18:34:41 <kc5tja> since I don't much care about multitasking, I can get away with my simpler approach, where the kernel contains the single event queue, on which it waits.
18:34:53 <kc5tja> Dispatching events involves invoking event handlers directly.
18:34:58 <TheBlueWizard> yeah....what I am trying to say is that one would have to plan out everything for application in old MacOS environment, and I understand it is quite laborious...that's what I don't like
18:35:11 <kc5tja> Hence, a limited form of cooperative multitasking comes about naturally, without the overhead of a task switcher.
18:35:53 <kc5tja> TheBlueWizard: Plan out everything?  Well, you had to pre-allocate memory that it'd need, but I don't see how that affects its event-driven nature.
18:36:03 --- join: gilbertdeb (gilbert@fl-nken-u2-c3b-118.miamfl.adelphia.net) joined #forth
18:36:13 <TheBlueWizard> hiya gilbertdeb
18:36:20 <gilbertdeb> hi Tbw
18:36:22 <kc5tja> An application can have several event pumps, one for each of its event processing needs.
18:36:58 <kc5tja> In my environment, for example, I have just the opposite problem: to switch between event pump requirements, I have to laboriously unregister event handlers, and register replacements.
18:39:55 <TheBlueWizard> seems you and I have differing visions of what things should be :/
18:40:27 <kc5tja> ??
18:40:41 <kc5tja> Explain please.
18:41:01 * TheBlueWizard sighs
18:41:10 * kc5tja isn't trying to be exasperating
18:41:27 <kc5tja> I really want to know -- I'm curious to know why you feel the way you do.
18:41:31 <TheBlueWizard> I'm afraid it will take a lot of explaining, which I'm in no mood to so tonight
18:41:47 <TheBlueWizard> s/to so/to do so/
18:42:35 <kc5tja> Well, FS/Forth's concept of an application is just a bunch of subroutines that are called at the appropriate times.  
18:42:41 <TheBlueWizard> plus my vision is too fuzzy to get well thought out, which means I don't wanna get into a tangle :)
18:42:48 <kc5tja> The only thing the initialization code does is configure the environment to support it, that's all.
18:42:52 <kc5tja> Like GEOS for the Commodore 64.
18:43:32 <kc5tja> I wouldn't tangle.
18:43:42 * kc5tja just notes that there are advantages and disadvantages to both techniques.
18:44:11 * TheBlueWizard nods
18:45:22 <TheBlueWizard> besides, I don't want to impose my ideas (however uncooked they may be) upon your project...not my place....I can make some small techical critiques
18:45:26 <TheBlueWizard> though
18:46:19 * kc5tja nods
18:46:52 * gilbertdeb notes that the process of trying to explain fuzzy ideas might just unfuzzify them ;)
18:47:40 <kc5tja> Well, here's a hypothetical scenario in FS/Forth:
18:48:13 <kc5tja> : keydown ." You pressed keycode " .h cr ;
18:48:21 <kc5tja> : keyup ." You released keycode " .h cr ;
18:48:31 <TheBlueWizard> gilbertdeb: maybe...but it could make things more confusing
18:49:05 <kc5tja> ' keydown ' keyup keyboard-handlers
18:49:17 <kc5tja> (I haven't quite figured out the interface for it yet)
18:49:28 <kc5tja> But that's the basic idea.
18:52:35 <TheBlueWizard> of course there has to be a set of default keyboard handlers which must reside in the kernel, and of course unregistering must either revery them back to default handlers, or "roll back" to older handlers, if handlers are "stacked up"...just my thought.  I suspect reverting back to default would be the simplest
18:53:43 <kc5tja> Yes, I'm quite aware of that.  :)
18:53:59 <kc5tja> And it's true, I really haven't figured out quite how to support this type of thing yet.
18:54:16 * TheBlueWizard nods
18:54:21 <kc5tja> Although, handler stacks is an idea I hadn't previously thought of.
18:54:45 <kc5tja> But, I'd prefer something that wouldn't necessarily involve EMPTY if I can avoid it.  :)
18:54:57 <kc5tja> (if I EMPTY an application, I expect the input handlers to revert automatically)
18:55:29 <TheBlueWizard> some DOS TSRs support "stacking" handlers...so you can delete the last one and the older TSR become active
18:58:04 <kc5tja> You have to explicitly quit those TSRs though.
18:59:24 <TheBlueWizard> yeah...it is the idea that counts
18:59:35 <kc5tja> When I EMPTY the dictionary, absolutely nothing in the already loaded code is executed.
18:59:39 <kc5tja> *idea*
18:59:44 <kc5tja> but EMPTY can itself be an event!
18:59:54 <kc5tja> Doggone it, why didn't I think of that before?
19:00:21 <TheBlueWizard> another advantage of stacked handlers is that if one handler doesn't know how to handle a certain event, it simply toss it to the next handler in the stack
19:01:14 <kc5tja> Yeah, but if I have three applications loaded like this: A B C
19:01:26 * TheBlueWizard blinks re: you not thinking of it before...he already thought of it before (re: EMPTY handler)
19:01:29 <kc5tja> and C does not implement an EMPTY handler, I do *not* want B's handler to run.
19:01:59 <kc5tja> I only want B's handler to run when I EMPTY B out of the dictionary.
19:02:32 <TheBlueWizard> then push a bunch of EMPTY handlerrs...but that's a bit ugly IMHO
19:03:29 <kc5tja> Or, if B and C are to be forgotten at the same time, I'd expect C's, then B's, EMPTY-handler to run.
19:03:30 <kc5tja> Gahh.
19:03:37 <kc5tja> (but not A's)
19:04:24 <kc5tja> But then again, C knows a prior that B is already loaded, so it's handler can invoke B's handler manually (as C++'s constructors invoke base-class constructors manually)
19:04:33 <kc5tja> So that's not that big of an issue
19:04:42 <kc5tja> And yes, the EMPTY handler must remember to remove itself as a handler.  :D
19:06:10 <TheBlueWizard> it can get tricky...I haven't really thought it through....I was just tossing out the thoughts on the board here
19:06:22 * kc5tja nods
19:06:49 <TheBlueWizard> the first event handlers must be EMPTY oners, and they should not be able to unregister themselves
19:07:01 <TheBlueWizard> s/oners/ones/
19:07:21 <kc5tja> Of course.
19:07:25 * kc5tja has to think this through a bit more.
19:07:32 <kc5tja> This has a lot of potential.
19:07:59 <kc5tja> However, it is incompatible with my earlier event handling plans, where the kernel does maintain an event queue.
19:08:11 <kc5tja> For this to work, the EMPTY handler cannot exist in the queue.
19:08:16 <kc5tja> err, EMPTY event
19:09:09 <kc5tja> Otherwise, it would take a variable length of time before it is properly handled, which could full well be never.
19:09:36 <kc5tja> Hence, it could seize up the console.
19:09:51 <kc5tja> OK, something to think about for later.
19:10:02 * TheBlueWizard smiles
19:10:26 <TheBlueWizard> as I said earlier, there are all kinds of shapes and flavors :D
19:10:58 <kc5tja> Actually, I think I have it.
19:11:06 <kc5tja> I can define interfaces in memory to things.
19:11:20 <kc5tja> Where an interface is a collection of pointers to (related) functions.
19:11:33 <kc5tja> So, the keyboard handler "interface" would have a key down and key up handler as a unit.
19:12:12 <kc5tja> EMPTY would be lumped in with a system management interface.
19:12:30 <kc5tja> SO I could do something like:
19:12:43 <kc5tja> IKeyboard keyb
19:12:52 <kc5tja> : dn ." Key down: " h. cr ;
19:12:59 <kc5tja> : up ." Key up: " h. cr ;
19:13:26 <kc5tja> ' dn ' up keyb IKeyboard!
19:13:29 <kc5tja> hmm....too verbose i think.
19:13:42 <kc5tja> And then:
19:13:55 <kc5tja> keyb key-handler
19:14:09 <kc5tja> where key-handler would take care of managing the keyboard handler stack.
19:14:13 <kc5tja> Yeah, too verbose.
19:14:18 * kc5tja thinks some more.
19:15:03 <TheBlueWizard> I'm sure you will eventually find a sweet spot solution to this event processing problem
19:15:12 * kc5tja nods
19:26:48 <TheBlueWizard> well, gotta go...bye all
19:26:54 <kc5tja> okies
19:27:02 <kc5tja> Later :)
19:27:04 <gilbertdeb> ciao
19:27:04 <TheBlueWizard> bye kc5tja
19:27:09 <TheBlueWizard> bye gilbertdeb
19:27:17 --- part: TheBlueWizard left #forth
21:29:04 --- part: gilbertdeb left #forth
21:47:37 --- quit: sic (Read error: 110 (Connection timed out))
22:01:10 --- join: sic (~shadow@205.247.28.94) joined #forth
22:07:25 --- join: gilbertdeb (gilbert@fl-nken-u2-c3b-118.miamfl.adelphia.net) joined #forth
22:17:50 --- nick: sic -> cleverdra
22:56:53 --- part: gilbertdeb left #forth
23:34:33 --- quit: cleverdra (orwell.freenode.net irc.freenode.net)
23:44:03 <kc5tja> Hmm...  I'm reading a paper by Rob Pike on concurrent window management issues that applies to the general case of event handling.
23:44:14 <kc5tja> It makes a strong case for concurrency in the Forth environment.
23:59:59 --- log: ended forth/03.08.03