00:00:00 --- log: started forth/10.05.13
00:02:05 --- quit: docl (Ping timeout: 246 seconds)
00:40:59 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
01:07:04 --- quit: gogonkt (Ping timeout: 260 seconds)
01:08:50 --- join: gogonkt (~info@59.39.13.206) joined #forth
01:51:31 --- quit: gogonkt (Ping timeout: 268 seconds)
01:53:26 --- join: gogonkt (~info@218.13.62.183) joined #forth
02:30:10 --- quit: mathrick (Ping timeout: 240 seconds)
02:44:14 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
02:52:19 --- quit: mathrick (Remote host closed the connection)
02:56:43 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
03:08:40 --- quit: mathrick (Ping timeout: 276 seconds)
03:09:02 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
04:15:48 --- join: zashi1 (~mhiles@nat/ibm/x-pzyveirjgqmpbaqx) joined #forth
04:16:32 --- quit: zashi (Ping timeout: 260 seconds)
05:45:10 <_I440r> deformative why would anyone in their right mind move TO california?
05:48:31 <schmx> nice and warm
05:48:55 <_I440r> and both morally and financially bankrupt
05:49:17 <schmx> haha. morally bankrupt. That's funny.
05:49:19 <_I440r> arizona is just as warm and you dont have the beach slobs :)
05:49:35 <_I440r> tax the rich! give it to the illegals! yay!
05:49:37 <schmx> beach slobs?
05:49:51 <_I440r> beach bums :)
05:49:52 <schmx> the rich seems the best people to actually tax.
05:50:18 <_I440r> no actually the government gets more revenue when they LOWER taxes
05:51:06 <schmx> I would think that varies from case to case.
05:51:17 <_I440r> and taxing ANYONE just so we can support people who should not be here... sorry but thats dumb
05:51:19 <schmx> I am not so familiar with CA, so what you say might be very true.
05:51:34 <schmx> Ya. You should leave the place back to the natives.
05:51:45 <scj> give it back to mexico
05:51:55 <_I440r> only time i actually lived there was when i was in the usaf but ive done quite a few contracts
05:52:10 <_I440r> so they can overrun it with drug lords and bent cops?
05:52:12 <_I440r> good plan
05:52:32 <_I440r> quadruple the lenght of the current border that our fefds refuse to secure
05:52:41 <scj> legalize drugs and undercut the drug lords
05:56:08 <schmx> scj: easier solution for most world problems seems to be to just nuke all of the USA ;)
05:56:29 <scj> but my tv shows?!?
05:56:39 <ASau`> Who cares about that crap?
05:57:27 <schmx> scj: you crazy. it is all about bollywood movies now.
05:58:01 <scj> can't stand the song and dance routines. musicals are the worst
05:58:38 <schmx> Or just throw out your tv :)
05:59:30 <ASau`> scj: that's because there's no culture in U.S.A.
05:59:47 * schmx sees the patentwars are flaring up on the smartphone market.
05:59:47 <ASau`> Austrians and Magyars did that right.
06:15:48 --- join: docl (~luke@216-161-87-126.ptld.qwest.net) joined #forth
06:22:54 --- quit: nighty^ (Quit: Disappears in a puff of smoke)
06:24:41 <KipIngram> Deformative: I wasn't around last night but I am this morning.  What's up?
06:44:27 --- quit: gogonkt (Ping timeout: 268 seconds)
07:02:05 --- join: nighty^ (~nighty@x122091.ppp.asahi-net.or.jp) joined #forth
07:02:32 <Deformative> _I440r: I am moving there for an internship.
07:03:10 <Deformative> KipIngram: Hey.
07:03:29 <Deformative> So I decided to bump up my opcode size to 6 bits.
07:03:42 <Deformative> And made my word size 18 bits.
07:08:48 <Deformative> So this opens a lot of room for trying to find optimal opcodes.
07:09:49 <Deformative> But I just have so many.
07:10:04 <Deformative> I thought of 43 so far.
07:11:04 <Deformative> http://paste.dprogramming.com/dplg3rg5
07:11:57 --- quit: nighty^ (Quit: Disappears in a puff of smoke)
07:12:09 <KipIngram> :-)  Yes, you could really go to town with 64 possible opcodes.
07:12:32 <Deformative> My favorite is my ternary opcode, but it is extremely limited at the moment.
07:12:56 <KipIngram> Tell me what it does.
07:13:00 <Deformative> I need to think of uses for it when it is not in the first slot of a cell.
07:13:32 <KipIngram> It will conditionally execute either the second or third opcode in the cell?
07:13:38 <Deformative> [TERNARY, a, b]  ternary will evaluate the top of the stack, execute opcode a, if true, b if false.
07:13:48 <Deformative> Yes.
07:13:50 <Deformative> In one cycle.
07:14:08 <Deformative> It opens up a small problem if A is a call.
07:14:16 <Deformative> I need to tell it to return to the next cell.
07:14:20 <Deformative> But not too big of a deal.
07:14:46 <Deformative> Actually, not sure if I can do it in one cycle.
07:14:49 <Deformative> I need to look into that more.
07:18:10 <KipIngram> Yes, that does look troublesome if one of the opcodes is a call.  If that opcode doesn't get executed you still have to move the IP past the call address in the instruction stream.
07:18:25 <KipIngram> Feels messy, but yeah, I'm sure you can backflip through it.
07:18:37 <KipIngram> Maybe just not in one cycle, like you said.
07:19:10 <Deformative> I feel like it is really useful fo doing long switch statements.
07:19:30 <Deformative> Without binary searching or hashing the key.
07:20:38 <Deformative> I think that TRUE and FALSE could very likely be the most useful and easily optimized things I added.
07:20:53 <Deformative> Push 0 or 1 to the stack as an opcode rather than a LIT.
07:21:03 <Deformative> Since those literals are so common.
07:21:13 <Deformative> They only take 6 bits.
07:21:25 <KipIngram> Yes, I think that sounds useful.
07:21:48 <KipIngram> I don't like the idea of "long switch statements".  This is Forth (sort of) - chunks of code are not supposed to be "long".
07:22:10 <Deformative> I feel like I don't have enough conditional operations.
07:22:25 <KipIngram> I'd probably implement something that would be a "long switch" in C as a call table in Forth.
07:22:39 <KipIngram> So a computed call.
07:23:09 <Deformative> Mhmm.
07:23:25 <Deformative> But I am hoping to port small-c to my platform.
07:23:37 <Deformative> And open up ?: functionality.
07:24:43 <KipIngram> I see.  That doesn't interest me, but sure, if that's one of your goals you should have an eye on setting up to do it efficiently.
07:25:34 <Deformative> So it would be useful for things like: vehicle = arg == 'B' ? bus : arg == 'A' ? airplane : etc;
07:26:37 <Deformative> The way people will string ternary operators together.
07:26:42 <Deformative> I would use that in place of a switch.
07:26:50 <Deformative> It is done in verilog sometimes too.
07:27:44 <KipIngram> Ok.  I came at mine from entirely the other direction: what can the hardware do very efficiently and how can I bridge that into something I can call "Forth."
07:28:08 <Deformative> I see.
07:28:24 <KipIngram> So given that my outcome was "Forthy" I let the hardware tell me what to design.
07:28:43 <Deformative> How many cycles/char can you do an strlen?
07:28:58 <KipIngram> Kind of like that old saw about a sculptor taking a big rock and removing the parts that didn't belong to the sculpture within.
07:29:29 <KipIngram> That would depend on how I represented strings, which has nothing to do with my hardware.  Do you mean a C-style null-terminated string?
07:29:39 <Deformative> Yes.
07:29:41 <KipIngram> Presuming I have a pointer to the first character on the stack.
07:29:43 <KipIngram> ?
07:29:45 <KipIngram> Ok, one sec.
07:29:46 <Deformative> Yes.
07:29:55 <KipIngram> Give me a minute or two to think about how I'd do that.
07:30:03 <KipIngram> I'll return shortly.
07:30:06 <Deformative> And what about a filter?
07:30:11 <Deformative> Do filter too. :)
07:30:20 <Deformative> Filter all integers in an array less than 5.
07:30:45 <Deformative> Ok, have fun.  I just thought I would bring these up because someone did to me and I they are helpful.
07:31:38 <Deformative> I figured out that I should probably add operators for keeping a pointer around and incrementing like you have.
07:31:50 <Deformative> I was also considering adding a register or 2.
07:32:06 <KipIngram> What's filter supposed to do?  Just count them?  I don't know if I find that as interesting, but I'll decide whether to tackle that after I finish strlen.
07:32:29 <Deformative> Ok.
07:32:30 <_I440r> dup begin count 0= until -   <-- like that?
07:32:36 <Deformative> Well, copy them into a second array.
07:32:41 <_I440r> erm swap - 
07:32:56 <_I440r> dup being count 0= until swap -
07:33:50 <Deformative> If count increments your pointer and dereferences, then yes.
07:34:23 <_I440r> count does a fetch of the contents of teh address and bumps the address. it reutnrs address +1 and a char
07:34:35 <Deformative> Then yes.
07:34:36 <_I440r> ( a1 --- a1+1 c1 )
07:34:41 <Deformative> Yep, exactly.
07:35:35 <_I440r> purists dont like using count in that way tho. its INTENDED to convert the address of a counted string into a address and count
07:35:49 <_I440r> so its stack comment is actually ( a1 --- a2 N1 )
07:36:17 <Deformative> I see.
07:36:49 <Deformative> KipIngram: I am also trying to think of useful ways to divide up my words.
07:36:53 <_I440r> you could make a new word called $@+ or something that has the same definition as count :)
07:37:23 <_I440r> :strlen ( a1 --- n1 ) dup begin $@+ 0= until swap - ;
07:37:26 <Deformative> Into 12 bit for vga, 8 bit for the standard byte/char, 16, etc
07:37:29 <_I440r> err : strlen  even
07:37:53 <Deformative> _I440r: Yeah, I was thinking about adding $@+ to my instruction set.
07:38:06 <_I440r> in the forth world count IS strlen :)
07:38:36 <_I440r> well. not exactly. it doesnt just return the length. it returns the address and length of the string :)
07:38:46 <Deformative> But I feel like it would be very very difficult to compile C using $@+.
07:39:10 <Deformative> I am trying to keep all my opcodes so that they are easy to translate C into.
07:39:32 <Deformative> Well, a C subset.
07:39:48 <_I440r> any reason why ?
07:40:14 <_I440r> for instance:  a good friend of mine (who hosts isforth.com) says taht developing embedded applications in C is like opening a can with a rock
07:40:55 <zashi1> :( I like using C on embedded systems
07:41:00 <zashi1> It's fun.
07:41:36 <_I440r> :) thems fighting words :P!
07:41:58 <zashi1> I'm still getting over how weird forth is for me. :) still such a noob.
07:42:04 <KipIngram> Deformative: Sorry - on a phone call now.
07:42:11 <Deformative> KipIngram: No worries.
07:42:16 <_I440r> noob is ok. the fact that your hear means your a SMART noob :)
07:42:36 <_I440r> and forth IS weird till you learn it in depth, then it makes absolute sense
07:42:52 <TreyB> here
07:42:54 <Deformative> _I440r: My assembly is forth-like.
07:42:58 <zashi1> I mean, it makes sense (mostly thanks to understand of computers that I've gained through using C) it's just very weird still.
07:43:10 <_I440r> yes microcoding in forth is a snap :)
07:43:22 <Deformative> My high level programming is hopefully C which translates to forth-like.
07:43:32 <Deformative> Which seems interesting to me.
07:45:01 <zashi1> You know a language is awesome when the users of it consider C high-level (I know, anything not machine-code is high-level, but modern, colloquial usage is C = low level; Python, Ruby, D = high level)
07:45:13 <zashi1> er.. not machine-code, I meant assembly.
07:45:53 <Deformative> D poopy now.
07:46:00 <_I440r> hey stupidly call C structured asm.  thats the biggest crock of horse shit 
07:46:00 <Deformative> And I never tried python/ruby.
07:46:02 <KipIngram> I think with my current operation the loop part of strlen would take four cycles.
07:46:07 <_I440r> "they"
07:46:17 <Deformative> If I wanted a scripting language I would use javascript/lua.
07:46:28 <KipIngram> That presumes that I add a "skip nop" optimization that I'd already planned to add but haven't yet.
07:46:31 <Deformative> I always say javascript/lua together because they are basically the same thing.
07:46:35 <Deformative> Just lua is faster.
07:46:37 <_I440r> both of which are object obfuscated :/
07:46:58 <KipIngram> Bear in mind, though, that my processor is not byte-oriented.  I'd store strings one character per 16-bit cell.
07:47:07 <KipIngram> The kind of apps I'm targeting just aren't string intensive.
07:47:24 <Deformative> Of course.
07:47:30 <KipIngram> I could store strings more compactly, of course, but then extra code would be needed to split cells, etc.
07:47:38 <zashi1> for simple utilities or something I need fast I usually use C. For a quick one-off app or pretty much anything else I want to do, I use Tcl. (Please don't hate me :[ )
07:47:46 <ASau`> _I440r: they work on non-linux platforms at least.
07:48:24 <KipIngram> That split operation would be good for that.
07:48:28 <_I440r> boggle
07:48:31 <_I440r> so does forth :)
07:49:00 <Deformative> KipIngram: Yeah, I am trying to figure out split operations for my core.
07:49:03 <zashi1> forth is an OS :D I find that so cool.
07:49:15 <KipIngram> Although if I were really serious about optimizing for strings I'd probably add a dedicated opcode to separate a cell into two bytes, so I didn't have to load the "8" parameter for the general split operation.
07:49:20 <_I440r> it is cool. its the OS, its the development system its the application
07:49:32 <Deformative> When I increased my opcode counts my ammount of logic went through the roof.
07:49:37 <Deformative> I hope I can fit it on my fpga.
07:49:52 <KipIngram> I shied away from split / join because I have an idea that they would take a fair bit of logic.
07:49:58 <_I440r> Deformative: i hear you can only use up to 80% of your logic in an fpga too
07:50:13 <KipIngram> 80% is a good rule of thumb.
07:50:22 <_I440r> i wouldnt create a special opcode for those. those can be done in "high level"
07:50:26 <Deformative> Altera is supposed to have one of the best plotters around.
07:50:38 <Deformative> Not uncommon for people go into 98%.
07:50:40 <KipIngram> You can use more if you're careful and hand-optimize / floorplan a bunch of stuff, but if you're just throwing Verilog at it then yeah, 80% or so.
07:50:48 <Deformative> From what I saw in ##fpga
07:51:38 <Deformative> zashi1: squeak is semi-interesting.
07:52:08 <KipIngram> Going that high is risky - you run the risk of designing your FPGA onto a circuit board (which requires that you freeze your pinout), encountering a need to change something (minor), and then not having it fit anymore.
07:52:19 <zashi1> Deformative: squeak?
07:52:22 <KipIngram> The 20% spare logic space just offers you insurance against such disasters.
07:52:54 <Deformative> KipIngram: Mhmm, but buying a bigger fpga is always an option too for some of those people.
07:53:27 <Deformative> zashi1: Also, whatever alan kay's new project is looks like squeak just more interesting.
07:53:43 <Deformative> It is basically to try fitting squeak in 20,000 lines of code.
07:54:01 <Deformative> And he has a ton of funding to do it.
07:54:44 <Deformative> zashi1: Squeak is modern smalltalk.
07:54:52 <_I440r> wtf, i need funding to develop isforth!
07:54:56 <KipIngram> Ok, if I added an opcode called "bytes" that split a 16-bit cell into two 8-bit bytes then my strlen inner loop would take six cycles.
07:55:00 <_I440r> how the fsck do ppl get funding like that!
07:55:27 <Deformative> _I440r: He got most of it from nsf.
07:55:31 <KipIngram> One cycle to set up, and a small number of cycles to wrap up after falling out of the loop.
07:55:35 <_I440r> nsf?
07:55:48 <Deformative> National science foundation or something along those lines.
07:55:58 <Deformative> KipIngram: That isn't bad at all.
07:56:27 <KipIngram> Deformative: Yes, if you've planned for that such that the bigger FPGA is pin compatible with your layout.  And *if* you only need to field the change in your new builds and not in the existing product.  
07:56:41 <KipIngram> Even then, though, you're now faced with maintining two versions of your product.
07:57:06 <KipIngram> Better to make the decision to go with the bigger fpga up front, so that you have that spare logic from the outset.
07:57:12 <Deformative> I understand.
07:57:44 <KipIngram> Oh, two cycles to set up for the strlen loop.
07:58:04 <KipIngram> Three, actually, because I have to fetch that cell.
07:58:56 <Deformative> Yeah, 18 bit words makes dealing with bytes difficult at best.
08:00:02 <KipIngram> I decided pretty early on that I was going to go with a standard power of two cell size.
08:00:20 <KipIngram> So it was either 16 or 32 bits.  I gave just a bit of thought to 24, but decided against it.
08:00:54 <Deformative> Well, I couldn't fit my return addresses in 16 bits.
08:01:04 <KipIngram> 24 gets me to a cell size that will support the DSP resolution we use around here.  We use 24-bit analog to digital converters (sigma-delta devices).
08:01:20 --- join: nighty^ (~nighty@x122091.ppp.asahi-net.or.jp) joined #forth
08:02:05 <Deformative> Because of my sub-word instructions, 16 bits was too small.
08:02:56 <_I440r> 32 bit lest you have 28465298365982346892 gigs of ram or something :)))
08:03:06 <Deformative> KipIngram: When I was thinking about 16 bits I was considering using the spare bit as a implicit next/return.
08:03:10 <_I440r> and in todays world thats not enough :/
08:03:40 <Deformative> Which was handy.
08:03:42 <KipIngram> I used the spare bit as an implicit "call".
08:03:49 <Deformative> Yep.
08:05:12 <Deformative> If I can guarantee that the next cell will always be fetched by the 2nd or 3rd operation of a word, then I can make ternary work in the 2nd or 3rd slot.
08:05:15 <Deformative> But it seems hairy.
08:07:12 <KipIngram> You're headed down a difficult path.  Once you start thinking about stuff like that you will see that it's very hard to guarantee those things.
08:07:33 <Deformative> Yeah.
08:07:36 --- join: Snoopy_1711 (Snoopy_161@dslb-084-059-099-246.pools.arcor-ip.net) joined #forth
08:08:02 <KipIngram> I spent months trying to come up with a fully pipelined design that gave me an almost unbroken stream of opcode execution, but the cost in logic just grew and grew and grew.
08:08:07 <KipIngram> What I have now is *so* simple.
08:08:42 <Deformative> Yeah.
08:09:43 <Deformative> I want to just think of a few more conditionals and a way to implement split/join-like then I want to get back to actually implementing the thing.
08:09:50 <Deformative> Because I know I fill think of things as I go.
08:10:04 --- quit: Snoopy_1611 (Ping timeout: 240 seconds)
08:10:25 <KipIngram> I haven't messed with mine in a while - I've got a ton of stress at the moment.  Hopefully that will resolve soon and I'll feel "playful" again.
08:13:26 <Deformative> Ok.
08:13:30 <Deformative> Well, good luck.
08:13:38 <Deformative> I have some things I need to do today.
08:13:43 <Deformative> So talk to you later.
08:16:15 --- quit: crc (Ping timeout: 258 seconds)
08:18:15 --- join: crc (~charlesch@184.77.185.20) joined #forth
08:41:02 --- quit: ASau` (Quit: off)
09:02:18 --- join: gogonkt (~info@218.13.56.119) joined #forth
09:37:39 --- quit: ASau (Ping timeout: 240 seconds)
09:39:26 --- quit: docl (Ping timeout: 264 seconds)
09:39:34 --- join: ASau (~user@83.69.227.32) joined #forth
11:18:56 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
11:49:42 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
11:53:17 --- quit: gogonkt (Ping timeout: 246 seconds)
12:03:03 --- join: gogonkt (~info@218.13.56.119) joined #forth
12:12:04 --- quit: gogonkt (Quit: leaving)
12:21:01 --- join: gogonkt (~info@218.13.56.119) joined #forth
12:38:51 --- quit: ygrek (Ping timeout: 245 seconds)
13:04:42 <Deformative> Hm, I just realized that I will not have enough address space to access my vga framebuffer. D:
13:05:00 <Deformative> I will need to use double precision or something... x.x
13:07:24 <Deformative> Or use 24 bit words I suppose.
13:35:29 <KipIngram> Maybe you could put a "dma controller" type thing in between; you'd set it up using row/column info.  For example, to draw a line you'd give it the row and column of the start point and the row and column of the end point.  Then you'd pump data at it, and the controller hardware would calculate frame buffer addresses for you.
13:36:07 <Deformative> Drawing the line seems difficult.
13:36:35 <KipIngram> Yeah.
13:37:06 <Deformative> I was looking at pixel by pixel because line drawing seemed to difficult.
13:37:34 <KipIngram> Or maybe you specify a row and then your "address" specifies the column within that row.  Any trick that keeps your processor-generated addresses from having to be the full address of a location in the buffer.
13:38:47 <Deformative> Well, I wanted to memory map the entire framebuffer data.
13:38:49 <Deformative> Heh.
13:39:08 <Deformative> So that is an impossibility unless I bump my word size to 24.
13:40:00 <Deformative> http://en.wikipedia.org/wiki/Bresenham's_line_algorithm
13:40:04 <Deformative> Perhaps I can use this.
13:40:15 <KipIngram> Re drawing lines, if you work with more address bits than you really need, so that the low order bits are ignored when producing the frame buffer pixel address, then you might make drawing a line easier.
13:40:50 <KipIngram> You could specify any line as "starting point, number of steps, row step, column step" and just go.
13:41:10 <Deformative> I could do a windowed approch.
13:41:13 <Deformative> That seems interesting.
13:41:17 <KipIngram> For "almost horizontal" lines the row would change only occasionally, when the increment spilled into the significant bits.
13:41:30 <KipIngram> For "almost vertical" lines the same would apply, except to the column.
13:41:53 <KipIngram> Either row step or column step would always be set to 1.
13:42:14 <KipIngram> Or rather, to the number that corresponded to one real pixel step.
13:42:27 <KipIngram> The other step would be set to less than that value.
13:42:34 <KipIngram> But now you need even more bits. ;-)
13:43:08 <Deformative> But really.. Most of the time I would be doing single pixel assignments.
13:43:39 <KipIngram> Ok.  You're not going to get a lot of performance that way though.
13:43:51 <Deformative> Yeah I know.
13:43:54 <Deformative> Hmm..
13:44:10 <KipIngram> This is where your FPGA could really help you - you could create all kinds of hardware accelerators.
13:44:15 <Deformative> But it will be more efficient when I need to draw single pixels.
13:44:24 <Deformative> I could use different ports I suppose.
13:44:26 <Deformative> That would help.
13:46:05 <KipIngram> This is something that can absorb a lot of your thought, I think.  Lots of ways to optimize.
13:47:15 <KipIngram> Bugging out for a while - need to drive.
13:48:11 <Deformative> Ok.
13:48:17 <Deformative> Talk to you later.
14:59:02 --- quit: qFox (Quit: Time for cookies!)
15:19:49 --- quit: kar8nga (Remote host closed the connection)
17:45:51 --- join: docl (~luke@216-161-87-126.ptld.qwest.net) joined #forth
18:25:26 --- join: probonono (~User@unaffiliated/probonono) joined #forth
18:28:01 <Deformative> KipIngram: Dual offset pointer has been done before:  http://opencores.com/project,fcpu
18:37:51 --- quit: flash (Ping timeout: 246 seconds)
18:52:32 --- join: flash (~flash@123.118.159.126) joined #forth
19:43:16 <KipIngram> What is that exactly?  The row / column thing, or the extra bits thing?  I haven't visited your link.
19:44:02 <KipIngram> I didn't figure anything I suggested earlier was new - it's really hard to come up with original ideas in such heavily occupied territory.
19:44:55 <Deformative> KipIngram: Having the operands trail after operator words.
19:45:47 <KipIngram> Oh, ok.  But you don't *have* to have two pointers to do that.  I do it with one.  Your scheme was a bit different, though.  I don't remember the details but I really liked it.
19:46:44 <Deformative> Yeah, that url seems to do it the exact same way as me.
19:46:52 <Deformative> So it isn't so unique.
19:46:59 <KipIngram> Oh, wait, I remember now.  That was what let you return to within a cell.
19:47:16 <KipIngram> I didn't need two pointers since I only address cell boundaries.
19:47:47 <Deformative> Yes.
19:48:11 <KipIngram> Darn.  I'd hoped you were onto something there.
19:50:25 <Deformative> Yeah, me too.
19:50:29 <Deformative> Oh well.
19:53:37 <Deformative> I think I will make a playstation controller interface.
19:53:46 <Deformative> I might not make a core. :/
19:56:36 <KipIngram> Today I completely overhauled my Perl scripts that I use to manage my stock market portfolio.
19:57:44 <KipIngram> My philosophy has been to stay in no matter what, and to value my portfolio relative to the market rather than in absolute terms.  That way I can gain regardless of what the market is doing.
19:58:11 <KipIngram> But that weird stuff last Thursday scared me out.  I got back in Friday morning, and was worse off by several percent than I would have been if I'd stayed in.
19:58:40 <KipIngram> So today I completely purged my visual display of all indication of the market's actual level.  There nothing I can see anymore that's not a "relative to the market" metric.
19:59:01 <KipIngram> With this version I'd have never seen the dive last Thursday.
20:01:08 <Deformative> I see.
20:04:28 <KipIngram> If I were close to retirement I'd have to be more concerned about actual $'s, but that's still a couple of decades off.
20:05:19 <KipIngram> By the way, I *heartily* recommend that you start investing immediately upon nailing down a salary.  Longevity wins in that game.  The time value of money thing is just too powerful to argue with.
20:05:55 <Deformative> I am in debt.
20:06:01 <Deformative> Yay school
20:10:09 <KipIngram> Yes, I know.  Just as soon as you can.  Try to max out your IRA every year.  401k's suck - you have to invest in funds that someone else manages.  Put your IRA into a brokerage account and pick your own stocks.
20:10:42 <KipIngram> The ability to trade frequenly without tax ramifications is a big big win.
20:10:58 <Deformative> I see.
20:14:45 <Deformative> Hm, can you think of a fun minimalist project I can do on my fpga?
20:14:51 <Deformative> I think the forth processor is too big now.
20:16:06 <Deformative> Unless I can think of a way to make the cpu more minimalist.
20:16:15 <Deformative> I could just only fill like 30 of the opcodes.
20:16:27 <Deformative> And get a bigger fpga when I run out of space.
20:18:07 <KipIngram> How about an mpeg encoder?
20:18:29 <Deformative> Nah. :/
20:19:09 <Deformative> Actually.
20:19:16 <Deformative>  I think that this psx thing is worthwhile.
20:19:24 <Deformative> I will make a module for interfacing a playstation controller.
20:19:29 <Deformative> And keyboard.
20:19:37 <Deformative> And I already have the timing for vga.
20:19:43 <Deformative> Then I will make a windowing system.
20:19:47 <Deformative> With stack machine.
20:19:50 <Deformative> And expand as needed.
20:20:17 <Deformative> So I will still do a forth-like core.
20:20:22 <KipIngram> Something that receives 24 bits of RGB info per pixel, at some high resoution stuff associated with making an mpeg.
20:20:24 <Deformative> It will just be the side project.
20:20:30 <KipIngram> Discrete cosine transforms and what not.
20:21:35 <KipIngram> The mpeg thing is something that's on my long-term to do list.  I want to grab the pixel info from a 1080p HDTV just as it's headed for the LCD panel and mpeg it.
20:21:50 <KipIngram> Then I can hook that into MythTV and have a DVR that will record anything.  Anything at all.
20:23:11 <KipIngram> And no cable company hanky panky will be able to stop it.  No matter how many games they play they do have to send a bitstream to the LCD panel.
20:23:47 <KipIngram> That's just a hell of a lot of info, and encoding it in real time will be a challenge.
20:25:28 <Deformative> Yeah,
20:26:12 --- quit: docl (Ping timeout: 252 seconds)
20:30:47 --- quit: gogonkt (Ping timeout: 264 seconds)
20:31:16 --- join: gogonkt (~info@119.126.114.155) joined #forth
20:35:52 --- join: docl (~luke@216-161-87-126.ptld.qwest.net) joined #forth
20:59:12 --- quit: gogonkt (Ping timeout: 252 seconds)
20:59:51 --- join: gogonkt (~info@218.13.55.20) joined #forth
21:05:14 --- quit: alex4nder (Read error: Operation timed out)
21:07:12 --- quit: gogonkt (Ping timeout: 260 seconds)
21:08:09 --- join: gogonkt (~info@218.13.55.20) joined #forth
22:29:06 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
22:31:42 <Deformative> KipIngram: I came up with a new idea.
22:31:45 <Deformative> I will still do a forth.
22:32:06 <Deformative> But it is a bit nonsensical and stupid.
22:32:11 <Deformative> So it won't really be serious, just for fun.
22:32:26 <Deformative> Well, I suppose it isn't a forth really.
22:32:47 <Deformative> But the entire architecture will be based on the number 3.
22:32:52 <Deformative> 3 hardware stacks.
22:33:01 <Deformative> All opcodes will have some relevence to 3.
22:33:06 <Deformative> Mostly ternary operators.
22:33:31 <Deformative> Well, talk to you later.
22:33:35 <Deformative> I am going to sleep.
22:38:12 --- quit: kar8nga (Remote host closed the connection)
22:46:49 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
22:48:39 --- quit: ASau (Remote host closed the connection)
22:49:26 --- join: ASau (~user@83.69.227.32) joined #forth
23:03:18 <ASau> There're more than two stacks in classic Forth already.
23:03:35 <ASau> Around 5 or 6 in fact.
23:04:20 <ASau> "Magic number sevel plus or minus two." :D
23:25:40 --- quit: kar8nga (Remote host closed the connection)
23:42:12 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
23:59:59 --- log: ended forth/10.05.13