00:00:00 --- log: started forth/04.10.07 00:01:49 I think I have to do a more fundamental header modification without segments, like move label: to the actual code. 00:02:47 The segment macros are allowing label: to be semanticly after the whole macro. 00:03:05 I'm not clear on why it's storing two longs the way it is. The tail of the __CODE is the label address after alignment before the CODE definiton, then the next is the final address being assembled. 00:03:33 Are you looking at the whole file/macro? 00:03:45 most of it :) 00:04:02 lemme paste the whole macro 00:04:10 --- join: tgunr (~davec@vsat-148-63-4-106.c001.g4.mrt.starband.net) joined #forth 00:04:30 #define __INITSEG__ .text 0 /* initialization code segment */ 00:04:31 #define __STRSEG__ .text 1 /* constant strings segment */ 00:04:31 #define __DATASEG__ .data 0 /* data segment; must be before code */ 00:04:31 #define __CODESEG__ .data 1 /* code segment; must be after data */ 00:04:31 #define __CODE(lex, name, label) \ 00:04:31 __CODESEG__ ; \ 00:04:32 __aligncode ; \ 00:04:34 label: ; \ 00:04:36 __SST__ ; \ 00:04:38 __DATASEG__ ; \ 00:04:40 __aligndata ; \ 00:04:42 .long label, PREVCODE ; \ 00:04:44 PREVCODE=. ; \ 00:04:46 _NAME=. ; \ 00:04:48 .byte lex ; \ 00:04:50 .ascii name ; \ 00:04:52 __aligndata ; \ 00:04:54 __CODESEG__ ; 00:07:07 so I think the problem I'M having is I'm hitting the data between where label: is physically and the end of the macro, which is where there's the code label: is supposed to label. 00:07:08 Is almost everything in osimplay in .data? 00:07:38 yeah. I do a fake .bss for uninitialized data at the end of the file. 00:07:44 thusly... 00:07:59 heap 00:07:59 allot 100000 00:08:29 heap tells the ELF macro that makes the header not to allocate any more file 00:09:00 I think technically it's all in .text, which is code 00:09:14 hmm I was wrong in my earlier understanding of the code. 00:09:35 That makes at least 2 of us 00:09:51 I think I have to move label to the end of the macro 00:11:18 I think I'm trying to execute the back-link 00:11:46 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 00:11:52 In eforth colon words the next thing is a call to DOLIST 00:13:02 sound like half a clue? 00:13:31 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 00:14:45 ? 00:17:15 HAYYYYYYLP! 00:19:43 The problem that creates is the label is then assembled after the link, a nasty problem I had with H3sm 00:23:10 00:23:16 00:23:30 Morning 00:23:43 * Robert reads through the L4 API docs. 00:24:17 Hi. any relation to kc5tja 00:24:23 ? 00:25:16 Yes, but a non-sexual one. 00:25:26 gasp 00:25:35 Actually he just reminded me of it, another guy I know told me about it a while ago. 00:25:39 And how he liked it. 00:25:57 yah, lots of people like sex. 00:26:08 BZZZZZZZTTTT 00:26:45 I think I'm going with a standard name field size to resolve the forward branch issue 00:27:07 Forward branch issue? 00:27:20 Seriously L4 seems interesting. If it's faster than Mach and allows debugging drivers like QNX can, it would be cool. 00:28:00 I'm converting a 386 forth with a segmented data/code model to a single file, and the header needs mungling. 00:28:56 I don't want to redo the threading scheme 00:30:00 I guess it's a canonical CFA, to a different address-space. 00:31:18 and if it's in the same file, the labelling gets screwed up 00:31:31 imaginator: is that your take on it? 00:34:30 * colorg checks his breath 00:37:34 colorg: it appears to me that the .data 0 segment is used for word addresses and a linked list of those words. .data 1 is the actual machine code for a word. 00:38:35 thanks 00:39:12 So label: is in the wrong place for a single memspace 00:39:14 I see now that the PREVCODE implements a linked list for each call of __CODE. 00:39:31 yeah, _NAME is for LATEST 00:39:52 i.e. it's only used at the end of the file 00:40:31 label: has to be semantically at the end of the macro, which adds assembly issues 00:41:25 it then becomes a forward reference from the .long label, the CFA 00:42:01 so I think I'm getting warmer. Thanks for the feedback. 00:47:05 imaginator: Why wouldn't it allow debugging of drivers? 00:50:33 kc5tja: I didn't intend to imply that it doesn't. Microkernels that allow such things are great. 00:51:02 How big is L4 and what is it written in? 00:51:25 :o) 00:59:55 Cool, I went from a segfault to a bus error 01:01:23 __CODE () { # ARGS... lex name label 01:01:23 twas=H 01:01:23 aq $((H+32)) # CFA 01:01:23 aq $PREVCODE # LFA 01:01:23 PREVCODE=$H # for LFA in later word 01:01:23 _NAME=$H # for LATEST 01:01:25 ab $1 01:01:27 ascii $2 01:01:29 H=$((twas+32)) 01:01:31 L $3 01:01:33 } 01:06:36 colorg: Depends on the specific implementation. Like the relationship between Unix and Linux, there are a variety of flavors of L4 too. 01:07:06 colorg: The one I'm looking at possibly using compiles to 135KB of code (uncompressed), and is written in a strict subset of C++. 01:07:33 imaginator: Why wouldn't a microkernel allow you to debug device drivers though? That's my question. They exist in userspace. 01:08:21 That's another issue then. Drivers in userspace? 01:08:30 135kB, is that "micro"? :) 01:08:38 *cough* 01:09:09 IF it has gobs of drivers yeah 01:10:00 scsi.c in Linux is about 800k of text IIRC :o) 01:10:48 My kernel 1200 bytes. It doesn't DO anything, but hey... 01:10:49 kc5tja: no argument. I suppose microkernel implies *most* drivers in userspace. 01:11:17 Robert: Compare to Linux. 01:12:05 kc5tja: What _isn't_ small comapred to Linux? 01:12:08 colorg: There is no issue about drivers in userspace. The issues that are commonly known are artifacts of monolithic kernel designs. 01:12:16 Robert: Windows. 01:12:47 mainframe stuff probably 01:13:02 Haha, right. But really, 135kB of only IPC and scheduling? 01:13:07 colorg: Actually, mainframe-grade OSes are about the size of Linux currently. 01:13:48 Robert: IPC, scheduling, MMU memory management, SMP support, and let's not forget that it's written in C++, not hand-crafted assembly like L4/x86. 01:14:17 Much of the bulk comes from optimizing the memory copy routines used in message passing between address spaces. 01:14:20 kc5tja: back to userspace, I can see that, kinda. Not clearly. My OS design was 4 kinds of channels, but interrupt handles, bottom-halves, are in the kernel. 01:14:23 Lots and lots of loops are unrolled. 01:15:15 colorg: L4 models hardware devices as kernel-level threads, which you can wait on via IPC. In fact, that's how you detect interrupts: you wait for them just as you would wait for ordinary messages from other tasks. 01:15:34 kc5tja: What L4 implementation are you talking about? 01:15:43 Robert: L4Ka::Pistachio. 01:15:51 For what CPU? 01:15:54 x86 01:16:02 Compiled for the PC99 standard 01:16:02 Why choose that over L4/x86? 01:16:28 Feels like I should google that. 01:16:33 Because L4/x86 isn't being developed anymore, doesn't support SMP, and has a substantially improved API. 01:16:47 In Ha3sm, Hohensee's (99% hypothetical) autonomous 3-stack machine, listeners register with the kernel and messages appear in thier message buffers apparently asynchronously. 01:16:53 PC99 is a Microsoft document detailing the hardware requirements of PCs that are Windows compliant. 01:17:13 I thought PC99 was Aisian PCs 01:17:19 Asian 01:17:46 colorg: IPC in L4 is 100% synchronous. It has the benefits of limiting kernel memory consumption, and also eliminates the need for managing message queues as separate objects. 01:17:57 colorg: Nope. 01:18:06 Ah, so you can run your Forth on computers "Designed for Windows(R)"? :) 01:18:24 Well, you can *boot* on them at least. 01:18:30 hehe. 01:18:33 Always something. 01:18:42 I like Ha3sm better. Kernel buffers don't get that big if you write them out fast enough 01:18:43 Whether or not it'll actually run depends on the compatibility of the device drivers. 01:19:08 colorg: You can't guarantee that they will though. 01:19:21 WHo can't? I'm the kernel. 01:19:49 That's nice. But since L4 is designed to be used independently of any one given operating system, L4 cannot make any guarantees. 01:20:05 That's a DoS 01:20:09 Say, weren't you arguing for synchronous IPC just yesterday? 01:20:31 Me? No. 01:21:53 A Ha3sm process has virtual devices, like a Ethernet buffer. No messages. It has pointers and the process can tell from the pointers in it's ring buffer if the kernel lapped it around the buffer or not. 01:22:22 Excuse my ignorance, but what is a synchronous API? 01:22:24 right. The point being, you can overflow the message queue. 01:22:43 Robert: Two processes, Alice and Bob, are running in the system. 01:22:47 In a process. The kernel doesn't wait for processes. 01:23:11 Robert: Alice wants to send Bob a message to do something for her. Alice will block until Bob receives the message. 01:23:17 The kernel writes thier buffers and is done with them. 01:23:24 Robert: Conversely, if Bob has nothing to do, he will block until Alice sends him a message. 01:23:40 kc5tja: Ah, OK. Thanks :) 01:23:41 E.g., the only time both processes are allowed to continue execution independently of each other is when Alice and Bob rendezvous. 01:24:00 there's a rendevous() call in Plan 9 01:24:10 L4 eliminates the need for it. 01:24:17 It's all automatic. 01:25:16 colorg: So, my question is, because of the possibility to overflow the message queue, do you just "drop messages" if they overflow? Like dropped Ethernet frames? 01:25:36 And if so, do you rely on higher-level protocols on top of the messaging system to handle reliability? 01:25:39 kc5tja: processes do, yes. The kernel doesn't. 01:25:46 That's what I meant. 01:26:10 What is the typical message buffer size for a process? 01:26:31 What's got a huge datarate? SCSI? Gigabit Ethernet? 01:27:07 Well, SCSI is in advance of 100MBps now, which is comparable to Gigabit Ethernet. But the fastest datarate I'm personally aware of is 10-gig-E. 01:27:43 (well, OK, OC-768 is the fastest data rate I'm aware of, weighing in at an monsterous 35Gbps, but I digress) 01:27:43 And how many processes on a PC need to listen to that? 01:28:27 kc5tja: How would you pass a memory block to e.g. a driver? 01:28:37 In an operating system that I would architect, perhaps many. Elevator algorithm would schedule drive seeks accordingly. 01:29:07 Or, put it this way; reliable from whose point of view? From the kernels point of view, I filled your buffer, I'm reliable. 01:29:25 Robert: When you send a message, you can send data through two different means (even concurrently). The first is a byte-by-byte copy from one address space to another (slow). The other is to actually *remap* a portion of your process' pages to the receiving task. 01:29:38 Be realistic here. 01:29:51 Reliable data transfer, by definition, means end-to-end reliability. 01:30:06 The kernel is known to offer only a datagram messaging service -- it is unreliable. 01:30:23 The processes themselves are responsible for reliable data transmission (e.g., using an adaptation of TCP, for example). 01:30:23 It's a design decision. I'm concerned with kernel reliability first, everything else a distant second. 01:30:45 That's how it factors to me. 01:30:54 * kc5tja nods -- nothing wrong with it. 01:31:03 But the term "unreliable" in this context isn't a bad thing. 01:31:14 It's good for personal realtime. It's Amigaish. 01:31:22 It's common message delivery terminology. Unreliable is like UDP, reliable is like TCP. 01:32:02 And for the programmer's model of a process. You ask for a virtual device. If the kernel thinks you can handle it, there it is in your memspace. 01:32:07 Well, Amiga didn't copy messages all over the place, which is where all of its speed really came from. 01:32:45 kc5tja: true, this is multi-user Amiga more or less 01:32:46 The asynchronous I/O model was a huge help too. 01:33:03 Uh oh -- ALL the crickets outside just went silent. :) 01:33:17 * colorg checks his armpits 01:33:25 * kc5tja checks for Bigfoot or Godzilla. 01:34:14 Anyway, L4 should be plenty good enough for what I'm looking to do. 01:34:42 My for channels are block and byte, send and recieve 01:34:45 I'm very satisfied with its feature set and its underlying philosophy. 01:34:46 u 01:36:18 send would be synchronous I guess, i.e. the sender would block. I forget. 01:37:47 or maybe it would block on a subsequent send attempt if the kernel didn't leave a semaphore. 01:39:33 So there is signalling, but that's async, it's just the ring buffer pointers 01:41:00 If you're about to lap the kernel, don't send. 01:42:05 * kc5tja nods 01:42:24 I refuse to go look at my notes :o) 01:42:27 In my earlier Dolphin kernels, I retained AmigaOS's and VMS's concept of event bits. I find them to be incredibly elegant. 01:43:56 Is that how listeners worked? 01:44:15 Pseudocode: 01:44:16 { 01:44:21 while( !done ) 01:44:22 { 01:44:34 signalsPending = Wait( signalsImListeningFor ); 01:44:45 if( signalsPending & MASK_1 ) handle_event_source_1(); 01:44:56 if( signalsPending & MASK_2 ) handle_event_source_2(); 01:44:59 ...etc... 01:45:01 } 01:45:02 } 01:45:20 SO any event bit is event_pending=TRUE 01:45:29 Note that AmigaOS let you "wire up" different objects to event signal bits. 01:45:48 That's what I'm curious about. Who flips the bit? 01:45:54 So you could have two message ports, for example, sharing the same event bit if you wanted. Though, with 32 event bits, this was really rare. 01:46:06 Who turns off the lights? 01:46:07 Outside tasks can only set bits. 01:46:34 Wait() clears them after returning the current state. 01:46:43 I like ring buffers :o) 01:46:49 (think interrupt controllers; the interrupt pending register of most controllers works the same way) 01:47:13 Then, 01:47:17 handle_event_source_X() 01:47:17 { 01:47:25 while( MessagesYetToCome() ) 01:47:26 { 01:47:35 m = GetMessage(); 01:47:38 HandleIt(m); 01:47:43 ReplyMsg(m); 01:47:46 } 01:47:46 } 01:48:06 (this assumes that a single event source is assigned to a single event bit, obviously) 01:48:28 Some Forthiness of Ha3sm, the please syscall is the entry to a Forth dictionary of kernel services. 01:49:37 Some people might balk at the two-levels of event handling -- but this is precisely what allowed AmigaOS to be so damn responsive compared to its Unix bretheren, and *certainly* compared to OS/2 and Windows. 01:50:02 Unix of course now implements the select() (or poll()) function call, which behaves similarly to Wait(), though it's a hell of a lot harder to use, and one heck of a lot less flexible. 01:50:04 please is, say, INT 0x81, which sends a text string of (please) open filesystem ext2 send 01:50:31 OK 01:50:52 (please) is a word that must be specified in the string? 01:52:36 no, but it might be a used as a text word interactively, but it would interpret/compile to the top-level syscall. The 4 channels, once open'ed via a please, might be different syscall #s for speed. 01:53:05 So there's 5 syscalls, one Forth interpreter and 4 fast IO calls. 01:53:34 with the authorization for the IO via the interpreter 01:53:50 ala open() etc 01:54:25 each process will get more stock goodies than 3 file descriptors, too. A clock, for example. 01:54:56 A process would be more like a user in unix. 01:55:17 i.e. a process would be like an Amigados. 01:55:32 With a Forth kernel :o) 01:55:59 * kc5tja nods 01:56:14 Yeah, clock support is one area in Linux that direly needs an overhaul. >:( 01:56:23 it's at about 1200 bytes and I have a bad floppy :o) 01:56:47 clocks are handy critters. 01:58:20 So I use 12 VTs. They'd be 12 Amigadoses. 12 processes. Writing a bunch of buffers wouldn't be that bad. 01:59:40 12 would have clocks, there'd be a filesystem or two with hot disk service, not much traffic 02:00:48 --- quit: imaginator ("sleep") 02:00:55 Can the application set how big its message queue is? 02:01:06 E.g., in anticipation of a lot of data, for example? 02:02:29 yes. There's a stock ring structure so when you open a channel you give the kernel the address, size, yaddayadda. What matters is that the reciever be able to tell when it's been lapped. 02:03:15 And processes don't do anything that would lap the kernel. 02:04:41 You give the kernel the address you want to be byte 0 of the buffer. Negative offsets are standard for size, next available byte, etc. 02:05:30 and a total throughput count maintained by the sender, which is how you can check if you've been lapped 02:06:37 The difference between data and an interrupt is an interrupt is itself a singleton, like a bit. 02:07:23 AN interrupt is either up or down. Data stores. 02:09:26 This lighter I bought this afternoon just made a recorded noise. Scared the fuck out of me. 02:13:50 Hahah 02:18:46 The flame turns green in about a second. I think it's got a little copper ball in the flame outlet. And it's got a girlie pic on it. Quite a glorious little piece of junk. 02:19:46 Ahh, St. Patrick's Day lighter. :D 02:20:17 it would be brilliant on St Patty's 02:50:40 oh dear 02:50:46 --- nick: fridge__ -> fridge 02:54:14 blerf 02:55:42 anyone use LILO? 03:01:04 I've used it in the past 03:01:11 I use grub now, given the choice though 03:02:21 After it loads an image where does it jump? 03:02:52 In other words, I'm thinking about booting a project kernel from LILO 03:03:14 oh, I don't know how it works in that much detail 03:03:33 I've booted a range of things with bootloaders 03:03:37 like memtest86 03:05:23 maybe it's ELF :o) 03:07:03 probably 03:13:20 well the front of a Linux bzimage has the bootsector aa55 and looks like code. 03:13:36 I guess it's bootsect.S 03:14:04 definitely not ELF 03:16:52 Yeah, it's just concatenated code 03:24:15 yeah, it's code at 0000000 03:25:13 It will be loaded into RAM at physical address 0x00007C00 though. 03:25:28 LILO is. 03:25:54 I recommend doing a far JMP to 07C0:0000h to make sure the CS register is set correctly inside your boot code (or, better yet, just plain don't depend on its value somehow). 03:26:23 Guaranteed that Linux's boot sector is loaded at 0x7C00. 03:26:31 LILO has to move itself out of the way to do it. 03:26:40 by the loader at 7c00? 03:27:05 The BIOS loads the MBR at 7c00. LILO.] 03:27:16 LILO is loaded at 7C00. During its start up phase, it moves itself out of the way so that it load the boot sector of the chosen OS at the 7C00 location. 03:27:28 ALL boot sectors, MBR or otherwise, go at 7C00. 03:27:31 AH. Makes sense. 03:27:54 (don't ask me; I frankly think that's a retarded place to put boot code. But I digress.) 03:28:00 That way a kernel image on a floppy works like a LILO-loader one, which they do. 03:28:07 yup 03:28:42 cool. I have a crisp floppy controller, and a germ of a kernel project, so... 03:28:52 :-) 03:30:00 LILO loads whatever size the file is from there? Like up to the PC RAM limit? 03:30:21 (I only need about 50k anyway...) 03:32:23 I guess so, from dim Linux memories 03:32:54 512k was the kernel size bugaboo for a while 03:33:43 I think LILO only boots the first 512 bytes of the image, treating it like a boot sector. I'm nto sure about that though. I know GRUB loads the whole kernel image into memory in one fell swoop. 03:34:00 that makes sense too. 03:34:37 grub knows more about filesystems. LILO is all CHS mapped 03:35:32 i.e. LILO creates a block map for an image 03:36:28 The first 3 bytes of a bzimage is in fact the first instruction of bootsect.S, movw $BLAH,%ax 03:37:20 still rmode of course. LILO uses the BIOS 03:38:28 I'll have to convert DOS to osimplay one of these days. Dear Mister Gates, Yes, you've been replaced by a shell script. 03:39:05 He'd be so horrified he wouldn't prosecute 03:54:22 Hehe 03:54:50 Let's not forget his little sidekick, Ballmer. 03:54:56 He'd sue in a heartbeat. 03:57:17 Indeed 03:58:50 --- join: crc (crc@140-pool1.ras11.nynyc-t.alerondial.net) joined #forth 03:59:22 AH, I did do a register dumper in osimplay. That's what I need for this eforth hurdle now. 04:25:41 anyone online ? i gonna test a new client - Miranda 04:25:58 --- nick: Serg_penguin -> Serg_test 04:27:10 --- join: Serg_Penguin (~Miranda@212.34.52.140) joined #forth 04:27:26 hi from Miranda :) 04:27:34 ACK 04:27:34 re from Mirc ;)) 04:27:43 NACK 04:28:02 Miranda is in Forth? 04:28:07 * Serg_test leaves Mirc - ghosts are BAD THING 04:28:10 no ! 04:28:18 just a client 04:28:22 --- quit: Serg_test () 04:30:06 it hasn't font options - i so used to BIG GREEN letters ;)) 04:30:07 -- multiline test 04:31:19 ACK /msg 04:32:15 e nuf 04:32:27 I beep on /msg, please stop 04:32:39 ok, i stopped 04:34:20 * Serg_Penguin wants to beep but dunno how to do so in Mirc 04:34:54 please /msg me for test 04:36:58 aha, it behaves ICQ way ;)) 04:37:18 Vice-versa I'm sure 04:37:27 IRC goes way back 04:38:03 i stomped on coffin of ICQ client coz of it ads 04:39:34 I've been using skype 04:39:47 hmm.. dunno it 04:39:52 * Serg_Penguin runs win32 04:42:33 I'm saying IRC is much older than other chat datasystems 04:42:55 aha 04:42:56 the damn thing does not show idle time !!! 04:43:49 colorg 36 1097126195 seconds idle 04:43:49 what does it mean ???? 04:44:05 36sec or almost eternity ? 04:44:28 * Serg_Penguin 's date is correct 04:44:37 Heh 04:46:10 :;bases 1097126195 04:46:12 01000001_01100100_11010001_00110011 10131150463 0x4164d133 1097126195 dec 04:46:33 Hmmmm, good thing we didn't STEP in it! 04:47:26 Miranda is mega buggy, last time i used a new version, it just bombed core 04:47:26 now they seem to fix some shroedinbugs ;)) 04:47:52 Not Heisenbugs? 04:48:41 google for Shroedinger cat ;) 04:48:50 0x00 to IER register 04:48:57 err, wrong window :-( 04:49:32 shroedingmice and shroedingrats ;)) 04:49:57 I'm looking at the code for Forreal. It's a good thing I got away from that. I was quite out of my mind. 04:50:29 Jargon File for Heisenbug 04:51:35 aha ! Jargon File _ROCKS_ !!! 04:52:16 Heh, that's a cute name. 04:52:43 i read it first in a RU translation, paper book 04:53:04 though, quite outdated 05:04:59 --- quit: Serg_Penguin ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05:08:58 imaginator was wondering what 256k of NOPs was for. I was benchmarking osimplay. It took 15 minutes toassemble 256k of NOPs 05:10:31 Make it faster :-) 05:11:35 Ever try to optimize Bash? It's like drop-forging cow manure 05:12:05 I've never written a large script in bash 05:12:12 * crc prefers simpler shells 05:17:28 My assembler in Bash is 130k 05:17:55 Assembler in bash? 05:17:57 Heh. 05:18:04 It must be a pain to update 05:18:04 You ARE crazy. 05:21:14 I don't think I've updated it at all tonight 05:36:53 OK 05:36:57 --- quit: colorg ("ircII EPIC4pre2 cLIeNUX. Can you say that?") 06:02:25 --- quit: madwork (Read error: 104 (Connection reset by peer)) 06:10:26 --- quit: Robert ("You lock the door and throw away the key. There's someone in my head, but it's not me!") 06:33:42 --- join: madwork (~madgarden@derby.metrics.com) joined #forth 06:52:26 --- quit: crc (Client Quit) 06:58:07 --- join: Robert_ (~pink@c-bf5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 06:59:03 --- nick: Robert_ -> Robert 08:04:16 --- quit: hrmpf ("sorry, had to go looking for myself....") 08:08:22 What's a good name for a word that finds the position of one string within another, like C's strstr()? 08:08:38 substring? 08:08:49 indexOf 08:08:55 inside 08:09:01 contains 08:09:07 pos 08:09:22 Yeah, pos -- that's an old BASIC keyword for the same thing. :) 08:09:31 Ahh, is it? Cool, I'll use that then. :D 08:09:33 And it's _short_ 08:09:38 $pos it is. 08:37:33 Off to bed for me. 08:38:52 night! 09:10:43 --- join: arke-sch00l (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth 09:52:28 --- join: crc (crc@248-pool1.ras11.nynyc-t.alerondial.net) joined #forth 10:06:47 --- quit: arke-sch00l ("CGI:IRC (EOF)") 10:08:28 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 10:09:52 --- quit: crc (Client Quit) 10:11:51 --- join: TheBlueWizard (TheBlueWiz@modem-089.nyc-tc04a.fcc.net) joined #forth 10:11:51 --- mode: ChanServ set +o TheBlueWizard 10:56:14 --- quit: TheBlueWizard (Nick collision from services.) 10:56:26 --- join: TheBlueWizard (TheBlueWiz@modem-011.nyc-tc03b.FCC.NET) joined #forth 10:56:26 --- mode: ChanServ set +o TheBlueWizard 11:12:52 --- join: wossname (~wossname@rn-v1w5a06.uwaterloo.ca) joined #forth 11:17:05 --- join: qFox (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 11:24:30 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 11:24:30 --- mode: ChanServ set +o Herkamire 11:26:55 --- quit: TheBlueWizard (Nick collision from services.) 11:27:13 --- join: TheBlueWizard (TheBlueWiz@63.250.24.237) joined #forth 11:27:13 --- mode: ChanServ set +o TheBlueWizard 11:35:31 --- quit: swsch_ ("Leaving") 12:23:30 --- join: arke-sch00l (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth 12:24:31 hiya 12:25:58 arke hiya 12:36:14 whats up? 12:39:54 nothing 12:40:36 just chillin' 12:40:37 :p 12:40:45 Hi 12:40:50 fitch deduction system is evil btw. 12:41:08 its not getting thru to me at all >:( 12:41:22 well, i should say not entirely. 12:41:43 I wonder if converting a dictionary into a Forth file is a Good Idea(TM). 12:41:57 to what purpose? 12:42:06 for reference? 12:42:07 To create a simple dict program? :D 12:42:15 i guess... 12:42:26 there should be a large database online 12:42:29 with forth words 12:42:37 not a project i'm gonna dive into though 12:42:43 wiki type of page 12:42:57 multiple words being allowed, with descriptions, etc 12:43:06 i mean multiple instances of the same word 12:43:16 Interesting idea, and if Forth was standardized *AND* the standards were followed, it might even work. 12:43:26 But I'm thinking about natural languages 12:43:26 even if it didnt, so what 12:43:29 oh 12:43:41 Would be pretty cool, especially with a Forth using hashed dictionaries. 12:44:10 sure go ahead and work out 140.000 words, i'll just use webster.com though :) 12:44:25 well, for the website it would be a database type of thing 12:44:47 perhaps with a test-module as kc5tja has been talking about 12:45:08 Hmm.. Perhaps even automatic benchmarking? 12:45:11 and huge discussions about words like to ;) 12:45:16 indeed 12:45:21 So that different words could be compared. 12:45:38 although speed does depend on the implementation, but heck. 12:46:02 Yeah, but a really good word always beats a bad one ;) 12:46:11 (i mean one word might bench good on one forth, where the other type would do better on anohter forth) 12:46:20 I know 12:46:23 :) 12:46:50