00:00:00 --- log: started forth/06.03.26
00:09:04 --- join: imaginator (n=George@georgeps.dsl.xmission.com) joined #forth
01:20:01 --- join: Cheery (n=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth
04:00:23 --- join: oldman (n=nobody@lsi-01.bit.uni-bonn.de) joined #forth
04:13:22 --- nick: Raystm2_ -> Raystm2
04:19:53 --- join: PoppaVic (n=pete@0-3pool196-200.nas30.chicago4.il.us.da.qwest.net) joined #forth
05:50:50 <PoppaVic> hmm..
05:51:05 <PoppaVic> ANyone awake?
05:51:26 <oxygene> yes
05:51:31 <PoppaVic> excellent.
05:51:45 <PoppaVic> ##C was getting tiresome, and I'm mulling some issues..
05:52:01 <PoppaVic> do you use structs often in forth?
05:52:48 <PoppaVic> Or even a lot of order/also vocs?
05:53:14 <oxygene> neither - though I kept issues simple so far (that'll change soon)
05:53:28 <PoppaVic> I'm beginning to think more about C "contexts" and structs/ptrs..
05:54:00 <PoppaVic> I'm beginning to think that voc order & such is sorta' a twisted replacement for "contexts"
05:59:01 <PoppaVic> I'm seeing some sort of strange pattern, anyway.
06:46:51 --- quit: oldman ("I am going away")
07:24:56 --- quit: PoppaVic ("recycling")
07:26:34 --- join: PoppaVic (n=pete@0-1pool73-50.nas24.chicago4.il.us.da.qwest.net) joined #forth
07:54:55 <PoppaVic> "Doom, Despair, and Agony on me..."
08:42:42 <Raystm2> "Deep, dark depression, exessive missery"...
08:42:42 <Raystm2> "If it wern't fer bad luck I'd have no luck at all"...
08:42:42 <Raystm2> "Gloom, Dispair, and Agony on me".
08:43:58 <Raystm2> o0O0ohhh!
08:45:06 --- quit: PoppaVic ("beerrun")
09:09:44 --- join: PoppaVic (n=pete@0-1pool72-148.nas24.chicago4.il.us.da.qwest.net) joined #forth
09:23:06 * crc is making more headway on the gtk+ bindings for retro
09:23:20 <PoppaVic> heh
09:23:35 <PoppaVic> I'm dealing with circular-logic today..
09:23:56 <PoppaVic> I had a wonderful brainflash... And, I've been chasing it's ass all day.
09:24:32 <PoppaVic> (sometimes, it even looks my own ass - but then it pulls ahead...)
10:02:15 --- join: TheBlueWizard (i=TheBlueW@ts001d0605.wdc-dc.xod.concentric.net) joined #forth
10:22:16 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth
10:25:42 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
10:45:16 <PoppaVic> oxygene: you still up?
10:47:02 <PoppaVic> tathi: you awake?
10:48:22 <tathi> yes
10:49:12 <PoppaVic> ok... I was thinking about contexts and nesting and unnesting and such..
10:49:42 <PoppaVic> Isn't the Rstack supposed to control the return-to points for secondaries? pcode?
10:50:08 <PoppaVic> I mean, that is it's primary use, is it not?
10:51:07 <tathi> secondaries/pcode meaning "anything that isn't a primitive" ?
10:51:11 <tathi> yes
10:51:31 <PoppaVic> Is there some standard that demands that the Rstack only holds an item of some given size? 
10:52:08 <tathi> it's supposed to be at least as wide as the data stack
10:52:14 <tathi> so you can use it for >R and such
10:52:16 <PoppaVic> hmm
10:52:22 <PoppaVic> I thought so
10:53:08 <PoppaVic> ok.. I'm trying to rephrase my early AM brainfart.. I keep chasing my ass aroundthe room as I consider it.
10:53:58 <PoppaVic> OK... hmm... YOu load a forth... it sets up the process, and then it runs QUIT, right? An infinite loop.
10:54:53 <PoppaVic> ..and, since it is written as a secondary, it's always got an Rstack entry...
10:55:31 <tathi> yeah, I guess so
10:55:37 <PoppaVic> hmm
10:56:04 <PoppaVic> and even r> is going to check before it dumps the entry and cores, right?
10:56:51 <tathi> depends on the implementation :)
10:57:57 <tathi> doing r> in the interpreter will crash a fair number of forths
10:58:34 <PoppaVic> yeah.. I thought I recalled a few mindless versions
10:59:21 <PoppaVic> and, in most cases there are really at least three stacks, right? Data, Return and (unreachable) Machine?
11:01:27 <tathi> machine?
11:01:32 <PoppaVic> Gforth (btw) sees "r>" and pauses, and then sez 'ok'
11:01:41 <PoppaVic> machine being for the cpu/asm
11:01:48 <crc> not all cpu's have a hardware stack
11:01:54 <PoppaVic> right
11:02:15 <tathi> If it's written in C, yeah, probably
11:02:22 <PoppaVic> all I mean is: most forths are riding above the one and only push/pop/call/jmp stack
11:02:26 <PoppaVic> right.
11:02:53 <tathi> if it's in asm, the machine stack is often either the data or the return stack
11:02:55 <PoppaVic> humph.. there could be a light at the end of the tunnel
11:03:06 <PoppaVic> ahh
11:03:24 <tathi> I'm not comfortable with thinking of a "machine" stack, in forth.
11:03:31 <PoppaVic> hadn't though of that, but it makes sense. Usually the Rstack, I suspect
11:03:31 <tathi> from a conceptual standpoint, it doesn't exist
11:03:47 <PoppaVic> tathi: and you shouldn't be thinking of it
11:04:03 <PoppaVic> however, C would 
11:04:03 <tathi> well, x86 calling conventions for C pass the parameters on the stack
11:04:25 <tathi> so there, it can make more sense to have it be the data stack
11:04:27 <PoppaVic> hehe - mixed-mode concepts now ;-)
11:05:04 <tathi> Yeah, I suppose if you're never going to bootstrap your forth
11:05:30 <PoppaVic> tathi: to be honest, I would also imagine many forths-from-asm also think of "pascal-mode" calls.
11:05:37 <tathi> But I usually am, so it only makes sense to design so that it would work if there actually ISN'T a third stack.
11:08:21 <PoppaVic> interesting
11:12:21 <PoppaVic> I'm thinking that your knowledge of a "number of stacks" is a flaw.. But I'm trying to decide how to best describe it.
11:13:44 <tathi> I suppose it doesn't matter
11:13:49 <tathi> what's your point in postulating three stacks?
11:15:39 <PoppaVic> Well, for starters: I am not using the C stack for much. Just calling funcs with a context and that should be all.
11:16:14 <PoppaVic> the context-ptr can have two stacks or more.
11:16:50 <PoppaVic> I'm just not sure.. I'm chasing down an idea. Wanted to double-check,
12:00:12 --- part: TheBlueWizard left #forth
12:26:16 --- quit: PoppaVic ("recycles")
12:28:15 --- join: PoppaVic (n=pete@0-1pool46-181.nas30.chicago4.il.us.da.qwest.net) joined #forth
12:28:43 --- join: segher (n=segher@dslb-084-056-184-010.pools.arcor-ip.net) joined #forth
12:41:25 --- quit: segher_ (Read error: 110 (Connection timed out))
12:52:57 --- quit: PoppaVic ("Pulls the pin...")
14:01:58 --- quit: Cheery ("Leaving")
14:12:49 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth
14:26:08 --- part: LOOP-HOG left #forth
14:27:00 --- join: Robert (n=robert@unaffiliated/robert) joined #forth
14:31:53 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth
14:32:13 <Robert> Hi.
14:33:22 <LOOP-HOG> hi
14:33:58 <LOOP-HOG> most people here have a creative name, but that's ok.  I still wonder where uiuiuiu get's his/hers?
14:37:20 <Robert> Maybe it was overheard from a screaming conversation in a mental hospital?
14:41:51 <LOOP-HOG> I don't know
14:42:07 <LOOP-HOG> Do any Forthing?
14:42:55 --- quit: virl ("Verlassend")
14:46:27 <Robert> Yeah.
14:46:33 <Robert> Writing a small assembler in it.
14:48:15 <tathi> x86?
14:48:25 <Robert> No way. :)
14:48:35 <Robert> http://www.youngprogrammers.net/wiki/2610 -- small hobby project.
14:49:08 <tathi> hehe
14:49:10 <tathi> sweet :)
14:49:48 <Robert> Forth is pretty well-suited for that.
14:49:58 <Robert> : instruction ( address nextip param opcode -- )
14:49:59 <Robert>   swap 3 << or 4 << or swap 4* rom + ! ;
14:50:03 <Robert> That's the core of the assembler.
14:51:31 <tathi> yeah, I can see that
15:44:15 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]")
15:50:11 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-133-096.pools.arcor-ip.net) joined #forth
15:58:03 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
15:58:05 --- nick: snoopy_1711 -> Snoopy42
17:09:10 --- quit: tathi ("bleh")
17:29:27 --- quit: uiuiuiu (Remote closed the connection)
17:29:31 --- join: uiuiuiu (i=ian@dslb-084-056-227-138.pools.arcor-ip.net) joined #forth
17:48:08 <JasonWoof> I enjoyed writing the assembler for fovium :)
17:48:23 <JasonWoof> most opcodes have no parameters
17:48:29 <JasonWoof> and a few have one
17:48:42 <JasonWoof> (just lit and the various branches iirc)
17:48:44 <Robert> Hehe, that's nice.
17:53:17 <crc> JasonWoof: are the fovium opcodes documented somewhere?
17:53:59 <JasonWoof> crc: not in much detail, but there's a list with some comments
17:54:09 <crc> ok
17:57:07 <JasonWoof> http://jasonwoof.org/fovium
17:57:51 <crc> cool
17:58:01 * crc is looking over the list now
17:58:08 <JasonWoof> I'll get serious about documenting it some day
17:59:40 <JasonWoof> I want there to be a specification document that is precice enough that you could implement a compatible VM with it
17:59:53 <crc> yeah
18:00:02 <crc> I'd like to implement a vm for it in retro sometime
18:00:10 <JasonWoof> cool :)
18:00:39 <JasonWoof> should be pretty easy
18:00:50 <JasonWoof> only tricky bit is supporting other-endian images
18:01:03 <crc> is it big or little endian?
18:01:12 <JasonWoof> it handles both
18:01:17 <crc> very nice
18:01:37 <JasonWoof> fronds is big endian
18:01:43 <crc> x86 has a 'bswap' instruction for changing one endian into another, so it shouldn't be a problem
18:02:03 <JasonWoof> sure
18:02:21 <JasonWoof> it's just extra bother to make sure you're running the correct version of the primitives
18:03:59 <JasonWoof> I might hack fronds so that it can reverse it's own endian
18:04:26 <crc> is fronds related to mist?
18:04:34 <JasonWoof> yeah, same thing
18:04:38 <crc> ok
18:06:03 <JasonWoof> I originally wanted to name it Frond. but the frond.org was taken
18:07:06 <JasonWoof> I've got the bootstrapping stuff in fronds all set up so it never executes anything in the new image until it's done and rebooting
18:09:17 <crc> cool
18:09:55 <JasonWoof> so the new image could be eg in a different endian
18:10:09 <JasonWoof> just have to hack my assembler some  more
18:10:27 <JasonWoof> shouldn't be too hard
18:10:34 <JasonWoof> I've already done a couple big hacks
18:10:48 <slava> what is the bootstrap code written in?
18:10:49 <JasonWoof> firstly to get it to compile at a different address (all branches in fovium are absolute)
18:11:02 <JasonWoof> and again when I changed the format of the branch instructions
18:11:16 <JasonWoof> by bootstrapping I meant fovium compiling itself
18:11:20 <JasonWoof> oops
18:11:26 <JasonWoof> by bootstrapping I meant fronds compiling itself
18:12:08 <JasonWoof> the initial fronds image is generated by a load of code in herkforth
18:12:30 <slava> yeah, i have 32 and 64-bit images of both endians, there's some details to take care of
18:24:39 <JasonWoof> I want to add a reboot syscall to fovium
18:25:37 <JasonWoof> it'll clear the stacks and start executing the image at the begining again
18:25:48 <JasonWoof> and probably check the endian again
18:26:51 <JasonWoof> crc: that's so cool you want to implement fovium in rf
18:26:58 <JasonWoof> that will encourage me to write the specification sooner
18:27:14 <crc> I'll look forward to reading it when it's written :)
18:27:21 <JasonWoof> right now I'm definitely puting a higher priority on making it so I can do fronds development in fronds
18:27:27 <crc> it's now on my to-do list
18:27:36 <JasonWoof> cooool :) :)
18:50:08 <Raystm2> can someone instruct me on how to change 32bit color values in hex into 16  bit color values in hex, Please?
18:50:23 <Raystm2> do I just 2/ them?
18:50:46 --- join: Flash00 (n=root@ip70-162-80-231.ph.ph.cox.net) joined #forth
18:53:29 <Raystm2> ooh that nearly worked.
18:55:15 <Flash00> Hello.  I'm interested in writing drivers for devices such as DVD burners.  I've never done any programming but from my research a language like Forth looks like the best fit for me.  Could anyone give me any advice?  Thanks.
18:57:01 <Raystm2> Flash00: as far as I know, the path to drivers using forth is to find said drivers in the linux libraries and rewrite them to fit your needs in forth.
18:57:24 <JasonWoof> Raystm2: depends on the formats
18:57:43 <JasonWoof> Raystm2: usually there's no 32-bit color usually it's 24
18:57:56 <JasonWoof> Raystm2: sometimes the leftover 8 are used for transparency, or simetimes unused
18:58:10 <Raystm2> Yes JasonWoof! thank you for that, I nearly forgot.
18:58:27 <JasonWoof> there are many formats for 16 bit color
18:59:00 <Raystm2> When tathi created the new colorforth image, he allowed for your choice of two modes of video.
18:59:09 <Raystm2> one he called 32 and the other 16 
18:59:19 <JasonWoof> you'll have to find the red blue and green values, and shift each down into the correct size, and or them together
18:59:24 <Raystm2> and then said using 16 you would have to recode the colors on block 30
18:59:52 <JasonWoof> you'll have to find out how the color palette is set up for 16-bit
18:59:58 <Raystm2>  ya.
19:00:16 <JasonWoof> you could guess that it would be in the order RGB
19:00:19 <JasonWoof> but it might not be
19:00:28 <JasonWoof> and which field gets the extra bit?
19:00:30 <Raystm2> now in the 32 bit version there is the original format that used to work on chucks old image like : white ffffff color ; 
19:00:48 <JasonWoof> right
19:00:59 <JasonWoof> it's fairly standard to have a byte for red, then green, then blue
19:01:02 <Raystm2> OH okay Chuck has done 565 in the past.
19:01:10 <JasonWoof> but afaik it's not so standard for 16 bit
19:01:12 <JasonWoof> ahh, cool
19:01:59 <JasonWoof> so you take the upper 5 bits of the red channel (the high 8 bits of those 24) and shift them up 11 bits
19:02:00 <JasonWoof> then you take the high 6 bits of green and shift it up 5 bits
19:02:07 <Raystm2> so I should rewrite the word color to take the 32 bits and convert to 565 before feeding to the kernel color word.
19:02:11 <JasonWoof> then you take the high 5 bits of the blue and "or" them together
19:02:42 <Raystm2> whoa, /me re reading what your saying here.
19:03:05 <Flash00> Raystm2: Thanks for the reply.  Rather than transcribe someone else's mistakes I prefer to make my own. :)  Seriously though, I like the idea of tinkering with the hardware at the most basic level possible.
19:03:28 <JasonWoof> : extract-red  ( color -- red byte ) 16 >> ;
19:03:38 <JasonWoof> : extract-green  ( 32color -- green-byte ) 8 >> 15 and ;
19:05:22 <JasonWoof> : extract-blue ( 32color -- blue-byte ) 255 and ;
19:05:22 <JasonWoof> oops, that 15 should be 255
19:05:22 <Raystm2> okay in green i see that
19:05:35 <JasonWoof> don't actually use those...
19:05:35 <Raystm2> cuz?
19:05:37 <JasonWoof> they are silly
19:05:43 <Raystm2> okay.
19:05:58 <JasonWoof> why shift down by 16 to get the red byte when you know you'll have to shift it down another 3 to make it a 5-bit sample?
19:06:10 <Raystm2> :16c 2/ color ; 
19:06:17 <Raystm2> works  but is dark in some colors
19:06:29 <JasonWoof> I just thought pseudo-code might be clearer than english
19:06:43 <Raystm2> yes makes sence to me so thank you.
19:07:26 <JasonWoof> you'd probably want to just shift the fields directly to where you want them in the new color
19:07:59 <JasonWoof> eg red goes from 8 bits into the word to 16 bits into it
19:08:00 <Raystm2> ya
19:08:20 <JasonWoof> and green from 16 to 21
19:08:35 <Raystm2> okay okay
19:09:12 <JasonWoof> ( 32-color -- 16-red-channel ) 8 >> $f800 and ;
19:10:09 <Raystm2> To keep the 32 bit format which is easier to code new colors, I should just do the math on each and seperate each value and combine to 565.
19:10:22 <JasonWoof> ( 32-color -- 16-green-channel ) 5 >> $7e0 and ;
19:10:23 <JasonWoof> ( 32-color -- 16-blue-channel ) 3 >> $1f and ;
19:10:41 <Raystm2> that looks good.
19:11:50 <JasonWoof> have to do a bit of juggling though
19:12:37 <Raystm2> couple of swaps and * by the bit posision and + in the ending
19:13:21 <JasonWoof> ( 32-color -- 16-color ) dup 32c->16r >r dup 32c->16g >r 32c->16b r> or r> or ;
19:13:44 <JasonWoof> shouldn't be * anywhere
19:13:50 <Raystm2> :) nice.
19:15:25 <JasonWoof> or you can save one slot on the return stack by moving "r> or" sooner:
19:15:30 <JasonWoof> ( 32-color -- 16-color ) dup 32c->16r >r dup 32c->16g r> or >r 32c->16b r> or ;
19:15:30 <JasonWoof> or you could use swap...
19:15:35 <JasonWoof> ( 32-color -- 16-color ) dup 32c->16r swap dup 32c->16g swap 32c->16b or or ;
19:15:51 <JasonWoof> or you could do it in asm :)
19:17:17 <JasonWoof> in ppc asm you could do one instruction per channel
19:17:19 <Raystm2> or you could inline it in the macros in machine colorforth byte code.
19:17:22 <JasonWoof> 32c->16c would be 3 instructions on ppc
19:17:22 <Raystm2> waste of macros when what is really needed is to recode the word color in the asm source. 
19:17:22 <Raystm2> that's cool.
19:17:27 <JasonWoof> I have no idea what it would take in x86 asm
19:18:14 * Raystm2 figures that out.
19:40:36 <JasonWoof> OK, now fronds has a nice persistant stack to use to track cursor movements
19:40:48 <JasonWoof> it has push ?pop and ?fwd
19:40:48 <JasonWoof> ?fwd is kinda like push, except instead of setting that next value on the stack it returns what was there already.
19:40:55 <JasonWoof> this stack is also circular
19:41:46 <JasonWoof> (that is you can push all you want and never run out of space, it'll just start eating up the oldest elements on the stack)
19:42:59 <JasonWoof> but it's smart enough that if you ?pop a lot, it won't go back past there
19:43:18 <JasonWoof> ditto with ?fwd
19:45:04 <JasonWoof> did get a bit ahead of myself there though... need to make it so you can actually jump somewhere in the editor first
19:52:06 --- quit: imaginator (".")
19:54:28 --- part: Flash00 left #forth
20:21:47 --- join: thinkinginbinary (n=tom@phoenix.thomastuttle.mooo.com) joined #forth
20:21:55 <thinkinginbinary> Quartus: hello
20:22:01 <thinkinginbinary> Quartus: Having a peaceful, PoppaVic-free Sunday?
20:22:11 * Robert giggles.
20:22:15 <thinkinginbinary> brb
20:22:16 --- quit: thinkinginbinary (Client Quit)
20:23:10 --- join: thinkinginbinary (n=tom@phoenix.thomastuttle.mooo.com) joined #forth
20:23:25 <thinkinginbinary> Alright, that's better.  Now who said "/me giggles"?  (Wrong color scheme - nicks were invisible.)
20:24:00 <Robert> That's me.
20:24:30 <thinkinginbinary> Robert: Ah.
20:42:15 <JasonWoof> kickass!
20:42:19 <JasonWoof> I've got output history!
20:42:30 <JasonWoof> and emit>mem
20:43:00 <JasonWoof> still needs a little work...
20:43:06 <JasonWoof> eg cr manages to get to the screen anyway
20:43:19 <JasonWoof> and the output history is not labeled as such
20:43:40 <JasonWoof> has some nice stuff though
20:43:50 <JasonWoof> emit>mem takes a count and won't write more than that to memory
20:47:12 <slava> why circular?
20:47:53 <slava> it will mask errors
20:48:39 --- join: Al2O3 (n=Al2O3@pool-70-104-20-219.dllstx.fios.verizon.net) joined #forth
20:54:19 <JasonWoof> eh?
20:54:19 <JasonWoof> there should be no limit on how many times you can jump the cursor around
20:54:22 <JasonWoof> what errors?
20:54:30 <slava> i thought you said your data stack is circular
20:54:36 <JasonWoof> not my data stack
20:54:40 <slava> oh
20:54:42 <JasonWoof> my stack of where the cursor has been
20:54:49 <slava> ok
21:01:23 <slava> JasonWoof: will you have online help?
21:03:19 <JasonWoof> slava: right here in this very channel :)
21:03:53 <JasonWoof> yeah, I plan on having a helpful wiki
21:03:53 <JasonWoof> with tutorials and so on
21:06:37 <JasonWoof> I hope to have a lot of information inside fronds
21:06:40 --- quit: thinkinginbinary ("leaving")
21:08:44 <slava> what is the difference between fronds and fovium?
21:08:45 <JasonWoof> I haven't decided how exactly fronds and the wiki will interract
21:08:45 <JasonWoof> fovium is the virtual machine
21:08:45 <JasonWoof> fronds is the OS
21:08:45 <slava> ok
21:08:45 <JasonWoof> I changed the name from Mist to Fronds rather recently
21:08:50 <slava> if i write a fovium implementation in factor, will fronds run there? :)
21:09:00 <JasonWoof> if you do it right :)
21:09:02 <slava> i could use it for benchmarking
21:09:12 <JasonWoof> that would be very cool
21:09:26 <slava> how does it do graphics output? does fovium have bytecodes modelled after SDL?
21:09:31 <slava> or just text output?
21:09:49 <JasonWoof> currently only text output
21:10:01 <JasonWoof> and syscalls for term-color and term-move
21:10:19 <JasonWoof> my implementation is graphical and has a simple terminal emulator built in
21:11:34 <slava> neat
21:11:39 <JasonWoof> the terminal does not have adequate input capabilities
21:12:03 <JasonWoof> Fronds needs to know when you press and release keys like alt
21:12:22 <slava> it uses that weird humane interface stuff?
21:12:25 <JasonWoof> yes
21:12:47 <JasonWoof> and I plan to write a dvorak translator
21:13:07 <JasonWoof> and write games
21:13:10 <JasonWoof> etc etc
21:13:39 <JasonWoof> I haven't written the graphics api yet
21:36:52 --- join: reuben (n=ben@leb-cr1-220-16.peak.org) joined #forth
21:36:52 --- part: reuben left #forth
23:44:44 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
23:57:03 --- quit: snowrichard (Remote closed the connection)
23:57:08 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
23:59:16 <snowrichard> hi
23:59:59 --- log: ended forth/06.03.26