00:00:00 --- log: started forth/05.07.07
01:06:11 --- quit: JasonWoof ("off to bed")
01:45:36 <kunphuzil> Can I get a decimal answer from division? 
02:07:41 --- quit: kunphuzil ("Download Gaim: http://gaim.sourceforge.net/")
02:45:33 --- join: Topaz (~top@host81-157-97-213.range81-157.btcentralplus.com) joined #forth
02:47:53 --- join: virl (icechat5@chello062178085149.1.12.vie.surfer.at) joined #forth
02:53:29 --- quit: Topaz ("Leaving")
04:12:39 --- join: PoppaVic (~pete@0-1pool46-217.nas30.chicago4.il.us.da.qwest.net) joined #forth
04:12:49 <PoppaVic> Mornin'
04:16:26 <tathi> hi
04:18:07 <PoppaVic> How goes it?
04:23:08 <tathi> Pretty well.  How's by you?
04:23:47 <PoppaVic> oh, hurtin'... ANd glaring at code.. Trying to see a clean way to do what I need..
04:25:01 <PoppaVic> I'm trying hard to see how the hell to reconcile what I want.. And it's sorta' painful as well.
04:25:34 <tathi> :(
04:26:09 <PoppaVic> IF I stick to "The Plan", I expect my brain-fog to slowly clear.
04:27:08 --- quit: virl (Read error: 104 (Connection reset by peer))
04:27:47 <PoppaVic> However, I was also spinning yesterday, trying to decide how to handle call-down to C where I'm going to need to shovel d-stack entries into the call.
04:28:12 <PoppaVic> the good ol' ellipsis (...) is painful.
04:31:27 <tathi> ahh.  So that's why you care about all the ABI stuff.
04:31:57 <PoppaVic> well, the ABI stuff will be also needed to provide config data to users
04:32:29 <tathi> true
04:40:01 --- join: virl (icechat5@chello062178085149.1.12.vie.surfer.at) joined #forth
04:41:01 <virl> what exactly are hashed dictionaries? which checksum algorithm do they use?
04:41:24 <PoppaVic> usually, they use multi-thread vocs
04:41:42 <PoppaVic> you 'hash' the name simply, to balance the threads
04:42:09 <PoppaVic> I never much use hashing code
04:42:41 <PoppaVic> I tend to use a number or balanced-trees
04:42:46 <PoppaVic> or/of
04:43:04 <virl> out of the name, a checksum is generated and then saved? this should be a very fast dictionary lookup
04:43:42 <PoppaVic> they usually use the hash to select which list/bucket/whatever is used
04:44:24 <PoppaVic> afaik, there is no fast, compact routine to insure that every word "hashes" into a unique code.
04:44:46 <virl> only useful on fast machines.
04:45:29 <PoppaVic> To me, it seems like most machines are more than fast enough for anything more complex than the simplest of lists.
04:48:03 <virl> hmm, a dictionary header reordering could speed up dictionary lookup, when the word access is somehow serial.
04:48:56 <PoppaVic> Lookup is just about the least important isue, to me.
04:49:44 <virl> ok, why? somehow the whole forth community is centered around small code and not performance.
04:49:50 <PoppaVic> strcmp is already bright enough to match lengths before chars
04:50:16 <PoppaVic> no, the "forth community" all have particular axes to grind
04:50:44 <PoppaVic> Like sitting in ##C and listening to lispers tell us all how bad C is.
04:52:09 <PoppaVic> The fact is, forth tends to be sweetly compact - which is good - but the all-time winning features are vocs and defining new words, (even if they overload OLD words)
04:53:05 <PoppaVic> C just has little that compares to that. C's strengths lie in other areas
04:53:40 <tathi> IsForth uses a hashed dictionary.  I'm sure there are others.
05:06:14 --- join: snoopy_16 (snoopy_161@dsl-084-058-132-083.arcor-ip.net) joined #forth
05:14:35 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
05:14:36 --- join: Snoopy42 (snoopy_161@dsl-084-058-132-083.arcor-ip.net) joined #forth
05:16:20 --- quit: snoopy_16 (Read error: 145 (Connection timed out))
05:49:15 <PoppaVic> I may be suffering brainfart delusions...
05:50:15 <PoppaVic> I think I'm focussing on issues before I get to them - or filtered thru umpty forths that are asm
05:51:45 <PoppaVic> if 'execute' runs the "word"... and something like 'evaluate' is the interp or compiler... Hmm.
05:52:23 <PoppaVic> I think... I think I see why some forths (like pfe) use setjmp/longjmp
05:53:22 <PoppaVic> I wish madwork was awake.. I need to raid his braincells
05:57:31 <PoppaVic> tathi: you know.. I've just realized... There is really no serious abi for 'words' and their args...
05:58:11 <tathi> nope.
05:58:36 <PoppaVic> we always just expect it, document it, and maybe recycle 'warm' and scream
05:58:43 <tathi> if you're writing a forth in asm, you pretty much just do whatever's simplest.
05:59:06 <PoppaVic> sure.. I just noticed it, though.. *sigh* Damn...
05:59:20 <tathi> what's wrong with that?
05:59:30 <tathi> they tend to be fairly similar across forths for the same platform.
05:59:49 <tathi> and it's not like you use it to interface with anything else.
06:00:05 <PoppaVic> hmm? Just cogitating the c-interface, for forthish 'words' - it's generally OK. For stackframe-like stuff like C, tis not a "good thing".
06:00:33 <tathi> oh.  Yeah, making a forth whose words can be called from C would be a bitch.
06:00:48 <PoppaVic> yep, and I'm planning either-direction
06:01:24 <tathi> of course, exporting some forth words as c-callable functions would be easy enough.
06:02:34 <PoppaVic> yeppers
06:02:34 <tathi> but following the C ABI for every forth word...not a good idea on RISC machines, anyway.
06:02:44 <tathi> unless you have a full optimizing compiler, I guess.
06:02:45 <PoppaVic> I was thinking of that, before I thought of the latter
06:02:54 <PoppaVic> no..
06:03:12 <PoppaVic> I was thinking of a "format string" field for each word
06:03:48 <tathi> giving the stack effects for it?
06:04:07 <PoppaVic> if it's a string, fine; tighter would be a bitfield-array. Yeah, exactly.
06:05:27 <PoppaVic> the old ( a b c --- b c a ) thing, plus we can consider the locals idea as well.
06:06:02 <PoppaVic> The kicker would be properly defining the "format chars"
06:06:50 <tathi> right
06:07:04 <PoppaVic> man, yet ANOTHER idea to add.. Shit
06:07:42 <PoppaVic> hmm
06:07:51 * PoppaVic lightbulb enabled
06:08:18 <PoppaVic> It's a special "lexicon"
06:08:48 <PoppaVic> in fact, given it's a header-field, it's also a special "interpreter"
06:09:39 <PoppaVic> I'm still semi-wonked on ... calls to C, though
06:10:04 --- nick: Raystm2 -> nanstm
06:10:53 <tathi> can't help you there.
06:11:04 <tathi> in fact, I can't think of any way to do that short of having your own compiler.
06:11:27 <PoppaVic> Yeah, it's somethink like libffi and trampolines and forth
06:12:38 <tathi> yeah, you could just build with ffcall, I guess.
06:12:50 <PoppaVic> the simplest I can imagine is: "fmt string %d\n" 1 2 CCALL printf 
06:13:47 <PoppaVic> but this doesn't account for returns
06:18:50 <PoppaVic> hrmph
06:19:27 <tathi> well, there's only 2 cases, 1 return value, or no return values.
06:19:45 <tathi> so you could just have CCALL1 and CCALL0 or something.
06:19:46 <PoppaVic> ahh, but the size of the return? The type?
06:19:53 <tathi> I think that's what factor does, actually.
06:20:01 <tathi> the size of the return is always one cell.
06:20:01 <PoppaVic> "factor"?
06:20:07 <tathi> http://factor.sourceforge.net/
06:20:13 <tathi> slava pestov's forth-like language.
06:20:34 <PoppaVic> wait a cycle - lemme' check - never heard of it before
06:20:37 <tathi> if it doesn't fit in one machine word, then it's a pointer to the real return value.
06:20:44 <tathi> it's more like joy, actually.
06:20:54 <tathi> (I think)
06:22:02 --- quit: virl ("We be chillin - IceChat style")
06:22:12 <PoppaVic> downloading... May have some ideas
06:22:28 <tathi> Pretty cool stuff.  Generational GC, can compile native code for x86/PPC, etc.
06:22:47 <tathi> It's image based, like squeak or whatever.
06:23:00 <PoppaVic> hmm
06:23:19 <PoppaVic> non-obectfile/lib, you mean
06:23:38 <PoppaVic> "object"
06:25:15 <PoppaVic> you know one of the HUGE issues? There is no goddamned libstackframe for C.
06:26:03 <PoppaVic> I'm rapidly approaching the tipover-pt where I get pissed at forthish AND C
06:26:04 <tathi> so write one.
06:26:08 <tathi> or stop bitching about it already.
06:26:22 <PoppaVic> it'd need to be asm, and I don't <shrug>
06:27:19 <tathi> if you're programming in C you're not supposed to need to deal with that crap.
06:27:37 <PoppaVic> true, but in interfacing you would.
06:27:38 <tathi> and most forth programmers sensibly ignore all that nonsense.
06:28:30 <PoppaVic> Yep.. WHat I've seen is that most forth-implementors ignore most everything above the cpu/os
06:28:41 <tathi> yeah.
06:28:50 --- quit: vitaminmoo (Read error: 104 (Connection reset by peer))
06:28:53 <tathi> why make the implementation far more complicated for something you don't need?
06:28:58 <PoppaVic> sort of odd, but historical
06:29:16 <tathi> and if you do need it, go ahead and implement it.
06:29:27 <PoppaVic> tathi: well, sort of.. It's like they want a forth shell, but not really..
06:30:16 <PoppaVic> heh - tried to build the latest PFE today - that bombed prettily ;-)
06:30:32 <tathi> yeah.  I don't think I've ever heard anything good about PFE
06:30:47 <tathi> well, not from anyone whose opinion I respect, anyway. :)
06:31:06 <PoppaVic> well, the OLDER stuff built ok - but the new stuff apparently screamed on the macosx lib/module perversions
06:31:26 <tathi> oh, ok.  I can see that.
06:31:59 <PoppaVic> yeah, relying on tools to do <this> outside your own are fraught with danger and pain
06:32:27 <PoppaVic> tis why this project is foremost in my head anymore
06:32:31 <tathi> you know, I think the thing is that most forthers generally think that YAGNI, so they don't do overgeneralized things like you're trying to do.
06:32:52 <PoppaVic> "yagni"?
06:33:04 <tathi> "You Aren't Going to Need It"
06:33:09 <PoppaVic> ahh
06:33:11 <PoppaVic> right
06:33:43 <PoppaVic> contra-wise, I try to consider generalizations first (like an outline) and work my way in.
06:34:13 <PoppaVic> good ol' top-down until I need bottom-up
06:35:01 <tathi> do you need more stack-frame manipulation than you can get from the ffcall lib and setjmp/longjmp?
06:35:20 <tathi> hmm, actually, if you want return-stack manipulation words, you probably do.
06:36:27 <PoppaVic> I'm really not sure yet...
06:37:14 <PoppaVic> I'm guessing that setjmp/longjmp is not really wise or fast, but has the advatage of being portable
06:37:19 <tathi> you have looked at ffcall, I assume?
06:37:24 <tathi> www.haible.de/bruno/packages-ffcall.html
06:37:41 <PoppaVic> hmmm
06:38:02 <PoppaVic> http://www.haible.de/bruno/packages-ffcall.html
06:38:11 <PoppaVic> loading page
06:38:52 <PoppaVic> yes.. havethat around
06:39:47 <tathi> ok, so calling out to C functions is no problem, you're just worried about the interface.
06:39:54 <tathi> (forth syntax)
06:39:58 <tathi> specifically return types
06:40:17 <PoppaVic> I guess so.. I'm still not sure I should adopt his lib - is the lib even supported anymore?
06:40:38 <tathi> dunno.  gforth uses it.
06:40:46 <PoppaVic> ahha!
06:40:59 <tathi> I have no idea how many platforms it supports or whatever.
06:41:06 <tathi> it works here (PPC Linux)
06:41:11 <PoppaVic> Yeah, that too can be painful
06:42:36 <tathi> anyway, when you're calling a C function, either you have a return value or you don't.
06:42:43 <PoppaVic> yeppers
06:42:43 <tathi> so the core functionality is ccall0 and ccall1
06:42:52 <PoppaVic> I believe I agree
06:43:08 <PoppaVic> it tends to suggest the user is responsible
06:43:17 <tathi> then you'd have to deal with the type, which I haven't thought about much.
06:43:46 <tathi> well, you have to provide the parameters somewhere.  The lib doesn't give you that.
06:43:55 <PoppaVic> yeppers
06:43:59 <tathi> that info is only in the C headers.
06:44:18 <PoppaVic> right, the code is the lib, the headers is akin to "heads"
06:44:57 <tathi> slava might have some thoughts on syntax for specifying return types.
06:45:09 <tathi> (I don't remember how he does it in factor)
06:45:10 <PoppaVic> I shall look it over
06:45:28 <tathi> I think he calls that stuff 'alien' btw
06:45:36 <tathi> (might help you find it)
06:46:11 <tathi> and...slava mostly only hangs out in #concatenative (if you want to talk to him).
06:46:40 <PoppaVic> I do get the feeling there is going to be a need for a C and Forthish datastack/stackframe interface.. The idea of a datastack in forth is alien to many languages
06:47:31 <PoppaVic> the thing that seems to matter is: to avoid "inline asm" as nonportable.
06:48:07 <PoppaVic> I know it can be done, but the package would benefit from a fist of simple asm files, I suppose.
06:49:02 <PoppaVic> anyway, try not to get too upset with my headgames ;-) I'm ballparking all this stuff in order to see where we can improve and extend ;-)
06:49:28 <tathi> yeah, sure.
06:49:43 <tathi> I'm curious to see where you get to
06:49:47 <PoppaVic> I do not mind the occasional slap, bitch, or punt ;-)
06:50:05 <PoppaVic> yeah, It's a real mind-bender
06:50:08 <tathi> Though I don't have much interest in going that direction myself. :)
06:50:41 <PoppaVic> I've got enough books around to fake out a TIL in asm, if I wanted... But we need to climb up a step ;-)
06:51:02 <PoppaVic> or, (from C) down a step.
06:51:05 * tathi is more into compiler design and such
06:51:24 <PoppaVic> oh, you mean hi -> native?
06:51:33 <tathi> well, forth -> native, mostly.
06:51:39 <PoppaVic> objects? binaries?
06:51:45 <PoppaVic> ahhh
06:51:58 <PoppaVic> ok, that explains why you suffer me ;-)
06:52:23 <tathi> I'm currently designing an optimizing compiler for a dialect of forth.
06:52:43 <tathi> I'm mostly interested in playing with the code generation aspect
06:52:52 <tathi> translating from stack -> registers, that sort of thing.
06:53:07 * Robert is also a bit interested in that. Which CPU are you coding for?
06:53:25 <tathi> but I see generating (for instance) ELF binaries and relocatables as relatively trivial, so I'm not averse to adding that at some point.
06:54:28 <tathi> Robert: I'll be doing PPC first, of course, but I'm hoping to be able to target x86 as well once I get it up and running.
06:54:43 <tathi> it's all design-docs in pseudo-forth-code ATM though :)
06:54:53 <PoppaVic> yeah, for me - it isn't trivial.. But then, this is because of the screwed up world of .o, and shared-lib/modules
06:55:38 <Robert> I was thinking about making such a Forth with register mapping and call it a macro assembler, not to scare the outsiders.
06:56:00 <tathi> PoppaVic: well, maybe not trivial.  But certainly not the huge problem that most people seem to see it as.
06:56:00 <PoppaVic> yes, same idea from the C end.
06:56:08 <Robert> That's one thing I really miss about most assemblers, there's no way to extend the macro interpreter.
06:56:16 <PoppaVic> we NEED a completely portable "assembler"
06:56:27 <tathi> Robert: yeah, that's kind of my motivation as well
06:56:42 <PoppaVic> C was supposed to be, but is now so committeed that the whole point was lost.
06:57:13 <PoppaVic> I agree there too, forth is an ideal way to get beyond cpp/c/asm
06:57:16 <Robert> Heh, the macro support in C is even worse than in the average assembler.
06:57:54 <PoppaVic> bob, think about the "average" C programmer - I would not WANT a neophyte to know much about macros
06:58:06 <Robert> Eh... of course.
06:58:40 <PoppaVic> it's like letting a perl-programmer pretend to write "programs" rather than scripts
07:01:04 <Robert> When you think about it, a script ought to be more detailed than a program. ;)
07:01:34 <PoppaVic> no
07:01:39 <PoppaVic> reverse it
07:02:09 <PoppaVic> a "program" should be the final, simplified, homogenized, preprocessed mess.
07:03:36 <PoppaVic> the "program" would be everything we need to know to compile a binary image for generating (what? an object? a .bin? Something)
07:04:11 <PoppaVic> ..an 'object' would be my guess (or "a.out")
07:04:46 <PoppaVic> a higher 'script' would generate .a or .so or .plugin
07:05:04 <PoppaVic> "higher" meaning: more complex
07:06:07 <PoppaVic> The prob with most forths is, they tend to play at being "more than an assembler" - but do not generate those .o/.a/.so/etc
07:06:58 <PoppaVic> what they are - and do seriously well - is an interpreter/compiler. BUT, they can't communicate well with the outside world.
07:08:33 <PoppaVic> Interactively, I seriously love forths. Even when I stick entirely to forthish: fine. But there are many, many libs out there for C - and far, FAR fewer for forths.
07:08:43 --- quit: nanstm (Read error: 131 (Connection reset by peer))
07:09:07 --- join: Raystm2 (~vircuser@adsl-68-95-253-95.dsl.rcsntx.swbell.net) joined #forth
07:22:30 --- quit: Stepan (Remote closed the connection)
07:22:34 --- join: Stepan (~Stepan@khepri.openbios.org) joined #forth
07:35:29 <PoppaVic> You know.. I'm wondering if we could use a "compiler stack" instead of a "return stack"
07:36:04 <Robert> Uhm, how do you mean?
07:36:13 <PoppaVic> the "machine stack" (cpu stack) isn't as much an issue as interpreter, passing and compiling
07:37:33 <PoppaVic> if we get an "language interface lib" for the datastack and cpustack, that's great; but it seems like we might benefit from a "compiler stack", rather than mixing shit into the datastack
07:38:20 <Robert> "shit" being compiler data, like addresses from IF to THEN?
07:38:48 <PoppaVic> addresses are data, I really meant markers more
07:39:03 <tathi> markers for what?
07:39:51 <PoppaVic> I guess, I'm thinking 'immediate/preproc', 'compile', 'execute'... Butm the markers are how most conditional/branches/balancing works
07:40:44 <PoppaVic> usually, conditionals and such shove data on the dstack to be snapped up on reconciling
07:41:32 <PoppaVic> I'm trying to see whom does what to whom and where and why to finally reach compiled asm/mc
07:41:35 <tathi> yah, that's what Robert asked.
07:41:54 <PoppaVic> right
07:41:56 <tathi> ANS says you can use a separate compiler stack, IIRC.
07:42:27 <PoppaVic> hmm.. I'm just pondering what we'd do, how deep it is, and why.
07:44:08 <tathi> it doesn't seem to be a problem to just have it on the data stack.
07:44:25 <PoppaVic> hmm
07:44:45 <PoppaVic> OK, so data intermixed with markers and stuff shouldn't be an issue?
07:44:46 <tathi> if you have code where it being on the data stack causes problems...
07:45:07 <PoppaVic> Yeah: recall, there IS no rstack here
07:45:25 <tathi> well, in a normal forth the markers are only used at compile time.
07:45:32 <PoppaVic> yup
07:45:42 <tathi> and...you generally don't do ANY stack manipulation at compile time.
07:46:04 <PoppaVic> Or maybe at interpret-time ( such as [IF] ...)
07:46:33 <tathi> well, normally [IF] is a parsing word, I think.
07:47:25 <tathi> ANS explains it that way -- I've never bothered implementing it.
07:48:14 <tathi> that is, [IF] just skips over stuff in the input, so it doesn't need markers.
07:49:41 <PoppaVic> hmm
07:50:55 <PoppaVic> interesting
07:51:29 <tathi> it's easy enough to have a separate compile stack.
07:51:31 <PoppaVic> ..OK, I think I'll bail for awhile.. Lotsa' ideas, all flitting around in Search Of.. a Solution.
07:51:37 --- quit: PoppaVic ("Pulls the pin...")
08:04:43 --- quit: Minataku (Remote closed the connection)
08:06:07 --- join: Topaz (~top@host81-157-97-213.range81-157.btcentralplus.com) joined #forth
08:07:12 <Robert> Hi
08:07:55 --- quit: Topaz (Remote closed the connection)
08:12:29 --- join: Topaz (~top@host81-157-97-213.range81-157.btcentralplus.com) joined #forth
08:28:23 --- join: PoppaVic (~pete@0-2pool238-86.nas24.chicago4.il.us.da.qwest.net) joined #forth
08:38:24 <PoppaVic> hmmm
08:39:07 <PoppaVic> You know..? Aside from the examples being x86, the gcc inline-asm examples are seriously powerful.
08:39:28 <Robert> And hard to decipher ;)
08:39:31 <PoppaVic> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
08:39:54 <PoppaVic> quite, however - with years of C and forth behind me, faking it is possible
08:40:07 <PoppaVic> I'm looking for "why the hell don't we...?"
08:40:12 <Robert> I usually just use fasm or nasm, and then link to the C program.
08:40:24 <PoppaVic> back to zero
08:41:09 <PoppaVic> Zero is nice, (hence 'C') - something PAST zero is better, if porting 'zero' is trivial.
08:42:12 <PoppaVic> this: http://my.execpc.com/~geezer/osd/libc/ is also sort of amusing
08:44:50 <PoppaVic> Yah... It seems likely I need to store a string to headers with proto/fmt-strings
08:47:10 <PoppaVic> in fact, I think tathi had a point as well.
08:51:10 --- join: PayphoneEd (~Ed@payphoneed.user) joined #forth
08:51:24 <Robert> Hi Ed
08:51:49 <PayphoneEd> Lo.
08:51:58 <PayphoneEd> Had to do a special kernel build
08:52:03 <PayphoneEd> Linux Piyoko 2.6.13-rc1-Pyocola-Debug-i686 #1 Thu Jul 7 11:39:03 EST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz GenuineIntel GNU/Linux
08:52:36 <Robert> Whoa.
08:52:42 <PoppaVic> OK, this means several things
08:52:51 <Robert> Long version speed and an impressive CPU.
08:52:57 <Robert> er, version string
08:53:01 <PayphoneEd> lol
08:53:05 <PoppaVic> huh?
08:53:07 <PayphoneEd> Yeah, it's usually shorter.
08:53:16 <PayphoneEd> The CPU is spot-on, though.
08:53:30 <PayphoneEd> Even more impressive? That's a desktop-spec P4 in a laptop.
08:53:52 <Robert> Oh. Does it catch on fire?
08:54:02 <PayphoneEd> Nope.
08:54:16 <PayphoneEd> Runs at an average of 45C.
08:54:20 * Robert has downclocked his 1.4GHz Pentium M to 600MHz to avoid melting the laptop.
08:54:38 <PayphoneEd> Piyoko also has a non-laptop-like cooling setup.
08:55:23 <PayphoneEd> It sucks in air from a fan on the bottom, exhaust is out the back where a very large heatsink is mounted and also out the side where there is another small fan.
08:55:36 <PayphoneEd> She's desktop replacement all the way.
08:56:08 <Robert> Yeah, same about this one.
08:56:46 <Robert> Looks kind of weird, I got like 4 desktops with CRTs and this laptop in my room, and I'm using this one 95% of the time.
08:56:53 <PayphoneEd> lol
08:56:59 <PayphoneEd> You should see my room.
08:57:29 <PayphoneEd> There's an old no-brand tower, an old Dell keyboard and a brand-x monitor in front of my closet
08:57:40 <PayphoneEd> Along with a Wyse WY-60 next to it doing nothing...
08:58:03 <PayphoneEd> I have a fan resting on top of another no-brand case which I plan to turn into a storage box...
08:58:16 <PayphoneEd> And an old ZDS monitor from the S-100 days.
09:01:27 <Robert> Heh.
09:02:08 <Robert> Well, they're good to have anyway.
09:02:25 <Robert> Like, it's not like I use my main computer for risky experiments.
09:03:27 <PayphoneEd> lol
09:40:55 --- join: virl (icechat5@chello062178085149.1.12.vie.surfer.at) joined #forth
09:41:58 --- quit: PoppaVic ("Pulls the pin...")
09:48:11 --- join: segher (~segher@blueice3n1.de.ibm.com) joined #forth
09:55:50 --- quit: OrngeTide ("l8r")
10:18:39 --- join: OrngeTide (~orange@rm-f.net) joined #forth
10:18:53 --- quit: Topaz ("Leaving")
10:45:06 <OrngeTide> small world... I got interested in this game and just noticed the url... http://herkamire.com/jason/vor
10:46:03 <tathi> nice.
10:46:06 <tathi> how'd you find it?
10:46:43 <tathi> oh, freshmeat got it up already. cool
10:47:38 <OrngeTide> yup:)
10:49:16 <Robert> Any recommendations on (semi-?)portable libraries for sound recording? I'd rather not hard-code OSS/Alsa stuff if there's any good alternative....
10:50:23 <segher> sdl?
10:50:44 <Robert> Are you sure it can do that? I checked the SDL docs and couldn't find anything suitable.
10:51:19 <segher> i don't know.  i just know lots of portable games use SDL
10:51:53 <Robert> Yeah, but I guess recording sound isn't one of the top priorities in a game... it's got a bunch of functions to play sounds though.
10:54:37 <segher> ah, _recording_ sound.  gotcha.
10:55:07 <Robert> Yeah.
10:55:15 <Robert> Well, seems like I'll use OSS or alsa.
11:02:45 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth
11:08:27 <Robert> Hi
11:10:12 --- join: JasonWoof (~jason@c-24-218-95-147.hsd1.ma.comcast.net) joined #forth
11:10:13 --- mode: ChanServ set +o JasonWoof
11:42:52 --- quit: virl ("If you can't laugh at yourself, make fun of other people.")
11:47:37 --- quit: segher (Read error: 104 (Connection reset by peer))
11:53:21 --- quit: KB1FYR ()
11:56:58 --- quit: Robert ("brb")
12:14:06 --- join: Robert (~snofs@c-f778e055.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth
12:36:15 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth
13:02:31 --- join: danniken- (CapStone@ppp-70-249-186-85.dsl.ltrkar.swbell.net) joined #forth
13:02:46 --- quit: danniken ("Connection reset by earthquakes")
13:03:16 --- nick: danniken- -> danniken
13:13:30 --- quit: KB1FYR ()
13:39:36 --- join: virl (icechat5@chello062178085149.1.12.vie.surfer.at) joined #forth
15:53:14 --- part: slava left #forth
17:02:19 <PayphoneEd> http://data.4chan.org/b/src/1120779036912.png
17:04:43 <Robert> Heh.
17:05:27 <PayphoneEd> I loved that UI.
17:05:45 <PayphoneEd> NT3.5 is like some kind of weird hybrid of 3.1 and 95...
17:06:07 <PayphoneEd> It's definitely a midpoint between the two, you can tell.
17:07:39 <Robert> *shrug*
17:39:31 --- quit: OrngeTide ("bye")
18:31:11 --- quit: tathi ("leaving")
19:25:09 --- join: snoopy_16 (snoopy_161@dsl-084-058-128-011.arcor-ip.net) joined #forth
19:33:40 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
19:33:41 --- nick: snoopy_16 -> Snoopy42
20:55:35 --- quit: I440r ("Leaving")
21:35:50 --- join: LOOP-HOG (~chatzilla@sub22-119.member.dsl-only.net) joined #forth
21:36:32 <LOOP-HOG> hi
21:48:44 --- quit: sproingie ("Konversation terminated!")
22:57:51 --- quit: LOOP-HOG (Read error: 104 (Connection reset by peer))
23:55:24 --- quit: swalters (Read error: 110 (Connection timed out))
23:55:48 --- quit: JasonWoof ("off to bed")
23:59:59 --- log: ended forth/05.07.07