00:00:00 --- log: started forth/07.09.22 00:19:58 --- join: snowrichard (n=richard@65.125.86.66) joined #forth 00:20:00 hi 00:20:18 JasonWoof: 00:20:19 hi 00:20:52 --- part: snowrichard left #forth 00:45:55 --- join: snowrichard (n=richard@65.125.86.66) joined #forth 00:45:55 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-102-070.pools.arcor-ip.net) joined #forth 00:48:04 hiya snoopy 00:48:10 snoopy42 00:48:27 wrong one sorry 00:50:39 --- part: snowrichard left #forth 00:57:35 hi 01:03:15 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 01:03:15 --- nick: snoopy_1711 -> Snoopy42 01:25:43 --- quit: doublec () 01:33:56 --- join: wossname (n=w@CPE00195b252b77-CM001a666a6e78.cpe.net.cable.rogers.com) joined #forth 01:54:15 --- quit: slava () 02:02:30 --- quit: Off_Namuh56 (Remote closed the connection) 03:41:05 --- join: Off_Namuh56 (i=GPS@gateway/tor/x-ba7ee11e3ca5fa56) joined #forth 04:03:00 --- quit: TreyB (Read error: 104 (Connection reset by peer)) 04:06:53 --- join: TreyB (n=trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 04:52:56 --- join: doublec (n=doublec@203-211-95-61.ue.woosh.co.nz) joined #forth 06:10:14 --- join: tgunr (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 06:17:19 --- quit: wossname (Read error: 110 (Connection timed out)) 06:44:09 --- quit: doublec () 07:27:12 --- join: Raystm2 (i=NanRay@dialup-4.163.252.227.Dial1.Denver1.Level3.net) joined #forth 07:47:16 --- quit: Baughn ("Rebootin'") 07:49:12 --- join: Baughn (n=svein@084202038064.customer.alfanett.no) joined #forth 08:01:04 --- quit: timlarson ("Leaving") 08:12:29 --- join: timlarson (n=timlarso@user-12l37rb.cable.mindspring.com) joined #forth 09:06:10 --- quit: segher (kornbluth.freenode.net irc.freenode.net) 09:12:52 --- join: segher (n=segher@82-217-247-28.cable.quicknet.nl) joined #forth 10:11:00 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth 10:33:54 --- join: tgunr_ (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 10:34:41 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 11:02:29 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-109-014.pools.arcor-ip.net) joined #forth 11:05:25 --- quit: tgunr_ (Read error: 104 (Connection reset by peer)) 11:06:24 --- join: tgunr (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 11:13:06 --- quit: tgunr () 11:17:19 --- join: tgunr (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 11:17:48 --- quit: tgunr (Client Quit) 11:18:54 --- join: tgunr (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 11:20:42 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 11:20:52 --- nick: snoopy_1711 -> Snoopy42 11:23:12 --- quit: ygrek (Remote closed the connection) 11:30:43 --- join: tgunr_ (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 11:32:36 --- part: tgunr_ left #forth 11:34:09 --- join: Robert (i=robert@unaffiliated/robert) joined #forth 11:58:40 oi 12:05:24 Io. 12:07:59 oi! 12:08:04 welcome Home! 12:08:12 Hows the family? 12:08:55 hmm -- is this the same "robert" who used to join here back in 2004, with a lower-case r? :) 12:09:20 Hi kc5tja and if it is robert hi Robert. 12:09:56 and if it's not robert, Hi Robert. 12:09:58 kc5tja: I was rob_ert a long time ago. 12:10:02 hi arke. 12:10:10 OK, different person then. :) 12:10:13 Just making sure. 12:10:23 I used to hang here though. 12:10:47 And hey, Raystm2 12:11:07 sm0ysr, too. 12:11:56 I've seen that nick... 12:12:01 long time ago... 12:13:28 Yeah, I got the OPN opers to kick the old Robert out around 2002, since he had been absent for a month. 12:13:33 --- part: tgunr left #forth 12:13:39 I've been clinging to this dream nick of mine ever since. 12:14:53 Haven't done too much Forth lately, university has corrupted me. Did find my old tforth system on the 386 the other day. 12:41:04 --- join: ygrek (i=user@gateway/tor/x-f0f2f1bda666df61) joined #forth 12:49:33 --- join: H4ns (n=Hans@host-216-153-144-216.spr.choiceone.net) joined #forth 12:58:42 --- quit: nighty^ (Client Quit) 12:58:56 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth 13:02:44 --- quit: ygrek ("Leaving") 13:03:33 * kc5tja has been de-initiativized by work. 13:03:47 I still speculate on Forth, but nothing publicly as come out in a while. 13:04:06 The Kestrel's firmware is the closest, but it's still pending my writing an emulation of the I/O and storage subsystems. 13:25:03 --- quit: Raystm2 (Read error: 104 (Connection reset by peer)) 13:25:15 --- join: Raystm2 (i=NanRay@dialup-4.163.252.227.Dial1.Denver1.Level3.net) joined #forth 13:26:52 --- join: frunobulax (n=mhx@f233009.upc-f.chello.nl) joined #forth 13:36:43 --- quit: frunobulax ("a quit that really quits") 13:47:09 --- join: slava (n=slava@CPE0007e97df149-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 13:47:18 i'm convinced that CALL and RET in x86 are fundamentally flawed 13:47:44 it's a mistake to conflate the calling of a subroutine with saving the return address 13:47:49 and loading of the return address with returning 13:48:19 what would be your replacement ops and their behaviours? 13:48:29 what the ARM or PowerPC does 13:48:40 with a link register 13:48:47 call saves the current pc in a link register and jumps 13:48:52 return jumps to the link register 13:49:01 it's up to the callee to save the link register on the stack 13:49:52 I would like that, that would make some coding styles simpler 13:50:07 i had to make a fucked up callign convention for x86 13:50:13 where stack frames are chained up 13:50:16 instaed of donw 13:50:17 down* 13:50:51 --- join: edrx (i=edrx@189.25.193.152) joined #forth 13:51:34 hi slava. 13:52:21 you could say x86 is not language agnostic 13:52:41 yes, it has a certain calling convention set in stone 13:53:39 slava: What's wrong with computed goto? 13:53:41 I have often wished the x86 had not become so popular 13:54:13 i don't really mind it 13:54:24 i just think it's a very silly instruction set 13:54:33 Yes. I agree. 13:54:40 not awful, just not optimal 13:55:13 Shit floats. 13:55:24 one day i'll test this hypothesis 13:55:47 Hey, how many other current archs have hardware emulation for a 30 year old system? 13:56:01 um, none? is my guess. 13:56:25 Exactly! So x86 can't be that bad. 13:56:31 Ha. 13:56:33 lol. :) 13:56:53 which is another way to say "not awful, just not optimal" 13:56:54 shit floats is pro'lly the most profound thing i've read in relation to the topic all day. 13:56:56 Look at how Apple handled moving from motorola to the powerpc. They did it without hardware emulation. 13:57:07 they barely pulled it off 13:57:18 I am not aware... 13:57:25 did you know that until mac os 8.5, the file system implementation was written in m68k assembly? 13:57:38 so even if you had a top of the line g3... every time you hit the fs you'd be running an emulator 13:57:42 Yeah. 13:57:47 I see. 13:58:18 Heh. 13:58:25 But the point is that the hardware is the wrong place to be making such concessions to compatibility. 13:58:37 I suppose the trade off is that the fs doesn't need to be all that fast to be quick enough. 13:58:39 I don't need ancient DOS programs to run at blazing speeds. 13:58:46 fs cannot be fast enough! 13:58:52 I see. 13:58:57 I am corrected. 13:59:29 That was just laziness. 13:59:33 You know better then I. I will try to abstain from talking about what I don't know. I come here to learn. 14:00:14 Being corrected is a good way to learn. 14:00:45 Not the most pleasant perhaps. 14:00:59 indeed. that's why I'm nolonger easily offended. 14:02:42 That would be difficult on IRC 14:03:39 --- quit: edrx (Read error: 104 (Connection reset by peer)) 14:03:49 You know, as the cycle of machine replacement winds on, wouldn't you think that 30 yo software would be replaced as well? Or are there also ( certainly there must be ) 30 year old machines running very important software. 14:04:11 stress very important. 14:05:24 Yeah, like our outpost in the solar system. 14:05:41 Porting software is trivial. 14:05:46 (others might point to banking systems in cobol as "important") 14:05:49 Hehe. 14:06:08 Look at all the architectures Linux runs on. 14:06:09 well, there is that, isn't there. Machines traveling the universe would definately fit the description. 14:06:10 I have my doubts about that. 14:06:37 We don't NEED x86. 14:07:08 I can't imagine banks haveing the same machines... but I CAN imagine them using the same software for 30 years if it works. 14:07:24 machines travelling have an interface...the machine back home does not have to stay the same architecture. 14:08:01 true that. 14:08:03 I can imaging the same people continuing to get rich after 30 years ;) 14:08:13 indeed. 14:08:51 timlarson i've been trying to catch up to y'all in the other chat all afternoon. lol. I'm not quite there yet. 14:09:30 hehe, keep trying, we have a pause right now for you to catch up :) 14:09:47 It's ironic that we're talking about portability... seeing how we probably work/worked on mutually incompatible forths. 14:10:45 I'd like to have many different Forths (varying levels of safety etc) running on a Forth chip. 14:11:43 Preferably one with 64 cores ;-) 14:12:19 i don't know of any forth which can scale to 64 cores 14:12:22 I would like that chip embedded in a tiny system with a virtual projection keyboard and screen. 14:12:44 slava: It doesn't have to scale. They can be dedicated to tasks. 14:12:55 that approach itself doesn't scale ;) 14:13:34 slava: You'd probably end up using 32 of them just for the OS. 14:13:35 Depends on your task I guess. What do you need the power for? In my end: gcc and...hmm... not much else. 14:13:49 i'd rather have multithreading with 64 symmetric cores 14:13:54 instead of dedicating cores to any one task 14:14:16 slava: Some tasks are very boring but very important. GC for instance. 14:14:26 i wouldn't dedicate a core to gc 14:14:39 or have one big shared heap even 14:15:07 Yes, but then you get into the nightmarish realm of ture parallel programming. 14:15:10 sound channels, video (2/3-D), wired networking, wireless networking... 14:15:18 nightmarish? 14:15:36 if all you have is pthreads at your disposal, perhaps 14:15:47 higher-level safe and composable concurrency abstractions exist 14:15:51 Hard on the noggin. Difficult to utilize. 14:16:13 message passing, channels, STM, data parallelism... 14:16:41 Isn't the Forth philosophy to do one thing and do it well? 14:17:26 forth is increasingly left behind 14:17:44 Indeed. 14:34:42 slava: Not to beat a dead horse, but I concur -- x86's design decisions made sense back in 1979, but not now. 14:36:49 --- quit: H4ns (Read error: 104 (Connection reset by peer)) 14:37:34 * Robert tries to imagine a world where the 6502 survived instead of the 8086. Would be nice to see the 16-, 32- and 64-bit patches applied to it. 14:37:50 65816 is the 16-bit patch. 14:37:58 Oh, joy. 14:37:58 The 6502 did survive. ;) 14:38:11 That's the CPU I'm using for the Kestrel. 14:38:25 madgarden: Not as well as x86. 14:38:36 Robert: Actually, not true. 14:38:37 :) 14:38:48 The 6502 survives a whole lot more than the x86, if you look at pure installation numbers. 14:38:50 That said, I implemented some homework assignemnt on 6502 the other day. 14:38:57 kc5tja: Where is it used? 14:38:58 Remember the desktop is only something like 15% of all computers in the world. 14:39:06 Robert: Do you drive a car? ;) 14:39:10 No. 14:39:27 I thought embedded designers started to move away from 6502 a while ago. 14:39:32 Nope. 14:40:23 There are 400MHz 6502 and 65816 systems out there, all of which are used as cores of ASICs. 14:40:33 Heh 14:40:44 That's pretty neat. 14:40:50 Yeah. 14:40:58 I guess the gate count isn't that high. 14:41:08 But, still, I'd rather RISC took over the desktop. x86 really does suck, from a programmer's perspective. 14:41:26 Gate count, and also static current draw is really low too. 14:41:26 Robert, and anyway you said "survived," not "conquered the desktop." 14:41:50 madgarden: I really didn't think 6502 survived into the 90s and beyond. 14:42:07 (except in dark, horrible places, like my room) 14:43:16 Not particularly efficient compared to modern archs though. Cycles per instruction rather than the other way around. 14:45:18 Well, that is true. But, the 6502 is still the fastest CISC processor in its class. :) 14:46:43 I originally wanted to use the 68000 CPU for my Kestrel, but their availability is dropping like a rock. 14:46:58 And the prices are not competitive, *AND* they have 64 pins on the chip (versus 40 on the 65816). 14:47:05 SO it all added up to make an expensive board. 14:47:23 Then I thought, "OK, I'll try a MISC chip inside an FPGA!" 14:47:27 Until I saw the FPGA prices. :) 14:47:46 And then there were the Patriot Scientific patent lawsuits. 14:47:51 I decided to just go back to the 6581. 14:47:54 65816 rather. 14:48:28 Yeah, not very cheap. I haven't really got around to building any microcomputer systems, but when the time comes, I have a gathered a supply of ICs from flea markets and such. 14:50:07 Tubes full of Z80, 1802, etc. and memory. 14:50:20 40-pin DIL, all very modern. 14:50:43 There's a shortage of 68000's? 14:51:05 What about the armies of obsolete Palm's? 14:51:33 male: What about them? 14:51:44 Crack 'em open. 14:51:48 No 14:52:33 Heh 14:52:50 They just end up as landfill. 14:53:01 OK, so you pay $25 to $50 for a used Palm. 14:53:07 HA! 14:53:09 That is already $40 more than the cost of a 65816. 14:53:25 They're well under $1. 14:53:34 Then you have to desolder the CPU, which is not a 68000, but a 683xx series chip, and has hundreds (yes, hundreds) of pins. 14:53:35 I have several I got free. 14:53:58 It's a surface mount device, which means you'll need a hot-air gun to get the thing off. 14:54:06 Yeah. 14:54:10 You'll have a massive failure rate, because chips and hot-air guns don't like each other. 14:54:21 I use a toaster oven... 14:54:29 But go on. 14:54:38 That's good for soldering surface mount devices, but not for desoldering. 14:54:59 I use a blow torch on thru-hole boards! 14:55:38 Chips aren't as fragile as you'd think. 14:55:45 If you're going to go through THAT kind of effort just to get your hands on a CPU that nobody makes in any significant quantities anymore, you just might as well LEAVE it there and use the cracked open Palm itself as the motherboard. 14:56:01 Even better. 14:56:04 A blow-torch is a bit more directed heat than an air gun is though. :) 14:56:14 But the Palm lacks the features that *I* want. 14:56:45 Okay okay. I'm just saying didn't know there was a shortage on 68xxx. 14:57:22 Oh yes. Coldfire is as close as you're going to get, and even then, they still cost more than I'd like to pay. 14:57:25 But I never buy anything new, so I've probably got a warpped view. 15:00:22 kc5tja: 4Mhz? Why don't you just use an Atari ST or something? 15:00:41 male: I need more information before I can answer you. 15:00:47 he's making his own computer 15:00:52 BTW, a 4MHz 65816 is _about_ as fast as an 8MHz 68000. 15:00:53 I know that. 15:01:02 kc5tja: i didn't know it was so fast 15:01:03 Yeah. My ST is 16Mhz. 15:01:08 And I didn't even have to build it. 15:01:17 where's the fun in that? 15:01:21 The Kestrel-2 will run at 12.6MHz (1/2 the VGA dot clock frequency) 15:02:13 Well, if the fun is in using it, I'd go with the ST. If the fun is in building it, then, hey, why go beyond the Elf. 15:02:26 slava: It isn't always easy to achieve those speeds, but it is doable. Typically not something a compiler is able to take advantage of without enormous effort. 15:02:49 male: The fun is in both using and building it. 15:03:39 If all you do is use prefabricated _everything_, then you have an understanding of _nothing_. 15:03:56 kc5tja: You could even just write an emulator for your ideal arch, and it would run faster than 4Mhz on x86. 15:04:11 You are behind the times. 15:04:15 Again, see my Kestrel-2 pages. 15:04:19 It's not like you're building your own CPU. 15:04:20 Okay. 15:04:32 I think you're only seeing the Kestrel-1. 15:04:45 BTW, I have built my own CPU before, and it worked remarkably well. 15:04:47 Gotcha. 15:04:50 * kc5tja wants to find the time to do it again. 15:05:18 --- quit: Raystm2 ("Should have paid the bill.") 15:05:29 Kestrel-2 will be an FPGA-based system, which will implement the "chipset". 15:05:48 It will also likely be the last Kestrel to use the 65816 as well. 15:06:02 are you working on kestrel right now? 15:06:19 Not actively. Work is sucking the creative energy right out of me. 15:09:09 kc5tja: Did you ever get into colorForth? I adapted it to run on the Linux framebuffer once and it felt like pretty good simulation of an operating system. 15:10:08 I wonder how a bunch of very individual people could form a company that would make a profit without suching out the creative energy? 15:10:10 --- join: crest_ (n=crest@p5489C42B.dip.t-dialin.net) joined #forth 15:18:15 --- quit: crest__ (Read error: 110 (Connection timed out)) 15:32:58 --- join: nighty__ (n=nighty@sushi.rural-networks.com) joined #forth 15:36:51 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 15:36:51 --- mode: ChanServ set +o tathi 15:44:12 --- join: FMota (n=FMota@dhcp-36-203-57-69.cf-res.cfu.net) joined #forth 15:49:03 --- quit: nighty^ (Read error: 113 (No route to host)) 15:49:51 male: ColorForth doesn't do anything for me. 15:50:14 colorforth gives me a hard on 15:50:25 I mean, it's really innovative, and I like how it extends programming into a two-dimensional work (where color is the other dimension). But, without create/does>, I'm just a fish out of water. 15:50:57 create/does> is nothing compared to the lack of, or you know, basic support for stuff like printing text to the screen 15:51:00 slava: I do hope you were being facetious. :) 15:51:24 Nothing in CF prevents printing stuff to the screen. 15:51:32 nothing makes it easy, either. 15:51:37 Just because the words for it aren't written doesn't make it an impossibility. 15:51:45 It's no easier nor harder than in any other Forth. 15:51:50 it's harder. 15:51:54 Why? 15:52:05 the core code to dispaly to the screen only exposes a routine to print huffman-encoded "words" of up to 5 characters each 15:52:10 * kc5tja notes that Kestrel Forth had to go through the same basic motions as CF to print stuff to the screen. 15:52:17 if you want to print a string of characters, write your own goddamn blitter 15:52:28 Which only proves my point. 15:52:29 Perfectly. 15:52:38 but you're using ascii, not some moronic "i want to compress my 5kb of source down to 2kb" huffman encoding where your word names are limited to 5 characters 15:52:52 That's irrelavent. 15:53:02 What you're saying is that ColorForth makes printing text to the screen harder. 15:53:05 it is relevant when your colorforth doesn't even give you a useful _font_ 15:53:12 i am, because it has nothing built in to help 15:53:24 there's no ." word 15:53:35 and no factors you could use to make one 15:53:39 Look. It's neither harder nor easier than having to write your own code in a punctuated Forth. 15:53:49 right 15:53:54 MY point is that create/does> is a physicaly IMPOSSIBILITY in ColorForth. 15:53:59 but in most punctuated forths, you don't have to write your own code to do it :) 15:54:07 Well, true that. :) 15:54:17 But, still, when I and sorear had to write the Kestrel's code, it sucked. :) 15:54:43 * kc5tja has pondered the possiblity of a "font forth" for the Kestrel (since it lacks color support at the moment). 15:54:50 heh 15:54:53 However, not without a punctuated Forth underneath it first. :) 15:54:56 i'd suggset sticking with plain text 15:55:33 Well, it depends. 15:55:40 Color is damn nice to have. 15:55:46 yes 15:55:54 but i'm not sure a color language is a good idea 15:55:58 Have you read up on "intentional programming?" 15:56:07 no 15:56:29 It's like Smalltalk, where the program is kept internally in a raw, parse-tree format. 15:56:49 i'm familiar with this idea 15:56:57 Then, to edit the program, you can instantiate a view on the code (read, on the parse tree) which decompiles it and recompiles it on demand as you make changes in the view. 15:57:06 yup 15:57:13 So, theoretically, I can have an Oberon view, a Lisp view, etc. 16:07:02 The manifestation of color isn't really the point. The point is preparsed, structured source. 16:07:41 Which does away with many problems. 16:08:17 And opens up a world of possibility for the editor. 16:08:26 --- join: wossname (n=w@CPE00195b252b77-CM001a666a6e78.cpe.net.cable.rogers.com) joined #forth 16:09:23 .. So if you have a "color" forth on top of a "punctuated" forth, you're just adding fluff. 16:09:36 Not to mention complexity. 16:10:17 Might as well just have a syntax highlighting editor... 16:10:35 Anyone up for writing an Emacs in Forth? 16:11:07 I thought not! 16:11:28 there's a guy working on an editor in factor 16:12:24 Sounds neat. 16:12:26 is equivalent to a colorforth editor where tokens have edit semantics and <->plaintext semantics 16:12:41 vi clone, though :) 16:12:50 slava: Even better ;-) 16:13:52 I wrote a vi-like editor with a forth-like command language once as an example program for my datastructures library. 16:14:06 Took about a day. 16:14:24 I wrote VIBE in Forth. ;) 16:15:06 However, to be honest, nobody wants to write an editor in Forth because there are already too many editors as it is. 16:15:27 Too many practically identical editors, yes. 16:15:36 But not too many innovative ones. 16:15:48 So, let's work towards a recreation of the Canon Cat. 16:15:58 i think an editor in factor would be interesting as a showcase of libraries, maybe not very useful though 16:16:02 I really liked STOIC's editor ED. 16:16:09 you'd have unicode text rendering and a portable gui 16:16:31 if somebody finished the regex library, we could use the xml parser to parse jedit syntax definitions, and get syntax highlighting for like 200 file types 16:16:37 * male doesn't use guis to edit text 16:16:54 male: That is a pity; they can offer a lot. 16:17:11 After all, to a monitor, it's all graphics anyway. 16:17:15 kc5tja: Yeah. Like tetris... 16:17:28 male: Tetris is easier to write for text than it is for a graphical screen. 16:17:32 writing a gui editor is easier than writing an ncurses editor 16:17:45 at least IMO 16:17:52 Having used ncurses extensively, I do not agree. 16:17:54 ncurses and it's friends are wretched 16:18:03 give me a decent gui toolkit any day 16:18:09 not javax.swing 16:18:31 ncurses is only a pain if you don't know how to factor and abstract it away from your program! 16:18:31 You know what I really miss from modern GUI APIs? 16:18:38 The ability to just #*$&(*%ing draw stuff on a window. 16:18:44 Yeah. 16:18:52 But that's SLOW. 16:18:52 I can't just say, "Open a window, and plot text here, and draw a line there." 16:18:58 errr 16:19:00 uhhhh 16:19:01 You can with Xlib. 16:19:02 no. 16:19:08 Or SDL. 16:19:17 SDL is a virtual frame buffer. 16:19:32 And you can't have more than one window open at a time. 16:19:37 huh? 16:19:38 Because SDL is non-reentrant. 16:19:42 you can certainly open a window and draw stuff 16:19:44 Use glut then. 16:19:46 but you draw in a refresh callback 16:20:00 there are many issues with ncurses 16:20:01 slava: What are you talking about? 16:20:07 first, it's all macros, so it's hard to bind to from another language 16:20:21 second, basic shit like backspace -vs- delete, function keys, home/end, don't work in a consistent way 16:20:25 --- join: tgunr (n=davec@70-41-240-186.cust.wildblue.net) joined #forth 16:20:49 They work if termcap works. 16:20:49 third, there's that huge 'terminfo' database with 2340234 terminal types nobody ever uses 16:21:00 Hey, I use them! 16:21:07 I've even added a few! 16:21:08 kc5tja: You know what I really miss from modern GUI APIs? 16:21:08 [7:17pm] kc5tja: The ability to just #*$&(*%ing draw stuff on a window. 16:21:17 i was referring to this 16:21:20 i'm not sure what you mean 16:21:25 any gui toolkit lets you draw stuff to a window 16:21:28 slava: Yes. Compare how to do this in, say, AmigaOS versus, oh, say Gdk, or Qt, or... 16:21:40 That's because those are widget based. 16:21:47 So what? 16:21:49 but you can create a blank widget and draw there 16:21:51 Wrong level. 16:22:00 most provide 'canvas' widgets for this purpose 16:22:06 slava: I've tried that once, and the amount of code involved was astronomical. 16:22:18 Yeah, but if that's all you're going to do then you certainly don't need GTK or QT. 16:22:25 gtk and qt are not known for conciseness 16:22:32 male: right 16:22:46 male: But it's not all I want to do. Obviously 16:22:48 certainly with cocoa it is very easy to open, say, an NSOpenGLView and have your way with her 16:22:53 I use SDL for those kinds of apps. 16:23:00 Even though SDL sucks. 16:23:05 or subclass NSView and use coregraphics rendering functions 16:23:11 It requires very little boilerplate. 16:23:44 --- quit: tgunr (Client Quit) 16:24:07 the main thing is that most guis have an inversion of control 16:24:10 That's what I liked about AmigaOS. You can have your widgets, and draw directly to the window too. Use the right tool, for the right job, at the right time. 16:24:18 the gui toolkit asks you to redraw your view when it's ready, you don't just draw stuff on a whim 16:24:33 slava: Of course!! 16:24:38 That happened in AmigaOS too. 16:24:41 kc5tja: i don't see how that's different from having a window containing widgets, some custom, some pre-baked 16:24:41 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth 16:24:49 where the custom widgets draw what you want to draw 16:24:55 if you're talking about boilerplate, well that's a different issue 16:25:05 many toolkits involve a ton of boilerplate even when you're not doing custom rendering 16:25:12 in java, setting up a dialog with ok/cancel buttons is an ordeal 16:25:24 That's the thing -- it is *ALL* boilerplate. 16:25:31 (What DO you think I was talking about?) 16:25:40 not all toolkits suck, though. 16:25:48 No, only the ones that poeple actually use. 16:25:58 i guess you can say that. 16:26:03 i'm quite fond of cocoa 16:26:08 it's a lot less boilerplatey than the others 16:26:10 Never used it, don't plan on doing so. 16:26:27 cocoa is one of those toolkits people use, though. 16:26:45 Well, if Cocoa is the NeXTStep API, then remember that it evolved in a time before boilerplate was the big thing. 16:26:56 it is the next step api with many changes 16:27:24 boilerplate is what yo uget when procedural programmers discover OOP 16:27:31 People use Cocoa, but Cocoa isn't broadly applicable to all platforms. 16:27:35 Gtk is portable to all platforms. 16:27:36 and go nuts with indirection instead of learning OOP 16:27:43 gtk doesn't run so well on windows or mac 16:27:51 well, it runs, but it doesn't fit in with native conventions there 16:27:51 It runs well enough. 16:28:06 The same could be said of WxWidgets too. 16:28:06 doe sgtk still require x11 on mac os? 16:28:30 No. 16:28:34 i still run some athena toolkit apps on mac os x, in x11.app 16:28:38 they look _very_ out of place 16:28:40 xfig and xdvi mainly 16:29:40 so what is the solution (seeing as I would prefer to have one than to keep wishing I had one)? 16:30:08 if i was writing an app for end users i'd use native toolkits 16:30:14 gtk on linux, win32 on windows, cocoa on mac 16:31:15 any kc5tja solutions to go with that? 16:31:43 I don't have a solution, because it is an unsolvable problem. 16:32:16 Amazing how so many people solve it. 16:32:17 no future solution? doomed to be bad forever? 16:32:17 The closest solution would be the GEM user interface system. 16:32:25 timlarson: Yes. 16:32:37 male: No. They don't solve a damn thing. They just "put up with it." 16:33:04 Stronger minds, I suppose. 16:33:17 No, just different. 16:33:36 GEM is obsolete and irrelevant 16:33:46 In the specific, yes. 16:33:51 --- join: doublec (n=doublec@203-211-95-213.ue.woosh.co.nz) joined #forth 16:33:59 In the generic, however, it's overarching architecture is still relevant. 16:34:05 I did not get to use GEM...could you describe the relevant aspects? 16:34:24 kc5tja: sure, but in the context of actually delivering gui apps to users, there aren't many options these days 16:34:25 GEM is a horizontal collection of libraries that work together to manage screen real-estate. 16:34:32 you either use something like swing or wxwidgets, or you use the platform's native api 16:34:47 i don't consider squeak, mcclim or anything like that a viable choice 16:34:55 Versus literally _everything_ else on the market, which are vertically-stacked libraries, designed to all but think for you. 16:35:49 timlarson: As far as actually _using_ GEM, it is no different than MacOS or Windows -- it's a WIMP environment like the others. 16:36:33 slava: did I miss something? Where did squeak, et. al. enter the discussion? 16:36:51 how does this horizontal cooperating library approach play out? 16:37:04 i was just pointing out that there are toolkits which are ideal in theory but don't work out in practice 16:37:22 sounds like basic good design...minimizing unneccessary binding in the system 16:37:32 timlarson: You have the VDI, which is kind of like SDL -- it virtualizes access to the frame buffer via a bunch of low-level graphics routines. When you call a VDI function, you literally are drawing onto the video card's real, honest to goodness frame buffer. 16:37:47 today's video cards don't even have frame buffers 16:38:02 timlarson: The AES is what manages the windows, menus, etc. The application solicits information from the AES on where it may draw onto the screen, etc. 16:38:07 slava: Yes they do. 16:38:12 They most absolutely, positively, 100% do. 16:38:16 Yeah. WTF? 16:38:31 Even AGP bus is considered "too slow" for read/write work. :) 16:38:43 so it is cooperative? apps can write into each other's spaces if they so desire? 16:39:12 timlarson: It may. The AES usually sets up clipping rectangles in the VDI, but the application draws using the coordinate spaces given to it by the AES. 16:40:05 --- quit: nighty__ (Read error: 113 (No route to host)) 16:40:15 It's actually a very Unix-y approach when you think about it -- small API, with lots of interconnections possible via the application. Enhancing video graphics capabilities involves ONLY the VDI; no need to retrofit the AES (versus when new features come out today, where you need to upgrade the entirety of your X11 suite). 16:40:32 so it could still be protective, as a design decision, ok. 16:40:38 --- join: H4ns (n=Hans@host-216-153-144-216.spr.choiceone.net) joined #forth 16:40:39 Right. 16:41:09 And, third-party widget libraries are still possible (but they're true libraries, not frameworks, so you remain in control). 16:41:33 I like that...can we get that (design) back somehow? 16:41:40 Not anymore. :( 16:41:54 Nobody would consider this kind of architecture -- because it's cooperative, it must be a bad design. 16:42:08 even simulated in a mem buffer sounds better 16:42:22 Because there a _reversion_ of control (versus inversion of control), it must involve more code. 16:42:25 etc. 16:42:43 I was planning on employing a GEM-alike architecture with the Kestrel. 16:42:44 kc5tja: You can bypass toolkits and use Xlib or Xt. 16:42:47 s/sounds better/still sounds better 16:42:59 male: And lose all the benefits of normal desktop integration in the process. 16:43:24 you know, there is that new architecture coming along...OLPC... 16:43:25 Xlib wouldn't be so bad were it not for its horrifying lack of color management skills. :) 16:43:28 kc5tja: Desktop integration? Sounds like a marketing term. 16:43:46 * male manages color in Xlib just fine. 16:43:50 if we fix it now, at least the poor of the world could enjoy programming with it 16:44:11 male: You want cut-n-paste? You want pretty icons when you minimize your windows? You want drag-n-drop? You either hack it yourself or use GTK. That's about the sum of it. 16:44:47 kc5tja: I don't use any of that stuff. I use a keyboard-driven tiling WM written in 100% Common Lisp. 16:44:59 --- part: tathi left #forth 16:45:02 male: I like xmonad myself. 16:45:08 The desktop metaphor is broken. 16:45:21 But, that being said, there is still a need for mouse-driven interfaces. 16:45:40 I type about 90WPM when I'm in the groove, but I still use a mouse for a lot of things. 16:45:41 Not if you have a light-pen! 16:45:55 Screw the light pen. I want touch screen! 16:46:02 That would all but eliminate my need for a mouse. 16:46:10 Too many fingerprints! 16:46:11 Except for when I'm in the Gimp. 16:46:32 True, but at least it is my fingerprints, and not someone else's. :) 16:47:10 (BTW, CL is also on my list of languages to learn.) 16:47:44 Well if you'd like to improve your attitude regards GUIs, we could always use some help on StumpWM. 16:47:57 Is this the WM you use? 16:48:24 I'm using right now, and modifying it while I do. 16:49:20 One of the original X11 window managers was written in Forth as I recall. 16:49:38 Working with Lisp makes me miss Forth. 16:49:49 Really? 16:49:53 * kc5tja googles 16:49:57 I thought twm was the original. 16:50:09 ONE of the original, not THE original. :) 16:51:22 Mitch Bradley's "uwm" 16:52:35 Scripted in Forth. 16:52:47 Still neat though. 17:00:18 Ahh, I thought it was written in Forth. 17:00:23 Oh well, still better than nothing. 17:01:11 --- join: geartooth (n=w@CPE00195b252b77-CM001a666a6e78.cpe.net.cable.rogers.com) joined #forth 17:19:12 --- quit: wossname (Connection timed out) 17:22:44 --- quit: doublec (Read error: 104 (Connection reset by peer)) 17:33:39 --- nick: geartooth -> wossname 17:38:55 --- join: I440r (n=mark4@ip70-190-68-238.ph.ph.cox.net) joined #forth 17:40:24 male: I've reviewed stumpwm, and I'm not thinking it's for me. I'll stick with xmonad. Thanks for the suggestion though. :) 17:50:49 can xmonad assign >1 window to a tile? 17:50:57 I don't think so. 17:51:08 StumpWM is decended from GNU Screen. 17:51:22 Xmonand is from dwm/wmii which are fully dynamic. 17:51:32 s/monand/monad/ 17:52:05 If you like screen, you'll like StumpWM ;-) 17:53:47 I guess it's the do-what-I-tell-you vs. do-what-you-think-is-best issue. 17:54:07 I like software that does what I tell it. 18:00:29 --- quit: H4ns (Read error: 110 (Connection timed out)) 18:06:06 I like screen. 18:07:07 But, it looks as if stumpwm still requires a bit of manual screen layout. 18:07:16 I prefer to let the wm do that stuff for me. 18:07:47 There is that small matter of getting the environment off the ground too. 18:07:48 :) 18:16:54 Yeah, well, the bootstraping problem comes with the Lisp territory. 18:17:31 StumpWM has static frame layout, but it also has (in my tree at least) automatic rule-based window placement. 18:17:54 I get very unnerved when moving from one window to another requires rearranging and repainting the entire screen. 18:19:23 The idea is that you split/merge frames as YOU see fit, instead of having the WM go nuts arranging them dynamically. 18:20:09 Using multi-windowed applications with dwm or xmonad--forget it. 18:22:11 Right now we're getting lots of ex Ion and Xmonad users. 18:22:48 Ion because of the insanity of its author and Xmonad because of, I presume, eye strain. 18:25:29 I'd love to have a Forth based WM just for the novelty, but I feel like it would be constantly begging one to reimplement NeWS. 18:36:43 projecting from personal experience, that is no doubt why nobody has completed one ;-) 18:36:58 --- join: H4ns (n=Hans@host-216-153-144-216.spr.choiceone.net) joined #forth 18:42:39 Using multi-windowed applications with stump wouldn't be any better than with xmonad. 18:43:17 kc5tja: How so? 18:43:24 NeWS is widely regarded as superior to X11. One must wonder why not, if this is true. 18:44:59 I use multi-windowed applications with xmonad all the time. 18:45:19 I'm not sure how eye-strain enters into it. 18:45:20 kc5tja: And you don't find it a pain to only be able to work with one window at a time? 18:45:38 This question, coming from someone who likes screen so much? 18:45:47 Screen is the epitome of one-window-at-a-time philosophy. 18:46:09 xmonad lets you work with a number of windows concurrently. 18:46:21 All xmonad does is rearrange them so that they're all on screen at a time. 18:46:27 kc5tja: Obviously you never got very far with Screen ;-) 18:46:33 Only one window has half the screen. 18:46:37 Corrent. 18:46:40 male: I have gotten quite far with it. 18:46:42 That's very wasteful. 18:46:46 But using its pains is most painful. 18:46:57 panes even 18:46:59 Many tiny windows might as well be hidden. 18:47:04 No. 18:47:14 *ALL* windows that are on the screen are visible concurrently. 18:47:26 There are never any hidden windows. 18:47:43 But tiny windows are useless, they just take up space. 18:47:59 Well, don't put 100 windows on a single screen. 18:48:02 Only have as many frames as you intend to have windows in to work with. 18:48:03 That's why you have 10 workspaces. 18:48:20 xmonad always meets your constraint. 18:48:20 * male has an unlimited number of workspaces. 18:48:29 But rarely uses more than 4. 18:48:38 I rarely use more than 2 with xmonad. 18:49:04 I'm not out to belittle stumpwm. I think it's neat. 18:49:21 But, I really think you're making a mountain out of a non-existant anthill with respect to xmonad. 18:49:49 I just don't see the difference between tiny windows and icons. 18:49:54 And I don't like icons ;-) 18:50:23 And I don't see the difference between tiny windows and http://hocwp.free.fr/stumpwm/stumpwm.png 18:51:11 Hey, I didn't take that screenshow. 18:51:12 t 18:51:16 * kc5tja shrugs 18:51:32 That's obviously a very inefficient use of the WM. 18:51:51 Besides, you can't tell much about Xmonad from a screenshot either. 18:52:17 sitting here with stumpwm+one xterm and i don't see any key bindings in the README 18:52:26 C-t ? 18:53:01 It's just like Screen only with C-t instead of C-a. 18:53:47 The only keys I use on a regular basis with screen are C-a a, C-a ", and C-a N (where N is an integer between 0 and 9 inclusive) 19:02:43 hum. i think i'll stick with ion for now 19:05:04 XeF4: Any particular reason? 19:05:41 XeF4: If you want to use Ion please consider running Tritium instead. Ion is deprecated for non-freedom. 19:08:52 male: comfort, gargantuan sbcl footprint, lack of interest in reading stumpwm sources right now 19:09:53 XeF4: Yes SBCL is pretty ridiculous. I use clisp, which is faster and much lighter. 19:12:12 But still, it is Lisp. If you want something stripped down, check out ratpoison, StumpWM's predecessor. 19:12:29 (which is written in C 19:13:48 looks like ion is still lgpl+obnoxious name clause 19:13:55 (re non-freedom) 19:15:52 XeF4: Expect more shenanigans. 19:17:19 ratpoison was not too bad...I used it when I was on a small-screened laptop. 19:18:19 timlarson: Yes, RP is great if you really only want one or two frames and don't plan on doing any advanced scripting/customization. 19:18:45 that was all I needed it for 19:18:56 timlarson: And it's certainly appropriate for low-mem machines. 19:19:58 Personally, I would have used a forth-like scripting language to extend RP rather than reimplementing it in CL. 19:20:50 --- join: edrx (i=edrx@189.25.19.1) joined #forth 19:28:40 --- quit: wossname () 19:28:51 --- join: wossname (n=w@CPE00195b252b77-CM001a666a6e78.cpe.net.cable.rogers.com) joined #forth 19:34:42 Sounds like Factor would be what you're looking for then. 19:34:47 Forth would be nice, but it's too dangerous. 19:35:09 One stack imbalance will bring your WM down faster and more spectacularly than the Hindenburg. :) 19:35:17 Factor is interesting, but for one thing I'm new to it, and for another thing its quite slow. 19:35:30 kc5tja: I'm well aware ;-) 19:35:51 OTOH, the fact that it would use Forth would add that much more "geek factor" to it. :) 19:35:59 "Heh, MY scripts don't crash the WM." 19:36:04 I would tend to use something like ficl. 19:36:12 That would be my next suggestion. 19:36:19 Or my own system, assuming I ever get back to it. 19:36:43 Or, how about using ColorForth? ;D 19:36:56 Now that would be the ultimate in NICHE. :D 19:37:00 Well, that's not a bad idea. 19:37:07 The WM is in your face, and so is CF. 19:37:18 I guess one just needs a windowing CF. 19:37:24 Hehe, the CF environment would be the root window. 19:37:33 Everything else sits on top. 19:38:25 Honestly, 90% of writing a WM is dealing with broken apps and vague ad-hoc standards. 19:38:49 You can get by with far less if you close it off (like Chuck likes to do) 19:40:07 Part of the power of StumWM that Lisp provides and Forth could too is that all I have to do is hit a key in Vim to have any part of the source I'm editing reevaluated by the running image. 19:40:48 Well, Lisp is far more amenable to that than Forth is. 19:41:03 Depends on the Forth ;-) 19:41:05 In Forth, you'd have to forget the definition you're looking to redefine, and everything after it, then recompile from that point on. 19:41:37 Well, I'm a little off-the-beaten path when it comes to Forth. 19:41:46 CL supports retroactive defuns? ooooooo 19:41:51 I like things like pointer safety, gc, and dynamic memory management. 19:41:57 And my own system reflects that. 19:42:11 I am liking the sound of that 19:42:11 As to many other Forth-likes. 19:42:32 XeF4: As does Scheme. In fact, any Lisp environment I'm aware of does. 19:42:35 toss in some term-rewriting/constraint-satisfaction 19:42:46 there are more forths than forth programmers, arent there 19:42:47 timlarson: I just wrote an interactive shell for StumpWM today ;-) 19:43:10 Would seem so. 19:43:16 * kc5tja thinks we should make a window manager in Forth, but using the J language for scripting. >:D 19:43:30 I've written at least 5 systems, one of them serious. 19:43:32 That way, all of your extensions will fit on a single line. :D 19:44:14 Yes. An important consideration is that the Forth used for scripting a program need not be the same (potentially dangerous) Forth used to implement it. 19:44:28 lets make the window manager and the app the same thing... 19:44:55 timlarson: What do you mean? 19:45:00 timlarson: You've just described MDI. 19:45:20 Nahh -- the app has nothing to do with rendering MDI windows. 19:45:25 I think it's closer to GEOS. :) 19:45:30 so we have a safe forth, constraints, layout... 19:45:32 GEOS/64 and /128 that is. 19:45:55 interactive distributed dynamic data interaction tool 19:46:42 new-standard browser 19:53:50 --- join: crest__ (n=crest@p5489D741.dip.t-dialin.net) joined #forth 19:57:39 What I've been thinking of was a Forth system where globals weren't really globals, but rather members of a class, and colon definitions are just methods on that class. 19:58:50 Oh well. A daydream for another day. 20:01:06 kc5tja: Not sure I follow. 20:01:33 object orientation via resolution restriction 20:01:49 --- quit: crest_ (Read error: 110 (Connection timed out)) 20:02:31 Yes, but, practically, how is this different from a Forth with a strong vocabulary/branch system? 20:06:49 --- quit: H4ns (Read error: 110 (Connection timed out)) 20:11:19 It's critically different. 20:11:33 Forth is absolutely horrible at manipulating 'objects' as we currently know them. 20:12:22 Unless it's an OO Forth. 20:12:24 This would offload some of the responsibility for managing and using objects to the language environment. 20:12:35 * (defun foo (a b) (+ a b)) (defun bar (a b) (foo a b)) (defun foo (a b) (- a b)) (bar 3 2) 20:12:52 hm, indeed it does 20:13:05 XeF4: I can't believe that shocks you ;-) 20:13:39 * kc5tja likes having contextual words like in Forth. 20:14:23 Eventually, if I ever get off my ass and hack again on Kestrel, I'll add an explicit "replace" keyword. 20:14:26 : foo + ; 20:14:30 : bar foo ; 20:14:32 : foo -; 20:14:45 2 3 bar => 5 20:14:54 : foo - ; replace 20:14:58 2 3 bar => -1 20:15:02 male: it doesn't shock me. i just thought i had vague memories of it not working in CL (and of being shocked when it didn't work). must be forgetting some important detail 20:15:49 kc5tja: Replacements require either an extra indirection or rewriting the affected code. 20:16:00 Yup. 20:16:11 The cost is the same as a DEFER'ed word. 20:16:24 kc5tja: Not necessarily. 20:16:27 less because one can patch a ju* (defun foo (a b) (+ a b)) (defun bar (a b) (foo a b)) (defun foo (a b) (- a b)) (bar 3 2) 20:16:31 doh 20:16:34 kc5tja: It can be cheaper. 20:16:38 male: All a DEFER'ed word is is a jump to another word. 20:16:41 How? 20:16:50 one can patch a jump into the old compiled code 20:17:02 so a word that has never been REPLACEd doesn't incur the cost 20:17:02 Now THAT is an expensive operation. :) 20:17:17 kc5tja: Never mind then. You're right. I was thinking of a DEFER that searched the dictionary. 20:17:48 XeF4: True. 20:17:49 XeF4: My system also doesn't incur a performance hit if you never replace the word. 20:18:16 As I envision it, replace would just overwrite the first 3 to 5 bytes of the old definition with a JMP instruction. 20:18:28 But if the software is indended to ever be reloaded, then that's not such an improvement. 20:18:35 (Kestrel Forth is a subroutine-threaded Forth; similar techniques exist for other threadings) 20:19:01 male: The idea is to allow fixing of existing code without incuring the expense of recompiling it. 20:19:52 kc5tja: I realize that, but with large changes it's often simpler to reload all definitions. 20:20:08 Yeah, but in Forth, I've often found myself doing this at the CLI: 20:20:10 : foo ... ; 20:20:11 : bar ... ; 20:20:13 kc5tja: Unless you've got an editor smart enough to only redefine the changed defs. 20:20:17 x y z bar -=> error 20:20:19 crap! 20:20:21 : foo .... ; 20:20:24 : bar ... ; 20:20:25 etc. 20:20:47 Again, I don't see why people are talking about having to only redefine the changed defs. 20:20:54 It's those changed defs that I'm very much talking about. :) 20:21:20 kc5tja: i was referring to overwriting the start of the old def with a JMP 20:21:25 (as you said) 20:30:51 otoh, having REPLACEd words in the dictionary could have unfortunate consequences after a FORGET 20:32:51 Yes, that is very true. 20:32:55 I don't see any way around that though. 20:33:47 aoeuaoeu oeau aoeu aoeu 20:33:59 oops. 20:35:43 XeF4: Such as? 20:36:25 XeF4: If you've got words pointing to FORGOTten words, you're in trouble anyway. 20:37:48 male: because REPLACEd words now have dangling pointers to their FORGOTten redefinitions 20:37:49 Well, that is precisely what would happen. 20:38:35 That is where a real GC would come in handy. 20:38:46 --- join: crest_ (n=crest@p5489F722.dip.t-dialin.net) joined #forth 20:39:27 one could use a compacting FORGET that keeps track of replaces but that would be rediculous 20:39:36 ridiulous 20:39:44 ridiculous 20:40:06 my 1337 Dvorak skills are failing me tonight. :) 20:41:16 MARKER words would work for this, though. 20:42:06 i last wrote significant forth in .fi ~2.5 years ago and now my fingers expect a .fi keymap when i type at gforth 20:42:22 Hehehe :) 20:47:15 --- quit: crest__ (Read error: 110 (Connection timed out)) 20:53:46 and the marker word restores all the bytes overwritten by REPLACE? 20:53:48 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth 20:59:32 That's how I'd do it, yeah. 21:00:28 But, realistically, I'd just stick with the GC idea. 21:00:44 brb 21:09:48 --- join: crest__ (n=crest@p5489E434.dip.t-dialin.net) joined #forth 21:13:48 back 21:14:30 --- part: edrx left #forth 21:16:55 --- quit: crest_ (Read error: 110 (Connection timed out)) 21:37:30 --- nick: male -> fob 21:38:14 --- nick: fob -> male 21:48:16 --- join: mark4_ (n=mark4@ip70-190-68-238.ph.ph.cox.net) joined #forth 22:02:26 http://blaugh.com/2007/06/18/good-quality-pet-blogging/ 22:06:04 --- quit: I440r (Read error: 110 (Connection timed out)) 22:08:55 --- quit: mark4_ (Read error: 110 (Connection timed out)) 22:19:20 This is a warped comic. 22:41:03 --- quit: Al2O3 ("Eggplant & SenseTalk: Driving Success Through Automation") 22:50:19 http://blaugh.com/2006/08/01/apple-of-my-eye/ 23:04:13 --- join: mr_proteus (n=proteusg@ppp-124.120.216.189.revip2.asianet.co.th) joined #forth 23:04:13 --- quit: proteusguy (Read error: 110 (Connection timed out)) 23:59:59 --- log: ended forth/07.09.22