00:00:00 --- log: started forth/04.09.19 00:00:40 --- join: proteusguy (~proteusgu@68-114-24-230.cpe.ga.charter.com) joined #forth 00:04:19 --- join: qFox (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 00:08:55 --- quit: Sonarman ("leaving") 01:12:04 --- quit: madwork_ (Read error: 101 (Network is unreachable)) 02:24:31 clear 02:24:32 oops 02:25:04 :) 02:25:05 Morning 02:42:36 Greetings 03:01:57 --- quit: qFox ("this quit is sponsored by somebody!") 03:08:09 I wonder how much a flat piece of glass would cost -- something in the size range of 13" square. 03:13:01 What are you going to do? 03:13:10 I need it for the solar oven. 03:13:21 I tried using plastic wrap, but it's too flimsey. 03:14:18 The alternative is to use transparent oven bags, leaving the solar oven itself wide open to the atmosphere. The items inside the bags cooks normally. I should probably experiment with that first. 03:18:32 Hmm...I wonder if Plexiglass would work, or if it would out-gas? 03:27:34 I think glass is pretty much a requirement. Plexiglass has too low a melting point, especially for a solar oven that can theoretically reach 200C in temperature. 04:06:24 --- join: crc (crc@107-pool1.ras11.nynyc-t.alerondial.net) joined #forth 04:06:37 re crc 04:06:43 Hi kc5tja 04:08:34 I finally finished implementing PUBLIC: late last night. :) 04:09:58 cool 04:19:49 Yep. Did a little test-driven development to realize it. I still have to hone my TDD techniques with Forth though. Forth makes TDD rather "interesting" in some respects. 04:20:06 What's test-driven development? 04:20:26 I'm rather shocked you don't know of it. I've explained it here numerous occasions. 04:20:37 :) 04:21:02 Let's suppose you are writing a function to display a graph of temperature over time. 04:21:25 ok 04:21:31 You need a function to compute the graph limits. Basically, what you do is you write your program as if the needed function already exists. 04:21:40 This is basically top-down design at this point. 04:21:50 You compile, the compilation ought to break. 04:22:32 (if it doesn't, then you either have a name collision with something else.) 04:22:39 s/either// 04:22:56 Anyway, once you confirm it's OK to go ahead using the desired name, you now "describe what is required of the function." 04:23:03 You do this using unit tests. 04:23:22 Let me fetch you a simple example from my PUBLIC: implementation: 04:23:44 0 ( FTS/Forth::Target::Word List Database::Entry::Unit tests ) 04:23:44 1 04:23:44 2 44 load 04:23:44 3 : t1 "reset $DEADBEEF "cfa! "buffer 16 + @ $DEADBEEF XOR 04:23:44 4 abort" 46:t1" ; t1 04:23:46 5 S" ABCDE" "name! 04:23:49 6 : t2 "buffer c@ 5 xor abort" 46:t2" ; t2 04:23:52 7 : t3 "buffer @ $43424105 xor abort" 46:t3" ; t3 04:23:54 8 : t4 "buffer cell+ @ $20204544 xor abort" 46:t4" ; t4 04:23:57 9 S" ABCDEFGHIJKLMNOPQRSTUVWXYZ" "name! 04:23:59 10 : t5 "buffer c@ 26 xor abort" 46:t5" ; t5 04:24:02 11 : t6 "buffer 16 + @ $DEADBEEF xor abort" 46:t6" ; t6 04:24:05 12 04:24:07 13 47 load 04:24:09 14 04:24:12 15 04:26:12 For example, t1 verifies the correct operation of the "cfa! word. t2..t4 verifies operation of the "name! word when the length of the name is less than 15 characters, while t5..t6 tests when the name is longer than 15 characters. 04:26:38 ok 04:27:04 Anyway, after you write these tests, you compile again -- again, it should break, since the code you're "testing" doesn't exist yet. Not a problem. 04:27:22 If it doesn't break, then something really weird is happening that requires additional research. 04:27:53 Finally, once you've verified proper compiler behavior, it's time to actually write the real code. (in this case, "cfa! and "name!, along with their private definitions). 04:28:12 You write the code using the absolute minimal code possible that still satisfies those tests. 04:28:32 Re-run the tests every time you make any change to the code. 04:28:51 Since you have these tests in source code form, you can run them as often as you like, whenever you want. Therefore, they're always present. 04:29:11 I see 04:29:14 And if you run tests in a partially ordered manner (e.g., run the tests for lower-level code first, then higher-level, etc), then you can isolate bugs trivially. 04:30:06 By definition: if the behavior of a function doesn't match the expectations of the unit test associated with it, then there is either a bug in the unit test or in the function under test (more often than not, it's the latter, but still). 04:31:07 Anyway, PUBLIC: itself is tested with a whole different source block. 04:31:30 Block 46 tests the "cfa! and "name! words, which are critical to getting PUBLIC: implemented. But PUBLIC: itself is tested in block 47. 04:32:28 Note that block 46 executes before 47; therefore, if an error exists with "cfa!/"name! that would affect the operation of PUBLIC:, then it'll have a much higher chance of being caught first in block 46, thus completely ruling out the test code in 47 and even the definition of PUBLIC: itself. 04:33:07 If nothing is caught in block 46, then "cfa!/"name! must be OK by the tests given in block 46; therefore, the problem must exist either in the definition of PUBLIC: (or its descendent words) or in the unit tests on block 47. 04:33:19 So, as you can see, it makes localizing and isolating an error easy. :) 04:33:24 I agree 04:33:54 I've never tried anything like that 04:34:29 * crc will have to consider it for future use 04:35:08 Yeah. My recommendation would be to try it for new projects, or for existing projects that exists only in dire states of affairs. :) 04:35:27 :-) 04:35:36 You'll find that writing production code takes longer -- sometimes up to twice as long. 04:35:54 That's not a problem for me 04:35:58 But, OTOH, you'll also find debugging to go substantially faster. To the point of being non-existant in many cases. 04:36:32 It's like the difference between old-fashioned garbage collectors, that stopped the system to collect garbage all in one fell swoop once memory was exhausted, and modern, incremental collectors that do collection in the background. :) 04:36:39 * crc wishes he had thought of doing this when he started developing RetroForth 04:37:05 It could have saved a lot of headaches during the early development 04:37:22 Hehe :) 04:37:43 I found I couldn't apply TDD to most of FTS/Forth's cross compiler. 04:38:01 The supporting infrastructure just didn't exist. 04:38:11 So I had to rely on more formal methods to get it working. 04:45:40 What's the next thing you need to implement? 04:47:01 Next, I need to get the cross-compiler to emit a data section for the vocabulary database in the ELF executable. 04:47:57 ok 05:00:18 I added a new .data section, but it's technically a "code" section and not a data section. Linux doesn't care though. 05:02:04 I keep everything in one section 05:09:51 * kc5tja personally prefers to keep multiple different sections. 05:09:56 It just seems cleaner that way to me. 05:10:13 I don't have to muddle around with relocating data. 05:11:27 why would you have to relocate data? 05:12:23 Because the dictionary will grow and shrink at run-time. 05:14:04 My dictionary only grows; it never shrinks (unless you run 'restore') 05:18:57 RetroForth/Native now has a working serial port driver and a serial console 05:21:07 My dictionary remains constant in size, but to achieve minimal code size in an ELF file, only the space actually used is written to the .code section. 05:21:41 The vocabulary database itself is written in a separate section, and is always fixed in size (20KB per vocabulary). 05:22:00 ok 05:22:30 I figure I would just let Linux itself handle the placement of the sections; I don't want to deal with it if I can avoid it. 05:22:40 It just complicates system startup. 05:23:33 right 05:48:36 Well, this is down-right fucking stupid. 05:48:58 Apparently writing characters to the console via direct kernel calls does not redirect output!! 05:49:21 Hence, there is no way for me to analyze buggy output of my program. >:( 05:51:39 You should be able to redirect output 05:52:20 I do it all the time and I use direct kernel calls 05:57:01 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 06:00:27 It doesn't work on x86 Linux. 06:00:49 Linux version 2.4.22 06:01:27 That's OK though -- I found the bug. :) 06:02:09 * kc5tja has confirmed that the database IS accessible in the target image at the predetermined load address. w00t!!! 06:02:12 * kc5tja celebrates! 06:02:18 This is a rather major milestone 06:03:57 good 06:06:15 :) 06:06:50 * crc is searching for information on parallel ports 06:13:39 Here's a great picture: http://elvis.beefytreats.net/files/suidog.jpg 06:14:25 Heh. 06:14:37 That's funny :-) 06:17:14 --- quit: crc ("Time for bed... Goodnight!") 06:33:37 kc5tja: how many days a week do you work? 06:39:55 I now work 5 days a week. 06:44:28 --- quit: saon (Read error: 60 (Operation timed out)) 06:54:40 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 06:57:18 --- quit: Topaz (Remote closed the connection) 07:24:10 --- join: qFox (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 07:41:52 --- join: saon (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 07:51:36 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 07:51:36 --- mode: ChanServ set +o Herkamire 09:03:54 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 09:06:47 --- quit: saon ("Leaving") 09:17:43 I need to write an essay about software bloat for school. Any recommendations on books or papers to read? 09:17:47 --- join: das (~das@adsl-64-219-100-33.dsl.lgvwtx.swbell.net) joined #forth 09:17:52 Hi das 09:18:00 hello Robert 09:18:05 I need to write an essay about software bloat for school. Any recommendations on books or papers to read? 09:18:18 I thought #forth might be a good place to ask. 09:18:56 * das does not of any papers or books on the subject off hand... 09:19:41 OK, thanks anyway, 09:21:55 although software is bloated, and things take up too much memory. If we could all get by with under a meg of RAM, it could all be battery backed, and we could easily have instant on, instant off computers. With 64 meg to a 1 gig on laptops it would not be pratical to battery back the RAM. 09:23:50 * Robert looks at his 512MB laptop. 09:24:14 The problem is that it's my multimedia station, so I need enough RAM and CPU to play movies. 09:24:30 This computer, on the other hand, is only used for IRC and my web page. 09:26:39 Even laptop OSes could be designed better. Battery back some working space of about 1 MB. Have about 512MB of scratch pad ram that does not matter for it to be volatile. 09:26:39 Robert: http://www.laputan.org/mud/mud.html 09:26:45 not exactly an academic paper 09:27:15 das: Ah, yeah. 09:27:18 fridge: Thanks. 09:27:47 The teachers WILL torture me with burning sticks if I don't have any academic papers to refer to, but I guess it's a start. 09:28:51 Heh. Cute picture. 09:28:55 * das is reading the article now... Good one fridge. :) 09:29:13 --- nick: das -> das-lunch 09:29:22 I'll be back in few hours... 09:29:33 OK, see you :) 09:31:13 I tried to view that page 09:31:24 firefox renders it as raw text 09:31:29 and doesn't render the tags 09:31:57 I'm using Firefox. 09:32:04 Works fine 09:32:46 hmm, maybe you could reference it 09:32:52 I read it ages ago 09:33:12 and just filed it away as a rant 09:33:15 I could also include some rants by Jeff Fox. 09:51:54 --- join: crc (crc@52-pool1.ras11.nynyc-t.alerondial.net) joined #forth 10:04:13 hi 10:04:28 crc, i was studying the retroforth asm source, its very nice 10:05:09 thank you 10:05:26 I've been working a lot on the native version :-) 10:07:07 The serial port driver is working now; it's just 15 lines of Forth code (not counting comments or blank lines) 10:07:15 I started a parallel port driver 10:08:08 There's also a version that does provides a serial console too 10:08:48 I'm almost happy with my block editor 10:35:42 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 10:37:21 hi tathi 10:37:31 crc, is all the source in blocks? 10:44:34 Not really 10:45:29 I could write the code to fit in 1k blocks, but there's no point in that right now 10:45:52 The core startup code has to be loaded at startup, and the compiler doesn't care what it looks like 10:46:13 I have one word per line in the "blocks" 10:46:47 hi slava 10:47:10 When I write code _in_ RetroForth, I try to use real blocks though 10:47:26 so you have a userspace -vs- kernelspace distinction 10:47:30 Yes 10:48:06 The kernel is small, and easy to modify, but it requires a recompile for each change 10:48:15 The userspace can just be reloaded :-) 10:48:24 cool 10:49:12 It works well enough for me 10:49:33 how must i compile a C program so it can look up its own symbols at runtime with dlsym(NULL,"foo")? 10:49:52 I have no idea 10:49:52 I haven't touched C in almost a year 10:49:56 good riddance ;) 10:50:15 It's still useful for some things... 10:51:23 -export-dynamic 10:53:20 * crc has just added dynamic linking to RetroForth 10:53:45 bleh, -export-dynamic bloats cfactor to 70kb. but it simplifies the ffi 10:54:16 ( 1 ) "box_integer" dlsym-self . 10:54:16 134534724 10:57:10 Dynamic library support adds ~1k to RetroForth 10:59:20 --- nick: das-lunch -> das 11:03:05 slava, I did some symbol look of own symbols a couple years ago, but don't remember how I did it. It was forth related. I was thinking of writing a Forth that translated to C, and when something needed to be run, everything that had no been compiled was theen compiled and linked to a .so file, then pulled back in and run. 11:03:16 i've figured it out now 11:06:55 i'm having a lot of fun with my integrated assembler 11:07:03 slava: what is ffi? 11:07:17 crc, calling C functions 11:07:25 ok 11:07:32 crc, loading .so at runtime with dlopen() 11:07:46 crc, then compiling words that call the C functions with parameters from the factor stack 11:07:53 crc, ie, SDL graphics :) :) 11:07:56 I just finished code to allow that in RetroForth 11:08:28 " libc.so" LoadLibraryAs LIBC 11:08:40 LIBC " exit" MapFunctionAs libc_exit 11:08:45 libc_exit 0 1 invoke 11:08:47 :-) 11:08:50 cool 11:08:58 how does invoke work? 11:09:15 TOS = number of parameters to pass 11:09:29 ok 11:09:30 It takes a value from the Forth stack, puts it on the return stack 11:09:45 my approach is similar i guess, except the parameters and their types are specified at 'MapFunctionAs' time, not with 'invoke' 11:09:49 It then calls the library function, cleans up the stack, etc 11:09:58 ok 11:10:40 This is identical to the system interface in RetroForth/Windows 11:11:20 I only had to change about six lines of code to allow it to work with libdl.so 11:11:45 what is the linux libdl api? 11:11:50 is it like freebsd? (dlopen/dlsym) 11:11:54 Yes 11:11:57 ok 11:12:00 so i just need to remember to add -ldl 11:12:02 And it's the same under BeOS 11:12:05 damn i'll have to start using autoconf soon 11:12:10 on solaris, i need -lnsl -lsocket 11:12:31 Right 11:12:36 Though BeOS doesn't include libdl.so, so it has to be downloaded from BeBits 11:12:41 * crc hates autoconf 11:12:46 yeah i hate it too 11:12:52 i might make a lighter solution 11:13:00 like a master Makefile then Makefile.linux Makefile.solaris etc 11:13:35 I just have a separate source tree for each OS 11:13:57 my source compiles without changes, its just linker flags and such that are troublesome 11:14:26 Just have the user edit the makefile manually :-) 11:15:29 heh 11:16:15 --- nick: das -> das-away 11:17:55 Or have them type 'make osname' 11:18:21 * crc used that before splitting the ports into separate source trees 11:22:17 --- join: arke (arke@adsl-69-209-54-62.dsl.chcgil.ameritech.net) joined #forth 11:22:30 hello arke 11:22:50 hi 11:22:55 I'm back 11:23:02 why does Robert have voice? :) 11:24:13 hi 11:28:12 * crc wonders what driver to write next... 11:28:49 Hi 11:28:55 arke: Because I can speak! 11:30:38 SDL_INIT_VIDEO SDL_Init 11:30:38 640 400 32 0 SDL_SetVideoMode 11:33:48 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 11:33:51 slava: don't you mean 11:34:01 640 400 32 SDL_HWSURFACE SDL_SetVideoMode ? 11:34:47 probably :) 11:35:03 :)P 11:36:56 --- join: crc_ (crc@9-pool2.ras11.nynyc-t.alerondial.net) joined #forth 11:36:57 --- quit: crc (Read error: 104 (Connection reset by peer)) 11:37:00 --- quit: crc_ (Client Quit) 11:37:02 --- join: crc (crc@9-pool2.ras11.nynyc-t.alerondial.net) joined #forth 11:37:32 --- quit: saon (Client Quit) 11:43:11 --- join: Frag-101 (XINU@12-222-128-22.client.insightBB.com) joined #forth 11:51:58 I can now send bytes to a parallel port; though I haven't figured out how to read from it yet 11:53:18 crc: :) 11:55:51 kc5tja: hi :) 11:59:42 Ok, now I can read from it too 12:00:04 * crc is writing drivers for RetroForth/Native 12:22:52 --- quit: qFox ("this quit is sponsored by somebody!") 12:28:25 --- join: crc_ (crc@71-pool1.ras11.nynyc-t.alerondial.net) joined #forth 12:28:39 --- quit: crc (Nick collision from services.) 12:28:44 --- nick: crc_ -> crc 12:39:52 --- quit: I440r ("Leaving") 12:48:14 Wow. Amazing the little details of differences between processors that you turn up when you're porting something. 12:48:38 Such as what? 12:48:46 I've just been learning about divide instructions on x86 and PPC. 12:48:52 they round the results differently in some cases. 12:49:03 interesting 12:49:10 PPC always rounds the quotient towards zero. 12:49:34 --- quit: proteusguy (Read error: 54 (Connection reset by peer)) 12:49:57 on x86, it rounds towards negative infinity. 12:50:00 --- join: proteusguy (~proteusgu@68-114-24-230.cpe.ga.charter.com) joined #forth 12:50:12 tathi, doesn't x86 have both forms of division? 12:50:32 slava: I don't know. 12:50:39 I'm talking about integer division here... 12:50:47 I thought there was just div and idiv. 12:51:00 oh, maybe there's a processor flag or something. 12:51:29 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 12:55:02 x86 = teh duck 12:55:03 :) 12:55:04 err 12:55:05 suck* 12:55:06 :) 12:56:17 x86 = the duck 12:56:19 I like that :) 12:56:22 hehe 12:56:33 teh even 12:56:35 tathi: ficl+sdl = frapiar :) 12:57:01 why ficl and not gforth? 12:58:16 because i can plug ficl into pretty much anything 12:58:57 core stuff is written in C 12:59:00 the rest in Forth 12:59:00 :) 12:59:12 arke: nice. 12:59:16 arke, why is the core in C? 13:00:18 slava: because I said so. 13:00:34 tathi: haven't decided if I want the GUI stuff in C or Forth. 13:00:44 tathi: Forth would be easier, C would be faster. 13:01:04 tathi: C would be much harder because I'd have to write all the bindings to ficl manually 13:02:44 slava: easiest thing for me, thats why 13:03:10 tathi: actually, I don't know which would be harder.... the C code can just be plugged in 13:03:16 right 13:03:23 ]while the forth one would have to be writen first 13:03:29 although i'd prefer that. 13:03:30 ... 13:03:32 that's cool that you're still working on it though -- I thought you had abandoned it for an OS project 13:05:37 i've got several projects 13:05:48 it depends on what OS im booted into which project im working on 13:05:52 ah. 13:05:54 right now, im in windows, so working on frapiar 13:06:21 operating systems these days. sheesh 13:08:27 :) 13:14:16 --- nick: das-away -> das 13:15:33 --- join: crc_ (crc@95-pool2.ras11.nynyc-t.alerondial.net) joined #forth 13:15:44 --- quit: crc (Nick collision from services.) 13:15:50 --- nick: crc_ -> crc 13:16:23 jeezus crc you're connecting like a monkey on crack 13:17:19 arke: you try keeping a connection alive when you're on dialup, have noisy lines, and the weather is stormy 13:17:21 :-) 13:21:29 --- quit: proteusguy (Connection reset by peer) 13:22:26 --- join: proteusguy (~proteusgu@68-114-24-230.cpe.ga.charter.com) joined #forth 13:22:55 i'm working on some words for interfacing with C structs 13:27:36 I just fixed an apple pro mouse 13:27:46 man those things are hard to get apart 13:30:08 had a little fun with it though: http://herkamire.com/downloads/mouse.jpg 13:30:35 haha, excellent 13:31:42 hehe 13:31:46 my school needs such! 13:33:33 if you want to see the rediculous 9-step process to get it open: http://www.sewardweb.com/applepromouse/ 13:33:37 http://herkamire.com/downloads/mouse.jpg 13:33:40 oopts 13:33:44 some parts are glued together. 13:34:19 you actually have to cut through two plastic things to get it apart. 13:34:26 :/ 13:34:51 :( 13:34:53 mur 13:34:55 teh mur 13:34:57 mur 13:34:59 teh mur 13:35:02 :) 13:35:05 ^_^ 13:35:07 finland at its best 13:35:09 yuay 13:35:12 im hyper 13:35:14 kill me 13:35:17 * arke drops dead 13:35:19 akreleeke 13:35:20 arke 13:35:22 terve 13:35:38 hypertext! 13:39:33 ( 21 ) .s 13:39:33 { # } 13:39:33 ( 22 ) surface-width . 13:39:33 640 13:39:54 i can do basic C structs now! 13:40:23 cool! 13:42:46 next steps is a better notion of conversion between C types and factor types 13:42:56 :) 13:43:01 then i should be able to draw pixels on the screen :) :) 13:45:37 good night 13:46:48 --- quit: tathi ("leaving") 13:53:43 ACK 13:53:59 I need some toothpicks to prop my eyes open 13:54:28 :) 14:04:08 --- quit: arke ("leaving") 14:04:30 --- join: arke_ (f2@bespin.org) joined #forth 14:05:03 --- nick: arke_ -> arke 14:10:26 --- join: TheBlueWizard (TheBlueWiz@modem-151.nyc-tc03b.FCC.NET) joined #forth 14:10:26 --- mode: ChanServ set +o TheBlueWizard 14:16:24 --- quit: crc ("Time for bed... Goodnight!") 14:59:35 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 15:20:06 --- quit: Herkamire ("trying herkforthos again") 15:31:12 Good morning. 15:31:32 'lo 15:32:25 hi 15:32:29 kc5tja hiya 15:32:31 kc5tja! :) 15:32:36 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 15:32:38 TheBlueWizard! :) 15:32:41 kc5tja, i've very close to drawing pixels with SDL 15:32:58 arke hiya! :) 15:33:08 ^_^ 15:33:38 15:34:17 kc5tja: modifying vibe to include escape code arrow keys. for myself. :) 15:34:57 arke: Sweet. 15:35:16 Hey, I just realized something pretty significant: in order for FTS/Forth/L4 to boot via Grub, I have no choice -- I MUST have a filesystem. 15:35:19 :) 15:35:35 ext2fs? :) 15:35:40 So I guess that pretty much solves that problem by default. 15:36:08 a grub supported FS, i assume? 15:36:09 ext2fs seems like a rather complicated filesystem. I'm not sure yet. 15:36:35 Well, it'd be nice, certainly. The alternative is to port another filesystem to Grub. 15:36:56 what does grub support? 15:37:05 I forget off the top of my head. 15:37:19 FAT, ext2fs, BSD FFS, and a small smattering of other filesystems, as I recall. 15:37:34 * arke looks oonline 15:40:31 kc5tja: FAT12/16/32, ext2, ufs, minix 15:40:45 except that that cna't be complete, as it boots nbtfs and reiserfs here 15:41:23 maybe the doc is a bit dated 15:42:08 I suppose one can implement a "raw" booting (e.g. assume the partition to be raw) 15:42:59 well, gotta go...all bye! 15:43:00 probably 15:43:02 bye TheBlueWizard 15:43:09 arke bye 15:43:43 bye TheBlueWizard 15:44:15 --- quit: saon ("Leaving") 15:44:51 das bye :) 15:45:24 --- part: TheBlueWizard left #forth 15:46:40 kc5tja: oh man, the way you handle this with find is INGENIOUS 15:47:02 arke: ?? 15:47:17 I tried looking too -- yeah, the list of filesystems still seems to be small, although it has expanded a bit. 15:48:19 kc5tja: vibe. you're interpreting by creating words with the hex name and searching for it. 15:48:53 OOH! I didn't know this! Maybe we don't need to support a filesystem. GRUB supports a block-list format to specify files too. 15:49:21 E.g., "kernel 10+20" will load starting at block 10 (512-byte blocks), which is 20 blocks long. 15:49:24 kc5tja: yay!!! :) 15:49:34 * kc5tja had no idea that even was supported. 15:49:50 kc5tja: thjat is awesome :) 15:50:31 Yes, very much so. 15:51:06 Although, I'm still very confused -- how does one configure a "menu.lst" file using this? 15:51:10 : handle-esc key? if eval-seq else cmd then ; 15:51:20 kc5tja: true. 15:51:45 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 15:51:45 --- mode: ChanServ set +o Herkamire 15:51:50 There must exist a path to the menu.lst file. So I'm thinking that, despite the ability to load raw block lists, a filesystem might still be quite desirable. 15:51:59 Boyaaa! 15:52:09 herkforth runs decently directly on OpenFirmware now 15:52:16 Herkamire: Congrats!! :) 15:52:19 :) 15:52:35 I just ran it for a bit, and determined the exact character dimentions of my screen. 15:52:42 Question: Does PearPC come with an OpenFirmware implementation for it already? Or did you need to copy the implementation from your current Mac? 15:52:56 once I punch those in you'll be able te see the command history and output 15:53:17 pearpc runs on it's own afaik. 15:53:20 Herkamire: yay :) 15:53:23 it emulates basic OF 15:53:56 the code I have to get the memory address for the frame buffer is getting a value, but storing to it crashes 15:53:57 Sweet :) 15:54:16 thought maybe it was a bug in pearpc, so I tried it directly under OF, and it crashes there too. 15:54:23 so apparently I'm missing something 15:54:46 FTS/Forth may be required to support a filesystem, to support booting from GRUB. 15:55:38 maybe the MMU being a bithc? :) 15:55:43 heh, that's a nice thing about OF 15:55:49 I guess. 15:56:03 what's a nice thing about OF? 15:56:06 it'll load an ELF 15:56:12 So will GRUB. 15:56:25 oh yeah 15:56:40 kc5tja: why do you need filesystem support to boot? 15:57:03 I don't have any fs support yet 15:57:08 But it loads its stage 1.5 and stage 2 loaders from disk, and any menu description must be found in a file called "boot/menu.lst". 15:59:01 haha 15:59:01 what a hack i just wrote 15:59:02 lets see if it works :) 15:59:41 it doesn't 15:59:43 :) 16:01:57 arke: FTS/Forth now has a Forth vocabulary that is built by the cross-compiler. And yes, the target application can see it. :) 16:02:25 arke: yay! 16:02:32 The next step is to implement the dictionary search code in the target image. 16:02:34 arke: that means a rudimentary interpreter soon :) 16:02:46 so, FIND basically 16:04:08 Correct. 16:04:48 create esc-seq-bmp ' up , ' down , ' left , ' right , : do-arrow cells esc-seq-bmp + execute ; : (eval-seq) key 'A - 4 < if do-arrow else drop cmd then ; : eval-seq key '[ = if (eval-seq) else cmd then ; : handle-esc key? if eval-seq else cmd then ; 16:04:53 'tis a hack 16:05:00