00:00:00 --- log: started forth/05.06.29 00:05:46 --- join: Raystm2_ (~vircuser@adsl-69-149-34-137.dsl.rcsntx.swbell.net) joined #forth 00:07:34 --- quit: Raystm2 (Read error: 131 (Connection reset by peer)) 00:15:43 --- quit: Herkamire ("off to bed") 00:30:25 teh hies 00:33:22 ever compared the speed of some forths with the speed of some bytecode based languages?(perl,java,python) 00:33:50 no.. 00:43:52 i think you would get some very interesting reults though 00:46:30 really? 00:47:57 on my machine: gforth takes 20 ms and perl takes(2nd run) 15 ms for 'helloworld' 00:48:03 yeah 00:48:23 you will probably find one forth is like WAY slower than perl and the next one is just lightning fast 00:48:29 try hellowlrld in retroforth 00:48:43 itll pobably pblow perl clean out of the water 00:48:49 it's not faster 00:54:35 frustrating 00:57:50 really 00:57:52 how fast is it? 00:58:05 and is this the linux nversion? 00:58:26 its the linux version 00:59:18 .... 00:59:23 how are you doing it? 00:59:32 ." HEllo, World!"? 00:59:44 retroforth linux should be MUCH faster 01:00:02 time echo '." Hello World" cr bye' | ./rf 01:00:42 I can't do it directly because retro doesn't support arguments.. 01:01:46 what is the result? 01:02:05 18 ms 01:02:11 iirc 01:02:12 ... 01:02:15 thats quite odd 01:03:36 I do another run 01:05:58 f2@bespin:~/retroforth/linux/bin$ time echo 'print "Hello World"' | perl 01:05:58 Hello World 01:05:58 real 0m0.004s 01:05:58 user 0m0.001s 01:05:58 sys 0m0.003s 01:06:16 f2@bespin:~/retroforth/linux/bin$ time echo '." Hello World" cr bye' | ./rf 01:06:16 RetroForth 8.0 :: Beta Release :: http://www.retroforth.org 01:06:16 Hello World 01:06:16 real 0m0.047s 01:06:16 user 0m0.046s 01:06:18 sys 0m0.000s 01:06:21 wtf 01:07:46 thiss is truly weird 01:09:44 ok, on my centrino 1.5 ghz notebook it takes for perl 0m0.003s(real) and for rf 0m0.009s(real) 01:10:21 better than yours, but its frustrating too. 01:14:32 I think thats the startup time of rf, it takes long, because it doesn't work with bytecodes. 01:16:19 but its faster than python :-) 01:17:26 Hehe. 01:17:30 Perl is a hack 01:17:35 thats why its "fast" 01:17:36 :) 01:17:43 python has a clean codebase, and is a buit slower.. 01:17:47 although even thats faster 01:17:48 so whatever 01:19:14 perl, is a hack, but it works. 01:19:40 I'm really interested in perls longtime speed compared to rf or another forth. 01:20:55 but why do you think perl is a hack? 01:23:03 I'd like really to think that forth is an alternative to C, but that is annoying. 01:25:31 --- quit: ianp (brown.freenode.net irc.freenode.net) 01:25:32 --- quit: arke (brown.freenode.net irc.freenode.net) 01:25:32 --- quit: vitaminmoo (brown.freenode.net irc.freenode.net) 01:25:37 --- quit: virl (brown.freenode.net irc.freenode.net) 01:25:37 --- quit: onetom (brown.freenode.net irc.freenode.net) 01:25:38 --- quit: ccfg (brown.freenode.net irc.freenode.net) 01:26:12 --- quit: swalters (brown.freenode.net irc.freenode.net) 01:26:12 --- quit: cmeme (brown.freenode.net irc.freenode.net) 01:26:32 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 01:26:32 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 01:27:49 --- quit: KB1FYR (brown.freenode.net irc.freenode.net) 01:27:49 --- quit: Snoopy42 (brown.freenode.net irc.freenode.net) 01:28:17 --- join: Snoopy42 (snoopy_161@dsl-084-058-140-059.arcor-ip.net) joined #forth 01:30:26 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 01:30:53 --- join: arke (f2@bespin.org) joined #forth 01:30:54 --- join: ccfg (ccfg@dsl-roigw3de0.dial.inet.fi) joined #forth 01:30:59 --- join: ianp (~ian@inpuj.com) joined #forth 01:31:17 --- join: onetom (~tom@ns.dunasoft.com) joined #forth 01:31:20 --- quit: Snoopy42 (brown.freenode.net irc.freenode.net) 01:32:20 --- join: Snoopy42 (snoopy_161@dsl-084-058-140-059.arcor-ip.net) joined #forth 01:32:20 --- mode: irc.freenode.net set +n 01:36:04 --- join: virl (Phantasus@chello062178085149.1.12.vie.surfer.at) joined #forth 01:36:26 sadly 01:48:00 --- join: Serg[ICQ] (~Miranda@212.34.52.140) joined #forth 01:48:49 --- join: vitaminmoo (~vitaminmo@dsl-94-128.peak.org) joined #forth 01:50:06 hi ! 01:50:06 http://cryptomancer.narod.ru/radio/1regen.htm - old dream came true 01:50:06 text in RU but pics say for themselves 02:17:04 optimizing would be really easy when we would now how fast a command on an intel processor is. 02:19:57 but we never know 02:20:21 because it depends on the cache, the state of the pipeline, which isnt always known, and the time of the month 02:20:51 why the time of the month? 02:23:12 That was a joke 02:23:13 :) 02:23:33 but really, it is INSANELY unpredictable 02:23:50 Modern C compilers compile the code that is fastest in the average case 02:23:55 not what could be the fastest 02:25:24 difficult. 02:26:06 now, heres the thing 02:26:23 implementing things in softwae is always easier than hardware 02:26:45 it is insanely hard to simulate the behaviour in software 02:26:49 they did it in hardware. 02:26:51 catch my drift? 02:27:34 who 'they'? 02:27:59 and which things they implemented in hardware? 02:29:27 intel and AMD 02:29:37 this being timings, and all these weird instructions 02:30:37 it got so hard for them that they even started using a RISC core and an emulation layer 02:30:43 but whatever 02:31:42 they emulated the instruction set? that is somehow sick. 02:35:26 Yes. 02:35:34 You know what the pentium 4 has at the core? 02:35:54 A A processor completely duffernet from the x86 02:36:12 annd then theres hardware on top that translates x86 instructions to that 02:36:20 wanna know why? 02:36:53 in a heavily pipelined system, imagine trying to add an instruction like "lodsd" which loads from memory, polaces in a register, then incremenets another register 02:37:53 it is much easier to just translate this on the fly to "mov eax, [esi]; add/sub esi, 4" 02:38:19 (oh, i forgot to mention, lodsb also can either subtract or add, depending on a CPU flag) 02:38:42 They're trying to keep it legacy compatible 02:38:54 these kinds of instrucions made sense 15, 20, 25 years ago 02:39:01 not today 02:39:06 (done with my rant) 02:39:53 I didn't know that, that the p4 is a RISC processor with an emulation layer. ok thats the reason why it is so fat and consumes so much power. 02:40:57 obh the AMD does the same 02:41:05 in fact, the AMD was the first one to do it 02:43:06 Now, we're not ure why the AMD is better on average 02:43:16 since nobody except AMD knows whats innside 02:43:32 but some people guess that the AMD "subclocks" 02:43:39 or something like that 02:43:43 i dont know the exact word 02:44:12 But I believe it was something along the lines of doing two things in one clock cycle by having two "toicks" 02:44:51 of course, nnobody knows that for ure. 02:47:50 so to optimize something somebody needs to know how long the instructions of the core RISC processor takes, and that is something undocumented, thanks AMD & Intel. 02:48:15 yep 02:48:31 of course, both publish huge guides on how to optimize 02:48:39 the amd optimization guide is very poopular 02:48:47 popular* very funny typo 02:59:45 --- quit: swalters ("User disconnected") 03:00:03 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 03:01:21 --- quit: swalters (Client Quit) 03:01:22 they can't scale this to infinity, can they? 03:01:34 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 03:02:49 they're getting close :) 03:03:38 my hope is that the cell chip will kick this bad design away. 03:12:42 :) 03:31:01 what does nasm mean, when it cries about a not specified operation size? 03:32:14 paste me the line 03:32:29 the line that makes the error, not the error itself 03:32:55 mov [text],35 03:33:46 aah 03:33:55 what size is the data 03:34:02 8bit, 16bit or 32bit? 03:34:35 32bit 03:34:48 but I didn't specified it. 03:34:49 mov [text, dword 35 03:34:59 mov [text], dword 35 03:39:32 and for 16bit or 8bit? 03:40:44 --- part: Serg[ICQ] left #forth 03:41:15 word for 16, byte for 8 03:42:20 --- join: crc2 (crc@pool-70-110-149-209.phil.east.verizon.net) joined #forth 03:42:20 --- quit: crc (Read error: 104 (Connection reset by peer)) 03:52:35 --- quit: madgarden (Read error: 110 (Connection timed out)) 03:59:53 --- quit: crc2 (Read error: 110 (Connection timed out)) 04:00:58 --- quit: vitaminmoo (brown.freenode.net irc.freenode.net) 04:00:58 --- quit: Snoopy42 (brown.freenode.net irc.freenode.net) 04:00:58 --- quit: KB1FYR (brown.freenode.net irc.freenode.net) 04:00:59 --- quit: swalters (brown.freenode.net irc.freenode.net) 04:01:01 --- quit: ccfg (brown.freenode.net irc.freenode.net) 04:01:01 --- quit: arke (brown.freenode.net irc.freenode.net) 04:01:01 --- quit: cmeme (brown.freenode.net irc.freenode.net) 04:01:02 --- quit: onetom (brown.freenode.net irc.freenode.net) 04:01:03 --- quit: ianp (brown.freenode.net irc.freenode.net) 04:01:03 --- quit: Raystm2_ (brown.freenode.net irc.freenode.net) 04:01:03 --- quit: hrmpf (brown.freenode.net irc.freenode.net) 04:01:03 --- quit: warpzero (brown.freenode.net irc.freenode.net) 04:01:32 --- join: warpzero (~warpzero@wza.us) joined #forth 04:01:32 --- join: hrmpf (~obi@gw.mastmoen.no) joined #forth 04:01:32 --- join: Raystm2_ (~vircuser@adsl-69-149-34-137.dsl.rcsntx.swbell.net) joined #forth 04:01:32 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 04:01:32 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 04:01:32 --- join: arke (f2@bespin.org) joined #forth 04:01:32 --- join: ccfg (ccfg@dsl-roigw3de0.dial.inet.fi) joined #forth 04:01:32 --- join: ianp (~ian@inpuj.com) joined #forth 04:01:32 --- join: onetom (~tom@ns.dunasoft.com) joined #forth 04:01:32 --- join: Snoopy42 (snoopy_161@dsl-084-058-140-059.arcor-ip.net) joined #forth 04:01:32 --- join: vitaminmoo (~vitaminmo@dsl-94-128.peak.org) joined #forth 04:01:32 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 04:03:00 --- quit: KB1FYR (brown.freenode.net irc.freenode.net) 04:03:13 --- join: KB1FYR (~Alex@d-66-63-85-222.suscom-maine.net) joined #forth 04:05:45 --- join: crc (crc@pool-70-110-147-187.phil.east.verizon.net) joined #forth 04:11:11 --- quit: KB1FYR (Read error: 110 (Connection timed out)) 04:48:38 arke, what are you doing that you know ia32 assembler? 04:54:58 --- quit: hrmpf ("whatever u do, do it right!") 05:07:42 --- join: PoppaVic (~pete@0-2pool236-130.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:12:01 --- join: Robert__ (~snofs@c-f778e055.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 05:12:38 --- nick: Robert__ -> Robert 06:02:42 --- join: madwork (~madgarden@derby.metrics.com) joined #forth 07:02:05 --- join: sproingie (~chuck@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:03:52 Hi. 07:08:40 heh.. I found an url describing M$ "p-code" formats.. Hillarious. 07:09:06 p-code? 07:09:32 pcode originally meant "pascal code" - but now generally means "portable-code" (token-code) 07:09:59 VB and friends appear to use a form of "stack-machine" ;-) 07:10:42 I'm sorta' mind-fucked today - my sinuses are so hurtful my vision is sorta' blurred.. So, I've been spinning in place and reviewing. 07:11:32 I see no "good" way to handle the C/.o mentality of code/data "segments" for a forthish thang. 07:12:27 It's sure that I can generate code on the fly, but it would end up in the dataseg, and I KNOW the kernel will scream and core if I try to run it. 07:13:17 Since my asm is woefully out-of-date, I am having probs visualizing a clean solution. 07:13:42 Actually, the kernel doesn't really prevent you from that. 07:13:49 And you can always change the permissions. 07:14:15 But the CPU will hate you forever if you mix code and data, and punish you by death (or at least a 90% slowdown of the code). 07:28:29 --- quit: saon ("Lost terminal") 07:30:05 --- join: saon (~saon@c-24-129-91-106.hsd1.fl.comcast.net) joined #forth 07:31:28 Hi, saon, 07:32:10 hey robert 07:32:12 sup? 07:32:32 Bored. 07:32:44 --- quit: swalters (Ping timeout: 14400 seconds) 07:33:42 * saon is losing weekday internet access when school starts 07:33:53 ugh 07:34:02 until first progress report. must be As and Bs =/ 07:34:21 which is lame because i learn more between wikipedia and irc than i do in school 07:34:28 Uhm, why is that? 07:34:34 Evil parents or evil school? 07:34:39 evil parents 07:35:42 if you want to generate code, you can do it on the stack 07:35:59 or generate it in data and copy it to the stack 07:36:59 if you just mix it up willy nilly, it'll be "slow", though still faster than just about anything you interpret 07:37:43 sproingie: me? stack? Heard of it, not what I was hoping for. 07:37:46 this is for x86 ... i suspect it goes double for ppc, but i couldnt say for sure 07:37:54 saon: :( 07:38:07 yes, stack. this is #forth, right? 07:38:17 i thought we liked stacks here :) 07:38:29 saon: In the electronics course I got an A for the digital part, and F at the analog part. ;) 07:39:01 I was reading about trampolining earlier... Not sure I care for the idea. 07:39:33 oh it's a nasty hack in general and doesn't even work on nonexecutable stacks 07:39:36 but it is fast 07:39:47 The only reason I can see for it is deploying ASM... 07:40:10 And, given multiuser/suid environments, it sounds like juggling nitro. 07:40:14 if your whole app is built around trampolining, it's not really a hack anymore 07:40:24 it's just using the stack as a code storage area like any other 07:40:44 trampolining has no extra implications for multiuser than any other code 07:40:53 suid always has nasty implications 07:40:59 robert, i'll probably just use some dialup service 07:41:07 that's good enough for irc and aim 07:41:14 saon: :| 07:41:18 saon: Why did they do that? 07:41:22 suid is actually pretty good in a system where *everything* is setuid, like MOO 07:41:45 i dunno. i failed some classes because i didn't do the homework 07:42:03 but mixing up the concepts is disaster, and it doesnt even work on systems open to outside code, e.g. code you download and run 07:42:11 sproingie: I'd be worried if the final-product was run by aroot, though - suid. I frankly do NOT trust users a whole lot. 07:42:39 PoppaVic: generated code always creates holes, trampolined or not. being on the stack isn't relevant 07:42:54 ..drivin' me nuts - and the lispers want me to read up on lisp to talk with them. 07:43:04 PoppaVic: most of the holes in java have been with the verifier not keeping pace with the JIT 07:43:21 * sproingie has no idea how lisp does it 07:43:41 yeah, it's obtuse and more convoluted than forth - it's a predecessor 07:43:54 saon: Oh. Did you fail because you didn't do the homework, or because you didn't learn enough by not doing the homework? 07:44:01 terms like "closure" make me homicidal. 07:44:02 i find lisp quite elegant. keep an open mind 07:44:19 if you refuse to learn something like closures, you're crippling yourself 07:44:24 robert, in the case of statistics, it was the latter. in the rest, it was the former 07:44:33 i had A test averages in everything but stat 07:44:40 although listening to lispers wax and espouse closures and whatnot makes me pretty homicidal too 07:45:11 don't judge the language by its followers 07:45:27 you could always start with elisp, which has no closures. easier to learn too, since it has all that built in help 07:45:48 Hah. 07:45:57 Well, have fun fighting buerocracy! 07:46:01 * sproingie can pretty easily explain closures in C terms. not forth tho 07:46:07 indeed 07:48:18 try in C 07:48:52 still pretty hard without first-class functions, but i'll try 07:48:58 wait, better idea: lemme recycle the ISP 07:49:02 --- quit: PoppaVic ("Pulls the pin...") 07:51:08 --- join: PoppaVic (~pete@0-3pool196-204.nas30.chicago4.il.us.da.qwest.net) joined #forth 07:51:15 re 07:51:26 back 07:51:26 mmkay, actually just using C is pretty hard 07:51:29 go for it 07:51:43 do you happen to know perl, python, or javascript? 07:52:10 I use to know jscript, the others I've encountered and not much more. 07:52:58 ok, javascript it is. lisp has first-class functions. means you can treat functions as variables 07:53:16 like func-ptrs? 07:53:28 e.g. adder = function(a,b) { return a + b } 07:53:42 adder(1, 2) 07:53:48 hmm, ok 07:54:01 you can also return a new function from a function 07:54:10 ok 07:54:20 like so: function make_adder { return function(a,b) { a + b } } 07:54:31 ahh 07:54:33 adder = make_adder(); adder(1,2) 07:54:38 follow so far? 07:54:46 or, using the 'adder' returned for a new ptr? 07:54:55 yeah, you can think of it like a function pointer 07:55:07 ok, got that 07:55:10 it's important that it's a *different* function each time you call it 07:55:16 it creates a new function and returns it 07:55:22 ahh 07:55:31 this gets important, and you'll see why in a sec 07:55:35 like a creator-word 07:55:38 exactly 07:55:41 ..and acting like a macro 07:56:05 but you get a neat trick with these functions. the "inner" function can remember variables in outer scopes 07:56:08 i'll show you what i mean 07:56:23 ahhh 07:56:28 function make_adder(a) { return function(b) { a + b } } 07:56:46 add2 = make_adder(2); add2(3) => 5 07:56:58 add10 = make_adder(10); add10(3) = 13 07:56:59 ahhhhaaa! 07:57:09 it makes vtables near trivial 07:57:12 yes it does 07:57:30 in fact, javascript actually uses static closures for objects 07:57:32 "ahh so, weedhopper" 07:57:47 that schmuck is what they call "closures"?? 07:57:50 that particular trick is called currying 07:57:55 ahhhh 07:58:31 it's caled a closure, because the inner function's variable bindings are the transitive closure of its inner bindings and all the other bindings in static scope (or in some cases dynamic) 07:58:39 basically, it's a CS term 07:59:01 Yeah, I can see that - "transitive closure" nearly made my head explode 07:59:27 the neat thing about closures in every language except python, is that you can actually write to the outer states as well like they were just another variable 07:59:35 in python they're read-only 07:59:43 how's this useful? watch 07:59:45 hmm, wait 08:00:17 yer suggesting far beyond the typical outer-scope as r/w, correct? 08:00:43 not sure what you mean 08:00:55 i'll give you the usual example 08:01:01 function make_counter(start) { count = start; start return function{ count = count + 1; return count } } 08:01:25 every time you call the function that make_counter gives you, it increments count by one and returns it 08:01:38 the neat thing is, each function you get back has its own copy of count 08:02:03 what the heck is start? 08:02:06 * sproingie probably didn't need to copy start into another variable, but some languages do funny things with parameter bindings 08:02:09 it's the starting value 08:02:12 oh, a fptr 08:02:17 ohhhh 08:02:18 it works like this: 08:02:49 the first line with "; start return.." mucked me 08:02:51 c1 =make_counter(0); c1() => 1; c1() => 2; c1 => 3 .. 08:02:56 oops 08:02:58 that was a typo 08:03:05 s'ok 08:03:05 function make_counter(start) { count = start; return function{ count = count + 1; return count } } 08:03:16 ahh 08:03:49 this is kinda bugged since it actually starts counting at 1 + the start value, but you can see how to fix that 08:04:07 now here's the neat thing. each function gets its own copy of start 08:04:41 c1 = make_counter(10); c2 = make_counter(50); c1 => 11; c1 => 12; c2 => 51; c2 => 52 08:05:15 er, s/start/count/, since that's what i'm using 08:05:36 a full copy of the func? or the start var? 08:05:46 its own copy of the func and all the variables it uses 08:05:52 including count 08:06:19 think of it like an object, and count is instance data for that object 08:06:23 ahhh-HA! This is like the ancient forth macro/end-macro thing, sans the 'count' 08:06:33 ahhh 08:06:50 in fact, objects *are* just static closures in javascript 08:07:01 javascript just adds some syntax sugar on top 08:07:08 so, envision an object - with a var - and the code is a macro? 08:07:26 yeah it's a bit like a macro, but there's no macro expansion going on per se 08:07:46 anyway, that's closures in a nutshell 08:08:00 well, in forth I've seen it either treated as a pure macro, or as an eval() type thing. 08:08:19 well forth has no real concept of scope, so you can't really do closures 08:08:28 so why is this a "closure"? 08:08:54 closures use the scope of variables. basically they remember all the variables in their scope, and get their own copies of them 08:09:08 yes, I've noted for years forth lacks 'scope' 08:09:14 make_counter() isn't the closure, the closure is what make_counter returns 08:09:57 basically a closure is a function that remembers what was in scope when it was created 08:10:10 --- join: Herkamire (~jason@Herkamire.student.supporter.pdpc) joined #forth 08:10:10 --- mode: ChanServ set +o Herkamire 08:10:15 and it's returning a new function, (using an old pattern), is it not? 08:10:22 yep 08:10:28 hmm. 08:11:03 well, it's NOT remembering other "in scope" vars, right? Just whatever it needed to operate? 08:11:35 just the variables it actually uses 08:11:54 riiight... Lemme' chew this for a bit 08:11:59 there's "dynamically scoped" closures that more or less remember everything, but those are rare and you don't see them anymore 08:12:58 lisp, scheme, and javascript only do static closures now (sometimes called lexical closures) 08:13:08 which are the kind I was using 08:14:58 just mentioning them because you'll sometimes hear lisp old-timers talking about dynamic closures 08:15:02 what is a "lexical closure"? 08:15:43 it's a closure, the kind I was using. in technical terms, they close over their lexical scope, which is all the variables that the compiler can see in the scope around the function 08:15:55 as opposed to dynamic, which is all the variables that exist at the time the function is called 08:15:56 ahhhh 08:16:21 ahhHAA! 08:16:39 That's gotta' be weird to manage 08:16:53 it is. dynamic scope can bend your brain pretty good 08:17:05 lisp used to use closures for OO-type stuff. scheme still does. 08:17:13 lisp mostly uses CLOS now 08:17:17 ok, I think I follow "closure" better, thankyou. 08:17:34 no prob :) 08:18:02 How would lisp deal with saving compiled files and loading them? Implementation issue? 08:18:12 lisp is usually image based 08:18:27 tho most lisps these days support compiled lisp files 08:18:28 ahhh, so I thought - I was getting static from Z 08:18:32 called FASL or something like that 08:18:58 So, the idea of .o/.a/.so & such goes right past them. 08:19:00 fasl's are implementation specific, compiling in general is 08:19:25 lispers hate linker .o files and company about as much as forthers do 08:19:38 yeah, I've gotten that impression 08:19:44 pretty sad 08:19:50 naw, .o is pretty sad 08:20:01 i mean ELF is ok for C, but it's showing its age 08:20:58 this is why I said "sad". A std relocatable-object format, and lib, is still a "good thing" - or we might as well return to cp/m and .com for it all. 08:21:27 tho linux's elf linker apparently lets you commit all kinds of abuse. coldstore had no problems rewriting the elf symbol table while another process had it dlopened 08:21:38 so i guess it's not so much the format that needs to evolve as much as the linker 08:22:12 Yeah, and the worst of it seems to be: there is no 'libo' to use in generating a .o 08:22:29 generating or USING, I should say 08:22:31 well, there's libelf 08:22:49 that's a third party lib that lets you munge elf sectons 08:23:01 for linux, sure - macosx doesn't use it. There is really no portable system. 08:23:16 I watch these things and follow trends vicariously. 08:23:30 libbfd is part of gcc that does some .o manipulation too 08:23:38 osx uses mach's linker format 08:23:44 presumably there's tools to mess with that as well 08:24:08 not sure how robust osx will be if those tools get used 08:25:16 linkers are in general a pain in the ass. elf supports using linkers other than ld.so, but i've never seen a system successfully mix them 08:25:38 i don't think you can run a ld.so elf file that links in libs that specify a different linker, for example 08:25:46 that needs to change if linkers are to evolve 08:25:49 yep 08:26:11 it's like similar issues with libtool and autoshit 08:26:23 libtool is an abomination that must be destroyed 08:26:39 automake must be exorcised from this dimension 08:26:43 autoconf isn't too bad 08:26:44 OK.. (I agree) I think I'm back in the saddle, and appreciate the help... 08:27:13 no prob. ok, gotta get going meself. 08:27:16 The kicker seems to be: hey, fine: you extended the binary - now exit and restart. Big Deal 08:27:31 np, I appreciate the time and conversation. 08:31:22 --- nick: Raystm2_ -> nanstm 08:32:14 fie on linkers! 08:32:53 not really, but I can understand the screams of pain 08:34:33 I'm suprised that, in all these years, no forth I know (or is freeware) has bothered to work up a linker/loader voc for at least elf. 08:44:29 plenty of forths have functionality for elf. they're called compilers :) 08:45:49 --- join: hrmpf (~obi@gw.mastmoen.no) joined #forth 08:45:50 tho i don't know of any freeware forths that do fully native compilation 08:46:02 hehe 08:46:20 This was my point, and I was thinking generate/load/link 08:46:35 yeah, that's what a native code compiler does 08:46:51 sure, but why must it be "native code"? 08:47:04 that's what .o is all about 08:47:34 not entirely 08:47:44 and elf is structured around that. technically you could pack a shell script in an elf format, but what would be the point? 08:48:02 relocatable-object: it could be data, colon-words, token-threaded, etc. 08:48:32 all that is just data as far as the cpu is concerned 08:48:47 no, unfortunately 08:48:49 cpu only cares about code and data 08:49:09 last I read, the .o is 'segmented' and screams when code is in the data-seg 08:49:33 Further, the .o is a file-format that requires a linker 08:49:41 .o doesn't have sections at all 08:49:47 ..and no forth encompasses that linker 08:49:57 .o lacks the sections?????? 08:50:10 er, i guess it must 08:50:16 I've never seen a .o breakout 08:50:24 it must, though 08:50:24 oh right, the linker assembles them and merges all the sections 08:50:35 and connects unresolved symbols together between .o files 08:50:41 right 08:50:57 relocates, etc. pretty tricky job 08:51:25 elf makes it pretty simple because it keeps a register pointing to the library offset all the time 08:51:31 yep, last I tried to read of .o format, I screamed and ran - but that was in my DOS days. We need a r/w libelf. 08:51:37 change libraries, just change the register 08:51:41 sproingie: you don't know of an open source forth that compiles to machine code? 08:51:48 yeah, that would help - like ancient .com 08:51:49 Herkamire: nope 08:52:03 half the forths I know of do it that way 08:52:09 .com is about as simple as it gets 08:52:14 I found an f2c.tar.gz, but haven't delved 08:52:15 3 people from this channel have their own 08:52:30 me: herkforth crc: retroforth I440r: isforth 08:52:47 none of those statically compile a standalone exe 08:52:49 I don't know that direct-compiled forth is any boon 08:52:57 mine's for ppc, the other two x86 08:53:02 let alone objects? 08:53:12 mine does 08:53:23 ah, there ya go 08:53:23 if I understand what that means 08:53:47 mine creates a binary in memory, with an elf header and everything, and writes it to a file 08:53:47 r/w of external object files? Linking to whatever or the runtime program? 08:53:51 direct threaded forth is probably pretty simple to compile to a standalone exe 08:53:52 (or it can do a mach-o header for osx) 08:54:13 rf is subroutine threaded, so a .exe would effectively compile the interpreter in as well 08:54:21 I don't do any linking though 08:54:38 Herkamire: I swear, I've got to read yer code, but damnit.. between this headache and all the demands on my attention, I'm running short. 08:54:39 forth sort of defies simple symbol tables 08:54:46 you probably don't want a symbol for each word 08:55:07 I never really wanted a symbol for anything 08:55:29 although from time to time I have an interest in linking to SDL 08:55:31 need 'em for linking. basically you'd just need an export table 08:55:38 yep 08:55:46 yeah, I never liked linking 08:55:51