00:00:00 --- log: started forth/02.06.21 00:04:37 --- join: Serg_penguin (~snaga_NOI@nat-ch1.nat.comex.ru) joined #forth 00:04:49 hi 00:25:51 --- quit: Serg_penguin () 00:45:27 --- join: davidw (~davidw@adsl-32-74.38-151.net24.it) joined #forth 01:09:46 --- join: Serg_penguin (~snaga_NOI@nat-ch1.nat.comex.ru) joined #forth 01:10:02 hi ! 01:58:52 hiû 01:58:56 hi 01:59:32 im busy, but my net connection is rather instable 01:59:54 and my irc client does autoreconnection 02:00:41 so usually thats not me who joins by hand but my clients automatism 02:08:45 --- join: Serg (~snaga_NOI@nat-ch1.nat.comex.ru) joined #forth 02:09:27 --- quit: Serg_penguin (Killed (NickServ (Nickname Enforcement))) 02:10:04 --- nick: Serg -> Serg_penguin 02:10:56 hi all ! 02:40:19 --- part: Serg_penguin left #forth 02:57:29 --- quit: davidw (Read error: 113 (No route to host)) 03:09:59 --- quit: air (Read error: 104 (Connection reset by peer)) 03:29:39 --- join: Speuler (l@p3E9B8E90.dip.t-dialin.net) joined #forth 03:29:57 g'day 03:36:06 --- join: davidw (~davidw@adsl-32-74.38-151.net24.it) joined #forth 03:43:36 --- join: Serg_penguin (~snaga_NOI@nat-ch1.nat.comex.ru) joined #forth 03:43:45 hi 03:49:35 --- join: air (brand@12-254-199-50.client.attbi.com) joined #forth 03:53:03 hi Serg_penguin 04:02:06 --- join: rob_ert (~robert@h237n2fls31o965.telia.com) joined #forth 04:03:33 --- quit: Speuler (Read error: 60 (Operation timed out)) 04:20:52 hi 05:40:08 --- quit: Serg_penguin () 06:12:09 --- join: tathi (~josh@wsip68-15-54-54.ri.ri.cox.net) joined #forth 06:43:44 --- join: Stepan (~stepan@Charybdis.suse.de) joined #forth 06:47:11 --- nick: Soap` -> SoapZZz 07:11:36 --- join: Serg_penguin (~snaga_NOI@nat-ch1.nat.comex.ru) joined #forth 07:11:48 hi 07:34:18 --- join: XeF4 (chobmt@12-245-116-85.client.attbi.com) joined #forth 07:55:13 --- quit: Serg_penguin () 08:08:32 --- quit: Stepan ("Do you think it is air you are breathing? Hmm?") 08:25:38 --- quit: XeF4 ("pois") 08:54:03 --- quit: |\| (Read error: 110 (Connection timed out)) 10:57:18 --- quit: davidw (Read error: 113 (No route to host)) 11:16:15 --- join: kc5tja (~kc5tja@stampede.org) joined #forth 11:31:52 --- quit: air ("reboot") 11:59:05 --- join: air (brand@12-254-199-50.client.attbi.com) joined #forth 12:11:27 --- join: |\| (LESLES@pcp01518417pcs.reding01.pa.comcast.net) joined #forth 12:42:15 --- quit: Fare ("ERC v2.91 $Revision: 1.239 $ (IRC client for Emacs)") 12:57:07 haho 12:58:56 re 13:00:16 hi, kc5tja 13:00:35 u became a resident member here as i c 13:00:44 so, whats up? 13:00:44 More or less. 13:00:49 Working. 13:00:56 what has happened in the last ~3weeks? 13:01:04 * kc5tja is stuck on a problem here at work, and I can't proceed until it's adequately resolved. 13:01:12 what r u working on? 13:01:26 Verifying our new series of chips. 13:01:40 Beyond that I can't tell you until this company makes a press release. 13:01:43 oy c 13:03:33 <|\|> hi 13:03:51 <|\|> i think kc5's company is designing a new Supercomputer, right? :P 13:04:03 No. 13:04:18 We design packet processing coprocessors for high speed networking applications. 13:04:31 <|\|> nice 13:04:45 By high speed, I'm talking OC-12 and higher. :) 13:04:46 <|\|> so, you would make parts that Cisco would use in their routers? 13:04:51 Yes. 13:05:49 <|\|> man, i love my sun... it is such a solid machine 13:05:56 <|\|> it is built like a *tank* 13:11:06 What machine is it? 13:11:31 <|\|> ultra2 13:11:55 <|\|> has an interesting history... used to be a web/ftp server for netscape.com in 97 13:12:41 Heh ... 13:12:45 * kc5tja still loves his Amiga 500. :) 13:12:54 <|\|> what are the specs on that amiga? 13:13:04 That thing was dropped down two flights of stairs ... twice. With the harddrive, and it still runs flawlessly. 13:13:05 <|\|> i'm not very familiar with amiga hardware 13:13:18 Depends on the model. The A500 is pretty low-end. 13:13:33 The A500 is basically a stripped Amiga 2000, targeting the C64/C128 market. 13:13:38 <|\|> ok 13:13:48 <|\|> so how's Amiga Workbench? 13:13:53 <|\|> is it pretty nice to work with? 13:14:00 It's a 68000 base CPU, 7.15909MHz for the US model. Stock, it came with 512K of RAM, but I've upgraded it to 3MB with the harddrive attachment. 13:14:05 It's sweet. 13:14:14 It's multitasking performance exceeds that of Linux in my opinion. 13:14:17 A500 has some nice games for it :) Sweet. 13:14:50 Unfortunantley, all programming software I got is the basic that comes with the workbench extras. 13:15:12 * kc5tja did mostly C and assembly language coding. 13:15:44 If only I'd known more about Forth back then, I would have coded my own or used one that was already available. 13:15:53 now I have to pretty much do it retroactively. :) 13:16:06 Only have a forth for my C128 :/ 13:16:10 Nothing for the Amiga. 13:16:23 And I haven't got any screen for the C128. 13:16:24 * kc5tja intends on putting his Amiga to work in musical applications and, in the future, control over my telescope. 13:16:31 Rest of the family wants the TV, heh. 13:17:04 Hehe... telescope control, wasn't that kind of what forth became famous for? 13:17:11 Yes 13:17:20 That was its first publicized use. 13:17:50 But programming imaging software for the Amiga is substantially easier than for X11 or Windows. 13:18:07 The operating system for it is extremely well made, and is very programmer friendly. 13:18:13 (while being user friendly at the same time) 13:18:17 Hehe. 13:18:26 Windows and X11 are very programmer hostile, in fact. 13:18:43 What makes Amiga's OS so friendly, then? 13:18:52 It's well factored and well implemented. 13:19:06 How much code do you need to open a window in X11 or Win32? 13:19:22 It takes **ONE** function call in AmigaOS. 13:19:29 Yay. 13:19:29 (conveniently called OpenWindow) 13:20:02 It's I/O model is the best I've ever seen. 13:20:04 Yes, I admit the Windows GUI API (the only one I've even looked at) seems a bit over-complicated. 13:20:13 I/O model? 13:20:23 The system-wide input/output philosophy. 13:20:31 **EVERYTHING** in AmigaOS is asynchronous by default. 13:20:59 Synchronicity occurs in one and only one point in the program, where the one and only one function that ever blocks a task is called: conveniently called (you guessed it!) Wait(). 13:21:24 Thus, the program structure is *far* more modular, and unbelievably easier to read and follow. 13:22:02 Although AmigaOS supported multithreaded application development since 1.0, it was never used until almost 7 years later when Kickstart 2.04 used it internally for certain things. 13:22:11 And even then, the individual applications rarely used multithreading. 13:22:22 The system was so fast and the software so simply structured that it simply wasn't needed. 13:22:53 :) 13:23:13 How's 68k assembly like? 13:23:21 Register starved, or a lot of them? 13:23:27 Many or few instructions? 13:23:28 Just the right amount. 13:23:37 What's the word length? 13:23:48 16-bit word length, but it was a 32-bit processor. 13:24:38 The 68000, when it was first introduced, was touted by many as being the world's first supercomputer on a chip. 13:25:02 <|\|> interesting 13:25:03 I'd say it's a mainframe on a chip, because frankly, it's just a modernized version of the DEC PDP-11 instruction set with more registers. 13:25:07 <|\|> asynchronous by default 13:25:33 Not like PC BIOS :} 13:25:57 Unix is even synchronous by default, adn look at the atrocities we have to go through today to circumvent that default behavior. 13:26:12 I mean, just *TRY* to integrate CORBA into an existing X11 application that uses GTK+. 13:26:22 It's not going to happen. 13:26:32 <|\|> yeah 13:26:37 <|\|> it would be nigh impossible 13:26:47 In fact, it's *so* bad, that the Gnome people actually wrote a *SPECIFIC VERSION OF ORBIT* just for Gnome!! 13:26:57 (libgnorba) 13:27:04 <|\|> ugh 13:27:11 <|\|> gnome is nasty 13:27:13 These types of things just don't exist in AmigaOS. 13:27:19 Gnome is a nice concept. I like it. 13:27:22 But its API sucks eggs. 13:27:41 What is Cobra? 13:27:47 Chuck Moore is often disappointed with the need for operating systems. 13:28:05 rob_ert: It's a remote object method invokation system that is 100% language independent. 13:28:07 <|\|> what is the alternative? 13:28:21 What is the alternative to what? 13:28:35 Not having an OS? 13:28:35 <|\|> Chuck Moore is often disappointed with the need for operating systems. 13:28:40 Having a forth :) 13:28:50 <|\|> what would be Chuck Moore's ideal scenario? 13:28:54 Chuck Moore is often disappointed with the need for operating systems. It's clear he never used AmigaOS. He'd no doubt find some fault (AmigaOS itself isn't perfect for everything), but AmigaOS is bar none the closest I've come. 13:29:10 <|\|> what does Chuck Moore want then, if not an OS? 13:29:15 <|\|> raw access to hardware all the time? 13:29:17 Chuck Moore's ideal is to not have an OS, but instead, write the application to the hardware directly. 13:29:25 <|\|> ah 13:29:32 <|\|> isn't that kind of, the DOS approach? 13:29:49 No. DOS is an operating system. You don't read/write files on the disk using direct hardware access. 13:30:06 It could be. 13:30:14 But you *don't*. That's the point. 13:30:21 With a slightly more advanced HD controller :) 13:31:13 <|\|> ok, so how would the typical user use a computer without an OS? 13:32:12 By writing forth and assembly code, of course. 13:32:21 (Sorry, I am bored) 13:32:26 <|\|> that doesn't sound very user-friendly... 13:32:28 <|\|> heh 13:32:39 The ordinary software could take care of it. 13:32:59 Like... a text editor allocating disk space on its own :P 13:33:36 <|\|> seriously, i don't understand this at all 13:34:21 I'm not sure HOW he want an OS-less system to work. 13:34:34 <|\|> ;/ 13:34:40 <|\|> i'm sure kc5 knows... 13:34:45 But for example, you could just add file system function to The Forth's vocabulary, and let the other programs use it. 13:34:56 <|\|> ah 13:35:04 <|\|> so basically 13:35:06 <|\|> each application 13:35:12 <|\|> would have its own "os" inside it 13:35:12 <|\|> ? 13:35:20 <|\|> that is shared among other apps 13:35:21 Either that, or they share one. 13:35:27 Yes. 13:35:37 <|\|> but the OS itself isn't a big entity that sits between the hardware and the apps 13:35:37 That would be kind of cool :) 13:35:43 Exactly. 13:35:43 <|\|> the apps have more control... 13:35:47 <|\|> good idea 13:35:56 Yes, every program would be an extention to the kernel. 13:35:58 <|\|> more communist than current approachs :) 13:36:08 <|\|> that's kind of like the Exokernel project @ MIT 13:36:13 (With the ability to do whatever they want *muahaha*) 13:36:43 <|\|> in the exokernel OS, every App uses a shared OS library 13:41:29 Sorry, I've been hacking some code. 13:41:45 * kc5tja thinks he found a repeatable pattern, which should help me debug further. 13:42:25 Anyway, to answer your questions, you can easily use a computer without an operating system. Early 8-bit machines had no operating system at all, but instead relied on BASIC to provide user interaction. But that raises the question, is a language and an OS the same? I argue that it is. 13:42:35 Forth is as much an operating system as anything else I've used. 13:42:54 A multitasking Forth could be argued to be an exokernel. It seems to fulfill all the requirements. 13:43:53 * kc5tja really likes the concept of the exokernel; however, I've not yet, even to this date, seen anything *concrete* about them. 13:44:08 There appears to be several exokernels, but all of them are quite different. They share little in common. 13:44:14 Though MIT's is certainly the most popular. 13:44:40 (In fact, my Dolphin appears to fulfill the requirements of an exokernel to a large degree; however, I admit it is not an exokernel). 13:47:22 Another interesting derivation of the work on nanokernels and exokernels is the concept of a cache kernel. 13:47:37 And that is? 13:47:45 * kc5tja tries to find it... 13:47:54 I can't really explain it because I'm not 100% sure of what it is myself. 13:48:17 But it appears that instead of managing resources directly like in an exokernel, virtualized instances of each resource is maintained in a kernel-maintained cache. 13:48:22 Everything is treated as cached object.s 13:48:34 (including processes, pages of memory, sometimes even interrupts themselves) 13:49:02 http://www-dsg.stanford.edu/papers/cachekernel/main.html 13:49:42 Lots of ideas out there :) 13:50:15 See, this is where I get hung up on -- in the exokernel, it separates protection from management. But isn't protection an intrinsic part of management? I just can't seem to wrap my mind around that. The best I can do to approach this is to maintain a kernel-private scoreboard over which resources are allocated to which tasks. 13:50:47 And then, what exactly does protection mean in this case? 13:54:33 However, in a way, GEM and my derivation of it for Dolphin constitutes a *VERY* exokernel-ish approach towards managing screen real-estate. 13:54:49 Hmm.. 13:54:50 Like for disk sharing and protection, I think I understand a little bit of what's going on here. 13:55:07 Basically the exokernel keeps a registration of which blocks are allocated to which processes. 13:55:19 But the kernel itself neither knows how to access nor cares what accesses those blocks. 13:55:41 Just as GEM's AES has **no** idea how to actually draw anything to the screen, while the application has direct access to the screen via the VDI. 13:55:54 But it definitely requires a large amount of cooperation. 13:56:05 (easy to implement, but it does require a certain amount of trust) 13:56:18 Hehe. 13:56:33 That's the problem, if you want to let other people into your computer. 13:56:59 Well, the idea behind the exokernel is that the libOSes would be trusted. 13:57:11 And it more or less makes sense to do so. 14:02:27 This sucks, I can't continue in the Exokernel slide show... :( 14:02:39 There it goes...damn network outtage. 14:06:21 --- quit: air (carter.openprojects.net irc.openprojects.net) 14:06:21 --- join: air (~brand@12-254-199-50.client.attbi.com) joined #forth 14:07:43 <|\|> yeah 14:07:45 <|\|> so uh 14:07:54 --- quit: tathi ("leaving") 14:09:28 ? 14:10:21 <|\|> n/m 14:10:31 * |\| just finished thinking about your comments 14:14:51 Ah 14:21:46 --- quit: |\| (Read error: 104 (Connection reset by peer)) 14:27:28 http://www.pdos.lcs.mit.edu/papers/exo-sosp97/exo-sosp97.html describes exokernels in more detail than I've ever seen to date. I'm really enjoying this. 14:28:22 And oddly enough, it pretty much describes the AmigaOS resource management API (the underpinnings of its I/O model) 14:28:31 Man ... this is incredible stuff. 14:28:48 Thanks, I will take a look. 14:28:50 Dolphin's resource management API was going to be similar, but a bit more loose. 14:29:11 ANd Dolphin is..? 14:29:21 * kc5tja thinks he'll start to lean away from the VMS-ish resource management style (close, but not quite exokernelish) and try to lean more towards exokernel in the future. 14:29:25 My OS, remember? 14:31:34 Actuallt, I didn't :) 14:31:47 I've only mentioned it here on this channel 20 times in the past. :) 14:32:09 I have a bad memory :) 14:32:30 Anyway, I'm also struggeling with some OS design. 14:32:35 Quite interesting topic. 14:33:18 * kc5tja nods 14:33:50 Of all the various "alternative" kernel models that exist (nanokernel, exokernel, and cached kernel), I think exokernel has the highest potential for success. 14:34:53 In short terms, what _is_ an exokernel? 14:34:59 What I also like is that exokernel is orthogonal to monolithic or microkernel design. 14:35:15 A resource manager that knows nothing at all of what it is managing. 14:35:58 For example, an exokernel can manage disk blocks in such a way to allow multiple concurrent filesystems to access a single harddrive safely and efficiently. 14:36:21 But the exokernel itself has no idea what a filesystem is, or for that matter, even what a partition is. 14:36:55 All it knows is that certain regions of blocks are locked for write-only access to process X, some are read/write to process Y, and the remainder are readable by Z, A, B, and C. 14:38:26 So, in what way do the device drivers and other servers use the exokernel? 14:39:08 Well, consider a floppy disk driver -- it needs access to DMA and to the floppy disk controller. 14:39:26 But the exokernel doesn't handle any memory protection itself? 14:39:52 When an application wants to read a track of data in, the driver must allocate the DMA channel the FDC relies on (this blocks the application until it's available), and then allocates the floppy disk controller (ditto). 14:40:22 Exokernels may or may not -- that's a policy individual applications need to decide on. 14:40:55 Once the application has been granted permission by the disk driver to use these resources, it's free to access the disk in any manner it sees fit (in this case, to read in a particular track). 14:41:17 Once the I/O operation completes, it releases the two resources, which allows other applications to utilize the resources if necessary. 14:41:31 A disk driver for a harddrive is only slightly more complex. 14:42:17 Before the disk driver is even acquired, the driver must first check to make sure the range of blocks requested is valid. If not, then an error is returned right away. 14:42:37 Otherwise, the appropriate IDE device is acquired, and I/O occurs as discussed above. Then it's released. 14:42:50 AmigaOS's trackdisk.device (floppy disk driver) worked *exactly* this way. 14:43:13 AmigaOS has a cia.resource that it can acquire, which includes all the functionality of floppy disk management. 14:43:19 Sounds quite neat. How about IPC? 14:43:24 What about it? 14:43:33 IPC, when all is said and done, is just shared memory. 14:44:02 All that's needed to support IPC is an adopted and well-known convention for sharing memory pages. 14:44:15 What are the advantages with this type of "resource allocation", compared with e.g. just a floppy driver that has a list of tasks to be done? 14:44:35 i.e. tracks to be read and written. 14:45:26 Well, for something as simple as a floppy, there isn't much advantage (except consistency with the remainder of the I/O subsystem). 14:45:32 But for harddrives, it is critical. 14:46:10 Why? 14:46:29 A FAT filesystem, for example, is definitely NOT optimized for use with an elevator algorithm to minimize seek delays, while something like BSD FFS and Linux's EXT2 are. 14:47:28 Thus, what if you wanted to implement a version of ext2 on a device driver that didn't support elevator scheduling of disk blocks? You'd end up with lackluster performance. 14:48:17 Likewise, if you implement a version of FAT on a disk driver that DID support the elevator algorithm, it'd end up being slower than expected anyway (because the driver is reading blocks out of expected order). 14:48:41 I see. 14:48:53 It's best to let the filesystem touch the hardware directly for this, to minimize latency. FAT knows how to best interleave sectors to minimize latency, while ext2fs knows best how to employ elevator for maximum throughput, etc. 14:50:06 It's interesting to note that AmigaOS does not have a resource established for harddrive use, but only for floppy use. This is because AmigaOS originally was designd as a floppy-only system. They do allow custom resources to be implemented, but a lot of boiler plate code has to be written to do it, so it's rarely done for external expansions. 14:50:21 As a result, AmigaOS harddrive performance has, in some cases, been criticized as being less flexible than the floppy interface. 14:50:36 However, in most cases, it's not an issue. 14:50:47 (Most AmigaOS harddrives only have one filesystem on it anyway) 14:51:22 So for something like what you or I would use, it wouldn't make much of an issue. But for something like a harddrive recording system for use in a professional audio recording studio, it could make an enormous benefit. 14:51:40 Hmm.. but about the scheduler, can't there be a floppy driver that takes simple commands, such as "read block x to memory location x", but the file system driver handles the scheduling? 14:52:27 You could, but why? That's horrendously slow. You're imposing a user/kernel/user mode transitions for something the filesystem could do by directly touching the hardware. 14:53:35 AmigaOS more or less got around this by doing "full track buffering" (e.g., it didn't read in individual sectors, but instead, entire disk cylinders!). But as you can imagine, for many small, widely distributed writes, that's horribly inefficient. 14:54:08 (of course, the hardware was optimized for full-track I/O as well, so there's not much you could have done on an Amiga to fix that) 14:55:32 But I intend on using full-track buffering on the PC for convenience reasons under Dolphin (and because its filesystem, DNFS, will be optimized to use extents instead of individual blocks). 14:55:53 But FAT uses many small, single-block updates. It'd be quite slow on a full-track-only device driver or filesystem. 14:57:29 Actually, how important will the FAT performance be? 14:58:07 I mean, even if I sometimes mount FAT disks, that's on quite rare occasions, and even a 50% speed loss would be tolerated. 14:58:22 You're missing the forest because all the trees are in the way. 14:58:34 I chose FAT, ext2, and DNFS as examples (which is what you asked for). 14:58:53 The general principles applied to this situation are universally applicable across many different fields of application. 14:59:24 And for the record, reading and writing FAT disks on an Amiga produces a very noticable drop in floppy disk performance. 16:24:38 --- join: skrawl (retext@user-38lcjkh.dialup.mindspring.com) joined #forth 17:03:49 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 17:18:05 --- join: davidw (~davidw@adsl-32-74.38-151.net24.it) joined #forth 17:43:02 --- nick: skrawl -> skr[A]wl 17:47:04 --- quit: davidw (Remote closed the connection) 17:47:05 --- join: davidw_ (~davidw@adsl-32-74.38-151.net24.it) joined #forth 17:47:49 --- nick: skr[A]wl -> skrawl 17:57:52 --- quit: skrawl ("Checking URLs whilst singing the praises of a singletasking OS *suuuure*") 18:08:07 Yay, my forth Pong is done :P 18:09:14 Now, time for sleep. 03:00. 18:12:00 --- quit: rob_ert ("Nothing is real. I think.") 18:25:52 --- quit: davidw_ (Read error: 113 (No route to host)) 18:27:50 --- join: skrawl (retext@user-38lcif6.dialup.mindspring.com) joined #forth 18:36:43 colorForth's if: is the 'then' implied, with its address on the data stack? 19:28:27 --- join: TheBlueWizard (TheBlueWiz@ip-216-25-205-129.vienna.va.fcc.net) joined #forth 19:28:48 hiya all 19:31:17 --- join: futhin (thin@h24-64-175-61.cg.shawcable.net) joined #forth 19:31:40 hiya futhin 19:32:42 heya 19:33:11 hm, well i was just passing by 19:33:33 passin' by? 19:33:33 so see you all later 19:33:46 ok...bye 19:34:48 --- quit: futhin (Client Quit) 19:55:22 gotta go...bye all 19:55:29 --- part: TheBlueWizard left #forth 20:20:38 --- quit: skrawl ("research") 20:39:27 --- join: I440r (~mark4@1Cust153.tnt1.bloomington.in.da.uu.net) joined #forth 21:13:47 --- join: kc5tja (~kc5tja@ip68-7-165-74.sd.sd.cox.net) joined #forth 21:43:27 --- join: skrawl (retext@user-38lcg8q.dialup.mindspring.com) joined #forth 21:43:36 hi skrawl 21:44:10 mornin 21:45:36 * I440r leeching pachelbels cannon :) 21:45:52 whodunnit? 21:46:11 heh its mozart :P 21:46:15 i think 21:46:17 errr 21:46:28 tcn would know for sure :) 21:47:08 so, in this particular case, whodunnit? (or are ya grabbing the printed score :P) 21:47:25 no 21:47:35 mp3 21:47:43 wish i could get the guitar tab for this tho 21:47:48 who's playing 21:47:50 ? 21:48:07 the mp3 doesnt say 21:49:03 a cpl of months ago i tried to download a realy realy realy good accoustic guitar version of it 21:49:06 12 string i think 21:49:13 cant even fucking find that version no more grr 21:54:15 hrm who wrote "the thrid man" ? 21:54:37 thats another one i want :) 21:54:53 dunno 21:55:24 me either heh 21:55:27 ya think we'll be pulling down .oggs rather than .mp3s anytime soon? 21:55:41 no 21:55:53 i dont like ogg 21:55:57 the extension is gay :P 21:56:01 heh 21:56:11 heh 21:56:15 other than that, why not? 21:56:29 actaully i used it for a while but there wernt any windows players then 21:56:38 i usually have my windows box play music 21:56:39 * skrawl quotes Sgt. Schultz: "I know nothink! Nothink!" 21:56:46 while i do the real work on the laptop :) 21:56:56 lol 22:11:26 --- quit: I440r ("Reality Strikes Again") 22:12:02 what's a good URL to pass to someone who's never heard of Forth, and is curious? 22:12:13 --- join: sbk_ (~kbs@dsl-65-184-98-221.telocity.com) joined #forth 22:17:56 I don't think one exists. 22:18:19 But for bleeding edge stuff, http://www.ultratechnology.com is it. 22:18:51 For more traditional Forth resources, http://www.taygeta.com or http://www.taygeta.org (whichever happens to be up at the time; his connections seem to be intermittent). 22:19:16 * kc5tja has often wanted to write a true Forth tutorial book, but I just haven't ever had the time. 22:19:43 It's kinda hard to find whatcha want on taygeta, at first. 22:20:11 Wouldn't a true Forth tutorial be inside a Forth? 22:21:11 In about a month, I will have been using Forth for about two days or so. :P 22:22:23 I just discovered the source for colorForth yesterday; I'll haveta build one to fit my machine(s). 22:37:04 --- quit: sbk_ ("Leaving") 22:40:51 --- quit: skrawl () 22:44:05 Man, I wish I didn't get that phone call. *sigh* I could have responded to scrawl's comments before he left. :( 22:54:06 --- quit: skylan (Read error: 104 (Connection reset by peer)) 22:54:11 --- join: skylan (sjh@207.164.213.42) joined #forth 23:59:59 --- log: ended forth/02.06.21