00:00:00 --- log: started forth/05.07.11 00:03:33 --- quit: saon|smgl (Read error: 110 (Connection timed out)) 00:03:33 --- quit: cmeme (Read error: 104 (Connection reset by peer)) 00:03:37 --- quit: Stepan (Read error: 104 (Connection reset by peer)) 00:03:59 --- quit: ianp_ (Read error: 104 (Connection reset by peer)) 00:04:15 --- quit: danniken (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: saon (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: madwork (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: Raystm2 (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: swalters (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: Robert (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: warpzero (brown.freenode.net irc.freenode.net) 00:04:15 --- quit: Snoopy42 (brown.freenode.net irc.freenode.net) 00:04:16 --- quit: I440r (Read error: 104 (Connection reset by peer)) 00:04:16 --- join: mark4_ (~mark4@rrcs-24-242-160-169.sw.biz.rr.com) joined #forth 00:04:32 --- quit: PayphoneEd (Read error: 104 (Connection reset by peer)) 00:05:07 --- join: crc (crc@pool-70-110-205-210.phil.east.verizon.net) joined #forth 00:05:07 --- join: Snoopy42 (snoopy_161@dsl-084-058-132-155.arcor-ip.net) joined #forth 00:05:07 --- join: warpzero (~warpzero@wza.us) joined #forth 00:05:07 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 00:05:07 --- join: danniken (CapStone@ppp-70-249-186-85.dsl.ltrkar.swbell.net) joined #forth 00:05:07 --- join: Robert (~snofs@c-f778e055.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 00:05:07 --- join: saon (1000@c-66-177-224-222.hsd1.fl.comcast.net) joined #forth 00:05:07 --- join: danniken- (CapStone@ppp-70-249-186-85.dsl.ltrkar.swbell.net) joined #forth 00:05:07 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 00:05:07 --- join: Raystm2 (~vircuser@adsl-69-149-51-226.dsl.rcsntx.swbell.net) joined #forth 00:05:07 --- join: skylan (~sjh@dialup-216-211-4-39.tbaytel.net) joined #forth 00:05:07 --- join: arke_ (f2@bespin.org) joined #forth 00:05:07 --- join: onetom (~tom@80.95.80.2) joined #forth 00:05:07 --- join: ccfg_ (ccfg@dsl-roigw3de0.dial.inet.fi) joined #forth 00:05:07 --- join: saon|smg1 (~saon@c-66-177-224-222.hsd1.fl.comcast.net) joined #forth 00:05:07 --- join: arke (f2@bespin.org) joined #forth 00:05:07 --- mode: irc.freenode.net set +o crc 00:05:24 --- join: PayphoneEd (~Ed@ip68-10-243-238.hr.hr.cox.net) joined #forth 00:05:46 --- quit: arke (Read error: 110 (Connection timed out)) 00:09:39 --- join: ianp (~ian@inpuj.com) joined #forth 00:09:40 --- join: Robert_ (~snofs@c-f778e055.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 00:09:53 --- join: Stepan (~Stepan@khepri.openbios.org) joined #forth 00:19:44 --- quit: Robert (Read error: 110 (Connection timed out)) 00:20:22 --- quit: danniken (Read error: 110 (Connection timed out)) 00:25:02 --- join: warpzero_ (~warpzero@wza.us) joined #forth 00:28:11 --- quit: warpzero (Client Quit) 00:52:02 --- join: aum (~aum@60-234-138-239.bitstream.orcon.net.nz) joined #forth 01:03:25 --- nick: danniken- -> danniken 02:32:43 --- join: snoopy_16 (snoopy_161@dsl-084-058-132-155.arcor-ip.net) joined #forth 02:38:53 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 02:38:57 --- nick: snoopy_16 -> Snoopy42 02:56:45 --- quit: PayphoneEd ("Reconnecting") 02:57:50 --- join: PayphoneEd (~Ed@payphoneed.user) joined #forth 03:01:52 --- join: crc2 (crc@pool-70-110-222-142.phil.east.verizon.net) joined #forth 03:15:52 --- quit: crc (Read error: 101 (Network is unreachable)) 03:20:23 --- nick: ccfg_ -> ccfg 03:21:25 --- quit: crc2 (Read error: 110 (Connection timed out)) 03:37:29 --- part: aum left #forth 03:39:53 --- join: aum (~aum@60-234-138-239.bitstream.orcon.net.nz) joined #forth 04:01:13 --- nick: warpzero_ -> warpzero 04:39:58 --- quit: aum () 05:00:08 --- nick: Robert_ -> Robert 05:15:20 PoppaVic was never here? 05:15:23 oh 05:15:24 nevermind 05:15:25 --- nick: arke_ -> arke 05:23:16 --- quit: saon ("Leaving") 05:29:46 --- join: saon (1000@c-66-177-224-222.hsd1.fl.comcast.net) joined #forth 05:35:40 --- join: danniken- (CapStone@ppp-70-249-186-85.dsl.ltrkar.swbell.net) joined #forth 05:35:40 --- quit: danniken (Read error: 104 (Connection reset by peer)) 05:36:01 --- join: PoppaVic (~pete@0-1pool46-26.nas30.chicago4.il.us.da.qwest.net) joined #forth 05:36:25 Mornin' 05:49:52 hi PoppaVic 05:53:30 Mornin' - sorry, was in the head ;-) 05:56:13 Near as I can tell from the last few days (reviewing older books), the 'vm' is the steppers/callers 05:58:13 I sorta' chuckled a few ago, as I reviewed the colorforth home page... Chucks "philosophy" has gotten caught in the Wheel Of Time. 06:05:19 --- part: PoppaVic left #forth 06:05:36 --- join: madwork (~madgarden@derby.metrics.com) joined #forth 06:05:49 Hi 06:06:19 --- join: PoppaVic (~pete@0-1pool46-26.nas30.chicago4.il.us.da.qwest.net) joined #forth 06:07:06 Hello 06:07:23 hiya.. Seems pretty lagged or sumpin' today 06:08:30 btw, looks like arke is gonna' kibitz on this libTIL/minish thingie ;-) 06:08:33 * madwork blocks PoppaVic's attack. 06:08:42 kibitz? 06:08:55 well, he wants to start writing code 06:09:11 Huh! Well, that's good! 06:09:22 ANd I've been trying to gather together a bunch of the ideas we've been bouncing 06:10:32 I'm making teh VM ^^ 06:10:56 :D 06:12:37 I'm still sorta' mindfucked over the engine getting up and down into hi-forth/C properly, but I'm presuming a mindblockage 06:13:18 Forthy uses wrapper functions. 06:13:36 And the stack passes data in and out. 06:13:43 right, no I'm thinking of the engine and "primitives" in general 06:13:46 Similar to Lua. 06:14:00 Yep, the primitives are C wrappers. 06:14:36 I wont use C wrappers 06:14:37 ^^ 06:14:56 madwork: myill be so fast you'll think it was native ^^ 06:14:58 Failed to open /DEV/Metabulider/VARIANTS for reading: No such file or directory 06:14:59 word_foobar(FSYSTEM *sys) 06:14:59 { 06:14:59 int foo fs_get_int(sys, -1); 06:14:59 fs_pop(sys); 06:14:59 fs_push_int(bar(foo)); 06:15:00 } 06:15:17 arke, FFI then? 06:15:17 http://rafb.net/paste/results/kM3MTB77.html 06:15:23 madwork: nope 06:15:36 see above... Those are my recollection of our raw ideas 06:15:36 :) 06:15:59 Hmm. 06:16:26 I don't use the C stack, I maintain my own stack. This is important for running multiple instances of the Forthy VM/env. 06:16:47 Then I can pause execution, multitask etc. between them as well. 06:16:50 so at least 2/vm, eh? Trying to avoid a return-stack 06:17:30 why do you want to avoid an rstack..? 06:17:31 I keep thinking that the R-stack is a really nasty crutch 06:17:37 .... 06:17:52 I'll need an rstack either way unless you dont mind the VM using like 4GB of memory 06:18:06 we _have_ an rstack - it's THE stack, and C/asm need it 06:18:12 noooooooo 06:18:14 lol 06:18:18 ok, new rule 06:18:24 PoppaVic, I don't agree. Like I said, it simplifies things, makes pausing/switching possible. 06:18:30 you dont owrry about VM implementation, only about design 06:18:50 madwork: yeah, I know - I'm just trying to get past the silly thing 06:19:16 There's a reason that Python had a huge drive to go stackless. 06:19:57 grr 06:19:59 :) 06:20:03 well, I recall working in the universe of registers, but it was a pita 06:20:24 either way you have a stack - a call stack, you always do 06:20:30 .. 06:20:35 :D 06:20:42 only if you think 2-stack forth 06:20:56 as I said, I'd like to think past the rstack 06:21:15 So, multiple return stacks then. :D 06:21:30 note state#2, ark 06:23:46 PoppaVic: so the VM should include the mechanism for compiling, right? 06:23:53 hmm? 06:24:28 no, I told you before... The vm is usually the prototypes, structs and code to do stepping, nesting, denesting, calls 06:25:10 i no get 06:25:13 the "virtual machine" - it is, as you thought the other day, the simulated-cpu system 06:25:49 oh, nothing more 06:25:56 the language is layered on it? 06:26:01 good, makes things easier on me :) 06:26:02 arke: do you have any forth books, or experience in the guts of any forths? 06:26:07 quite 06:26:20 although I despise the way traditional forths work 06:26:35 i prefer colorforth or retroforth guts to gforth or isforth guts anyday 06:26:39 right, the vm in the libTIL is the bottom-most code/structs to handle everything tossed on top and beneath it (in C) 06:27:13 as I mentioned, I looked over colorforth again today - and I shook my head and walkedawayt 06:27:20 wow 06:27:25 you didnt delve deep then :) 06:27:44 colorforth is wonderful if syou look past the surface 06:27:49 the overview of the site made me ill, not to mention my eyes water 06:27:56 arke, what's wrong with traditional forths? 06:28:23 madwork: read "moving forth" and you'll understand 06:28:36 Heh. 06:28:41 Now there's a good argument. 06:28:50 I've 2 brodies, a loeliger, and a bunch of tings 06:29:14 Reminds me about how christians tend to explain their religion, "read the bible and you'll understand". 06:29:18 i got 1 brodie (thinking), and i printed out a whole nunch of rodriguez' and CM's stuff 06:29:21 heh 06:29:33 rob: yep.. Too few manpages ;-) 06:30:37 actually, as long as my religious friends do not think I am ridiculing THEM, I can often enjoy talking comparative-religion with them. I still have a prob with suspension-of-belief issues, though 06:30:45 arke, I don't have time to read Moving Forth at the moment. Care to summarize in a sentence or two? :P 06:30:54 PoppaVic: if you want to have the C stack frame handle the return stack stuff, you will, literally, use 30 times the memory 06:31:21 madwork: vocs are ugly as they are traditionally implemented 06:31:57 arke, no.. You'd have "THE stack" owned by C, and our datastack owned by the vm. Further, you'd emulate regs you want in the vm. 06:32:26 PoppaVic: you dont understand 06:32:32 anyway, if there is an r-stack, then I want it a static in the vm.c and invisible to users.. THey do NOT need to fuck with it. 06:32:58 PoppaVic: thank you 06:33:02 arke, I don't see how "using the C stack" would require more memory. You're essentially making a subroutine-threaded Forth in C. 06:33:18 It may well be we are on intersecting planes, so.. As long as the code is readable. 06:33:18 dammit y'all are stupid 06:33:24 PoppaVic, I agree with that sentiment. Forthy restricts access to the rstack. 06:33:40 yeah, I see little reason for gymnastics 06:34:13 madwork: because eeach stack frame allocates register space, the extra bp, all that shit 06:34:18 ma 06:34:20 PoppaVic, just add a 3rd stack to replace the "R" stack words, ie >R R@ R> 06:34:34 so what, arke? It's there for C to do just that. 06:34:49 yes! 06:34:52 arke, if you're not switching contexts, that's no issue. 06:34:55 madwork: I think I'd try to live w/o them, if possible 06:35:05 madwork: and also, we are 06:35:11 PoppaVic, then you'll be juggling a lot. 06:35:11 PoppaVic: so, rememebr the rule ^^ 06:35:34 PoppaVic: also, why so disapproving of rstacks? 06:35:40 madwork: nah - remember our talk about the locals-stuff? 06:36:03 arke: just damned tired of all the gymnastics words and such 06:36:20 PoppaVic: ....thats it... 06:36:23 PoppaVic: ^^ 06:37:18 madwork: given those "locals", const, vars, arrays and something like block-local vars of C, we should not NEED all the gymnastics 06:37:29 PoppaVic: well, hwos this ... since theres more layers on the VM anyway 06:37:44 why not let me implement a forth VM with C binding 06:37:45 granted, we'd leave in some primitives down deep and irksome to reach 06:37:45 PoppaVic, what stack are you going to throw the locals on? 06:37:56 an your layer then eradicates the rstack from user view? 06:38:11 arke: go ahead, let's see what you have in mind. 06:38:38 I'll be sure to add "pick" 06:39:04 madwork: I would imagine we could either use a special voc and "virtual" stack, or some other voodoo. 06:39:05 and it'll be fast ^^ 06:39:06 Heh. 06:39:22 PoppaVic: oh, how do you want to solve the voc issue? 06:39:32 PoppaVic, or just allow instantiating arbitrary stacks for whatever purposes. 06:39:34 you can add it ;-) I still think in terms of my dstack being that nodal-queue ;-) 06:39:36 PoppaVic: ...wait, nevermind, thats _your_ layer, not mine :D 06:39:53 madwork: yes, planned to allow for stack-generating 06:40:40 right, arke: yer writing the interface between a TIL vm and C 06:41:26 So you make a global variable and put a locals stack in it. :) 06:42:12 arke: parsing#2 was an idea mad & I had discussed 06:42:46 mad: or, the invocation of the locals would do the same, yeah 06:43:17 PoppaVic: well, you're doing the languag eon top of the forth vm anyway, right? 06:43:22 PoppaVic: so its not my problem :) 06:43:53 right. And, the vm is embedded in a C wrapper "program", to either be self-contained or called back and forth betwen the two 06:44:05 Forth VM's are dead simple. Hurry up with that 10 lines of code, arke. ;) 06:44:50 yeah, given his rstack and his vm "registers", it's easier - but he has some interesting ideas. 06:45:28 As I said, I'll just have to see what develops from his view 06:46:17 madwork: I think he's writing a CPUvm under the TIL/C-vm 06:46:48 Why? 06:48:18 we had discussed it the other day: A "portable asm" could be useful. 06:48:37 the llvm ideas and such almost intrigue 06:49:18 Seems like needless extra work with a performance hit to boot. 06:49:31 translating such a simple "portable-asm" between platforms would be a whole lot easier than C porting and such, I imagine 06:50:04 as I said, I'm not sure all what he has in mind, so I'm interested to see what he's hollering about 06:50:51 basically, my VM is a CPU Forth VM, which support pick and FAST, FSATS, FAST, C library interfacing 06:51:00 and with FAST, i mean FASSTTTTTT1!!!11111oneoneone 06:51:03 madwork: btw, any comments or changes to that post I showed you are welcome 06:51:12 arke, ah, OK. 06:51:29 faster than forthy ever will be 06:51:35 unless you adopt my 1337 technique 06:51:40 So, how's this magical C lib interfacing work without FFI or wrappers? 06:51:43 :P 06:51:50 well, let's see the code and less braggin' ;-) 06:51:51 va_args :) 06:52:05 Hm. 06:52:52 as well as separate opcodes for different types of C programs 06:53:01 (note: doesnt support passing literal structures or doubles) 06:53:03 well, if his dstack supports the 'classing' we discussed (see Data etc), then maybe 06:53:14 (well, it does, but its a bit slower 06:54:54 There are plus and minus to the way C uses the stack/args and the way forth does, but gcc & friends are a lot more painstaking than forths typically are. Not sure which approach is "better", but we can try to figure it out. 06:56:34 the fact that most forths are also interpreters sorta' closes off the way C approaches the world, but that's ok. It mostly offers "ideas" 06:57:36 lol 06:57:46 well, nice that you have exactly 0 idea of how my VM works :) 06:57:56 You still have to get your dstack args in/out of the C stack varargs. 06:58:25 dude, I wrote a couple years ago.. But I've seen so damned many ways to do the same sorta' job that I have to judge on what I read and run 06:58:35 madwork: yes, but I'm making _AT LEAST_ 1 function call less per invocation than you are 06:58:58 PoppaVic: well, it wont be special except for the C interfacing part :) 06:59:15 hey, I'll be happy to see it 06:59:26 PoppaVic: the rest will just be a forth vm. the instrucitons wont even be organized, to make it faster for compilers and easier for me to write. 06:59:40 err, rather 06:59:46 the C interfacing instructions arent 06:59:48 :D 07:00:25 As said, I look forward to it. Maybe it'll help smite this brainlock I have lately. 07:01:24 arke, you'll be throwing dstack value references in the varargs I assume? 07:02:23 * PoppaVic believes his queued dstack is about to get beaten down 07:05:28 madwork: indeed 07:05:37 PoppaVic, your dstack fields are tag, types union? 07:05:52 madwork: heh.. Sometimes, I even think we need the voclist, the preproc-voc and even a macro/define voc ;-/ 07:06:42 ?? 07:06:49 Not in the data stack. 07:06:56 madwork: each dstack entry is a queue node. The tagfield was originally an int (up in the queue node), but it can be kicked 07:07:39 I dunno, that just wigs me out. ;) 07:07:55 Failed to open /DEV/metabuilder/usefuls/queue.h for reading: No such file or directory 07:08:05 http://rafb.net/paste/results/2goCPF25.html 07:08:08 damned typoes 07:10:48 madwork: the code is just plain-old generic. I got tired of writing stacks/queues. 07:12:12 writing it to work either way just makes it handier is all. All it lacks is an sorted-insertion/extraction pair (and I didn't want to get involved) 07:13:04 --- join: sproingie (foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:37:44 PoppaVic: i hate your code!!!!1 :P 07:37:48 its too pretty 07:38:03 heh.. I been at it for decades - forgive me 07:38:45 http://rafb.net/paste/results/YjwnaO95.html 07:39:34 hehe 07:39:44 mine has the function of the file, my name, and a changelog at the top 07:39:55 i try not to comment unless its necessary 07:39:59 (self commenting code, yum) 07:40:33 I got tired of running thru a dozen files with the same sorta' shit in a variety of places 07:41:52 Failed to open /DEV/Metabuilder/usefuls/basic.h for reading: No such file or directory 07:42:04 http://rafb.net/paste/results/SV7ANA84.html 07:42:41 I finally broke down and grabbed lua, btw.. It's organized well, but the code/names don't thrill me 07:42:59 SCREAM? 07:43:46 yeah.. What I often do before I flip off the code and abort/exit/ehatever 07:44:05 Lua is pretty nifty. 07:44:17 what are the arguments? 07:44:31 I dunno' if I'd use it, mad - but I grabbed it for checking 07:45:31 Lua really shows off the power of hash tables and multiple return values. 07:45:52 #define SCREAM__(fp,w,m,fn,l,fu) \ 07:45:52 fprintf((fp), "%s:%u:%s; %s: %s", (fn), (l), (fu), (w), (m)) 07:46:43 FILE( filename, line, funcname, warning, message 07:47:22 obviously, the SCREAM() macro does a load of work for you already 07:47:45 whats FP, W, and M? 07:47:49 so, think "FILE*, what, scream) 07:48:02 example? 07:49:09 { if(!p) { SCREAM(stderr, "Argument", "Can't be NULL); abort(); } ... 07:50:02 ah 07:51:53 All it does is minimize typing and standardize the reporting 08:01:18 PoppaVic: where lua annoys me the most is its use of ONLY floating point. it has no concept of an int 08:01:31 yeah, a shitload of interp do that 08:01:34 PoppaVic: its niche is in games tho, so i can see how that happens 08:01:54 I see they really mess with the idea of "strings", too 08:01:57 it also has a really overly complex notion of an array 08:02:18 huh, what's their hack with strings? 08:02:42 they let you declare one, but to change it, you declare a new one with changes 08:02:47 over & over & over 08:02:53 immutable strings 08:02:57 not uncommon 08:03:01 right 08:03:05 not tasty, though 08:03:08 anyway, the datatypes are not terribly fun, and i'm not too fond of the syntax, but the VM is a nice study 08:03:22 register-based, very fast, small enough to understand easily 08:03:31 yes, their code is also pretty clean (even if the naming and such irks me) 08:03:43 yep 08:03:49 As an example, (at the least), it's pretty 08:04:15 i keep kicking around the notion of a register-based concatenative language 08:04:26 probably impossible for mere humans to express 08:04:32 more of a thought experiment 08:05:06 I'd use a vm 08:05:27 ..circling back to that "this 'cpu' is _portable_" 08:06:41 sure, a vm would be the target 08:07:00 Near as I can tell, with vtables and structs and dlopen+ "modules", adapting to assorted platforms should be fairly easy 08:07:15 just thinking if it's possible to have a concatenative language using registers instead of a stack 08:07:40 i'm starting to think the concepts are inimical 08:07:47 That was mostly why arke's ideas were quite interesting the other day 08:07:55 which, sp? 08:08:42 the whole idea of literals automatically "pushing" 08:08:48 i guess that could translate to "allocate" 08:08:56 I always found forth that fed umpty-args across a fist of funcs to be pretty irksome. I dunno if you can HAVE "enough" regs, in that case 08:08:57 though it would really just be arranging regs into a stack 08:08:57 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 08:09:25 easy enough to impose arbitrary limitations 08:09:32 well, it depends on what you want.. 08:09:34 some forths don't allow you to have more than n items on a stack 08:09:45 where n is sometimes really small 08:10:04 I can well imagine a voc that takes in 'forth' and instead of a colon-def, it generates vm-cpu code. 08:10:31 ia32 would certainly make such a design challenging. again, probably better to target a vm with more virtual regs 08:10:59 I was going to use arrays for stack, and gave it up as Yet ANother Issue that some clown would complain was too big or too small 08:11:08 sure, gforth actually has a register-based vm in its vmgen example code 08:11:15 i don't think the input language is forthlike tho 08:11:20 going to my queue-code made it easier 08:11:58 might be easier to approach the problem from theory 08:12:19 transform a linear combinator system (forth) into a register machine 08:12:20 the prob with gforth, imho, is they tied so DAMNED tight to gcc and worked SO hard at "gee, ain't we fast as hell?" 08:12:34 rf runs circles around gforth 08:12:38 without even really trying 08:12:46 ignoring C would 08:12:55 sproingie: are you talking about a concatenative language actually without a stack? 08:13:04 or just compiling concatenative languages for register machines? 08:13:09 Doesn't thrill me to live in asm, though 08:13:18 tathi: without a stack 08:13:33 tathi: sort of a thought experiment. no idea whether it could be practical 08:13:55 you can't really live w/o a stack and nest, call-down, return 08:14:03 probably not 08:14:12 but it'd be interesting to see how far it could go 08:14:24 I doubt very far - args are Yet Another Issue 08:14:44 i think the lack of knowledge how many args a function takes would be a show stopper 08:15:06 hard to allocate regs when you don't know which ones you can safely clobber 08:15:28 UNLESS you plan to allocate/stock/pass...../destroy an 'object' full of args 08:15:29 could use stack inference, but again that's just mapping a stack onto regs 08:16:14 the idea resurfaced when i was doing a locally factored definition in rf 08:16:38 i thought "i have this variable here, wouldn't it be nice if i could stuff it into a register if i could prove nothing else used it?" 08:16:38 but, the allocate/stock/0:access goto 0/discard mess would prolly chew as much time as a stack would mem 08:17:01 why not use structs? 08:17:26 Same as passing data in & out of a func where you just HATE to use a dozen args 08:17:27 hm. make all functions unary and take and return a single struct? 08:17:40 sure - whatever type(s) they need 08:17:44 would make register allocation fairly straightforward. round-robin. 08:17:51 /need/demand/ 08:18:27 I've done similar for many C funcs 08:18:42 the notion is de rigeur in java 08:18:48 "value objects" 08:18:57 ..I get tired of loooong arg-lists, and just declare a struct we demand 08:19:32 as another interesting effect of putting args into structs, you can get typesafety 08:19:41 and the language becomes more like haskell 08:19:51 a system of combinators mapping types to types 08:19:55 functors 08:21:44 sure, you can get carried away ;-) 08:21:57 * sproingie thrashes about in the turing tarpit 08:22:44 Recall that C already "types" for me, (unless I go insane), so it's mostly a convenience and makes shit so much more clear/readable. 08:24:31 but, something like: WEret* WEfoo(WEret *dst, WEwork *src); is nice to work with 08:26:14 oh.. lua "arrays" - these are 'tables'? I can see the scream 08:27:11 It's like creating a voc and all the overhead for a char** argv 08:28:25 mind you, I often consider these "associative arrays" - but for dynamic, ordered/unordered collections of info 08:29:32 I HAVE been considering something like them for the libTIL/minish stuff. But, to demand their universal use seems a bit extreme 08:35:16 hmm.. I have to wonder if using stackframes integrally would improve matters. 08:38:39 or.. hmph.. The stack is regs/ptrs - and the 'args' are ALL ptrs to dynamic structs. 08:39:13 * PoppaVic sighs 08:39:42 ok, gotta' do some choring... Back in a bit... 08:39:46 --- quit: PoppaVic ("chores") 08:46:11 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 08:58:56 --- join: AlexF (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 08:58:57 --- quit: KB1FYR (Read error: 104 (Connection reset by peer)) 09:04:20 --- quit: tathi ("leaving") 09:04:21 --- quit: AlexF (Read error: 104 (Connection reset by peer)) 09:27:50 --- join: PoppaVic (~pete@0-1pool46-94.nas30.chicago4.il.us.da.qwest.net) joined #forth 09:28:07 back for more punishment 09:29:53 Fun. 09:30:33 well, hell.. Had to get the van up to the shop for lube & checkup At least it ain't 200 degrees in the shade 10:26:47 yikes... Looking at shit about __builtin_* makes hair grow on yer palms and yer eyes melt. 10:34:02 Hmmmmmmmm..... HaIrY PaLmS 10:35:48 Well, after like 3 days+ of searching, I see no neat, clean way to ascertain C stackframes portably. Interesting. 10:36:32 arke: I've even dipped into thinking GCC-specific. 10:37:33 you'd need to write a test.c, and write a tester.c that does gcc -S and parses the output from the former source to learn about stackframes. 10:38:17 At least it doesn't make you grow hair on your eyes. 10:38:19 This means every goddamned arch would need a different parser to learn about it 10:39:05 PoppaVic: I still dont know why you try :) 10:39:21 Persistance and obstinacy 10:39:39 may i inquire your age? 10:39:44 It would be GOOD to know. But, if we can skip it cleanly, rock on 10:39:55 umm.. 2005? makes me 45 10:40:04 Heh. 10:40:22 * PoppaVic forgets his own birthdays 10:40:25 :) 10:40:55 i would if i didnt get presents :) 10:41:23 Hell, we could be in worse shape: some whacked frog in ##C wants to write C via gcc and have a running binary on an OS-less platform with a different arch 10:42:00 Heh 10:42:26 of course, a lot of forthers wanna' ignore the os and libc, too ;-) 10:43:00 ^^ 10:44:25 well, Chuck insists on it as well 10:44:38 ^^ 10:47:20 Given your cpu-VM, I think an "assembler" should be on the agenda ;-) 10:48:07 ..with the portable-cpu idea plus metacompile ;-) 10:51:23 ansi-C "vm+pasm_voc" pasm-expanded local mc|asm; [optional compile local asm] 10:52:20 well, the VM should only be used if JIT can't be done 10:52:22 :) 10:52:24 Anyway, the ideas seem sound 10:52:32 no 10:52:49 JIT means trusting folks to "lay down code" that can't fuck you. 10:53:08 well, note that im not putting failsafes in the VM 10:53:28 crashing is as easy as "0 ccall" 10:53:31 so, either the JIT is ala' colon-word type stuff, or you generate a file which is binary or arch-asm 10:53:42 crashes are np. 10:54:04 imagine all the shit folks could do if asm was interactive and non-paranoid 10:54:44 ..imagine you "must" run some mess as root - and lo & behold - it was a hack to begin with 10:55:05 libs and calls are an excellent abstraction 10:56:25 If they were not, some enterprising goof woulda' hacked up a non-linux/X11 system and shell quite a while ago 10:58:22 JIT is such a vague term anyway, well postdating forth - and I heard it far, far too much in biz 11:05:00 Further, JIT is just not something we want for asm, and it would be too awful to REALLY code for - according to all our talks the last few weeks in here 11:05:23 now, EMULATING asm - with the vm, FINE, 11:28:19 OK, I'm ready to chow and chill awhile... Take care. 11:28:22 --- part: PoppaVic left #forth 11:35:54 Crashes are no problem: signal(SIGSEGV, foobar); :) 11:43:25 --- nick: danniken- -> danniken 12:23:45 ^^ 13:06:36 --- nick: Raystm2 -> nanstm 14:28:04 If we can affect a paradigm shift at the grass roots level this roll out will be optimised 14:51:10 --- join: JasonWoof (~jason@Herkamire.student.supporter.pdpc) joined #forth 14:51:10 --- mode: ChanServ set +o JasonWoof 15:04:18 --- join: madgarden (~madgarden@Toronto-HSE-ppp3708567.sympatico.ca) joined #forth 16:43:17 --- join: crc (crc@pool-70-110-170-228.phil.east.verizon.net) joined #forth 16:44:15 --- mode: ChanServ set +o crc 16:45:04 --- join: jdrake (jdrake@CPE0080c6ead6a9-CM0012254195d6.cpe.net.cable.rogers.com) joined #forth 16:45:24 --- quit: Robert ("You made reality up just to tease me.") 18:49:31 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 19:27:38 --- join: snoopy_16 (snoopy_161@dsl-084-058-134-088.arcor-ip.net) joined #forth 19:35:57 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 19:36:06 --- nick: snoopy_16 -> Snoopy42 20:09:22 --- nick: nanstm -> Raystm2 20:19:07 --- join: alexander_ (~alexander@69.17.112.153) joined #forth 20:19:09 yoh 20:21:49 ola 21:06:37 --- quit: KB1FYR () 22:35:02 --- quit: JasonWoof ("off to bed") 22:54:44 --- quit: sproingie ("Konversation terminated!") 23:41:20 --- quit: jdrake (Read error: 110 (Connection timed out)) 23:59:59 --- log: ended forth/05.07.11