00:00:00 --- log: started forth/02.08.04 00:00:33 But here's the conundrum: what if I want to append a block to a specific program, without affecting the remainder? I'd have to implement a block copy for blocks that somehow wouldn't shift the remainder of the blocks. 00:00:45 It's still doable. 00:00:52 I'll have to think on that for a bit. 00:01:36 hmm 00:02:02 when you are thinking about these things, blocks & filesystems, you are thinking about FS/Forth? 00:02:14 and you are concerned about portability of your pygmy code ?? 00:03:06 Yes and no to both questions. 00:03:31 I'm just looking for good ways of implementing storage mechanisms that aren't overly complicated. 00:03:48 Striving for backward compatibility is an issue, but it's not critical. 00:03:59 I'm willing to break backward compatibility if necessary with FS/Forth. 00:04:27 i think it would be a good idea to have zero concern for backward compatibility 00:04:34 otherwise it'll suck you backwards :P 00:04:52 look at intel processors ;) 00:07:09 I disagree. 00:07:38 FS/Forth will need a persistence system of some kind. Blocks are the easiest and most economical way to implement this. 00:08:23 FS/Forths blocks, if we go with address-space centric view of blocks will be largely incompatible with Pygmy's use of blocks. 00:08:44 However, once in the Forth environment, I still need some way of getting data from and putting data back on to a storage volume. 00:09:16 --- quit: proteus (Read error: 110 (Connection timed out)) 00:09:43 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 00:10:30 Using blocks to implement a filesystem would work wonders. 00:12:31 do you know anything about tunes' filesystem? they didn't make it sound like there was going to be a filesystem (iirc) 00:13:37 but i guess it's impossible not to have a filesystem? 00:13:58 That depends. 00:14:18 A filesystem needn't be like FAT or ext2fs. 00:14:30 It could also be a system where files, or objects in general, are referenced by number instead. 00:16:15 However filesystems are convenient -- they allow you to treat each file as a unique address space, each independently controllable and growable/shrinkable. Blocks requires more coordination. 00:21:43 There is another advantage to using files over blocks, and that is you have a nice compact encoding for text data (carriage returns serve as line breaks). 00:21:47 It wastes less space. 00:22:31 yeah 00:24:58 Well, I think I'm going to go to bed now. 00:26:34 yeah 00:26:50 i'm staying up to finish reading a really interesting article about a new germ theory 00:30:41 Hehe :) 00:30:44 OK, talk to you later. 00:30:52 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 01:02:55 --- quit: proteus (Read error: 113 (No route to host)) 01:03:13 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 01:40:49 --- quit: proteus ("using sirc version 2.211+KSIRC/1.2.1") 01:47:07 --- join: proteusguy (~scherrey@24-197-147-197.charterga.net) joined #forth 02:03:41 --- quit: futhin ("good night :)") 02:08:44 --- quit: proteusguy (Read error: 110 (Connection timed out)) 02:52:29 --- join: proteusguy (~scherrey@24-197-147-197.charterga.net) joined #forth 04:08:20 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 04:08:44 --- quit: proteusguy (Read error: 110 (Connection timed out)) 05:11:41 --- quit: proteus (Read error: 110 (Connection timed out)) 05:11:48 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 05:31:12 --- join: onetom (~root@novtan.bio.u-szeged.hu) joined #forth 05:32:13 welcome, me good old friends! :) 06:09:03 --- quit: proteus (Read error: 110 (Connection timed out)) 06:09:18 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 07:09:06 --- quit: proteus (Read error: 110 (Connection timed out)) 07:09:19 --- join: proteus (~scherrey@24-197-147-197.charterga.net) joined #forth 08:08:27 --- join: proteusguy (~scherrey@24-197-147-197.charterga.net) joined #forth 08:09:29 --- quit: proteus (Read error: 110 (Connection timed out)) 08:11:37 --- quit: Phoon (Remote closed the connection) 08:11:38 --- join: Phoon (~fsck@207.190.11.59) joined #forth 08:20:09 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 08:20:26 * kc5tja yawns -- good morning 08:21:01 its still sunday @ most places iguess.. 08:21:14 so the channel is silent 4 hours 08:21:24 It turned Sunday here precisely 8 hours 21 minutes ago. 08:21:24 hi, anyway ;) 08:21:37 17:21 here 08:22:57 * kc5tja is currently working on the attributes and architecture of FS/Forth. 08:29:15 huh, twas long ago when we discussed such things :) 08:29:38 whats the news since then? 08:29:57 what attribs r u talkin about? 08:34:56 --- join: I440r (~mark4@1Cust41.tnt1.bloomington.in.da.uu.net) joined #forth 08:41:41 I'm working on FS/Forth's block I/O architecture. 08:42:48 --- quit: proteusguy (Read error: 104 (Connection reset by peer)) 08:42:53 There are two basic techniques I can use to implement blocks, each with their own advantages. 08:42:53 I like to call them direct and inverted, after direct paging and inverted paging implementations in microprocessors. 08:43:13 With direct blocks, the system is limited to max(CPU address space, disk address space) blocks that are persistent. 08:45:01 So if you have a computer with 8MB of RAM (like my laptop), and a 250MB harddrive, then you only have 8MB of block storage space that will be persistent (in this case, you have a maximum of 8MB of addressible block storage to boot, since the CPU can't address RAM above those 8MB. 08:45:52 To access the the 8MB to 250MB region of the harddrive, you'l need to touch the hardware directly and sidestep BLOCK. 08:45:52 I think you can see why I call this "Direct Blocks." :) 08:46:57 isforth needs a block wordset 08:47:49 With an inverted block system, my maximum addressible persistent space is the amount of device storage I have available (for a 16-bit implementation, 64MB is the limit; for a 32-bit, 4TB is the limit). 08:47:49 All of RAM, except for the kernel and the dictionary space, is treated as a swappable cache for disk blocks. 08:48:20 The block system maintains sufficient mapping information to swap blocks in and out as they're needed, and remembers from which device it acquired them so that writebacks can safely occur. 08:48:39 Blocks behave more like pages in this behavior. 08:49:49 --- quit: kc5tja ("[x]chat") 08:49:53 --- join: kc5tja_ (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 08:50:09 OK, my network connection is sucking *BADLY* 08:50:53 Anyway, the inverted block system gives me the maximum amount of persistent storage space, but the cost is I have to segregate RAM into two regions (block managed, and non-block managed) 08:50:53 --- quit: kc5tja_ (Client Quit) 08:52:13 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 08:52:15 * kc5tja sighs 08:53:28 16 seconds ping time here. I'm having some major network problems. 08:53:28 What was the last thing you folks saw from me? 08:55:25 Anyway, the inverted block system gives me the maximum amount of persistent storage space, but the cost is I have to segregate RAM into two regions (block managed, and non-block managed) 08:55:26 [kc5tja_:#forth PING] 08:57:11 I really fucking hate it when my network does this. I really do. 09:02:33 what sort of connection are you on 09:03:06 im gettiong 4 seconds with a ping to you 09:03:31 Yes, and there should be *zero* reason for it. 09:03:50 I'm on cable modem, but by all accounts, it appears as if my central server is at least half the problem 09:03:55 4 seconds ping isnt bad :) 09:04:17 traceroute show a bottleneck ? 09:04:34 Dude, I was getting 16 and 30 seconds pings not too long ago. 09:04:34 None. 09:04:40 When I touched the console of my router box, it took just as long for it to respond. 09:04:55 weird 09:05:03 * kc5tja really needs to swap harddrives in that thing... 09:05:07 network card got a conflict ? 09:05:22 Well, I completely forgot my train of thought. 09:05:22 No. 09:05:22 Conflict with what? 09:05:30 10-base-T cards are point to point connections. 09:06:17 Oh, how I would love to replace Linux on my router box with Forth... Implement a TCP/IP stack on it, and NAT, and I'll be alls et. 09:06:20 all set even 09:07:29 I could even optimize the networking for the RTL8139 chipset, which uses ring buffers (which Linux *HATES*, but deals with nonetheless). 09:08:15 heh 09:16:21 MOTHER OF CHRIST!! 86 ping time 09:38:02 I think I'm going to use an inverted block management policy. 09:38:04 While I like the features of the direct block management system (especially since : BLOCK 1024 * ; ), the inverted system gives me access to a much larger persistent store. 09:54:46 Jesus. 50% packet loss pinging irc.openprojects.net 09:54:52 That's thoroughly unacceptable. 10:12:47 hi 10:13:13 im backreading the block system essay ;) 10:14:53 kc5tja: u can alloy the two techiques, cant u? 10:15:01 :) 10:15:01 No. 10:15:05 u can even reuse the words 10:15:08 why? 10:15:19 Because it's either a direct mapping, or it's not. 10:15:48 u can make a simple, direct mapping case 10:16:17 then build the hdd routines and alloy both into an inverted scheme 10:16:42 by redefining the word BLOCK, eg 10:16:45 and the like 10:17:19 Because it just is. 10:17:41 You either have a 1:1 mapping of blocks in RAM to blocks on disk, or you don't. 10:17:41 You're not making any sense. 10:18:26 The reason you can't alloy the two is because the CPU only addresses 4GB of space (4.2TB if you use segmentation, but I don't). 10:18:37 My computer currently has a 60GB (yes, 60GB) harddrive in it. 10:18:52 That's a lot more than 4GB. 10:18:53 A direct mapping technique would waste 56GB of drive space. 10:19:10 Purely by virtue of the fact that it can't access it even if we wanted to. 10:20:51 The inverted technique splits the address spaces into non-blocked and blocked. The blocked addresses exist in a logically separate address space, and thus, can be efficiently managed by the block system to address greater than 4.2GB. 10:22:42 An alternative would be to use the CPU's paging system to establish multiple address spaces, and let each address space address up to a maximum of 4.2GB, but that's many orders of magnitudes harder to implement (especially in 16-bit mode). 10:24:52 And it's not generally as useful except from a fault isolation standpoint (if a program crashes, it takes only itself down). 10:39:59 --- quit: kc5tja ("BitchX: ribbed for her pleasure!") 10:40:43 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 10:46:43 u r not really getting the point :) 10:46:58 2 implement inverted block handling 10:47:17 u need 2 handle the memory as a cache 10:48:20 u can implement the caching algorithm via a direct-block system 10:48:36 s/via/using/ 10:49:17 so u can already have the ease of blocks while implementing 10:49:29 the other, more complex inverted blk sys 10:50:48 im also dreaming about this stuff nowdays, anyway, uknow 10:51:04 just i dont really have enough time 2 realize my visions 10:53:23 some1 mailed me an ecos kernel w tcpip support and a forth compiled 4 it and melded into a bootable image ~3months ago, but i havent even tried that yet :( 10:58:55 But implementing an inverted block system on top of a direct block system simply doesn't work. 10:58:55 You have to manage the cache, yes. 10:58:55 But using blocks to do it doesn't work -- blocks necessarily implies persistence. 11:00:50 So using a persistent cache to manage persistent stores will potentially result in accessing the disk up to three times PER BLOCK. 11:00:50 It's significantly more complicated, and it's slower. 11:00:50 It's a no-win situation. 11:03:45 "accessing the disk 3 times"??? why? 11:04:06 the cache would b in memory 11:04:32 ... or? ... let me think 11:05:21 bbl 11:09:49 It's just plain easier to not use blocks to implement blocks. 11:10:35 That's counter-productive. 11:13:41 Just manage the RAM as any other cache controller would. 11:13:49 It makes things go a lot smoother, and less code is involved. 11:34:46 --- join: futhin (thin@h24-64-175-61.cg.shawcable.net) joined #forth 11:35:12 re futhin 11:35:18 howdy 11:35:20 heya i440r 11:35:57 One of my ISP's routers is suffering thermal damage; I'm losing 50% of all my packets, so if I seem laggy, that's one reason why I would be. 11:36:39 ouch 11:40:36 --- quit: futhin ("gtgfortheday") 11:40:52 Well, that was quick... 11:41:07 b4n 11:41:21 I thought you were already gone... :) 11:41:22 bb @ wednesday 11:41:30 OK 11:41:52 Nice seeing you again. :) 11:42:03 :) thx 11:42:43 btw, did u know there is a ans4th heap manager available implemented w blocks? 11:43:16 via blocks? 11:43:38 Yes 11:44:00 Blocks constitutes a very simple virtual memory system. 11:44:33 It would make some sense to treat it as a contiguous address space "outside the chip" so to speak. 11:44:50 (where "chip" is the host CPU) 12:08:51 --- quit: clog (^C) 12:08:51 --- log: stopped forth/02.08.04 12:10:00 --- log: started forth/02.08.04 12:10:00 --- join: clog (~nef@bespin.org) joined #forth 12:10:00 --- topic: 'Forth: using bits without limits | x86 Linux Forth coded in asm - http://isforth.clss.net | home of forth - http://www.ultratechnology.com' 12:10:00 --- topic: set by futhin on [Sun Jul 28 18:42:21 2002] 12:10:00 --- names: list (clog kc5tja I440r Phoon onetom Stepan Soap` sif Fractal rob_ert goshawk` @ChanServ) 12:31:58 --- quit: Phoon ("Hail, Caesar! We who are about to die salute you!") 13:07:25 --- quit: I440r () 15:33:54 --- quit: Stepan ("BitchX-1.0c18 -- just do it.") 16:18:30 --- join: Stepan (~stepan@ns.virtualhost.dk) joined #forth 16:18:35 hi :) 16:18:51 re 18:09:54 --- quit: Stepan ("BitchX: a new fragrance for men, by Calvin Klein") 18:39:02 --- nick: kc5tja -> kc-food 18:39:09 --- join: I440r (~mark4@1Cust201.tnt2.bloomington.in.da.uu.net) joined #forth 18:41:18 --- quit: Soap` (Read error: 104 (Connection reset by peer)) 19:37:22 --- nick: kc-food -> kc5tja 20:27:24 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 20:30:01 hi proteusguy 20:30:25 re 20:30:37 phone -- brb 20:31:09 proteusguy: u checked out my compiler yet ? 20:32:18 back 20:33:04 wb :) 20:34:39 Man, this is always hanging me up for some reason. 20:34:57 I can't figure out the best way to handle input and output in the Forth environment. 20:35:24 I know beyond any shadow of a doubt that I don't want a restrictive console interface in Forth, because those are being phased out for better architectures (Thank God too!). 20:35:35 I know how to handle multitasking so that it's event driven. 20:35:40 Input, actually, isn't the problem. 20:35:41 i like query and expect 20:35:57 Query and Expect are 30 year old idioms that have no place in the kernel. 20:36:26 If they exist, they exist as part of the console application, and not as a proper part of the Forth kernel itself. 20:36:38 Besides, they're decidedly NOT event driven. 20:36:45 u mean they have been relpaced by nore snazzy up to date (read complex) methods heh 20:36:56 true 20:37:12 Well, ColorForth still has QUERY, but he implements them in a new manner that is sensitive to the other tasks in his Forth. 20:37:25 So, like I said, you can have them, but they're not technically part of the core anymore. 20:37:42 But, again, like I said -- input is something I've already solved. 20:37:50 It's OUTPUT that's tearing me into two. 20:38:06 I want a system employing scene graphs, because of several nice attributes they have. 20:38:36 define scene graphs 20:38:56 * kc5tja is getting sick of explaining what they are ... looking for URL. 20:39:21 I440r: sorry - just now getting to look here and see I've been ignoring people... 20:39:57 nope - I haven't had a chance to look at the compiler yet. sorry. doing some python/C++ development right now and don't have time to get into the forth as I would like yet. 20:39:59 proteusguy: lol that never happens to me.... honest ;) 20:40:02 http://www.berlin-consortium.org/arch.html 20:40:18 That's a rather sophisticated example of a scene graph. 20:40:28 Obviously mine would be substantially simpler. 20:42:49 cool 20:42:58 ill hafta rtfm that :) 20:44:02 The scene graph technique would allow me to implement easy to manage user interfaces with relatively little effort. 20:44:02 The only problem I have with them is that they do tend to suck up a bit of memory. 20:44:02 For graphical environments, that's OK, because the overhead is minimal compared to the graphics bandwidth involved. 20:44:26 But for text displays.... it's at least on par with the text bandwidth, if not more. 20:44:32 (especially for single character updates) 20:45:45 * kc5tja may have to forego the scene graph for the DOS version, at least, and implement something similar, but less memory intensive. Something more like what GEM uses, where the application has total control over the screen with the VDI, but cooperates willingly with the AES to only render those portions of the screen it has been allocated. 20:46:19 my text windowing code in linux needs to be faster 20:46:37 How is it currently implemented? 20:46:54 but i cant figure out how to speed it up 20:47:04 Does each application render to the screen directly? 20:47:15 well i create a buffer for the screen 20:47:24 and another one for each window 20:47:33 you output to windows and then say update the screen 20:47:44 OK 20:47:48 all widows get written into the screen buffer (actually there are 2 screen buffers) 20:48:02 Sounds like a scene graph technique to me. 20:48:12 Up to that point, it should be blindingly fast. 20:48:20 after writing all windows into the screen the code goes through each screen cell and sees which cells have changed and positions the cursor and writes that char out 20:48:34 OK, that's the slow-down. 20:48:40 if it knows the cursor is already there it doesnt update cursor pos 20:48:45 * proteusguy just glanced at the screen graph stuff... 20:48:46 I would find which lines are different, and then just update the whole line. 20:49:02 cursor reposition. yes 20:49:03 This way, the ESC overhead is amortized. 20:49:12 how is this architecturally different than the Xwin reverse client-server concept? 20:49:21 ill try it 20:49:30 proteusguy: It's a fundamentally different concept. 20:49:31 kc5 not realy 20:49:46 proteusguy: X11 has no idea how the screen is structured except for which windows are contained within which windows. 20:49:52 depends on how many color changes there are on that line :) 20:50:08 proteusguy: A scene graph, however, knows not only structural relationships, but also how to render the screen. 20:50:26 I440r: If you have each character a different color, then you're screwed. 20:51:03 proteusguy: Also, X11 renders the screen with pixels. Some high-level commands are available like line, box, etc. But ultimately, X11 only is concerned with pixels. 20:51:09 kc5 it doesnt make any arbitary restrictions on what colors a user can use 20:51:18 if either a character or a attribute is different the character is updated 20:51:35 ok so its kinda an xlib++? 20:51:48 proteusguy: Scene graphs, however, are like CAD programs -- they are more concerned with the abstract contents of the screen. When you tell one it has a line from (0,0) to (15,15), it knows it has a *line* there, and not a 16x16 matrix of pixels that happens to "look" like a line. 20:52:08 however. if i change to blue background, white foreground and the next char has the same attribs 20:52:08 the escape sequence isnt written. just the char 20:52:19 proteusguy: It's really not correct to think of it in terms of xlib, because it really isn't anything close to it. 20:52:27 but for every single character i have to do 20:52:43 position cursor if not in correct location 20:52:47 I440r: Then you can't speed it up. 20:53:00 write attribute escape sequence if needed 20:53:00 write character 20:53:18 kc5 better code would be faster code 20:53:21 --- join: proteus (~irc@24-197-147-197.charterga.net) joined #forth 20:53:33 I440r: Better code?! You're already doing the simplest possible thing you can!! 20:53:41 You can't optimize that! 20:53:45 smarter algorighms for finding the shortest path through all the changed characters of a screen 20:53:57 but thats complex 20:54:00 i want faster and if possible SIMPLER 20:54:00 Your I/O overhead is what's dwarfing the performance of your code, not your algorithm. 20:54:20 kc5 ncurses has the same i/o overhead 20:54:28 and its alot faster than my code 20:54:29 Yes, it does. 20:54:48 maybe some "coded" defs in my code would speed it up a little 20:54:50 but not by much 20:55:01 type mc [enter] 20:55:05 What you need, pure and simple, is a profiler. 20:55:07 and the display changes almost instantly 20:55:31 Don't guess at what your code might be doing. Measure it. 20:55:33 with my code you can JUST see the display being drawn down the screen 20:55:50 I'll tell you what's going on in NCurses... 20:56:12 They do a run-length check for attributes, and aggregates characters into a buffer, and spits the whole buffer out at once. 20:56:29 All the characters of the same attributes are put out as a single string. 20:56:34 You're going character by character. Don't do that. 20:56:41 oooh! 20:56:49 hrm 20:57:15 Try that, and I'm willing to bet you performance will jump quite a bit. 20:57:39 will mean a rethink of some of the code but for a speedup it would be worthit :) 21:02:29 Yeah, I think I'll take the GEM approach for the low memory requirements it has. 21:02:47 I'll switch to using scene graphs for the 32-bit native version, where more memory will be readily available to me. 21:03:10 Or, if I decide to explore graphics mode in 16-bit mode, I might revisit the scene graph approach. 21:10:21 --- quit: proteusguy (Read error: 110 (Connection timed out)) 21:53:30 --- quit: I440r ("Reality Strikes Again") 21:55:08 --- join: ree (ree@12.44.219.129) joined #forth 21:55:13 hey llamas 21:55:36 llamas? Have you been hanging around a character named wakko at all? 21:55:43 hah, no 21:55:53 Just wondering; that's his favorite word. :) 21:55:56 just some stupid intro message 21:56:08 I finally got back on the computers 21:58:13 (long story) 21:58:33 That's OK; I'm just working on a few things. 21:58:57 so how is forth treating you 21:59:26 I don't know; I haven't written mine yet. :) 22:00:07 But I'm currently using Pygmy Forth, and it's going really well. 22:00:29 I just downloaded and installed PFE under Linux, and I'm rather pleased with it too·. 22:00:39 ahh 22:01:07 * kc5tja is trying to engineer various aspects of his Forth, and putting them together to see how they feel. 22:01:27 Writing hypothetical programs for it, like a 4-function calculator application, etc. 22:03:44 I just moved, need to finish a few things 22:03:49 sorry to cut our conversation short 22:03:54 take care 22:03:55 OK 22:03:58 You too 22:04:40 --- quit: ree ("bbiab, got to setup computers") 22:10:26 --- quit: proteus (Connection timed out) 22:51:43 --- join: futhin (~thin@h24-64-175-61.cg.shawcable.net) joined #forth 22:52:25 greetings onetom and kc5tja 22:52:47 I think onetom won't be back until Wednesday, he said earlier today. 22:53:32 yep 22:55:47 wasn't sure if he left already 23:06:09 hi 23:06:40 im traveling by the 9:20 train coz i missed the 7:20 :) 23:06:55 the 1 @7:20 23:07:01 onetom: Where are you going? 23:13:21 www.sziget.hu 23:13:32 its a music festival in budapset 23:15:20 Ahh, cool. 23:25:45 kc: what about a bsd+forth system? 23:25:59 ive just browsing the picobsd site 23:26:00 What about it? 23:26:30 I know it uses Ficl for its Forth environment. I heard some decent things about Ficl. 23:26:31 wouldnt it b simpler 2 integrate some 4th w a bsd? 23:26:51 onetom: lol, just sent you an email 23:26:52 so we can use the bsd drivers and its tcpip stack 23:27:05 futhin: gonna chk itr 23:28:09 I don't want to do that because it results in a much bigger system. 23:29:09 I want a small system; something that I can easily manage on my own. 23:38:34 but the drivers.... 23:38:51 brb 23:38:51 im thinking from a different direction 23:39:23 id like 2 use my forthos as fast as possible as my desktop system 23:40:18 and this "awfully" requires internet connetivity 23:40:39 a telnet access @least 23:41:37 and "some" ftp 23:42:01 * kc5tja nods 23:42:06 I'm not concerned so much with those things. 23:42:15 I want them, certainly, but I want my own implementation of them. 23:43:07 so idont have 2 bluner w floppies 23:43:27 but later u can implement those 23:43:50 chuck moore has tcp/ip on his todo for colorforth 23:43:56 I have no intention of blundering with floppies to start with either. That's why I'm going to use GRUB for a boot-loader. 23:44:00 but u can develop comfortably and durable enough on a floppy... 23:44:01 let's hope he codes that up soon ;) 23:44:29 futhin: his colorforth itself either worx 4 me :) 23:45:13 kc5tja: but where do u store the 4th related stuff then? 23:45:40 onetom: response to my email? or did you just reply ? 23:47:12 response? ive just read the half of ur mail yet :) 23:49:43 I'd use a separate partition on the harddrive. 23:49:57 heh 23:50:06 Unlike Chuck, I acknowledge that some things *must* be *slightly* complicated in order to co-exist peacefully with other complex systems. :) 23:51:09 Like, for example, my whole scene graph implementation for my Forth -- yes, it's a complexity, but it solves the problem of managing the screen when you have multiple applications running concurrently (as I will when I'm done with it). 23:51:40 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 23:53:57 futhin: i dont have much 2 reply 2 ur mail 23:54:31 futhin: just KEEP ON w the diet! & u wont need tips then ;) 23:54:46 heh 23:54:49 yeah 23:55:01 onetom: do you hang out anyplace that lets you meet girls?? 23:55:46 futhin: seriously: i always picked up girls from my direct environment 23:56:38 futhin: so school mate come 2 mind 1st. and after that their girlfriends 23:58:08 futhin: but i had only ~8 girlfirend in me entire life 23:58:51 futhin: so i cant substract any moral or tips. yet ..... :) 23:58:58 heh 23:59:51 futhin: but personally i love folk music. so concerts could play this role too 23:59:59 --- log: ended forth/02.08.04