00:00:00 --- log: started forth/05.09.23 00:20:19 Ok. Formatted & cleaned up, all the text files (resource.h, hello.rcp, hello.c, and Makefile) fit on 4 pages. 00:20:55 Is that any more than 1 line? ;) 00:21:30 Well, let's see. One for the filename/comment, one blank, two for the definition (why not), one more blank, one for the MakePRC line. That'd be six. 00:21:56 hehe 00:22:04 Extavagance! ;) 00:22:04 If I want the menu & about box, it ramps up a few lines. 00:23:11 (extravagance) 00:28:58 #asm is a bit presumptuous. They seem to think that asm coding is always on a x86 from the topic ;) 00:29:16 I suppose the lion's share of it is. 00:30:41 I just thought that in a way it is ironic. Of all the platforms that for the majority of tasks dont need going near asm, x86 is it 00:32:54 It would only be newer x86 instructions and embedded processors that asm would be needed for wouldnt it? 00:33:05 I don't quite understand. 00:33:20 What you mean, that is. 00:34:18 Hand-coded assembler can still sometimes take you closer to the metal than even the best optimizing compiler, though they're pretty good these days. 00:34:36 I was trying to think of legitimate reasons for coding in asm (if you arent just leanring) 00:37:45 The need for speed, I guess. Anyway I'm off. 00:37:54 enjoy! 01:09:10 --- join: amca_ (n=plump@as-bri-2-49.ozonline.com.au) joined #forth 01:12:49 --- quit: amca (Nick collision from services.) 01:13:13 --- nick: amca_ -> amca 03:00:28 --- quit: madgarden (Read error: 113 (No route to host)) 03:09:20 --- quit: amca ("d34d") 05:06:29 --- join: aardvarx (n=folajimi@shell4.sea5.speakeasy.net) joined #forth 05:08:10 Morning, all. 05:10:17 --- join: madgarden (n=madgarde@Kitchener-HSE-ppp3577624.sympatico.ca) joined #forth 05:44:06 --- quit: saon ("Lost terminal") 05:58:17 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 05:58:53 --- quit: saon (Client Quit) 06:01:18 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 06:15:31 morning aardvarx :) 06:17:43 :) 06:34:40 --- join: PoppaVic (n=pete@0-1pool67-80.nas22.chicago4.il.us.da.qwest.net) joined #forth 06:35:00 Yo ho-ho. 06:36:46 I got your message yesterday. 06:36:52 ahh? 06:37:01 Which msg? 06:37:41 10:47:03 aardvarx: intsead of commenting about my writing a book and such, perhaps yer "Q:" is better served with specific issues or questions? I'm not sure how to A: such stuff in ways other than those bordering on the rude. 06:40:03 The suggested actions were gleaned from comments in the channel shortly after you left; the idea was not to heckle/troll. 06:40:19 hidy-ho PoppaVic 06:48:11 --- quit: PoppaVic (Nick collision from services.) 06:48:22 --- join: PoppaVic (n=pete@0-2pool236-124.nas22.chicago4.il.us.da.qwest.net) joined #forth 06:48:36 goddamned isp keeps dropping off 06:48:46 What were you saying, aardvarx ? 06:49:02 The suggested actions were gleaned from comments in the channel shortly after you left; the idea was not to heckle/troll. 06:49:14 um, ok 06:49:57 10:47:03 aardvarx: intsead of commenting about my 06:49:57 writing a book and such, perhaps yer "Q:" is better served 06:49:57 with specific issues or questions? I'm not sure how to A: 06:49:58 such stuff in ways other than those bordering on the rude. 06:50:07 eeew! 06:50:12 ahh 06:50:14 That came out wrong! 06:50:52 10:47:03 aardvarx: intsead of commenting about my writing a book and such, perhaps yer "Q:" is better served with specific issues or questions? I'm not sure how to A: such stuff in ways other than those bordering on the rude. 06:50:59 There. Much better. 06:51:13 S'ok 06:51:28 * PoppaVic wonders what it all means... "What is Life?" 06:52:25 Well, most of what you say sounds like greek to me. I just thought that having a context would help. 06:52:33 right. 06:52:35 I can't tell whether you're coming or going. 06:52:41 Contexts always help. 06:54:52 I cannot ask specific (but relevant) questions without having a _roadmap_ 06:55:09 Yeppers. I'm just about ready to begin one. 06:55:30 I still lack a good "concept" for strings and io 'layers'. 06:55:42 Quartus, ping. 06:56:19 PoppaVic, I have no idea what you're talking about :P 06:56:52 aardvarx: it ain't difficult... I am considering the vm as built in layers, not a shitpile of disorganized fluff. 06:57:15 oh -- PoppaVic, you missed my 'hidy-ho' due to isp :( 06:57:30 So, I consider a "string" as a distinct struct/object, and not 100% needed for all purposes. And, IO is another such layer. 06:57:40 hi Ray_work ;-) Bad day with the isp, my apologies. 06:57:46 PoppaVic, how many layers do you have at the moment? 06:58:11 not your fault, no appology necessary :) 06:58:13 core is flow/some FFI, and single-precision/gymnastics 06:58:33 doubles are like long-longs; and reals are C "doubles" 06:58:54 To date, those are the layers I am considering. 06:59:11 Hold it. 06:59:24 Define *Core* 06:59:46 hold on... 07:00:09 http://rafb.net/paste/results/SkOIQm16.html 07:00:42 As I said: flow/machine/stepping/ffi and the essentials of gymnastics and single-precision numbers. 07:01:35 This file is what I (so far) consider *THE* "core" wordset (opcodes) 07:02:07 I see. 07:02:09 lines 40-43 are really, really tentative. 07:04:03 I see 40..43 as "structured flow", and MAYBE useful; and lines 34..38 as unstructured (dangerous), but very flexible. 07:05:40 So, there are three layers so far, correct? 07:06:05 Right. Or, "three sets of opcodes". 07:06:38 1. Core (including single precision) 07:06:46 2. Doubles 07:06:50 3. Reals 07:07:12 right 07:07:51 #3 is currently considered as automagically requiring #2, but I believe it might be a mistake to do so. 07:08:16 because I can envision a guy coding in FP exclusively. 07:08:29 I'm afraid I don't know any more than you do at this point. Quartus may be the one to answer that. 07:08:34 (It'd be dumb, but it would also be compact) 07:08:48 FP == floating point, right? 07:09:24 aardvarx: right. NOW.. Consider "strings" and "input-output"... You can now begin to see why I'm stalled/stalling/tinkering. 07:10:12 Well, you are going from arithmetic to the netherworld of characters, right? 07:10:36 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 07:10:37 If that is the case, I don't see how you can make the transition between both. 07:10:44 tathi, tathi !!! 07:10:54 Not really. I've long considered that we should not be exposing a "string" as discrete subunits. 07:10:54 So nice to see you, tathi! 07:11:06 hi tathi 07:11:22 I feel so welcomed :) 07:11:24 hi all 07:11:48 tathi: well, yer company is appreciated - and aardvarx is enthusiastic ;-) 07:12:04 PoppaVic, pose your problem to tathi; perhaps you might gain more insight. 07:12:44 * tathi finally spent some time learning about Factor yesterday. Interesting system. 07:12:45 aardvarx: ok, but he's seen it before (I am sure), and quite probably been considering in his own ways and projects. 07:13:05 * Ray_work ( side note, mainly for myself, thinking about implimenting Rational Trig with Tractenberg math in colorforth . 07:13:22 tathi: consider a near-opaque "string" type. What should we consider for operations? Same with "io" 07:15:25 hmm 07:15:57 is there a need to parse the text, cut it up like a list and take slices? 07:16:09 most languages implement approximately the same set, I think. 07:16:23 Ray_work: come again? 07:16:52 Ray_work: you mean for "strings"? 07:16:57 sorry sub string for text yes 07:17:03 :( 07:17:07 I'm not sure I've done enough string stuff to list it off the top of my head though. 07:17:11 for I am a bone head today. 07:17:18 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:17:36 hi sproingie 07:17:41 hmm, well the basic opcodes would be strictly handling, copying, regx, searching, etc. (ie: still no terminal i/o) 07:17:48 hi sproingie 07:18:10 Yeah. 07:18:45 I've always felt C had the right idea, then lost track and got messy and stupid. 07:18:49 hi all 07:18:59 PoppaVic, is the CORE on the wiki? 07:19:07 sproingie, good day. 07:19:09 mmm intriguing. where did C go wrong? 07:19:21 aardvarx: I can post a tarball today, if you like. 07:19:29 Very well. 07:19:46 arguably va_args is perhaps one area it went wrong. something that underspecified in a system programming language doesn't belong 07:20:01 sproingie: I think they began with the ol' KISS-principle, and then added things too similar to other things, and then screwed life with regex and whatnot. 07:20:19 C added regex? 07:20:55 there is a libc regex-support, but afaik they never matched even things as "simple" (core) as "grep" 07:21:04 since when is libc the C language? 07:21:17 libc is the crap that went into unix 07:21:26 sproingie: I'm talking about "strings and operations/opcodes" 07:21:34 which i suppose is hard to separate from C since C was written to port unix 07:21:53 the inital screwup is that there is no "string type" 07:21:57 strings ... what strings? 07:22:03 PoppaVic, will this be a separate layer? 07:22:04 exactly 07:22:09 it's a shame pascal was always so mistreated 07:22:18 a lot of C's sins have never been borne by pascal 07:22:31 aardvarx: sure, added only if you NEED strings or demand something that itself needs strings. 07:22:44 buffer overruns? you could have made the length field a range value 07:22:49 strings? got 'em 07:22:58 sproingie: I worked in pascal for a few years, and yeah - it had some oddities, but I never hated it. 07:23:17 pascal's syntax isn't always the best, but frankly neither is C's 07:23:24 agreed 07:23:34 PoppaVic: did you ever meet Karel the Robot in your pascal days? 07:23:35 I even tried modula-2, one year 07:23:47 write-once run-anywhere bytecode? pascal. 07:23:54 Ray_work: nah, I was learning to program and beat on my cp/m system 07:24:05 :) 07:24:16 sproingie: yah, except TP didn't bytecode - it compiled. 07:24:42 most did, but UCSD Pascal was the first mainstream language to compile to bytecode 07:24:54 as mainstream as languages got then 07:24:54 yah, sounds familiar 07:26:01 i think pascal just lacked some stuff that systems programming really needed 07:26:09 like bitfields in structs 07:26:26 aardvarx: the kick with this project of mine is to underlay forth, ride atop C - and come up with the "layers" of bytecode-ops to support nearly any insanity from ANS-forth to - well, we don't care. 07:26:34 right. 07:26:57 I've always preferred bitfields over masking-voodo 07:27:19 * sproingie switches his system font to tahoma and wonders why on earth anyone would use it. maybe i don't have the subpixel hinter working properly 07:27:42 looks decent on windows. looks like ass on ubuntu 07:29:19 PoppaVic, I think I might need a picture to understand what you just said. 07:29:28 However, that can probably wait. 07:29:37 aardvarx: boy, do I understand THAT feeling! ;-) 07:31:20 Anyway, back to core... 07:31:26 aardvarx: Try thinking of it this way... This engine/vm rides atop C as portable as possible. We emulate an idealizes stack-based CPU. We write "modules" supporting more and more different 'types' 07:31:43 "idealized" 07:32:04 I had it reversed. 07:32:20 I thought Forth was closer to the metal. 07:32:22 Folks can use it to write "a forth" or they can write "a pascal" - or whatever. 07:32:54 aardvarx: yes, on the whole - looking over the spectrum of Forths, they are. We want to climb above it. 07:33:19 --- join: JasonWoof (n=jason@c-24-218-59-196.hsd1.ma.comcast.net) joined #forth 07:33:19 --- mode: ChanServ set +o JasonWoof 07:33:21 C is actually closer to the metal. 07:33:26 JasonWoof, HEY!!! 07:33:45 Now, mind you: nothing sez a guy or team could not recompile the bytecode to HIT the metal. 07:33:54 hi JasonWoof 07:34:30 Why do you need the engine, then? Why not just use C for everything? 07:34:40 aardvarx: indeed, they might want to "optimize" the bytecode and THEN recompile it. - or optimize asm-from-byte-code and optimize that. 07:35:11 aardvarx: you ever write an interpreter, let alone a compiler, let alone an extensible interp/compiler? 07:35:31 Answer to all questions: no. 07:35:45 C is probably not closer to the metal than forth 07:35:52 ..It's a tedious and paiful chore nor for the faint-hearted, so: why not write a single layer/tool that you CAN use to do the schlock? 07:36:36 Too much information at once. 07:36:40 Trust me, aardvarx - you write enough interpreters and parsers over the years, you just get fed the fuck up. 07:37:02 forth is more like BCPL than C. BCPL was also untyped, it only had "cells" 07:37:11 I always liked forths; I always liked C - and they never seemed to play-well-together. 07:37:28 sproingie: I'll but that. 07:37:30 buy 07:37:35 Back to core... explain (slowly) what you mean by "flow/machine/stepping/ffi and the essentials of gymnastics..." 07:38:22 i'd say with forth and bare metal, it depends on which forth you use 07:38:23 I understand that *core* is a bunch of primary opcodes. 07:38:58 retroforth is definitely more bare-metal than C. you usually get a good understanding of exactly what asm is coming out of each primitive op 07:38:59 PoppaVic, what did you mean by "flow/machine/stepping/ffi"? 07:39:40 sproingie, if that is the case, shouldn't the model proposed by PoppaVic be reversed? 07:39:58 flow-control, machine-special (altering vm), stepping thru the pcode, and ffi outside the vm-universe. 07:40:22 right, sproingie 07:40:41 aardvarx: the map isn't the territory. either layer can produce raw instructions and access main memory, so it doesn't matter which one he prefers 07:40:49 aardvarx: you've got to keep in mind the basic premise of "Using C as a 'portable assembler'" 07:40:53 aardvarx: ultimately the end product is what he's aiming at 07:41:16 C is a lousy portable assembler. way too much policy. 07:41:39 right. And, the fact that we can then write a tool in ANY language to really, truly write asm or assemble-direct - based on the pcode. 07:42:25 sproingie: I agree, and I tried to broach that with folks... Everyone in every channel acted like I was a plague-ridden heretic and dropped it. 07:42:38 PoppaVic, machine-special? Do you mean machine-specific opcodes? If so, what are those for? 07:43:09 aardvarx: strictly related to changing/altering the vm in a consistent way. 07:43:35 see allotX and altTable 07:44:12 then consider lines 25..26 07:44:59 When you say, "*altering* the VM..." does this affect how it operates, or is it just cosmetic? 07:45:19 aardvarx: now, please bear in mind thru ALL of this: these are simple 'opcodes' - there is still a function-pointer used.. "pointer" is the important term. 07:45:31 PoppaVic: i suspect you'd have found a sympathetic ear in #haskell, which has both C and C-- backends. I imagine the C-- folks prefer it far above C 07:45:35 there is no "cosmetic" down here. 07:46:25 tho i suspect the C-- "folks" is probably just Simon, who I don't think does IRC 07:46:35 that's why he gets work done on haskell :) 07:46:42 C-- is a language? 07:46:43 sproingie: could be, the #asm folks just stared and got insulting and peeved; the ##C folks were not interested; and C-- looked like (to me) they had little to stand on. 07:46:54 yeah 07:47:12 FFI? 07:47:21 aardvarx: unfortunately, what I saw at their 'home' suggested they are writing for doze. 07:47:44 or "for sale" or something... I recall I gave up on it. 07:47:46 well, casting aspersions on C's suitability to a task probably isn't the most genial subject for #C 07:47:48 Well, keep moving then! 07:47:59 :P 07:48:01 foreign-function-interface 07:48:14 C-- works perfectly well on *nix 07:48:22 sproingie: oh, my no - the lispers and C++ wouldcheer and rally. 07:48:31 LLVM looks a bit more interesting to me, but it has vastly different goals than C-- 07:48:57 sproingie: I had to give up on it, the whole thing looked like it was mostly overcomplicating C. 07:49:10 yeah, I recall LLVM 07:49:16 C-- is for writing runtimes. LLVM is one. 07:49:35 C-- hardly overcomplicates C, it in fact simplifies it 07:50:11 this is why I decided on a forthish "engine" - we can do more and extensibly, all we need is a lower-level of organization. 07:50:20 of course its best compiler is in ocaml, so that sort of bloats your toolchain, but you only need it to build the compiler itself 07:50:22 HALT! 07:50:50 yeah, I don't want to learn ocaml atop the rest of the crap. 07:50:54 you don't have to 07:51:01 This *IS* important! Is that the primary reason for using Forth? 07:51:03 just build the compiler with it 07:51:17 aardvarx: which? what? State it first. 07:51:50 "this is why I decided on a forthish "engine" - we can do more and extensibly, all we need is a lower-level of organization" 07:51:56 i don't know what haskell uses to turn its C-- backend into native. it might have a compiler in haskell 07:51:59 right. 07:52:01 you probably want to learn haskell even less 07:52:07 YOu got it, aardvarx 07:52:58 sproingie: and, those tools would always be 2ndry installs. gcc/C is almost always installed everywhere, w/o further ado 07:53:16 sure, but you said yourself that it's crap 07:53:43 certainly nothing wrong with forth as a backend, though it would be tricky to turn into really good native code 07:53:50 No, I said it wasn't a perfect "portable assembler" - but for a VM,we don't care. 07:54:15 unless that native code was for a pure stack machine of course, like an ignite chip or a java vm 07:54:23 PoppaVic: oh you're targeting bytecode? 07:54:24 yeah. Turning the pcode into local asm or mc would be interesting. 07:54:30 yes 07:54:34 i thought you were targeting native 07:54:42 screw using C then 07:54:42 oh, my no. 07:54:55 heh, I think in C, dude 07:54:58 using C would be totally pointless 07:55:17 if your VM is stack-based, forth would make a great IL 07:55:27 Hey, once we get a "system", we can rewrite in whatever. 07:55:28 in fact gforth has vmgen for that sort of thing 07:55:42 IL - intermediate language? yes 07:56:02 there's a register machine example for vmgen too, but i never looked that close at it 07:56:25 yeah, vmgen looked pretty weird to me, but sure - I use gforth daily. 07:56:57 --- join: ccfg (n=ccfg@dsl-roigw3a42.dial.inet.fi) joined #forth 07:57:06 I think my prob with gforth is STILL that they really work on "optimizing" and "configuring" and then fall down some on docs. 07:57:25 gforth's docs are egregiously bad 07:57:57 it seems an excellent forth. not as fast as bigforth, but a hell of a lot more stable 07:57:58 I want to avoid every possible gcc "attribute" and completely ignore the cpu (except as in sizes/order) 07:58:11 PoppaVic, pcode == Primitive opCODE? 07:58:17 yeah, tinkering in gforth is fun.. Far more so than bash 07:58:42 aardvarx: pcode == bytecode 07:58:49 aardvarx: pcode := bytecode := "intermediate code" - Synthetic-assembler. 07:58:54 pcode is an old term from the ucsd pascal days 07:59:04 yeah, it dates me 07:59:05 the P stood for Pascal 07:59:10 right 07:59:20 or, think of it as "portable code" 07:59:30 C <- pcode <- Forth VM ? 07:59:32 ah, "portable" is probably actually what it stood for 07:59:41 maybe we can call it "bcode" nowadays 07:59:47 Bare Metal <- C ? 07:59:59 Bare Metal <- C <- pcode <- Forth VM ? 08:00:15 C\vm\pcode\[any languages] 08:00:17 no point in doing pcode to C 08:00:33 pcode to bare metal is well-understood and not that hard to do 08:00:52 O_o 08:00:56 I refuse, 100%, writing assembler 08:00:57 But... 08:01:00 every JIT compiler does it 08:01:06 and any serious VM has a JIT 08:01:23 pcode is higher than the VM; how can it be close to the metal? 08:01:26 That's nice, and I'm not writing an assembler. 08:02:04 pcode IS the VM ... it's the code the VM runs, anyway 08:02:10 aardvarx: easy: take a pcode-image... Convert it to local asm-source... Assemble it. 08:02:30 all the "parsing" is already done for the convertor 08:02:34 JIT is something you can do piecemeal 08:02:45 compiling to C you have to do pretty much all at once 08:03:25 if you do your so-called "JIT" ahead of time and cache it away somewhere, you have the basic model of .NET 08:03:28 morning aardvarx, PoppaVic 08:04:09 well, I fixed the bug that had me stumped yesterday, and now I'm stumped on the next one 08:04:12 that's where .NET just kills java. java spends so much effort analyzing and compiling the bytecode at runtime ... and throws it away every time it exits 08:05:14 that and assemblies have far cooler metadata features than the hack that is .jar 08:05:18 --- nick: tattrdkat -> virsys 08:05:20 yep, and .NET is not your friend either.. But, we do all agree there advantages to pcode/bytecode. 08:05:50 or should i say .jar .war .ear etc 08:06:06 i think j2ee recently metastisized a few more .?ar file formats 08:06:07 no idea - never suffer it deliberately 08:06:30 Why the hell would they NEED all those files?? 08:06:42 with .net, they just rev the schema for assemblies in some backward compatible way and the assembly cache understands it 08:06:55 PoppaVic: because java has no real concept of "a container of jars" 08:07:04 ugh. Idiots. 08:08:06 --- nick: Raystm2 -> nanstm 08:09:03 i'm sure if they gave it such a concept, you'd have to write a 300-line "archive descriptor" xml file to manage it 08:09:23 to be fair, that is exactly how .NET does assemblies, but it's more or less transparent 08:09:37 heheheheha! btw, I've back-burned the idea of stack-typing. 08:09:56 I'll never embrace XML as world-savior. 08:10:10 it makes sense for this case, it's a very hierarchical config file 08:10:28 sounds like piss-poor-planning 08:10:30 i prefer yaml for quick and dirty structured data 08:10:48 but all yaml tools i've seen are nasty unstable hacks, so i have to pull out xml when i need it to be solid 08:11:10 I've heard of several formats for config, but I often think folks try to treat a config as a precompiler 08:11:49 ..and, then they top it off by wanting weird internal tables/lookup 08:12:05 ..even weird "relationships" 08:12:17 can't blame them, when they language they're using isn't sufficiently declarative itself 08:12:28 could be 08:12:31 they yearn to move all that declarative logic into the config file 08:13:00 I always find myself using either straight-text/columnized or ancient text-style INI files. 08:13:24 KISS is a wonderful principle. 08:14:11 sproingie: I suspect those same folks also yearn for "all numbers are reals and all strings are unicode" 08:15:03 i'm all for the latter. actually strings and numbers should be polymorphic 08:15:13 in other words: they want a universally-useful, flexible, hand-holding language and files. 08:15:13 scheme does a nice job with numbers. perl and python do all right with strings 08:15:42 python does what it can to make unicode confusing and scary. in perl you hardly even notice unicode 08:15:57 sproingie: If I can come up with a way to do so for strings and numbers, I'd be fine with it. But, I think we need to lower-layers before we get there. 08:16:36 sproingie: and, mind you: opaque-types don't bother me, when well written. 08:16:49 unlike C++'s std::string 08:16:56 ewwww 08:17:13 there's a msdn blog that goes into great detail about how much std::string sucks 08:18:13 well, look at single, double and FP precision-numbers and forthish... There are some intersections, but not UNIVERSAL unity. And, it's the same with strings. 08:19:56 Now, to be honest, I'd also considered making doubles.h and reals.h reflect the single-precision core.. I see no real problem with opcodes that do nothing but scream to stderr and otherwise NOP. Folks trying to bit-bash FP's _need_ a slap 08:20:47 just curious, you designing a new language on top of this? 08:24:58 prolly.. with roots in forth 08:25:51 Idon't want it "unapproachable", but I do end up needing an extensible, interpretive-compiler for my own use anyway. 08:26:47 sproingie: this is another reason I often ask you guys (and some in ##C) about ideas/peeves. 08:28:26 I think we have - collectively - a lot of interesting ideas; we also can benefit from restricting the core to C for now - just to declare a clean api and make it portable - and THEN we can smite it as required. 08:29:52 Sadly, we have to consider ansi|c99 plus posix, but both situations are correctable in the "engine space" 08:30:20 hm. well, language design is hard. sounds like you want something like a compiler toolkit of some sort, perhaps an embedded language? 08:30:29 PoppaVic, HEY!!! 08:30:34 From what I can tell, lisp-contributors and engines already saw this years ago 08:30:47 What's wrong with POSIX and ANSI|C99 ? 08:30:47 sproingie: both, yes - bingo. 08:31:28 plenty of languages to go by as far as embedded goes 08:31:35 From what I have read, they are supposed to avoid PROBLEMS, not CREATE them. 08:31:39 what's your main goal? nice syntax? interoperability with C? 08:31:41 ansi itself is cripple, you'd need posix - and posix is no more universally-portable than C99. So, you write the cleanest C you can tolerate as the "core". 08:31:54 * aardvarx shakes head. 08:32:03 ANSI is crippled? 08:32:37 sproingie: back and forth from C/fovm, and syntaxes that satisfy forthers while not being slavish to ANS or C 08:32:45 PoppaVic, How do you define "clean"? 08:33:07 the point is to write an "engine" that simplifies all further code/app development for Metabuilder. 08:33:26 PoppaVic, I'm with you there 100% 08:33:38 what's Metabuilder? 08:33:46 aardvarx: "clean" (to me) Means, that any variation of C can be tinkered within an hour or so to make the shit build and run. 08:33:52 sounds like you're looking for runtime support for a specific tool 08:34:08 What I would like to know is, why do you perceive ANSI and POSIX as impediments. 08:34:32 Metabuilder is my conceptual "fuck gnu autoshit" utility for configure, make, install/uninstall. 08:34:33 * sproingie sees a lot of tools named metabuilder, nothing that's obviosus 08:35:14 sproingie, I'm not sure he's clear about Metabuilder at this point. 08:35:16 aardvarx: ansi lacks all forms of file-hierachy-support; Posix is adopted piecemeal all over. 08:35:21 i definitely believe in leaving autotools in the dust ... not sure what requires a brand new language and runtime though 08:35:28 I think things might get clearer once the VM is complete. 08:35:44 Metabuilder would "unify" the syntax/semantics at all steps - and be extensible. 08:36:12 to sound like a Smug Lisp Weenie ... sounds like lisp 08:36:31 ..and the distro-site would be the definitive location for Metabuilder "extensions" - just like the perl-foo site. 08:36:50 sproingie: no doubt, lisp predates forth 08:36:52 definitely sounds like lisp. asdf, specifically 08:37:08 no idea - never could figure out lisp 08:38:01 lisp unifies the configuration and building steps within the language, syntax is as regular as it gets (with some weird warts of course), and semantics are excruciatingly well-defined, without relying on all the baggage of posix 08:38:24 Basically, I'm looking at forth, C, and ASM - laying autoshit on it - and screaming at the result. THEN, trying to break out ideas and such. 08:38:26 not to say that common lisp doesn't have its own baggage, though there's always scheme for the do-over enthusiasts 08:39:28 sproingie: yeah, and I also note the lispers I talk with are always talking about issues that are more computer-science topics than "makes sense", realworld can-do. 08:40:19 I always liked the "feel" of forth, aside from mechanicals and some of the RPN issues. 08:40:40 I always liked C for the ability to pervert the world semi-portably. 08:40:54 asm, though: yer stuck. 08:41:30 And, mind you: gcc can generate asm - so, there is no reason folks should be overly bugged by using C. 08:43:11 i've always seen forth as a sort of super-duper macro assembler 08:43:20 First, we get a vm/engine working; add then vocs/words (headers); Then, we can relax or write bytecode translators to asm or C or mc - I don't care. 08:43:29 sproingie: yeah, not a bad view. 08:44:14 What does *forthish* mean? 08:44:58 rpn, i presume 08:45:22 PoppaVic, sproingie raised a good question earlier. Could you, in five sentences, explain what *METABUILDER* is? 08:46:22 aardvarx: "forthish" is my clean, collective term for something akin to all the forth-variants we know of. 08:48:28 OK.. "Metabuilder: A project which will allow programmers to utilize a single, extensible, consistent interface and language/semantic to perform all the duties which currently require learning GNU autotools, m4, sh and a variety of other, lower tools - which themselves must be installed." 08:49:37 "Metabuilder is not to be remotely confused with REPLACING GNU Autotools. It is, instead, a way to endrun a variety of languages and semantics with one unified tool and semantic." 08:50:04 Does this help you, aardvarx ? 08:50:21 unified language front-end? 08:50:22 Somewhat. 08:50:29 PoppaVic: what languages are you targeting to start with? 08:50:32 sproingie: sorta', yeah 08:51:00 sproingie: well, Metabuilder will rely on the vm/engine 08:51:30 FOr me, just insuring my C can install wherever metabuilder is installed is a plus. 08:52:01 a large part of the whole problem is Make+sh+tools 08:52:14 MAKE is a problem? 08:52:23 * sproingie shrugs. i don't use make for non-trivial projects 08:52:30 aardvarx: check out how many versions of 'make' there are 08:52:42 * aardvarx will not even try. 08:52:44 ..then check if the make uses sh or perl 08:52:59 there's posix make, gnu make, bsd make, and versions that don't count 08:53:09 THEN, look over gnu autoshit and see what THAT silly sucker requires 08:53:10 that makes (har har) three 08:53:35 i know of no make whatsoever that uses perl 08:53:49 and, hell.. Meanwhile, I could easily change my universe to work in this vm. 08:53:52 i suppose you COULD set SHELL to something exotic 08:53:57 --- quit: virsys ("bah") 08:54:06 sproingie: I had read that some doze-platforms subbed perl for sh 08:54:09 make is pretty agnostic about the shell it runs as long as it returns a status code 08:54:31 sproingie: the prob remains: they should be integrated 08:54:33 PoppaVic: oddly enough, i never thought of that. nmake certainly doesn't use perl 08:54:48 i guess nmake is another dialect, but it's retrograde, not really worth considering 08:54:59 hmm.. I'd not wish it on enemies, but I swear I read it. 08:55:05 no one writes serious makefiles for nmake 08:55:30 PoppaVic: i've never seen a makefile use perl, ever. though come to think of it, it's a pretty neat idea 08:55:33