00:00:00 --- log: started forth/05.09.08
01:13:30 --- quit: onetom (Read error: 54 (Connection reset by peer))
01:15:58 --- join: onetom (n=tom@ns.dunasoft.com) joined #forth
02:38:52 --- quit: onetom (Remote closed the connection)
02:44:57 --- join: onetom (n=tom@ns.dunasoft.com) joined #forth
03:53:43 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth
05:28:21 --- quit: tathi ("leaving")
06:19:48 --- join: PoppaVic (n=pete@63.157.64.73) joined #forth
06:20:07 <PoppaVic> G'day
06:22:54 --- join: Ray_work (n=vircuser@adsl-66-139-199-228.dsl.rcsntx.swbell.net) joined #forth
07:29:32 <PoppaVic> humhmph
07:30:16 <PoppaVic> I've got to wonder how often folks bother with reals/doubles/floats and don't use libm.
07:31:40 <PoppaVic> or say "trig and support", if libm is offensive
07:56:12 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
07:56:26 <PoppaVic> Hi tathi 
07:56:35 <tathi> Hi
07:58:16 <PoppaVic> I'm cogitating doubles/-lm and pretty well convinced, but also considering strings. I'm just about convinced we need them integral (and a struct), or we need a way to load a plugin-lib - even before our our image load/save
07:59:43 <PoppaVic> I'm just incapable of envisioning other than the most basic, useless programs without string/terminal i/o.
08:04:26 <PoppaVic> what's yer thoughts on image load/save and opcodes for dlopen stuff, tathi?
08:08:45 <PoppaVic> hmm.. No thoughts?
08:10:32 <tathi> eh...was busy programming :)
08:11:48 <PoppaVic> np. Just an odd interface, between ##C and #forth. It takes folks that are aware at both ends ;-)
08:13:14 <PoppaVic> The C guys and my own sad experiences sort of convince me that if you support c-doubles, you might just as well support the majority of libm funcs, too
08:13:25 <tathi> yeah, probably.
08:14:10 <PoppaVic> but, I'm also considering the dlopen-type issues: we could prolly just use some opcodes to open/reference
08:14:37 <PoppaVic> THAT then leads me to think we need string-support early-on.
08:14:42 <tathi> hmm, I haven't ever really used dlopen stuff, so I don't think I have much to say about it.
08:15:38 <PoppaVic> well. It's almost 100% a dynamic-interface to a compiled .so (or apple-variant) - a plugin.
08:17:15 <PoppaVic> you open the lib, and then try to (pseudocode): "gimme("somefunc");.
08:17:35 <PoppaVic> getting a ptr or error, etc
08:18:01 <PoppaVic> also works on dynamic programs themselves.
08:18:03 <tathi> oh, that.
08:18:14 <tathi> seems pretty trivial to me.
08:18:15 <PoppaVic> yeppers
08:18:21 <PoppaVic> man dlopen
08:18:50 <tathi> I don't see that there's anything to decide.
08:18:57 <tathi> Wouldn't you just expose that functionality?
08:19:14 <PoppaVic> tathi: well, sure - the interface is fairly easy. What I am thinking is we should just integrate them as opcodes - which leads me to also consider string-opcodes, you see?
08:20:20 <PoppaVic> [litS]["somefunc"][dlsym] ...
08:21:30 <PoppaVic> in the case of strings and dyopen/sym support integration... we can leave doubles and whatnot as "options".
08:21:59 <PoppaVic> sorry, I mean "floats", not doubles - mixed C/forth terms
08:28:02 <PoppaVic> It gets rather confuzzling, because of term/symbol-intersections.
08:51:22 <Ray_work> Hi PoppaVic Hi tathi :)
08:51:29 <PoppaVic> hiya
08:52:04 <Ray_work> Today my age is the answer to the ultimate question of the universe and everything :
08:52:05 <Ray_work> :)
08:52:21 <PoppaVic> umm.. ok
08:52:39 <PoppaVic> ../z
08:52:40 <PoppaVic> 8: C= * 1, S= * 2, I= * 4, L= * 4, LL= * 8, F= *4, D= * 8
08:52:40 <PoppaVic> CELL=4; DCELL=8; FOVM=92; defaults=8
08:52:40 <PoppaVic> OPSx=39; CP_OPSx=57; DP_OPSx=59; FP_OPSx=107
08:52:47 <Ray_work> no that's not it :)
08:53:07 <tathi> Hi Ray :)
08:53:13 <PoppaVic> I decided to break out the "precisions" into unique enumerations/tables
08:53:15 <Ray_work> how are ya Josh :)
08:53:31 <tathi> I'm good.  Your birthday today?
08:53:40 <Ray_work> yeah. /me = old fart now
08:54:01 <PoppaVic> heh - I've got nearly a corner on "old fart"
08:54:11 <Ray_work> hehe
08:54:20 <Ray_work> 42, you?
08:54:33 <PoppaVic> umm 60... so, 45?
08:54:37 <Ray_work> hehe
08:54:58 <Ray_work> You win, again, sir!
08:55:19 <PoppaVic> goodie! Can I buy smokes or gas with the winnings??
08:55:52 <PoppaVic> http://rafb.net/paste/results/4UkXyg44.html
08:57:59 <PoppaVic> cool... That sorta' opens a few 'windows'
08:59:48 <Ray_work> If you dip the ciggies in the gas you can solve both problems. 
09:00:10 <PoppaVic> not me. I like my tobacco unfucked
09:07:28 <PoppaVic> OK, bbiab: beer run.. I think I've got this thing on the run. cogitate...
09:07:31 --- quit: PoppaVic ("Pulls the pin...")
09:38:26 --- join: PoppaVic (n=pete@0-2pool236-175.nas22.chicago4.il.us.da.qwest.net) joined #forth
09:39:01 <PoppaVic> Crap, entertaining *AND* programming..
09:42:53 <PoppaVic> ok, tathi: talk to me about strings.
09:43:24 <PoppaVic> I see Zascii and "other", in my universe.
10:10:53 <tathi> huh.  I never liked zero-terminated strings, personally.
10:11:02 <tathi> But in a C world, you're kind of stuck with them :(
10:13:00 <PoppaVic> yeah, but the alternatives?
10:13:46 <PoppaVic> Further, *I* know what a 'char' is.. But we also have wchar/unicode and "wtf is a 'string'?"
10:17:50 <PoppaVic> Are there are "alternative-structs" for strings? I've seen maybe a dozen, and I've never been overly impressed.
10:20:00 <PoppaVic> the best case I can envision is [count, "string", '\0'] and then marking ascii versus "other"
10:57:28 <PoppaVic> ahhh...
11:04:21 --- quit: Snoopy42 (zelazny.freenode.net irc.freenode.net)
11:08:31 <slava> i suggest using counted 16-bit char strings
11:09:27 <virl> 16bit? do you mean wide chars? or the counter should be 16bit wide?
11:09:52 <slava> the counter should be 32 bits, and the chars should be 16 bits
11:10:06 <docl> unicode, eh?
11:10:47 <PoppaVic> unicode, utf8: whatever. i've always felt "strings" were a lame term.
11:10:59 <slava> no, don't do utf8; it makes certian operations very complicated
11:11:09 <slava> getting the nth character or the length is not O(1)
11:11:17 <PoppaVic> ascii, I live in and with. There is no excuse for alternatives.
11:11:32 <PoppaVic> for LACK OF, sorry
11:11:51 <virl> lack of what? utf?
11:11:53 <PoppaVic> 80% of it seems to be structure+methods.
11:12:20 <PoppaVic> here;s the latest....
11:12:50 <PoppaVic> http://rafb.net/paste/results/bKUU6l87.html
11:13:00 <PoppaVic> http://rafb.net/paste/results/htTjni71.html
11:13:14 <PoppaVic> http://rafb.net/paste/results/0TbHhF36.html
11:13:43 <PoppaVic> I think string-support should be at least touched in the core - which has now changed, mind you.
11:15:03 <PoppaVic> You'll note I decided to pull the number and precision support OUT of the core. It's a form of OO programming, near as I can tell
11:16:05 <slava> what i this?
11:16:10 <slava> s/i/is/
11:20:05 <PoppaVic> http://rafb.net/paste/results/1SewPn63.html
11:20:07 <PoppaVic> ../z
11:20:08 <PoppaVic> 8: C= * 1, S= * 2, I= * 4, L= * 4, LL= * 8, F= *4, D= * 8
11:20:08 <PoppaVic> CELL=4; DCELL=8; FOVM=96; defaults=8
11:20:08 <PoppaVic> OPSx=52; SN_OPSx=57; DN_OPSx=59; RN_OPSx=107
11:21:18 <docl> it's a forth-like virtual machine to help portability
11:21:30 <PoppaVic> docl: nut, I'm still looking for and struct(ascii,other) universe
11:22:22 <PoppaVic> hm? sure "forthish" has been my goal from the beginning.
11:22:41 <PoppaVic> nut/note
11:27:13 <PoppaVic> docl: are you following at all?
11:27:20 <docl> hmm not really
11:27:57 <docl> you're trying to implement strings better I guess
11:27:59 <PoppaVic> ok, wherein are you getting lost?
11:28:47 <PoppaVic> strings are as much a 'type'/struct as a cell, dcell or int - we only vary storage-space/treatment.
11:29:06 <docl> ok
11:29:20 <PoppaVic> ascii SIZE is easy, so are assorted 16-bit unicode
11:29:42 <PoppaVic> the STRUCTS are at issue, and so are the assorted methods/support.
11:30:39 <PoppaVic> we could have { uchar ct; char *string; } or a variety of shit.
11:30:55 <docl> hmm.  there's more than one possible way to do this, I take it.
11:31:04 <PoppaVic> we need a really basic struct/core of support and then extensions.
11:31:10 <docl> uchar ?
11:31:20 <PoppaVic> unsigned char
11:31:23 <docl> ok
11:31:31 <PoppaVic> ..typical of a lot of forth
11:32:27 <PoppaVic> so we can have "counted 'strings' or ended 'strings'" and both leave "wtf is a 'string'" up for grabs.
11:32:29 <docl> ok so it could be a struct containing the count and a pointer
11:32:34 <docl> just like in forth
11:32:42 <PoppaVic> yeah, it can be almost anything
11:32:54 --- join: Snoopy42 (i=snoopy_1@dsl-084-058-137-203.arcor-ip.net) joined #forth
11:33:05 <PoppaVic> a "string" is more a _concept_ than something fixed
11:33:09 <docl> or just count from a pointer to a delimeter like "\0"
11:33:13 <docl> right
11:34:22 <PoppaVic> I can live really well in ascii, but I think we need to decompose enough to make unicode or wchar_t damn-nearly transparent.
11:34:37 <docl> well if you want educational value, you could put multiple strategies with different names
11:34:55 <PoppaVic> bad idea at this stage
11:35:25 <PoppaVic> consider what you'd want a char "structure" and methods to look like - basic, generic.
11:35:53 <docl> yeah gp
11:35:56 <PoppaVic> count is not "bad" and neither is "end" (\0)
11:36:13 <docl> but still, being roped to one or the other might be combersome for some people
11:36:25 <docl> not that they couldn't make their own in any case
11:36:47 <PoppaVic> right. We want basic literal, get/put, input/output.
11:37:22 <docl> well, I guess I like counted better.
11:37:26 <PoppaVic> I can't see swap, dup, over and shit for a "string" - where I CAN for a pointer.
11:37:51 <PoppaVic> counted is not bad. It's basically a buffer-ptr
11:38:11 <PoppaVic> ...otoh, you can truncate a buffer early
11:38:41 <PoppaVic> so, yeah: this takes some thought
11:38:45 <docl> by changing the count?  or inserting an eol?
11:39:00 <docl> or both even?
11:39:02 <PoppaVic> ..most languages either OVERTHINK it, or they UNDERTHINK the silly fucker
11:39:51 <PoppaVic> a terminator is NOT a "bad thing" - a lot of C lives by it; otoh, a BUFSIZE limiter is *ALSO* sensible.
11:40:10 <PoppaVic> (think fgets and such)
11:40:37 <docl> you could have both and just have it go with the smallest indicator?
11:41:05 <PoppaVic> worst case is, yes: a counter PLUS a byte/cell of "terminator"
11:41:25 <PoppaVic> But, we still need a "basic-library" of opcodes
11:41:45 <docl> another idea is you could have an ending byte that points to another string, allowing multipart strings
11:42:20 <PoppaVic> Hell, I wouldn't even mind if we could ascertain ascii-versus-other "typing" from an address.
11:42:26 <PoppaVic> no
11:42:34 <PoppaVic> a string is a string
11:42:40 <PoppaVic> a char is a char
11:42:56 <PoppaVic> bolting a char to a string IS "a string"
11:43:27 <PoppaVic> multidimensional arrays and such are another issue you might raise and I'll listen to.
11:43:52 <docl> I could picture linked lists that behave like strings, is all I'm saying
11:44:04 <PoppaVic> to me, a 'string-of.." is a structure of "chars-within"
11:44:48 <docl> an array in memory starting here and ending there
11:45:02 <PoppaVic> yes,I know - I can envision a shitload of spastics. We need consider only "ascii" versus "other" and how to baseline-support and differentiate.
11:46:03 <PoppaVic> see opsets.h
11:46:22 <PoppaVic> we need to consider the operators (byte-codes)
11:46:32 <PoppaVic> and the structs.h structures.
11:46:49 <PoppaVic> oh..
11:47:39 <PoppaVic> And, just base yer "reality" on the "working-space" of stacks/between. I've got to add a dict "segment" yet.
11:48:15 <PoppaVic> I can envision a string-stack as easily as interfacing to malloc
11:49:56 <PoppaVic> anyway... you now have my latest. We are considering strings(portability) & support.
11:51:06 <docl> cool
11:51:29 <PoppaVic> I think we are really close..
11:52:06 <PoppaVic> if you look at opsets.h, we almost spill the ABI like spunk.
11:52:52 --- join: JasonWoof (n=jason@c-24-218-59-196.hsd1.ma.comcast.net) joined #forth
11:52:52 --- mode: ChanServ set +o JasonWoof
11:52:56 <PoppaVic> between that file and the idea of "everything is bytecode and structs", we should be golden.
11:53:16 <PoppaVic> hi jas
11:54:11 <PoppaVic> docl: worst-case is "you don't know what cpu-regs/stacks are REALLY available" - and that doesn't really bug me much.
11:55:02 <docl> just matters that we know what can be done and how to do it
11:55:19 <PoppaVic> right. Virtual and structs
11:55:49 <PoppaVic> optimized "guts" anywhere are only a plus
11:56:24 <PoppaVic> the coolness is "not a requirement"
11:56:46 <docl> hehe
11:57:20 <PoppaVic> well, it compares somewhat to dozish "there IS a conio.h" versus unix/posix/X
11:58:01 <PoppaVic> based on tathi's comments, all we care is "32-bit" for about 90%
11:58:26 <PoppaVic> and, frankly, I can see a way to get that down to 16
11:59:35 <PoppaVic> otoh: why? almost 98% are at 32-bit
12:00:04 <PoppaVic> only embedded "tools" use less than 32-bit
12:00:12 --- quit: virsys (SendQ exceeded)
12:00:33 --- join: Serg[GPRS] (n=Miranda@193.201.231.126) joined #forth
12:00:58 <docl> hmm.  isn't 32-bit twice as memory-intensive?
12:01:06 <PoppaVic> hell, one of my pet-peeves are the idiots that think FILES should be so huge than a "long" can't index
12:01:20 <PoppaVic> docl: WHAT?!?!
12:01:23 <PoppaVic> No.
12:01:34 <PoppaVic> has to do with the goddamned cpu/os
12:01:38 <docl> ahh
12:02:01 <PoppaVic> people obsess over bits
12:02:10 <docl> ahh ok
12:02:40 <PoppaVic> "I got a new 64-bit CPU - how can I compile directly and exploit..."
12:02:42 --- part: Serg[GPRS] left #forth
12:03:00 <docl> hmm.  is 64-bit twice as fast?
12:03:01 <PoppaVic> 16 is now "old", 32 is average
12:03:07 <PoppaVic> not remotely
12:03:30 <PoppaVic> this is why I think 8 and 16 bit
12:03:56 <PoppaVic> they need opcodes, RAM/ROM addressing and modes
12:04:41 <PoppaVic> 16 v 32 v 64 bits SHOULD imply "more and more memory"
12:05:08 <PoppaVic> otherwise, you might as well use a z80
12:05:25 <PoppaVic> and, we are never writing "assemblers"
12:05:48 <PoppaVic> docl: look close at structs.h
12:06:28 <PoppaVic> I may have made a few "since 32-bit" assumptions, but I doubt it.
12:07:36 <docl> what's the use of the extra bits anyway?
12:07:41 <PoppaVic> anyway.. Gotta' split - unable to focus anymore... Stay well, and email me or comment tomorrow
12:07:46 <docl> ok see ya
12:07:47 <PoppaVic> BUSS access
12:07:52 --- quit: PoppaVic ("Pulls the pin...")
12:13:29 <tathi> 64-bit means you can handle bigger numbers faster.
12:13:45 * tathi thinks the main use is for cryptographic applications
12:14:07 <tathi> main use for big numbers, that is.
12:14:18 <docl> ok I see
12:25:01 <slava> and large data sets
15:13:04 --- join: crc (i=crc@pool-70-110-191-94.phil.east.verizon.net) joined #forth
15:31:27 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth
15:48:38 --- join: crc2 (i=crc@pool-70-110-167-133.phil.east.verizon.net) joined #forth
15:54:48 <Quartus> Hey all.
15:54:58 <slava> hey
15:55:37 <Quartus> What's up?
15:55:49 <slava> working on my compiler
16:06:43 --- quit: crc (Read error: 101 (Network is unreachable))
16:08:56 --- join: asymptote (n=weldon@220.muma.nsvl.chcgil24.dsl.att.net) joined #forth
16:09:12 * Amanita_Virosa is away: Gaming
16:09:14 --- nick: Amanita_Virosa -> V|acant
16:18:58 --- quit: asymptote ("Leaving")
16:22:13 --- quit: I440r ("Leaving")
16:46:49 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth
16:47:34 --- quit: V|acant (Read error: 113 (No route to host))
16:51:56 --- nick: crc2 -> crc
16:54:03 --- mode: ChanServ set +o crc
17:35:42 --- quit: tathi ("leaving")
18:53:10 --- join: amca (n=plump@as-bri-1-106.ozonline.com.au) joined #forth
18:55:27 <slava> hi amca
18:55:40 <amca> Gday slava. How are ye today?
19:33:56 --- join: amca_ (n=plump@as-bri-4-1-180.ozonline.com.au) joined #forth
19:34:01 --- quit: Amanita_Virosa ("Whoops, back to work for me")
19:37:44 --- quit: virl (Remote closed the connection)
19:51:18 --- quit: amca (Read error: 113 (No route to host))
19:51:26 --- nick: amca_ -> amca
19:54:43 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-139-199.arcor-ip.net) joined #forth
19:55:14 --- quit: YoyoFreeBSD_ (Read error: 110 (Connection timed out))
19:55:18 --- quit: Snoopy42 (Nick collision from services.)
19:55:52 --- nick: snoopy_16 -> Snoopy42
20:38:30 --- quit: JasonWoof ("leaving")
23:37:54 --- join: amca_ (n=plump@as-bri-3-188.ozonline.com.au) joined #forth
23:57:05 --- quit: amca (Read error: 113 (No route to host))
23:58:38 --- nick: amca_ -> amca
23:59:59 --- log: ended forth/05.09.08