00:00:00 --- log: started forth/06.03.17
06:51:03 --- join: PoppaVic (n=pete@0-2pool238-140.nas24.chicago4.il.us.da.qwest.net) joined #forth
07:32:15 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
07:33:51 --- join: ravenEx (i=ravenEx@VPN-239-118.aichyna.com) joined #forth
08:14:13 --- quit: ravenEx (Read error: 145 (Connection timed out))
08:17:30 --- quit: tathi ("leaving")
08:32:16 --- join: ravenEx (i=ravenEx@VPN-224-120.aichyna.com) joined #forth
08:45:52 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth
08:55:03 --- quit: ravenEx (Read error: 131 (Connection reset by peer))
09:16:46 --- quit: PoppaVic ("Pulls the pin...")
09:19:22 --- join: PoppaVic (n=pete@0-2pool236-7.nas22.chicago4.il.us.da.qwest.net) joined #forth
09:20:53 --- join: ecraven (n=nex@193.171.46.9) joined #forth
09:20:56 <ecraven> hey all W(
09:21:02 <ecraven> ;) that one intended..
09:21:13 <ecraven> are the colorforth vlsi-design tools available?
09:26:12 <virl> ecraven, how is the Pulvermuehlerstraße 41?
09:27:08 <ecraven> fine, though i moved :) now i'm living on dametzstrasze close to the passage
09:27:24 <ecraven> (i'll move yet again soon i guess.. i'm almost finished with my master's.. now i need a phd :)
09:28:00 <virl> what do you do with forth?
09:28:24 <ecraven> i'm mainly working on scheme, but i like stack machines, and forth is kind of the archetype of that :)
09:28:48 <ecraven> so i'm thinking about how an efficient stack processor for scheme would look like
09:29:57 <virl> which study direction loves scheme?
09:30:59 <ecraven> just me :) noone else at my uni does any scheme i think.. little bits of lisp at the RISC
09:31:33 <ecraven> i was thinking about going to vienna, i read a bit about anton ertl.. forth seems really interesting as well ;)
09:31:39 <virl> what do you study?
09:31:45 <ecraven> informatik
09:31:54 <virl> ah..
09:31:55 <ecraven> i handed in my thesis two days ago.. now the prof. is correcting it
09:33:00 <virl> I would it really love when the forthers of vienna could found a forth user group
09:33:29 <ecraven> how many are there? i thought there were a lot around, just by googling..
09:34:23 <ecraven> how hard is it to implement a very basic forth interpreter in -- say -- C#?
09:34:43 <virl> puh, well, me, perhaps you, anton ertl... well the rest I don't know...
09:34:54 <ecraven> i need to do a project with some 250-500 lines of c# code (i don't like c# at all..), so i though i might just as well do something interesting..
09:35:10 <virl> implementing Forth in such an ugly language like C
09:35:13 <virl> implementing Forth in such an ugly language like C#
09:35:14 <ecraven> virl: hm.. i can come to vienna every now and then :) i'd just have to actually learn forth one of these days..
09:35:47 <ecraven> what are good online resources for learning forth? (apart from starting forth and thinking forth, both by leo brody)
09:36:46 <virl> well, they are the best start, but for what are you searching?
09:36:57 <ecraven> virl: you know martin schoeberl? he wrote a paper about stack machines, probably another forther
09:36:59 <virl> they are good for the basic
09:37:05 <ecraven> yes, basics are what i need :)
09:37:17 <virl> ecraven, no I didn't know
09:37:28 <ecraven> about the c# thing, is that possible? i guess i'll learn forth well enough by implementing it..
09:37:50 <virl> it's possible but it's ugly
09:38:18 <virl> it's also ugly to implement it in C, so I guess it's not prettier to implement it in C#
09:38:28 <ecraven> ok, i don't care much about that, don't intend to use it much :)
09:38:49 <virl> are you a C# guy?
09:38:57 <ecraven> another question.. how are stacks implemented in hardware? does any implementation use a giant shifter?
09:39:10 <ecraven> not at all, i find it ugly and unusable, but i need that one exam for finishing..
09:39:15 <ecraven> so i have to do some sort of project.. 
09:39:28 <ecraven> i never used c# so far, just a bit of c++ and c (both of which i don't like much either..(
09:39:38 <ecraven> i'm probably a scheme guy  :)
09:39:54 <ecraven> and partly a forth guy (from what i read about it..)
09:40:33 <virl> well, I'm from the C direction, but I don't like C#, Java, or too much of the C++ stuff.
09:41:37 <virl> Lisp/scheme& Co, are not really that what I would like to code. Forth is what Lisp/Scheme isn't for me ;-)
09:41:43 <ecraven> do you know stuff about compiling c to forth (or any stack architecture?)
09:41:51 <PoppaVic> hehehehe
09:42:16 <ecraven> scheme gives me abstractions that forth doesn't (yet).. but that's probably mostly because i'm not good at forth at all :)
09:42:17 <virl> PoppaVic, what is funny?
09:44:07 <virl> ecraven, well, for me I don't see where schemes abstractions has sense for me
09:44:23 <PoppaVic> Yer talking FFI - and good luck
09:44:41 <ecraven> ffi as in foreign function interface?
09:45:09 <PoppaVic> C and "forth" are never likely to meet. FICL comes the closest I've seen, but it offends real Forths.
09:45:14 <PoppaVic> right
09:45:42 <PoppaVic> I'm working on an alternative, but it's just bald-making/hair-pulling.
09:46:24 <ecraven> i was just interested in a few optimisations that could be applied when compiling c to forth
09:46:37 <ecraven> (or to any general stack architecture)
09:47:06 <PoppaVic> To illuminate: Apparently the LOWEST LEVEL must be what you write the FFI in, and the hi-level shit must provide a clean interface.
09:47:34 <PoppaVic> oh, stacks... pfft Those can be as simple or complex as you like
09:48:11 <PoppaVic> for those, here are a few clues: "context" and even "vtables"
09:48:53 <oxygene> hmm.. I have c ffi in my asm forth - quite simple actually (at least on x86, as standard calling convention helps a lot there)
09:49:21 <ecraven> does any c compiler change the argument order in function calls to get optimal code?
09:49:22 <PoppaVic> I've at least two FFI systems, and neither makes me interested - mostly they make me want to scream
09:49:31 <PoppaVic> no.
09:49:35 <oxygene> ecraven: they can't, at least on exported symbols
09:49:38 <PoppaVic> optimal is horseshit
09:49:53 <PoppaVic> yer thinking (I hope) of "calling conventions"
09:50:25 <ecraven> oxygene: then on not-exported symbols.. 
09:50:42 <ecraven> PoppaVic: in this context i don't think so :) it can save a lot
09:50:56 <PoppaVic> I doubt it - play on.
09:51:01 <oxygene> ecraven: internally they can do anything.. but few do (some ARM compilers are said to do that on static functions)
09:52:21 <ecraven> int div(int x, int y) { return (x / y); };   now if / would normally take the arguments in reverse order, the compiler could just treat the function as: int div(int y, int x) { return (y / x); };
09:52:28 <ecraven> this would mean no SWAP is needed..
09:52:37 <ecraven> oxygene: so some arm compilers do things like that?
09:52:48 <slava> what do you mean by / taking its arguments "in reverse order"?
09:52:53 <slava> on most CPUs arithmetic is performed on registers
09:52:58 <PoppaVic> stupid "optimzations"
09:53:58 <ecraven> slava: on a stack architecture, assuming / takes the arguments for x/y with x on top of stack and y beneath it
09:54:12 <slava> why would you compile C to a stack architecture?
09:54:16 <ecraven> ah, an error, in the second function above, it should be return (x / y); obviously
09:54:32 <ecraven> slava: i'm compiling scheme, but i assume more people can read C than scheme
09:54:55 <slava> for scheme, you don't want a forth-style data stack, you want a call stack with frames
09:55:21 <ecraven> slava: i have an implementation with one data and one return stack.. works nicely :)
09:55:30 <slava> how do you implement closures?
09:55:34 <slava> copying the stacks?
09:55:38 <ecraven> as soon as i get a decent compiler, i can even scrap the base pointer
09:55:42 <ecraven> no, just copy the values
09:55:47 <ecraven> if they are assigned, i box them..
09:55:55 <PoppaVic> not likely
09:55:56 <ecraven> flat closures
09:56:00 <slava> ecraven: ok
09:56:08 <PoppaVic> and yer heading into time and space
09:56:22 <ecraven> slava: slow as hell right now, but that's because i haven't optimised anything.. 
09:56:29 <ecraven> PoppaVic: of course, it's not forth :) 
09:56:46 <ecraven> but i keep thinking that stack architectures are the way to go, because function calls are so cheap here..
09:56:46 <slava> ecraven: add some type analysis and inlining
09:56:52 <ecraven> slava: i will.. later :)
09:57:04 <PoppaVic> Yout can see the channel title and topic?
09:57:05 <ecraven> so, that funny optimisation thing i was talking about, does that make sense? 
09:57:12 <slava> ecraven: on powerpc, stack code runs slow unless you inline a lot
09:57:20 <ecraven> PoppaVic: am i spamming or trolling or not speaking english?
09:57:29 <PoppaVic> Not sure
09:57:43 <PoppaVic> #forth is prettywell "anti-C"
09:57:46 <oxygene> heh
09:57:48 <slava> you're anti C
09:57:55 <ecraven> i'm not trying to convert anyone to scheme, i'm just explaining what i was doing, and why i was asking about that optimisation thing
09:57:59 --- join: [Forth] (n=Forth@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth
09:58:01 <ecraven> sorry for the C example, next time i'll use scheme :)
09:58:04 <PoppaVic> not likely, I live in ##C
09:58:08 --- quit: [Forth] (Client Quit)
09:58:37 <ecraven> one more question, what are recent stack processors? can i get pdfs about their specs or manuals anywhere?
09:58:51 <slava> probably mostly hardware JVM implementations
10:00:16 <slava> if you want good performance you'll end up compiling your stack code to register code anyway
10:00:28 <PoppaVic> umm
10:00:48 <ecraven> so register machines are considered faster than stack machines?
10:00:52 <slava> no
10:00:58 <oxygene> no, just the more common design
10:00:59 <virl> why doesn't powerpc loves stacks
10:01:11 <PoppaVic> this whole "good performance" shitpile is remeniscent of ##C and "preoptimizing"
10:01:14 <slava> but code which shuffles operands on a stack will run slower than something which directly operates on registers on most CPUs
10:01:31 <PoppaVic> get used to it
10:01:34 <ecraven> slava: then don't shuffle them. have the compiler find out the way to avoid that as much as possible
10:01:45 <PoppaVic> gymnastics are a PITA
10:01:45 <slava> ecraven: yeah, or have the compiler place intermedaite values in registers
10:01:53 <PoppaVic> bah
10:01:54 <slava> eg, 2 + doesn't need to push the 2 then pop it again
10:01:56 <ecraven> slava: no registers, pure stack :)
10:02:27 <PoppaVic> ecraven: THEY WILL never tolerate it
10:02:28 <oxygene> ecraven: even then you'll have to shuffle if you only get the TOS.. even the most popular stack machine around, the jvm does direct access on the first few stack elements
10:02:42 <slava> that's incorrect
10:02:53 <slava> the JVM has instructions lke forth's dup, over, 2dup, and swap
10:02:58 <ecraven> if i have the (few top elements of) stacks on-chip, pushing 2 shouldn't be too costly
10:03:12 <ecraven> and then accessing the top few elements isn't so much of a problem either.. 
10:03:28 <slava> on-chip? you're making your own architecture?
10:03:33 <ecraven> why not :)
10:03:34 <PoppaVic> yeah, it's sorta' a dead end
10:03:37 <oxygene> slava: didn't say that it wouldn't have these
10:03:47 <ecraven> i was just thinking about the possibilities..
10:04:01 <ecraven> fpga aren't too expensive to try :)
10:04:35 <PoppaVic> Folks just can't see that a forthish needs to be a VM - or maybr a transliterator int another language, or an FFI
10:04:59 <ecraven> well, thanks for the talking, if you don't mind i'll be back later.. gotta go now :)
10:05:00 <PoppaVic> anyway, yeah - it's ugly.
10:05:07 <slava> what is ugly?
10:05:54 --- quit: ecraven ("bbl")
10:06:01 <PoppaVic> slava: folks want to skip levels and filters and get right into guts. It's silly.
10:06:52 <PoppaVic> anyway, I am not here to argue it.. I leave Quartus to declaim all alternatives.
10:18:31 <virl> skip levels and filters?
10:19:53 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
10:19:59 --- join: segher_ (n=segher@dslb-084-056-137-030.pools.arcor-ip.net) joined #forth
10:20:45 <PoppaVic> skip levels: generate B from A input.. Maybe even a file. Filtering.
10:22:25 <PoppaVic> I'm too deep in the hole today, but you can see all these issues yourself.. They ain't remotely "unique"
10:24:03 <tathi> dang, I always miss ecraven
10:24:18 <PoppaVic> tathi: yer getting old ;-)
10:24:34 <tathi> I'm getting old?
10:24:58 <PoppaVic> tathi: yeah, slow ;-)
10:25:06 <tathi> oh :)
10:26:12 <PoppaVic> He's got some points... Seems like talking with a younger-you or me ;-)
10:27:30 <PoppaVic> tathi: and, mind you: you've more experience across a spectrum than *my* spectrum... And we can still "talk C" ;-)
10:30:50 --- quit: segher (Read error: 110 (Connection timed out))
10:30:52 <tathi> :)
10:32:00 <PoppaVic> tathi: I think his MAJOR issue is "C" - and there may well be FFI issues he can't see yet.
10:32:15 <tathi> huh?
10:32:17 <PoppaVic> ..basically, he can't envision a VM
10:32:41 <PoppaVic> He wanted his forthish to talk C
10:33:21 <tathi> oh.  I haven't heard anything from him about that
10:33:47 <tathi> Last I knew, he was curious about compiling register-based languages (like C or scheme) to stack-based CPUs (not that there are many of those)
10:33:53 <PoppaVic> Yeah.. it's just not "standard" for forths
10:33:55 <tathi> and how to do optimization in such a compiler.
10:34:25 <PoppaVic> right... He can't "optimize" without laying out a variety of issues
10:34:56 <tathi> There is a fair amount written about translating stack>register, but apparently very little the other way around
10:35:21 <PoppaVic> sure, they can't think like we'd wish
10:35:50 <PoppaVic> ..and folks used to 8080 and Z80 are "archaic"
10:37:21 <tathi> I have a suspicion that parameter order doesn't matter that much
10:37:29 <PoppaVic> Do you realize how WEIRD how it feels to talk about "writing emulators", and then folks that are confuzzles?
10:38:01 <tathi> I don't have much evidence to back that up, but every time I try rearranging my forth code, it always turns out to be practically the same either way.
10:38:11 <tathi> speed-wise anyway
10:38:26 <PoppaVic> right
10:38:38 <PoppaVic> so, readability becomes the major issue.
10:38:56 <PoppaVic> I always find that interesting.
10:39:11 --- join: Lars_G (n=lars@unaffiliated/lars-g/x-000001) joined #forth
10:39:37 <tathi> yeah.  For us humans, it's good to have a convention about parameter order so you don't have to go look it up for every word. :)
10:39:50 <tathi> Computers, of course, look it up anyway, so they don't care :P
10:40:04 <PoppaVic> I think, (from what I've seen), RE generation of source might become the issue... But, again: folks never seem to envision translators|filters over [goto zero]
10:41:05 <PoppaVic> I know for a fact that lispers want to go from SOURCE to binaries, and most C-programs are thinking the same way.
10:41:28 <tathi> well yeah, you often lose information going to binary
10:41:43 <tathi> IMO the source that a human entered should be the canonical version
10:41:53 <PoppaVic> Only folks like forthers seem to understand layers... Or maybe folks like me and C and "contexts"
10:42:08 <tathi> and anything generated by a translator should be consider a 'cached' value, more or less.
10:42:26 <PoppaVic> I simply think filters are filters - reaching a final "do this"
10:43:02 <tathi> yeah, that's true -- what you do with the output is up to you
10:43:07 <PoppaVic> you can store the intermediates, or tags, or just point at the source (like ancient "view fields")
10:43:46 <PoppaVic> tathi: it makes life so interesting ;-)
10:43:58 <tathi> my preference would be to point at the source, but if it's designed as filters you can build that on top easily enough.
10:44:04 <tathi> life is always interesting :)
10:44:10 <PoppaVic> right: view-fields
10:45:15 <PoppaVic> And, I want all this happy-horsehit removed from the human input versus loads versus links, whatever... In forthish, it's time and space oriented.
10:46:02 <PoppaVic> time, spaces and ORDER
10:46:17 <PoppaVic> Makes life more intriguing
11:07:00 <slava> systems with edit/compile/restart app cycles are annoying
11:07:14 <slava> nobody ever learns from smalltalk and lisp's interactive environment
11:07:28 <tathi> they don't?
11:07:31 <PoppaVic> keep slavering ;-)
11:07:40 <Lars_G> Hey slava
11:07:42 <tathi> I thought that was a big part of why Python and Ruby are so popular?
11:07:49 <slava> tathi: not in the forth and C world
11:07:56 <slava> most forths can't even reliably redefine words
11:08:12 <oxygene> tathi: I think they're still often used in a edit/compile/start fashion
11:08:14 <tathi> huh.  I must not have used most forths then.
11:08:27 <slava> replacing definitions, not adding a new word with the same name
11:08:34 <oxygene> tathi: too annoying to code your stuff on that joke of a REPL, then move it over to a text file once it works
11:08:54 <tathi> ok, I'll admit that they usually come out-of-the box with a lousy interface
11:09:02 <tathi> slava: that's a feature, not a bug.
11:09:14 <tathi> if you want to replace a definition, you have to say so before hand ;)
11:10:08 <tathi> ah, I'll just shut up; I think I basically agree with you
11:10:58 <PoppaVic> tathi: I still keep trying to envision "database"
11:13:19 <JasonWoof> slava: I agree about the edin/compile/restart cycle being annoying
11:13:33 <JasonWoof> and I think it's interesting how different our solutions are :)
11:13:37 <PoppaVic> annoying is not "bad"
11:13:49 <slava> JasonWoof: while working on my objective C binding i remembered just how irritating it is
11:13:50 <JasonWoof> heh
11:13:54 <PoppaVic> ..and interp is not "compile" on that scale.
11:13:57 <slava> JasonWoof: you cannot really redefine classes in the objc runtime
11:14:10 <JasonWoof> well I don't like being annoyed or annoying..
11:14:14 <slava> JasonWoof: or even add a new class with the same name
11:14:18 <PoppaVic> oh, well... objc - die well.
11:14:32 <oxygene> PoppaVic: unfortunately apple is still alive - so objc won't die either
11:14:50 <PoppaVic> oxygene: sure it does... I ignore it daily.
11:14:55 <slava> cocoa is far superior to anything on x11
11:15:07 <oxygene> now that's easy
11:15:13 <PoppaVic> that's nice - now make it work in C or forth
11:15:14 <slava> yeah
11:15:15 <JasonWoof> oxygene: eh? do you think Apple has a negative effect on society?
11:15:20 <slava> factor can call cocoa now
11:15:27 <slava> so can mops, an os x forth
11:15:39 <slava> nobody writes gui apps in plain C
11:15:43 <PoppaVic> you are talking variants and layers... Keep talking
11:15:53 <oxygene> unfortunately x11 is kept on life support and attached to strings so it looks like it's still alive and kicking..
11:15:56 <JasonWoof> slava: huh? I thought most GUI aps were written in C
11:16:03 <JasonWoof> GTK certainly is
11:16:05 <PoppaVic> slava: right - nice yto know YOU "know"
11:16:09 <slava> gtk is not most gui apps
11:16:19 <PoppaVic> bullshit
11:16:58 <PoppaVic> slava: you want to write crap that is dedicated? fine.. Stop the shit. Might as well talk "asm"
11:17:09 <JasonWoof> slava: that was just an example
11:17:25 <PoppaVic> JasonWoof: I knew that ;-)
11:17:45 <JasonWoof> PoppaVic: you're ahead of the game today! ;)
11:17:49 <PoppaVic> as a rule. GTK+ is sorta' ugly, but works... in C.
11:18:26 <PoppaVic> JasonWoof: I'm three-flags into the wind and ready for a nap - but this is the most activity we've had in weeks. ;-)
11:20:04 <PoppaVic> I still want to know why interpreters can't talk to "filters" that are "compiling" or further "interpreting" - and I don't want to hear horseshit about cpu "speeds".
11:20:23 --- join: ravenEx (i=ravenEx@VPN-239-196.aichyna.com) joined #forth
11:20:36 <JasonWoof> "It ain't easy to walk a straight line when you're half in the bag and three sheets to the wind so to speak"  -- (I think this is Trey from PHISH)
11:20:48 <PoppaVic> ..it sounds a lot like "My expectations are too high"
11:21:14 <PoppaVic> JasonWoof: I agree.. I've been doodling docs and kibitzing all day.
11:35:33 --- join: Serg_Penguin (i=Serg_Pen@ppp85-140-28-31.pppoe.mtu-net.ru) joined #forth
11:37:01 --- quit: PoppaVic ("Pulls the pin...")
11:40:46 --- part: Lars_G left #forth
11:41:15 <JasonWoof> what's this? I'm done making calls and I don't have to go yet
11:41:21 <JasonWoof> FREEDOM!
11:57:24 <arke> :)
12:04:31 --- join: granv (n=grahame@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth
12:06:26 --- quit: granv (Remote closed the connection)
12:07:45 --- part: Serg_Penguin left #forth
12:12:53 <JasonWoof> hrrm... I should probably eat something
12:12:59 <JasonWoof> nah, I'll program =)
12:13:15 <tathi> :)
12:13:33 * tathi is doing both
12:18:14 <JasonWoof> hehe
12:18:16 <JasonWoof> oooooooh
12:18:30 <JasonWoof> I'm really happy with my DB code in gforth
12:18:59 <JasonWoof> I made something kinda like printf
12:19:36 <JasonWoof> and I had already made something for defining strings:
12:19:49 <JasonWoof> " hi Hellow, World!
12:20:03 <JasonWoof> : hello hi ctype ;
12:20:11 <JasonWoof> ==> Hellow, World!
12:20:24 <JasonWoof> I really do know how to spell hello, I swear
12:20:43 <JasonWoof> anyway, so you put things like %" and %d and %t in the string
12:21:09 <JasonWoof> " s-prices-del update prices set active=0 where prod_id=%"
12:21:35 <JasonWoof> edit @ s-prices-del %sql
12:21:54 --- join: granv (n=Forth@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth
12:22:07 <JasonWoof> %sql is used for queries with no rows returned
12:22:23 <JasonWoof> if there's returned data you can use %int %data %array etc
12:23:11 <JasonWoof> these all call %type to make the final query string and send it to mysql
12:23:32 <JasonWoof> they differ only in how they format/store/etc the resulting rows
12:24:12 <JasonWoof> the %" directive for %type takes a string off the stack prints it in double quotes with backslashes before \ and "
12:24:17 <JasonWoof> esc_sql() sort of thing
12:24:43 <JasonWoof> other directives can print strings as is, or take an int off the stack, etc
12:25:04 <tathi> sounds nice
12:26:50 <JasonWoof> at first I was trying to do stuff like:  "prices" >table "id,cents" >fields "where cents!=0" >where db-array
12:26:53 <JasonWoof> but it was clumsy
12:27:28 <JasonWoof> even if I did have a good way of quoting like above...
12:27:36 <JasonWoof> (which I didn't)
12:27:41 <tathi> heh
12:28:10 <JasonWoof> the way I implemented %data %int %array etc
12:28:21 <JasonWoof> is that there are several callbacks you can set
12:28:56 <JasonWoof> the main one (only required one) gets passed a row from mysql
12:29:20 <JasonWoof> db-row-xt ( addrs counts u -- )
12:29:41 <JasonWoof> u is the number of fields. addrs points to an array of data addresses, counts points to an array of their counts
12:29:46 <JasonWoof> (this is how mysql gives it to me)
12:30:01 <JasonWoof> the default db-row-xt calls db-field-xt for each field in there ( addr u -- )
12:30:27 <JasonWoof> then I added db-pre-xt and db-post-xt
12:30:50 <JasonWoof> so you could setup/fixup some kind of data structure
12:30:54 <JasonWoof> used it for %array
12:31:57 <JasonWoof> %array returns a data object [count, data...] with the following format: fields/row, field-addr1, field-addr2...
12:32:52 <JasonWoof> the mysql call to get the number of rows in the query result doesn't work on my box (I think because it returns a long long and ffcall/fflib.fs doesn't handle that properly)
12:32:53 <tathi> for each field in each row?  or just for the first row, then the rest are the same size?
12:33:16 <JasonWoof> so I needed db-post-xt to fix the data structure
12:33:50 <tathi> ah
12:34:29 <JasonWoof> the fields of all rows are just in there
12:34:48 <JasonWoof> but the main array object is just addresses (and that one int for fields per row)
12:35:10 <JasonWoof> at each address is a string object [count, text]
12:35:46 <JasonWoof> I figured I might need the fields/row for pulldown menu options arrays
12:36:44 <JasonWoof> it would be much easier to build this array if I knew ahead of time how many fields total there would be so I could allocate the main array first
12:36:47 <JasonWoof> but alass...
12:37:29 <JasonWoof> I had to code it so the main array accumulated somewhere else, then I move it to the heap after I'm done packing all the strings onto the heap
12:38:07 <JasonWoof> I need to add a few directives
12:38:10 <JasonWoof> like %int?
12:38:29 <JasonWoof> which pushes a t/f flag saying if it hit a row
12:38:56 <JasonWoof> otherwise if the db gets messed up and things don't link properly, then it won't return any results and my code will do a stack underflow
12:43:46 <JasonWoof> if anybody wants to see code: svn://svn.jasonwoof.org:2200/gforthcgi/
12:44:13 <JasonWoof> that's my home computer so it's not always on
12:49:11 --- quit: granv ("abort" Reality Strikes Again"")
12:49:47 --- join: granv (n=grahame@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth
13:17:59 --- quit: Cheery ("Leaving")
13:29:30 <virl> re.. anything new?
13:29:37 --- quit: tathi ("running errands")
13:29:42 --- quit: granv (Remote closed the connection)
14:30:05 --- join: Lars_G (n=lars@unaffiliated/lars-g/x-000001) joined #forth
14:35:31 <virl> hi Lars_G 
14:36:35 --- join: crc (i=crc@pool-70-110-153-15.phil.east.verizon.net) joined #forth
15:02:01 --- part: Lars_G left #forth
15:08:38 --- quit: uiuiuiu (Remote closed the connection)
15:08:39 --- join: uiuiuiu (i=ian@dslb-084-056-233-037.pools.arcor-ip.net) joined #forth
15:17:13 --- quit: ravenEx (Read error: 131 (Connection reset by peer))
15:26:25 --- join: Amanita_Virosa (n=jenni@adsl-69-154-178-250.dsl.hstntx.swbell.net) joined #forth
15:40:25 --- quit: Amanita_Virosa ("Wewps.")
15:43:25 --- part: slava left #forth
16:25:32 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
16:43:58 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-135-022.pools.arcor-ip.net) joined #forth
16:46:39 <arke> alala
16:46:45 <arke> noo she is teh g0ne
16:52:18 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
16:52:41 --- nick: snoopy_1711 -> Snoopy42
17:00:28 --- quit: virl (Remote closed the connection)
17:01:24 <Raystm2> arke? still in US?
17:15:26 <arke> yessir
17:15:31 <arke> til the 29th
17:15:38 <arke> going to denver, eh? :)
17:17:07 <Raystm2> naw, my vacation has been cut short by another employees family emergency. :(
17:52:03 --- quit: crc ()
19:05:16 --- join: Amanita_Virosa (n=jenni@adsl-69-154-178-250.dsl.hstntx.swbell.net) joined #forth
19:25:42 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth
19:27:38 <LOOP-HOG> hi
19:52:08 <LOOP-HOG> oops
19:52:09 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]")
21:26:43 --- quit: tathi ("leaving")
21:32:54 --- quit: Amanita_Virosa ("Sleep is for the awesome.")
23:59:59 --- log: ended forth/06.03.17