00:00:00 --- log: started forth/05.06.30 00:14:45 --- join: danniken- (CapStone@70.249.186.85) joined #forth 00:14:46 --- quit: danniken (Read error: 54 (Connection reset by peer)) 00:35:35 --- quit: alexander_ (Remote closed the connection) 00:48:21 --- quit: Herkamire ("off to bed") 02:33:38 --- quit: kunphuzil ("Download Gaim: http://gaim.sourceforge.net/") 02:54:16 yay! japanese is postfix! 03:59:44 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 04:18:21 howdy tathi 04:18:29 you're up early! baking the buns eh? 04:26:06 heh. I'm not up particularly early for me. 04:26:13 * tathi is a morning person 04:27:22 so...when you put that topic on c4th-ot about Forth chips, were you thinking of Patriot Scientific? 04:27:26 or...? 04:35:46 yeah i was 04:36:01 ok. 04:36:11 well, it actually sparked some useful stuff 04:36:37 they don't really have anything on their current web site saying that they sell actual chips. 04:36:56 but both rj_cf and Herkamire contacted them and they were pretty helpful 04:37:23 yeah i contacted them 2-3 years ago and was told the chip was 15 bucks 04:37:38 individual purchase 04:37:38 up to $17 now, apparently. 04:37:40 yeah 04:37:41 ah 04:38:03 well its just that sometimes forthers bemoan lack of forthchips .. 04:38:08 * tathi really needs to get into electronics one of these days... 04:38:36 --- join: virl (Phantasus@chello062178085149.1.12.vie.surfer.at) joined #forth 04:38:43 i guess the other factor is that you need additional equipment to interface with the chips properly don't you? 04:38:49 is that why you make the comment about electronics 04:39:08 yah, because I don't know enough to build a system just now. 04:39:11 but they do sell a package for that interfacing.. 04:39:24 cool. 04:39:31 does somebody know the link to the gforth sdl ffi example, from yesterday? 04:39:37 well i would just imagine you get the chip and the package and then hook it up to your computer and communicate to the chip via port 04:39:48 They told Herkamire on the phone that they didn't have much in the way of development boards, except for some FPGA versions. 04:39:56 virl: http://tunes.org/~nef/logs/forth/ 04:40:01 But that once they finished getting their website up they would be working on some new boards. 04:40:12 virl: that code example? 04:40:20 how long ago did they tell him this? 04:40:36 http://www.falvotech.com/projects/kestrel/repo/kestrel/cores/cpu/sdl.fs 04:40:41 cuz the email to me said there was a development board to purchase 04:40:50 and this was 2-3 years ago.. 04:41:00 this was last week or so. 04:41:30 ok well i think the chip is probably a different one now 04:41:35 yep tathi, that example. how did come to this? 04:42:01 that's from kc5tja's emulator for his Kestrel project, back when he was still working on it. 04:42:45 eph: yah, I got the impression that they are kind of starting something new. 04:42:52 and don't have everything finished yet. 04:43:13 what about that licensing thing with AMD? 04:43:27 don't know anything about it 04:43:37 i half expected the licensing thing would be a ploy to stop sales of the chip to the public heh 04:43:47 a little bit of jeff fox's paranoia rubbed off on me 04:44:56 :) 04:47:50 virl: it sounds like they stole the ffi syntax from bigforth, so it might be documented there... 04:52:26 eph: so are you up to anything interesting lately? 05:22:26 in which forth magazine is the structure mechanism described? 05:33:14 --- join: PoppaVic (~pete@0-2pool238-88.nas24.chicago4.il.us.da.qwest.net) joined #forth 05:33:39 Mornin' 05:33:45 Hi 05:54:08 PoppaVic: were you talking yesterday about actually writing a libelf? 05:54:14 or just saying that we needed one? 05:54:27 no, I don't believe I'dtry to write it alone. 05:54:45 I do too much code alone now - it slows progress down to a crawl 05:55:12 ok. 05:56:08 Just curious -- I'd rather like to have such a thing, but don't feel like writing one myself either. 05:56:27 Not that there's anything too difficult about it, but it would be awfully tedious. 05:56:29 Yeah, it would mean an awful lot of reasearch into the elf formats 05:57:12 The ELF format is documented in the SysV ABI documents. It's not actually that complicated. 05:58:16 The tricky bit would be implementing the restrictions to be able to generate files which are OK with various operating systems. 05:58:32 Linux is pretty lax about checking, so you can get away with a lot. 05:58:37 yep 05:58:53 But BSD (FreeBSD at least) disallows some things that the spec EXPLICITLY says are OK. 05:59:02 well, I can't see it being any more tough than the dlopen-interface most places use (one way or another) 05:59:17 Yeah, like I said, it's mostly just tedious. 05:59:43 (I'm talking about relocatable files; .o) 05:59:47 Another Good Thing(tm) would be a ass-kickin' breakout of goddamned libc 05:59:52 executables are almost trivial 06:00:10 what do you mean by breakout? 06:00:19 sure, the .o output for relocatability would be the most important part. 06:00:45 breakout: as in, beating libc into a set of none-kitchen-sink libs 06:01:25 breaking it up so that you can only use the parts that you need? 06:01:56 s/only use/use only/ 06:02:03 well, more so we can rebuild sections easier and isolate groups. 06:02:31 have you looked at dietlibc much? I'd be curious what you think of that project. 06:02:55 I'd peeked at dietlibc and ulibc awhile back - not worked with either, though 06:03:01 (I think there are a couple of similar projects, but dietlibc seems the nicest) 06:34:07 --- join: sproingie (~chuck@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 06:41:56 --- quit: madwork (Connection reset by peer) 06:41:57 --- join: madwork_ (~madgarden@derby.metrics.com) joined #forth 07:15:39 * PoppaVic humpfs 07:20:53 tathi: I dunno asm well, but isn't there a way to tell the asm (hence build objects) Such that code and data are all in the same space? 07:21:48 hmm...somewhat depends on the system. 07:22:11 I don't know that there's a simple answer to that. 07:22:33 If you have static data, you can pretty much always put that in with the code. 07:22:40 well, I know of .data and .text, but almost invariably the default is to disallow code-running from .data' (and prolly the heap). 07:22:48 right. 07:23:31 doesn't rf execute from the heap? 07:23:40 Iffin' we can set up the core to properly torque the segments and perms, it'd be interesting. 07:23:46 and often .text is write protected. 07:23:49 sproingie: no idea 07:23:54 yes, tathi 07:24:01 or possibly rf's heap is allocated in code 07:24:10 but you can get around most of this stuff if you're willing to write a linker script. 07:24:10 hmm 07:24:21 hmm. 07:24:30 i don't see any segment markers in rf.asm, so it's probably part of code 07:24:33 and (under Linux, at least) you can use mprotect() to change the permissions on a block of memory. 07:24:57 I'm trying to NOT think about linkers and such at the mo.. Just focussing on a core-lib and then the tools 07:25:08 yes, I'd seen mprotect 07:25:23 oh wait there it is. section bss 07:25:28 ok, macosx has mprotect as well 07:25:47 umm.. bss isn't the heap, though 07:25:54 yah, i forget what bss is 07:26:00 blank space section 07:26:07 static vars? 07:26:08 I think it's static vars 07:26:22 linkers confuse and frighten this poor unfrozen caveman coder 07:26:46 I've come to a reasonable agreement with my linker :P 07:27:05 i've even read Linkers and Loaders 07:27:11 and i STILL don't really understand linkers 07:27:19 * tathi thinks all this stuff is more badly documented than actually difficult to use. 07:27:25 oh my yes 07:27:30 I sorta' do, but - as you suggest - it's quite convoluted. 07:27:39 gnu tools have some horrid documentation 07:27:57 half of them have a man page that tells you that man is old and busted and to use info instead 07:28:01 and then the info page doesnt exist 07:28:08 I imagine the linkers/loaders are really no tougher than cfa, pfa, lfa, nfa, etc - but the docs are written by illiterates. 07:28:08 I generally use a linker script that's about 7 lines long 07:28:09 or it's no better than a summary of options 07:28:23 I have a couple of more complicated ones, but I don't usually use those. 07:28:56 right, GNU screwed up years ago by deciding THEY did not need support man, but that info was golden - and even their info-files often make me want to hurl. 07:29:17 brb 07:29:23 tathi: I presume you mean written in a forthish 07:30:43 I think I am prolly hung up by seeing "C generated " versus "I am so damned 'leet ASM " 07:31:08 what written in a forthish? 07:31:24 your 'script' 07:31:33 no. 07:31:42 GNU ld takes a linker script to tell it how to put things together. 07:31:48 it has a huge long complicated one built in. 07:31:55 which you can see by running ld --verbose, I think. 07:32:08 ok, I've not bothered on this powerbook 07:32:30 but yeah, this is for programs written in asm 07:32:47 right.. interfacing with C would prolly be painful. 07:33:13 ld is pretty neat, even the dynamic loader can interpret a script 07:33:21 it's probably more tricky to mess with segment permissions from C-generated .o files. 07:33:29 tathi: yah 07:33:45 on my system, /usr/lib/libc.so is a two-line linker script 07:33:47 I don't think the linker will change permissions from what they are in the sections in the .o files. 07:33:49 Or, a simple sed/perl/regexish script could handle it 07:33:51 OUTPUT_FORMAT(elf64-x86-64) 07:33:51 GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) 07:34:28 But! It would be trivial to write a C program that would modify the section permissions on .o files. 07:34:31 hmm.. afaik, an object is damn near as much loader-info as it is code & data 07:34:42 so maybe you could do things that way. 07:34:44 i think the default permissions on the sections are set by the kernel 07:34:44 tathi: right 07:35:26 hmm.. I'd never noticed that that issue mattered to asm-programers 07:35:35 what issue? 07:35:39 oh, default - as in "you'd override" 07:35:43 ah. 07:36:09 sproingie: the kernel pretty much just loads things the way the ELF file says to. 07:36:31 you can run into conflicts, of course. 07:36:35 sure 07:36:42 "I can't load your program there; that's where the kernel is!" sort of thing 07:37:03 afaik, the kernel isn't terible smart: mostly considering files, sockets, streams, perms, users, etc 07:37:14 yah 07:37:31 kernel shouldnt be smart 07:37:38 I know 07:38:13 Which is why I think the mess is "doable" - but currently no idea how to do so, let alone if it would mung c 07:38:49 I'm fairly sure the .o would just id .sections and record offsets and shit to change. 07:38:58 well, if you have something specific you want to do in code, I might be able to help you out with it. 07:39:12 ok, let me gather more ducks for the shoot 07:39:13 you can have any section you want, really. ld is just used to a certain naming convention 07:39:31 yeah, but the C compiler only generates certain ones. 07:39:36 right, and C mandates a few - but I don't believe they CAN mandate how they are treated. 07:39:42 it's not too hard to tell it to generate different ones 07:39:58 tho...if you're going C->asm, then you could use a sed/perl/awk script to change those :) 07:39:59 it's like one asm statement 07:40:08 asm("section .funkytown"); 07:40:09 righto 07:40:10 something like that 07:40:35 PoppaVic: GNU as won't let you put different permissions on sections named .text .data .bss 07:40:48 ahhh 07:40:51 so to some extent, they CAN mandad how they are treated. 07:41:00 mandate 07:41:05 ok, I'd wondered about that 07:41:15 I'm not sure if that would interfere. 07:41:23 but you still have several options. 07:41:29 1) change the names before assembling 07:41:41 2) change the permissions on .o files after assembling 07:42:10 grr, had a 3rd idea, but I lost it 07:42:27 ah. 07:42:35 3) mprotect to change permissions once you're running. 07:42:40 Well, let's pause a mo.. here is where I see an issue: 1) let's assume you've loaded a forthish assembler: where the heck do you run the compiled code?; 2) generating and loading modules. 07:43:04 yeah, mprotect seems POSSIBLE, but it's gonna' take me a shitload of reading 07:43:06 rf runs everything out of bss apparently 07:43:09 ah. 07:43:15 mprotect is one system call. simple 07:43:43 hmm, I may need to bail very soon - thunder is driving in hard. 07:43:50 if you compile code into memory, you MUST mprotect it before you run it. 07:43:53 (if you want to be portable) 07:44:08 do you mprotect the ptr? the whole heap? 07:44:16 whichever pages your code lives in 07:44:30 hmm, which is a malloc issue 07:44:30 you protect one page at a time. mprotect is a convenience that hits a whole range 07:44:31 mprotect(const void *addr, size_t len, int prot); 07:44:39 ahhhh! 07:45:00 basically it advises the VM subsystem to give those addresses that protection when they're paged in, if they're not already 07:45:03 so, you'd use the ptr, the size the code invokes, and the new perms 07:45:10 if you're doing asm, you can do something more specific, but if you're running from C, you use mprotect. 07:45:13 yup. 07:45:18 see man mprotect 07:45:22 ahhhh-so, weedhoppa'! 07:45:32 OK, will consider that as well, thank-you. 07:46:07 in my little forth, I just have PPC asm code to flush the data cache and invalidate the instruction cache, for instance. 07:46:08 ok, I'm bailing - the sky is now black and trees are flailing... 07:46:11 if you're dynamically generating code, you might just want to use the asm to protect one page at a time 07:46:11 bbl 07:46:12 laters then 07:46:15 --- quit: PoppaVic ("Pulls the pin...") 07:46:33 no surge protectors, eh? 07:46:46 i suppose that won't help against a direct hit 07:47:10 it seems like it's mostly chance. 07:47:31 had a lightning bolt hit here a couple of weeks ago, about 30 feet from the house. 07:47:41 this box is right at that corner of the house too. 07:47:47 it was running at the time. 07:47:52 * sproingie lives in a pretty modern building with 15 floors above him. not worried about direct hits 07:47:56 no damage at all 07:48:12 long as it doesn't hit your power, shouldn't cause any damage 07:48:12 lost a couple ports on the ethernet switch though. 07:48:35 hmm 07:48:47 strange that the ports fried tho 07:49:29 well, the power line coming into the house is over on that side as well 07:49:35 so I assume we got at least some surge 08:23:39 --- join: PoppaVic (~pete@0-2pool236-192.nas22.chicago4.il.us.da.qwest.net) joined #forth 08:24:04 * Robert returns again. 08:24:14 back - I think 08:24:23 Hi - probably 08:24:33 Yay to Adobe's CS suite of software 08:24:40 Installing right now. 08:24:43 You know what I hate? 08:24:51 when programs refuse to install because you have to restart. 08:24:52 I mean, wtf 08:25:15 Eh, what system are you using? 08:25:36 http://linux.about.com/library/cmd/blcmdl2_mprotect.htm 08:26:09 Interestingly enough, mprotect ALMOST does what we want, but posix apparently restricts it to only mmap'd use 08:26:24 Or, without all the banners, man 2 mprotect ;) 08:26:38 heh. you beat me to it :) 08:27:11 PoppaVic: Portability in unforthish. :) 08:27:28 well, it seemed important, and the thunder is down 08:27:34 PoppaVic: Besides, you could always change that one syscall if you're moving the system. 08:28:01 XP, of course :P 08:28:05 What exactly are you going to use it for? 08:28:19 arke: Eeeew... But, what did I expect from a BASIC coder? :) 08:28:24 ahhh 08:28:28 http://www.quepublishing.com/articles/article.asp?p=23618&seqNum=10&rl=1 08:28:40 I was unaware mmap could allocate akin to malloc 08:30:02 yeah, mmap is the front end to a huge pile of similar functionality. 08:30:04 Robert: :) 08:30:28 well, damn tathi - that could be useful, if it were not so irksome. 08:31:06 sorry, what's irksome? 08:31:28 using mmap to allocate memory? 08:31:40 well, *I* have never suffered mmap, and the manpages are not much of a thrill. 08:33:07 What I planned was to allocate a working-buffer to compile into, and resize as required. But, this mmap/mprotect stuff might mung that up a bit. 08:33:20 void *fun_mmap(size_t len, int prot) { return mmap(NULL, len, prot, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0); } 08:33:36 :) 08:33:43 what the heck was that? 08:34:18 a C function wrapping mmap, and leaving out all the parameters that you don't care about for just allocating memory. 08:34:26 hmmmpf 08:34:41 it'd be EXEC as well, no? 08:34:57 oh, I see it - lemme digest a bit 08:35:51 that code would return a ptr to a mmap'd 'page-aligned' mess we'd havepermed, right? Still need to copy over the buffered code and whatnot? 08:36:19 well, you have to allocate the working buffer initially. 08:36:45 you could have another function that did a memcopy (or whatever the currently accepted name is) as well. 08:36:52 (for resizing, that is) 08:37:40 oh, wait, resizing is more complicated, isn't it? 08:38:04 because you might have things calling into your compiled code from outside your buffer? 08:38:10 yah 08:38:17 and moving it would screw up any relative offsets. 08:38:26 * sproingie suggests taking a look at JIT compilers and seeing how they do it 08:38:38 recall: 1) the forth : lists are trivial to store; 2) asm isn't trivial. 08:38:57 but you're going to have to deal with that anyway, because realloc doesn't guarantee that it's going to stay in the same place either. 08:39:03 right 08:39:23 absolute addressing would be a "bad thing" - within the realloced code 08:39:34 so resizing a memory block *could* be that trivial. 08:39:54 though you could try mmaping more pages consecutively if they're available. 08:39:56 yes, as long as it is all relative 08:39:59 and only move stuff if necessary. 08:40:03 right 08:41:25 It almost suggests to me that mmapping a file (which we generate tmp) and "window" within is also plausible. 08:41:45 sure. 08:42:25 having never used mmap in any way, shape or form - it seems a trifle daunting, but I am not at the point where I need to worry, either. 08:43:07 If mmapped files automagically "scroll" for the next 'read', it'd be near trivial. 08:44:31 hrm. I don't know about automagically scroll. 08:44:39 tathi: it almost sounds like a dynamic, file-based, buffered executable. 08:44:53 like... a few removes from a linker/loader 08:45:12 mmap would just map a file into memory somewhere. 08:45:23 right, with a window (buffer) size 08:45:52 well, you give it a fd, a file offset, and a length 08:46:02 hmm, I was just looking into that 08:46:03 if you want that to change, you have to change it yourself 08:46:34 IsForth's fload simply mmaps the entire file into memory. 08:46:42 ouch 08:46:53 why ouch? 08:47:06 unless you have a file that's bigger than your address space... 08:47:07 seeing the size of what some folks consider one file?? 08:47:48 I'm cogitating, I'm cogitating! ;-) How would dlopen/dlsym work this mess? 08:48:33 ref a label, look it up, save it and the fd and offset for access? 08:49:14 well, if you want a symbol, you have to load the whole .o file containing that symbol. 08:49:24 that's why libraries usually have a lot of little C files. 08:49:50 'cause then they get compiled to a lot of little .o files, and thus you have finer granularity when you use the library. 08:49:59 yeppers, and I agree 08:50:18 what's wrong with mmaping the file into memory? that's how open(2) works on most unixen actually 08:50:23 ok. I'm never sure how much stuff people already know :) 08:50:34 I'd wager as well that the mmap'd space is as likely to hit the swap-file as any other mess. 08:50:54 yah, it's all managed by the MMU anyway, so it's not necessarily loaded until you need it. 08:50:55 np, tathi better safe than talking parallel 08:51:05 (dunno how good the implementations are) 08:51:09 hmmmm. Interesting 08:51:30 that's why filesystems generally allocate in units of 4KB 08:51:40 that way it matches the memory system's page size for easy mmaping 08:51:42 The funny part is... These sorta' "small .o" are what I recall from the Long Ago of cp/m and C 08:52:04 PoppaVic: mmap'd files don't load the file contents into main memory, they do it lazily 08:52:07 generally, .c and .o had one func or a few 08:52:14 PoppaVic: it only reads it off the disk when you actually read the page 08:52:20 sproingie: even better, I suppose 08:52:46 it's how open works, at least in bsd anyway 08:52:54 sproingie: do we actually need to ask it to move ahead before a r/w or is the mmaped file going to automate it? 08:53:15 linux's VM is such a godawful MESS that i wouldn't be surprised if open(2) didn't actually use it 08:53:22 sproingie: :) 08:53:31 PoppaVic: i'm not sure what you mean by "move ahead" 08:53:47 I say again: the linux-weenies need to stop hacking for a year and recode clean. 08:53:52 * PoppaVic sighs 08:53:57 the linux weenies need to take an axe to the VM code 08:53:58 linux: love/hate 08:54:02 google for "kswapd" 08:54:09 noooo! 08:54:14 you'll find a litany of fear and loathing and hate that goes back to 1998 08:54:28 and continues to this day 08:54:51 sproingie: by "move ahead", hmm... like a normal FILE* - where the buffer is filled, flushed; or read, indexed and read, etc. 08:54:54 I leave them fighting and continue to use the, after all, working product. 08:55:05 it's probably the most frequent support question of experienced admins: "why is kswapd eating 99PU?" 08:55:42 PoppaVic: stream ops basically move a pointer in the mmap'd file memory, and the VM will swap it in on read 08:56:00 * sproingie hm, keyboard is eating keys, should be "99% CPU" 08:56:29 if it were up to me, i'd convert every one of our servers at work to freebsd 08:56:36 sproingie: so, you can really read thru the whole file that was mmaped; or you can keep writing to it and the FILE grows, right? rewind works on it as well as seek? 08:56:42 because we're running into the kswapd problem every time we do something as simple as untar a large file 08:57:07 PoppaVic: it uses mmap for existing files. i actually don't know how it deals with growing it 08:57:13 PoppaVic: mmaping the whole file is just like taking a normal FILE* and reading the whole thing into a huge buffer. 08:57:15 PoppaVic: and linux may not even do it that way 08:57:17 only more efficient 08:57:35 tathi: the latter I follow, just not sure what monster-size is apropos. 08:58:03 * sproingie had to fight to get them to use fedora instead of an RHEL (which they don't bother buying support for) because "it's not the corporate standard" 08:58:18 Hmm.. I wonder if APUE has a decent mmap & friends section. 08:58:31 so i doubt freebsd is even a starter 08:59:16 hell, there are still folks that declaim *nix for plan9 or things in their heads 08:59:49 I fully agree it'd be damn nice to unify the *nix universe for 2006 09:00:09 i interviewed at ncube years ago. they apparently use plan9 in their media distribution boxes 09:00:10 alas, too many illiterate haqueers 09:01:09 oh, and lets never forget the goddamned "ivory-tower commies" 09:01:37 like who 09:05:00 The committees that mandate stuff we generally had no prob with before the mandates 09:05:42 look at poor ol' C - gcc-modes, ansi, c79, c99, and several poxsix 09:06:14 Long live gets() 09:07:20 posix has nothing to do with the C standard 09:07:31 blame IEEE for posix 09:07:34 heh - no shit ;-) 09:08:02 C is - now - nearly as bad as umpty forthish dialects 09:08:11 i think the C and C++ committees do fine. hardly ivory tower at all 09:08:24 I think they love dicking semantics 09:08:58 no, they're stuck with certain semantics that they really cant change 09:09:05 I'd wish 09:09:43 I think they'd do better in stopping the incessant desire to run into C++ and focus on a libc standardization. 09:09:58 that's not C's job, that's SUS's 09:10:03 heh 09:10:36 C was what I was talking about, I know it irks folks that actually follow/find and READ the assorted std's docs 09:11:02 anyway Just an itch I can't scratch 09:11:05 i think SUS can safely assume that unix will always use a C interface 09:11:21 what you actually implement the OS in is your choice, but you'll have to provide a C interface 09:11:34 (which C? which libc? Does either matter?) 09:11:57 i don't think posix actually cares if you split it out into a hundred different libs 09:12:11 as long as your headers are the same. it's a source-level standard 09:13:20 SUS = Single Unix Specification? 09:13:24 yep 09:13:26 posix itself is off The manpages will reference diff stds 09:13:40 well, SUS is the latest one 09:13:43 tathi: alas, there is no SCS 09:14:23 sure there is 09:14:30 seeing that gcc is as prevalent as it is, they otter start there and just admit to it. 09:14:48 ISO sets the C standard 09:14:54 and - as mentioned - libc manpages and funcs are just not as portable as they should be. 09:15:07 ISO sets *A* "C-standard" 09:16:45 i don't see any others 09:16:52 ok. 09:32:41 ahhh.. 09:32:52 tathi: interesting - http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/indications/chapter_2_section_3.html 09:33:54 exactly 09:34:10 --- quit: saon ("Lost terminal") 09:34:44 Soo, you almost have to write a vm imp wrapper around it, and use a variant of a struct-pointer 09:34:52 --- quit: sproingie (Read error: 104 (Connection reset by peer)) 09:35:28 --- nick: Raystm2 -> nanstm 09:35:45 BUT, it sounds like - once hooked to a fd - you can do seeks/reads/writes which are using the mmap "space" instead of several buffers 09:36:06 --- join: saon (~saon@c-24-129-91-106.hsd1.fl.comcast.net) joined #forth 09:45:36 --- quit: PoppaVic (Read error: 60 (Operation timed out)) 09:48:36 --- quit: virl () 09:58:29 --- quit: saon ("leaving") 10:19:43 --- join: kunphuzil (~Jason@ip-69-10-97-161.cableaz.net) joined #forth 10:20:09 --- join: Herkamire (~jason@Herkamire.student.supporter.pdpc) joined #forth 10:20:09 --- mode: ChanServ set +o Herkamire 10:24:31 --- join: saon (~saon@c-24-129-91-106.hsd1.fl.comcast.net) joined #forth 10:43:40 --- quit: cmeme (Remote closed the connection) 10:44:30 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 10:44:46 --- quit: cmeme (Remote closed the connection) 10:45:34 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 10:56:04 --- quit: kunphuzil (Read error: 110 (Connection timed out)) 11:07:27 --- join: [Forth] (~Forth@rrcs-24-242-160-169.sw.biz.rr.com) joined #forth 11:07:36 --- quit: [Forth] (Client Quit) 12:09:54 --- join: kunphuzi1 (~Jason@ip-69-10-97-161.cableaz.net) joined #forth 12:30:48 --- join: qFox (~C00K13S@92pc222.sshunet.nl) joined #forth 12:32:41 Hi foxie. 12:32:51 heya 12:33:55 what up 12:36:15 Code and reading and stuff and now you 13:01:04 --- quit: saon ("leaving") 13:03:41 --- join: saon (~saon@c-24-129-91-106.hsd1.fl.comcast.net) joined #forth 13:14:38 Robert: Do you know of AA batteries? 13:15:13 Sorry, wrong channel. Though the right person ;) 13:20:59 --- join: PoppaVic (~pete@0-1pool72-42.nas24.chicago4.il.us.da.qwest.net) joined #forth 13:21:52 OK, storm appears over (bastard) 13:35:10 --- quit: saon ("leaving") 13:36:49 --- join: saon (~saon@c-24-129-91-106.hsd1.fl.comcast.net) joined #forth 13:52:00 --- nick: kunphuzi1 -> kunphuzil 14:26:08 hi everyone 14:26:25 lo 14:27:12 Hi 14:30:58 * crc is doing the last-minute preparations for releasing retroforth 8.0 14:31:16 cool. 14:31:24 got the handbook done? 14:31:33 (or was that for 7.6?) 14:32:20 how can you go from 7.6 to 8.0 lol 14:32:24 thats cheating :P 14:33:51 http://www.retroforth.org/handbook.pdf 14:34:00 Completely redone for 8.0 14:34:13 very nice. 14:35:03 I440r: I had a 7.7 and 7.8, but they were never released publically 14:55:48 well since 8.0 is a rewrite of the core so surely it should start with a new major number eh? 14:56:22 Yes 14:56:33