00:00:00 --- log: started forth/05.10.19
02:08:49 --- join: ramkrsna (n=ramkrsna@61.2.66.55) joined #forth
03:01:20 --- quit: aum ()
03:14:13 --- quit: ramkrsna (No route to host)
04:05:35 --- quit: saon ("Lost terminal")
04:06:59 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth
04:41:06 --- join: snoopy_17 (i=snoopy_1@dslb-084-058-139-063.pools.arcor-ip.net) joined #forth
04:49:22 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
04:49:30 --- nick: snoopy_17 -> Snoopy42
05:53:55 --- nick: Robert__ -> Robert
05:59:07 --- join: PoppaVic (n=pete@0-2pool236-135.nas22.chicago4.il.us.da.qwest.net) joined #forth
06:10:07 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth
06:10:47 <PoppaVic> Howdy, sp
06:17:48 <Ray_work> Good morning.
06:19:35 <PoppaVic> hi ray
06:21:12 <Ray_work> How's your vm treating you Pete?
06:21:20 <PoppaVic> Badly
06:22:16 <Ray_work> You just havn't thrown enough caffein at it. :)
06:22:29 <PoppaVic> I can see exactly 3 ways to proceed: 1) Take a long break and go reload for a few days; 2) Base it on Gforth for the nonce; 3) Start whanging out C that works and build haphazardly.
06:24:24 <Ray_work> 1) this is an "also do" to go along with 2) been there done that 3) this sounds like it might have promise to weed out some of the nuances of the problem.
06:25:18 <PoppaVic> Yeah, the issues breed issues.
06:26:23 <Ray_work> I guess, the closer you get to the "aum" of forth, the fuzzier the lines get.
06:26:56 <PoppaVic> Part of the prob is in trying to keep the work it DOES as totally relocatable; part is the fact we have to hide real ptrs/addresses from idjits; and part is interfacing.
06:27:02 <PoppaVic> "aum"?
06:27:45 <Ray_work> for want of a better word, /me imagines Buddest monks chanting "aum"
06:27:51 <PoppaVic> ahh
06:27:58 <PoppaVic> the Zen-o-Forth
06:28:08 <Ray_work> yes.
06:28:50 <Ray_work> I was thinking that the "C" work option above, would provide you with a focal length.
06:29:02 <PoppaVic> Yeah. Well, it seems to be perhaps due to single-handedly trying to stomp-to-death a variety of issues... Instead of synergy, I'm just getting snarfled
06:29:14 <PoppaVic> Yeah, that's what I am considering
06:30:25 <PoppaVic> I'm thinkin' of writing a tinkertoy, cranking up a loader/saver and interpreter - just to have a baseline.
06:31:22 <PoppaVic> But,another really irksome issue is the overabundance of structs, pointers, and handles used by C. Interfacing to a lot of stuff becomes quite irksome.
06:31:55 <Ray_work> first customer of the day, please pardon my absence...
06:32:12 <PoppaVic> sure
06:33:50 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
06:36:02 <Ray_work> That was a quick and easy.
06:36:06 <Ray_work> Hi tathi :)
06:37:52 <Ray_work> PoppaVic: some how, the chip manufacturer, Patriot, tackled that issue in hardware on the IGNITE chip.
06:38:08 <PoppaVic> right
06:38:11 <Ray_work> I don't pretend to understand it all.
06:38:19 * Ray_work still learning it.
06:38:41 <PoppaVic> not worth my energy to learn a chip I'll never use
06:38:59 <Ray_work> just made it worse for me :)
06:39:01 <Ray_work> hehe
06:49:18 <sproingie> til i can lay my hands on a gumstix-style machine with an ignite, patriot's cpu is forever a theoretical curiosity to me
06:50:26 <tathi> Hi Ray
06:51:32 <PoppaVic> hmm, interesting.. gforth 6.2 won't build: it screws up on "long-longs"
06:52:11 <sproingie> what version and platform?
06:52:15 * sproingie has never had a problem with it
06:52:28 <PoppaVic> 0.6.2 gforth, using gcc 3.3 on macosX
06:52:49 <sproingie> ah.  foreign platform for me
06:53:21 <PoppaVic> yeah, it screams about trying to use an aggregate-type as a integer
06:54:13 <sproingie> gcc does?
06:54:20 <sproingie> upgrade gcc
06:54:27 <PoppaVic> ./prim:2309: error: aggregate value used where an integer was expected
06:54:50 <PoppaVic> more like that. It's already v3.3, and I won't install 2.95
06:55:04 <sproingie> try 3.4 or 4.0
07:02:42 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth
07:21:10 --- join: ramkrsna (n=ramkrsna@61.2.69.99) joined #forth
07:24:12 <PoppaVic> hmm
07:24:20 <PoppaVic> lying seems to be building
07:28:29 <PoppaVic> huh.. Weird. OK, it was extremely silly... apparently "./configure ac_cv_sizeof_long_long=0" is what they want to shut it up... But that fails miserably; using =8 made it all play well, since it seems to pass the check and bench makes
07:43:19 <PoppaVic> hehe.. ANd, then all the double-crap is 10x larger than it should be.. Way weird
07:57:40 --- nick: Raystm2 -> nanstm
08:00:05 <PoppaVic> hmm.. It looks like a fundamental issue.
08:09:47 <PoppaVic> Ray_work: Yeah, I think I have to approach this from a simple-tool and play hacker.
08:10:10 <PoppaVic> tathi: you awake?
08:10:32 <tathi> I'm in-and-out.. doing some fall cleanup
08:10:36 <tathi> what's up?
08:10:55 <PoppaVic> Isn't a mmap a malloc-variant with some connections to files? Sorta' a "window" into a file?
08:11:50 <PoppaVic> The mmap won't "scroll" back and forth as desired w/o program intervention, will it?
08:13:14 <tathi> yeah, basically.
08:13:32 <PoppaVic> I've been thinking of buffers or "segments", and that leads me to consider the mmap you have mentioned. But, we'd still need manual re-addressing/loading, right? And, if I understand what I've read: it won't automagically save and advance, etc.
08:13:47 <tathi> it can be an efficient way to read input files -- but probably not at all good for writing.
08:13:53 <PoppaVic> ahhh
08:14:23 <tathi> I'll usually just attempt to mmap a whole input file into memory.
08:14:25 <PoppaVic> OK, I _thought_ I got a handle on that - but the docs were obtuse.
08:14:45 <tathi> And then let the OS can handle the actual disk loads on an as-needed basis.
08:14:56 <PoppaVic> right.. Like, we'd prolly like to mmap a "precompiled object"
08:15:01 <tathi> yup.
08:15:18 <tathi> it has alignment restrictions, since usually a MMU works on 4KiB pages.
08:15:18 <PoppaVic> wait... the above: the OS loads?
08:16:01 <tathi> mmap is (AFAIK) a fairly direct exposure of the basic functionality of hardware Memory Management Units.
08:16:03 <PoppaVic> If it is not auto "windowed/scrolled", where does the OS come into to loadings?
08:16:18 <PoppaVic> right, so I had gathered
08:16:23 <tathi> it allows you to create a mapping between CPU address space and a file.
08:16:26 <PoppaVic> ..maybe even 1 notch too low
08:16:40 <tathi> generally the data doesn't actually get loaded until you try to access it, I think.
08:17:02 <PoppaVic> a FILE - or a section of file? Is the OS advancing the mmap if you try to access outside the mmap?
08:17:23 <tathi> not outside of the mapping, within it.
08:17:53 <PoppaVic> ok.. Now I'm confused
08:18:23 <PoppaVic> I thought a mmap was a given-size space/window - and we were loading chuncks of file to that space?
08:18:39 <tathi> ok, let's take the Linux ELF loader for example.
08:18:45 <PoppaVic> ok
08:18:48 <sproingie> mmap is like one of the fundamental primitives of most unix memory management
08:18:56 <PoppaVic> so they say
08:19:10 <sproingie> open(2) and company are often implemented in terms of mmap
08:19:11 <tathi> for most executables, it probably just maps the whole file into memory.
08:19:17 <PoppaVic> ok
08:19:36 <tathi> but...it just creates the mapping.
08:19:38 <PoppaVic> you mean: allocating a huge-ass map 
08:19:50 <sproingie> mmap is about as fast as you can get, provided you can eat the overhead of setting aside the vm chunk for the whole file
08:19:51 <tathi> If it's a big app, and most of the code normally doesn't get used, it may not actaully get loaded from disk.
08:19:57 <sproingie> it doesn't actually read in the whole file, it does it lazily
08:20:02 <PoppaVic> So, the idea of 'scrolling" is NOT integral at all
08:20:07 <PoppaVic> ?
08:20:14 <sproingie> it ALWAYS reads the file one 4k page at a time
08:20:19 <tathi> There is no "scrolling".  I'm not sure where you got that concept from.
08:20:21 <PoppaVic> ahhhhhh
08:20:26 <sproingie> there's no "scrolling" in mmap.  mmap is random access
08:20:46 <PoppaVic> wait a sec, let me get my phrasing together and strain the lizard
08:20:53 <tathi> if the processor tries to read from a memory page that hasn't yet been loaded from disk, it will generate a page fault interrupt.
08:21:00 <tathi> which will trigger the disk driver to load that page.
08:21:00 <sproingie> on windows, mmap doesn't underly file i/o.  windows is strangely more like unix with files than unix itself is
08:21:14 <sproingie> windows deals with streams and mmap is the "hack"
08:21:28 <tathi> heh
08:21:47 <sproingie> owes to windows's vms heritage i guess
08:22:18 <sproingie> considering what the vm in vms stands for ... even extra irony
08:22:35 <PoppaVic> OK..
08:22:46 <Robert> What does it stand for?
08:22:53 <sproingie> virtual memory
08:23:42 <PoppaVic> We have a FILE - we don't know the current size; OR we _do_ know we are working in 4K blocks/"windows" and using a FILE... We want to "address" data w/i the space.
08:23:57 <sproingie> just mmap the file, it'll figure out the rest
08:24:06 <PoppaVic> "scrolling" would just mean the underlying mechanics would reload or 'scroll' for us.
08:24:15 <PoppaVic> ahhhhhh?
08:24:36 <sproingie> "scroll" is no one's term, and it's wildly inaccurate
08:24:46 <sproingie> paging is what you're probably thinking of, and yes, it always pages
08:25:05 <PoppaVic> sproingie: so, we can mmap MONSTERS, and let the underlying shit reload/save and get back to prior data or open up a new writing-space?
08:25:11 <PoppaVic> paging works, yeah
08:25:26 <sproingie> yes
08:25:39 <sproingie> in fact, that's all a swapfile is for the most part, it's a gigantic mmap'd file
08:25:46 <PoppaVic> oh, sheesh - dead-cool.. I was unsure from my reading if that was all possible.
08:25:53 <sproingie> though it's implemented at a somewhat lower level for speed
08:25:59 <PoppaVic> yeah, I figured a swapfile was close-related
08:26:46 <sproingie> linux obscures file i/o's relationship with mmap with all kinds of nasty obfuscations
08:26:57 <sproingie> read the freebsd source and you'll see it pretty clearly
08:27:04 <PoppaVic> so we simple mmap an EXISTING file ala' 4k (or whatever), and she pages around as needed. This work with unwritten-data? (like a swapfile?)
08:27:09 <sproingie> or even better, netbsd, tho it takes it to an even bigger extreme
08:28:05 <sproingie> you can mmap a new file or an existing one.  you do have to know the size of an existing file if you want to read the whole thing, that's what stat() is for
08:28:16 <PoppaVic> right
08:28:34 <PoppaVic> Oh, man.. That opens a whole new universe.
08:28:49 <sproingie> virtual memory is *simple* in concept
08:29:02 <sproingie> as long as you have an OS that does it in a reasonable fashion
08:29:07 <PoppaVic> ..methinks I'm so goddamned old, I keep thinking buffers and reads
08:29:14 <sproingie> linux is not such an OS.  windows sure as hell isn't.  BSD is great to learn from
08:29:39 <PoppaVic> Yeah, bsd was always pretty slick. macosx uses it at the core
08:29:50 <sproingie> no, osx uses mach at the core
08:30:01 <sproingie> mach's virtual memory is probably complicated as all fuckin get-out
08:30:21 <PoppaVic> I thought mach was BSD based? So say a lot of my manpages and such?
08:30:39 <sproingie> BSD is often implemented on top of mach
08:30:47 <PoppaVic> All *I* care about is if the mmap and shit does what we are discussing
08:30:47 <sproingie> mach is a microkernel that makes it easy to run other OS's on top of
08:30:55 <PoppaVic> ahhhhh
08:30:58 <sproingie> both bsd and linux have run on mach
08:31:30 <sproingie> mach isn't even that great of a microkernel
08:31:41 <PoppaVic> OK, if this is an issue: wtf is this "darwin" thing?
08:32:02 <sproingie> darwin is both the mach microkernel and freebsd kernel personality on top
08:32:08 <PoppaVic> I _know_ "yellowdog" used to be the Linux distro
08:32:12 <PoppaVic> ahhh
08:32:15 <PoppaVic> ok, cool
08:32:25 <sproingie> yellowdog is just linuxppc.  there was mklinux which was popular on old macs
08:32:29 <PoppaVic> So... I should be golden, per our mmap stuff
08:33:00 <sproingie> probably.  it's hard to be slow with mmap
08:33:22 <PoppaVic> yeah, at the least it uses your buffer instead of 3 and 2 copies
08:33:29 <sproingie> just make sure you call munmap when you're done, otherwise you lose most of your data
08:33:37 <PoppaVic> But, the biggie is that paging-stuff
08:33:55 <PoppaVic> sproingie: doesn't *sync() also play with mmap?
08:34:17 <sproingie> sync should flush mmap, but it isn't really required to
08:34:30 <sproingie> all sync does is ask nicely for the kernel to flush the buffer cache
08:34:36 <sproingie> it doesn't force it on most unixes
08:34:50 <PoppaVic> right, one SHOULD cleanup - but a timed/access sync is not a bad idea
08:35:10 <sproingie> fsync should be able to do it on a file-by-file basis, but there's no corresponding control for mmap
08:35:23 <PoppaVic> the kick is to make it unnoticable
08:35:36 <PoppaVic> lemme check quick
08:35:49 <sproingie> mmkay, i gotta get going
08:35:52 * sproingie waves
08:36:02 <PoppaVic> msync
08:36:07 <PoppaVic> laters
09:00:12 --- quit: saon ("brb")
09:01:38 --- join: saon (n=saon@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth
09:09:40 --- join: Astrobe (n=astrobe@LAubervilliers-151-11-56-82.w193-251.abo.wanadoo.fr) joined #forth
09:10:03 <Robert> Hi, Astrobe.
09:10:12 <Astrobe> Hey, Robert.
09:10:46 <Astrobe> We met here a long time ago, did we?
09:11:08 <Robert> Yes, we did. I remember that you had written a rather extensive Forth system. :)
09:11:57 <Astrobe> Yes, I've compacted it since by writting a C version :)
09:12:13 <PoppaVic> which is this?
09:12:49 <Astrobe> PoppaVic: (if this one was for me) 4IM.
09:13:07 <PoppaVic> is there an url?
09:13:23 <Astrobe> yes, 4IM.atspace.com
09:13:56 <Astrobe> However, the Lindows version is currently alpha >
09:14:06 <Astrobe> and the docs are in french only at the moment.
09:14:32 <Robert> Food, brb.
09:14:41 * Robert doesn't read French. :(
09:15:04 <Astrobe> Robert: if you read C, comments in the source are in english.
09:15:35 <Robert> Ah. :)
09:15:36 <Astrobe> BTW, the doc that was written for the DOS version is still more or less valid >
09:16:08 <PoppaVic> saved the url; it is another PC-specific pile
09:16:37 <Astrobe> PoppaVic: You're unsign Mac
09:16:46 <PoppaVic> powerbook, yep.
09:17:01 <Astrobe> using mac. Oh dear. One day of C writting.
09:17:15 <PoppaVic> Not worth the energy to me.
09:17:27 <PoppaVic>  If I am going to write C, I just write C
09:18:27 <PoppaVic> ..similar to bothering to xlating French
09:18:30 <Astrobe> no this was just I wrote unsign(ed) instead of using. My fingers are playing me strange tricks.
09:19:12 <PoppaVic> I still think we've a gap to fill.. I just wish I could envision easier
09:20:25 <PoppaVic> OK, I'm off to a few chores. Tootles, folks.
09:20:28 --- quit: PoppaVic ("Pulls the pin...")
09:23:34 <Astrobe> Too late... I didn't get what he said.
09:23:38 --- nick: nanstm -> tiff
09:24:39 --- nick: tiff -> nanstm
09:31:29 --- quit: ramkrsna ("printk("Rusty's brain broke \n");")
09:45:29 <Astrobe> This chat room is as ectic as c.l.f. (sigh :)
09:46:31 * Robert returns.
09:46:52 * Robert pokes saon as well. I know you're alive.
09:57:26 --- quit: Astrobe ("Leaving")
10:02:33 <virl> re, what's shaking?
10:05:32 <Robert> Hm, not too much.
10:05:38 <Robert> Trying to read up some on error-correcting codes.
10:09:19 <tathi> Have plans to do something with them?
10:10:06 <Quartus> I suspect he wants to correct errors in some of his codes. :)
10:11:10 <tathi> hmm...
10:11:18 * tathi has errors in his codes too :)
10:12:22 <Quartus> :)
11:00:07 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth
11:06:23 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
11:07:20 <Robert> Er...
11:07:28 <Robert> Hi, aum and snowrichard 
11:07:40 <Robert> tathi: Yeah, I do. Thinking about playing with them on the shortwave bands.
11:09:55 <virl> shortwave bands?
11:10:44 <Robert> Yeah.. the most popular digital modes there have either none or very weak error correction.
11:11:39 <virl> eh? what? I don't understand
11:12:05 <snowrichard> hi
11:12:25 <Robert> virl: Which part?
11:12:47 <virl> what are shortwave bands?
11:13:02 <Robert> The radio frequency spectrum between about 3 and 30 MHz.
11:15:28 <virl> ah ... that one, I thought you mean a band, oopsi..
11:37:15 --- quit: aum ()
11:47:08 --- join: OrngeTide (i=orange@rm-f.net) joined #forth
12:01:48 --- quit: snowrichard ("Leaving")
12:54:47 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
13:02:57 --- quit: snowrichard ("Leaving")
14:22:59 --- nick: nanstm -> tiff
14:39:31 --- join: madgarden (n=madgarde@Toronto-HSE-ppp3708444.sympatico.ca) joined #forth
14:45:04 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth
14:51:24 <Robert> Hi madgarden and Amanita_Virosa.
14:51:35 <Amanita_Virosa> hey
14:52:53 <madgarden> hi
14:55:09 <Ray_work> hey
14:56:53 <Robert> And hi Ray.
15:16:05 --- quit: madgarden (Read error: 104 (Connection reset by peer))
16:13:40 --- nick: tiff -> Raystm2
16:28:21 --- quit: virsys (Connection timed out)
16:28:51 --- join: virsys (n=virsys@or-65-40-180-181.dyn.sprint-hsd.net) joined #forth
16:52:17 --- quit: tathi ("leaving")
17:01:32 --- join: madgarden (n=madgarde@Toronto-HSE-ppp3708444.sympatico.ca) joined #forth
17:07:02 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
17:07:06 --- join: richard_ (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
17:07:20 --- quit: richard_ (Read error: 104 (Connection reset by peer))
17:26:56 --- quit: Amanita_Virosa ("Excess audiophilia.")
17:37:37 --- quit: snowrichard ("Leaving")
18:03:22 --- quit: saon ("Lost terminal")
18:04:49 --- join: saon (n=saon@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth
19:23:41 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
19:26:10 --- quit: virsys (Connection timed out)
19:26:34 --- join: virsys (n=virsys@or-65-40-180-181.dyn.sprint-hsd.net) joined #forth
19:27:13 --- part: snowrichard left #forth
19:27:24 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
19:29:16 --- quit: snowrichard (Client Quit)
20:09:55 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
20:29:03 --- part: snowrichard left #forth
20:29:16 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
20:31:18 --- quit: snowrichard (Client Quit)
21:34:51 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
21:36:24 --- quit: snowrichard (Client Quit)
22:25:02 --- quit: virl (Remote closed the connection)
22:40:05 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
22:43:15 --- join: richard_ (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
22:43:51 --- quit: richard_ (Client Quit)
22:47:38 --- quit: snowrichard ("Leaving")
22:49:36 --- quit: sproingie (Remote closed the connection)
23:09:44 --- quit: OrngeTide (" bye")
23:23:00 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
23:30:18 --- quit: JasonWoof ("off to bed")
23:38:12 --- quit: warpzero (Read error: 101 (Network is unreachable))
23:59:59 --- log: ended forth/05.10.19