00:00:00 --- log: started forth/05.09.05 00:16:06 --- quit: onetom (Read error: 104 (Connection reset by peer)) 00:16:08 --- join: onetom_ (n=tom@ns.dunasoft.com) joined #forth 01:19:53 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth 01:20:14 --- part: aum left #forth 01:22:39 --- quit: crc (Read error: 110 (Connection timed out)) 02:00:29 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 02:01:09 --- quit: ayrnieu (Nick collision from services.) 02:01:13 --- nick: ayrnieu_ -> ayrnieu 02:43:41 --- nick: thinfu -> cduce 02:56:34 --- join: crc (i=crc@pool-70-110-135-196.phil.east.verizon.net) joined #forth 03:13:38 --- nick: cduce -> thinfu 03:23:48 --- nick: onetom_ -> onetom 04:13:16 --- join: binaryguy (n=binarygu@host86-131-188-103.range86-131.btcentralplus.com) joined #forth 04:32:35 --- quit: binaryguy ("Leaving") 04:40:39 --- quit: onetom (Read error: 104 (Connection reset by peer)) 04:41:50 --- join: onetom (n=tom@ns.dunasoft.com) joined #forth 05:15:03 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 05:48:56 --- join: PoppaVic (n=pete@0-2pool236-245.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:49:15 G'day 06:00:23 --- quit: saon ("Lost terminal") 06:02:34 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 06:19:53 hi everyone 06:20:00 howdy 06:21:38 hey crc 06:28:06 --- quit: onetom (Remote closed the connection) 06:28:19 --- join: onetom (n=tom@ns.dunasoft.com) joined #forth 06:35:10 * PoppaVic sighs 06:38:02 hi ppl 06:38:39 hi docl 06:38:53 how's the code coming? 06:39:22 oh, trying to organize a bit and prettify. Tathi and Quartus are pretty adamant that they need docs to follow it ;-) 06:39:45 heh, might be a good idea there 06:39:57 well it has comments 06:40:18 and mneumonic names 06:40:48 yah, but as I told them - it was a conglomerate of ideas.. Docs were not called for at the time. 06:41:44 I'm odd in that I prefer to beat up headers, then code, then make the two play together. In this case, I suppose I'd have to write docs instead of code. 06:42:06 well at least it should be easy to document 06:42:48 yeah, if I can wrap my head around assorted ideas and structs. 06:43:14 just tell what each segment does, it's streamlined enough that much of it should be self-explanatory once you describe the generalities 06:43:50 right. Daunting at this point, since some ideas are still in flux. 06:43:54 also you'll want to describe anything remotely "wierd" 06:44:15 heh - since it isn't an ANS forth, that should be fun ;-) 06:44:24 hehe 06:45:17 anyway, yeah.. It's looking almost attractive. 06:45:49 http://rafb.net/paste/results/2FBrdN20.html 06:46:14 see around 45 for some stuff that seemed to confuse theguys. 06:46:18 lots shorter 06:46:32 breaking out new files from the original. 06:47:21 what are the mneumonics (IPO,UPO,etc) for? 06:47:48 ok.. That is where they get confused. 06:48:17 p=pointer? 06:48:20 each of those (PP/DP/LP) are CELL[2] (aka DCELLS) 06:48:27 ok 06:48:29 yup 06:48:44 the little memo/drawing should demonstrate the spaces. 06:48:48 each is a double cell 06:48:52 what's the O? 06:48:59 they work like zero 06:49:04 aah 06:49:39 they work like (that's a zero not O) old SP0 and such - outlining work-areas 06:49:41 that could confuse. would Z work better? 06:49:52 sorry, typo city for a sec there 06:50:05 0 not O 06:50:19 so, DP[0] is the same as "DP0" 06:51:06 ok needs a comment "zero not O" or change to DPZ 06:51:31 and using up-growth and down-growth, we can reduce the amount of work we need to do in testing ranges - and collosion will be the same as the long-ago program stack/heap collisions 06:51:39 huh? 06:52:02 you don't want to confuse readers with dumb fonts like mine 06:52:10 ahhh 06:53:12 hey, this is fovm, not f0vm, right? 06:53:26 I believe, if this worked out, then creating an image... Saving an image... and Loading an image - would all be simplified. 06:53:30 yup 06:53:47 my twist and tathi-sources 06:59:21 http://rafb.net/paste/results/zXNxWO86.html 06:59:29 above is the operators, for now. 07:01:44 cool 07:02:22 yeah.. I'm just thinkin' & rethinkin' and memory-joggin' to see if I can remember any other ops you just GOT to have to run the engine. 07:08:26 I'm sort of trying to recall if/when/what I'd read about forth word-use-frequencies. 07:09:25 Because, if doubles and floats are unusual-enough, then I'd yank the opcodes out to a new enumeration and vtables. 07:11:20 Prob is... That would then imply/demand 1 opcode-byte of 'litOPtable' plus a CELL of table-ptr plus a byte-code from that table. 07:11:47 so, it makes the code slightly larger by 1+sizeof(CELL) 07:12:47 otoh, it means we can have more-organized tables-of-bytecodes and maybe gain back easier obj-generation/loading/etc. 07:17:24 hmm, smaller more focused tables seem better to me 07:18:33 right. I'm thinking the core table should be all the flow-control, literals, etc plus single-precision stuff. I'm just about sure that doubles and c-doubles (FP) really deserve their own tables. 07:19:28 costing 1.25 more CELLS for the other tables bugs me only marginally. 07:20:14 this is 1.25 per table? 07:20:27 no, for table #2+ 07:20:46 for all fovm_core ops it'd be 1 bytecode 07:21:22 but, switching to another table is 1 bytecode + 1 tableptr + 1 bytecode 07:21:45 this is all assuming 32-bit, 4-byte words 07:21:51 CELLS 07:24:01 I know from experience we are talking about C-speeds plus about 20-30% of overhead, or maybe 2-10x slower than an optimized asm-program. But we would then have a really nice VM basis for portable code, regeneration, source-generation and metacompiling. 07:24:32 of course, our sizes for data/calls is similarly smaller by about the same ratios. 07:26:07 On machines of 300mhz or better, the speed-losses are more than acceptable for general-purpose/interactive work. 07:26:51 and, of course, if we can translate/cross-compile to "native-code" (asm or c), then hell - we got it all by the balls. 07:27:56 so it will slow things down a bit, but it can be optimized later? 07:28:50 anything can be - but those slow-down rates for forth are typical. And, while not "direct-threaded", the functable[opcode-byte] solution is a nice tradeoff 07:29:22 remember: just using the byte-codes themselves is a good start to pseudo-compiling. 07:37:32 OR... hmm...... I can add a core_opcode... For the alternate std-tables. But, that sounds like a wimpy admission of "oh-shit". 07:38:25 nah.. THe current solution may cost an extra CELL, but yeah: it's far more flexible. 07:56:57 http://rafb.net/paste/results/oPPXBa14.html 07:57:14 Check this out, docl - reorganized a trifle and added alt-tables. 07:58:38 cool 07:59:27 hmm, think about this a sec: under get,put - would an opcode of "ptrInc" and "ptrDec" seem very sensible? 08:00:00 maybe. is that different from a regular incr or decr? 08:00:12 yeah, +1 assumes a number 08:00:33 Adding the two I mentioned would mean easier stepping-code 08:00:38 yeah, do it 08:00:52 can always take it out later if it doesn't help 08:01:29 done 08:02:05 hmm, actually... I'll rename it more generically with same meaning 08:02:43 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 08:03:10 hi tathi 08:03:53 called now "ptrPrev, ptrNext" 08:05:04 sounds good 08:05:36 docl: now, it should not matter if the native is grow UP or DOWN - we can still step-past a 'unit' 08:05:38 hi 08:05:46 hi tathi 08:06:02 yeah, generic style is good 08:06:39 less room for the natives to confuse people 08:07:05 yah. The better sep between the vm/bytecode and machine, the better 08:32:13 hmm, went silent 08:36:16 brb... This is tedious 08:36:18 --- quit: PoppaVic ("Pulls the pin...") 08:39:18 --- join: PoppaVic (n=pete@0-1pool46-213.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:40:55 how are you improving the separation between the vm and machine, and why 08:41:56 Hmm? Oh.. 08:42:30 well, the bytecodes and the 'engine' structure and THEN C which ITSELF generates native-code 08:43:36 when you say bytecode you mean words don't you? 08:43:51 cuz as far as i'm concerned forth is a vm, and the words are bytecodes 08:43:53 nope 08:44:43 a bytecode is a bytecode 08:44:49 a cell is a cell 08:45:28 i'm not talking about cells when i say "word" 08:45:58 a word is N bytes - in this case, 32-bit cells or 4-bytes each 08:46:05 i'm talking about forth's dictionary.. the words are effectively bytecode by all definitions 08:46:22 oh, forget dictionary - that's another whole issue 08:46:33 and, no - they are not 08:46:48 a bytecode is a byte+data[...] 08:47:09 a 'word' is lexing/parsing/strings and dictionary/lookup 08:47:31 i'm not really talking about whatever you're coding 08:47:35 i'm just talking about forth 08:47:38 sure 08:47:59 hmm 08:48:01 and a 'word' is misused and has been for years.. Worse, you need a context to use it 08:48:20 bytecode includes data? 08:48:34 isn't bytecode essentially the assembly lang of the vm 08:49:01 well i guess there's the storage of the code & data that needs to be translated 08:49:21 not entirely 08:49:31 you store both code and data in the dictionary 08:49:37 so thats pratically bytecode 08:49:37 mostly it's the ABI 08:49:44 no (again) 08:49:52 yes 08:49:53 :P 08:50:50 saying no just gives you an excuse to code extraneous stuff, or additional layers.. 08:51:07 sorry, you are just wrong 08:51:23 "practically bytecode" is akin to "nearly pregnant" 08:51:57 and forths have tendencies to be indirect/direct-coded and NOT usually byte-coded 08:52:06 forth is already described as a VM in the first place 08:52:24 and it has nothing to do with the low level stuff like ITC,DTC etc 08:52:25 ns 08:52:34 sorry, you'd be wrong again 08:53:02 what is the purpose of what you're coding? 08:53:05 portability? 08:53:10 yeah. 08:53:51 Working up a VM that is forthish, in C, that can be used to run assorted shit portably and well - and using C for more porability than asm 08:53:52 well you can achieve the same portability without doing the bytecode at the implementation 08:54:36 btw are you aware of retroforth? 08:54:40 yep 08:55:06 and fpc, and f83, and FIG, and herk, and gforth, and - well, the list never ends 08:55:15 sure 08:56:14 problem with almost everything since FIG-forth is asm-programmers and ABI's 08:56:35 what's ABI 08:56:44 Not an issue on 'embedded' systems, but it can become an issue in other ways 08:56:53 Application Binary Interface 08:57:24 retroforth is what i would call a fairly portable forth.. implementations for several platforms and more coming 08:57:40 no need to use C 08:57:52 I'm working on something that will be useful itself, or to C, or - with a few supports - for optimizing/compiling/resourcing(translating) 08:58:02 no need to use asm 09:00:03 there are more advatanges to do it in asm unfortunately.. 09:00:10 i've never seen a non-bloated forth that was coded in C 09:01:27 in fact i would characterise most problems with *nix and windows OSes due to the fact they coded them in C/C++ 09:01:33 flawed paradigm 09:01:42 that's nice 09:03:01 basically, yer telling me every implementation you've seen/used is too lame to compile, optimize/link 09:03:14 ..which is no suprise 09:04:02 ..since even most assemblers are "compiling", or they'd never need the linker/loaders 09:04:17 but, ok. Been there; Seen that. 09:07:00 oh.. And, let us not forget: an interactive-forth is the NORMAL order. Compiling/decompiling/debugging is not a normal issue. Other than those assorted issues, sure: yer right. 09:11:52 why are you coding what you are coding when the reality is that nobody programs in forth? :P 09:13:05 because I want an extensible vm for about four projects. 09:13:38 forth vm or general vm 09:14:12 forth is not even forth... ANS is a joke 09:14:27 ? i never speak of ANS 09:14:40 I want a forthish/forthlike vm, and Everything afte will spin from that. 09:14:54 ANS has nothing to do with forth 09:15:04 sure it does - they say they do 09:15:14 what they say doesn't count for much 09:15:15 meanwhile, I recall FIG 09:15:45 you're speaking in terms of standards.. the only forth is chuck moore's forth :P 09:16:03 ANS has the same todo with forth like Java has the same todo with good OOP design 09:16:26 The bottom line is... We need our lovely interactive-universe, and should be able to suffer a few extra clocks. AND, we should be able to export src to make objects to link and load. 09:17:12 anything else is not my prob. Since, I want to write source, "compile", link and load. End of story. 09:18:58 why do you need link and load, thats mostly to save cpu cycles 09:19:16 i.e. creating a bunch of objects at different tims then linking them.. 09:19:26 but in forth you can just compile it all at once :P 09:19:32 * PoppaVic sighs 09:19:37 err...it's also used to connect together things made in different languages... 09:19:40 you can't get it, can you? 09:20:05 thanks, tathi - I was running out of patience ;-) 09:20:57 eh don't take this conversation so seriously, i'm just arguing for fun 09:21:20 yah, thinfu likes stirring things up :-) 09:21:34 yup :) 09:21:54 <-- troll, the fuzzy cuddly loveable kind 09:22:23 thinfu: so...you been doing anything interesting lately? 09:22:47 went on a 6 day hike 2 weeks ago :P 09:22:58 actually been avoiding programming 09:23:00 nice 09:23:07 yah, I figured 09:24:02 * tathi is trying to learn Verilog, just for kicks. 09:24:08 neat 09:24:13 thats the vector-based lang right ? 09:24:48 no. hardware description language :) 09:24:56 oh heh 09:25:26 though speaking of vector languages...I was reading #concatenative logs, and now I'm kind of curious about K. :) 09:26:00 heh 09:26:05 whats the point of learning all these languages? :P 09:26:41 fun. :) 09:26:51 why do you think I program at all? :P 09:27:15 i dunno, to code tools that you need on the fly? 09:27:26 though...I suppose one of these years I'll try and make some money at it... 09:27:57 better start now :P 09:28:21 or you'll be 35 years old before you know it and finally attempting to do just that 09:28:31 yeah. 09:29:16 i think there's a market for custom programming. lot of businesses are probably doing some repetive stuff that could be eliminated with a custom program or two 09:29:22 or whatever 09:30:26 --- join: qFox (n=C00K13S@92pc222.sshunet.nl) joined #forth 09:31:12 yesterday i was daydreaming about a forthchip THI (the humane interface) laptop that is about 10" long, 6" wide, and 2-3" thick 09:31:34 there are many markets - sadly, MM/webby-shit is the high$ 09:31:37 heh. 09:31:40 essentially just big enough for the keyboard and the lcd is about the same size 09:31:57 actually, that's why I'm playing with verilog -- I want to design a forthchip a bit simpler than the IGNITE 09:32:00 lot of laptops i see are trying to fit the biggest lcd.. 21" or whatever, thats crap 09:32:03 and put it in a pocket-sized computer 09:32:18 i think the lcd should be about the same size as the keyboard 09:32:22 and the keyboard would be THI-based 09:32:29 so it would sort of be book-sized 09:32:34 and durable 09:32:35 yeah, my roommate in college had one of the little tiny Soni VAIOs, it was really nice. 09:32:39 so you can just throw it in your backpack 09:32:43 smaller even than the 12" powerbook 09:33:09 the cpu has no serious bearing on "size" 09:33:35 I know, I just don't want to deal with the complexity of the IGNITE. 09:33:49 and then mass manufacture this and sell it to everyone in the world for cheap, including all the 3rd world countries 09:33:54 subversion thru computers! 09:33:56 And, there are several "integrated/embedded devices" that can satisfy, with decent core-code 09:34:11 tathi: how is IGNITE complex? 09:34:14 haven't really looked at it.. 09:34:16 thinfu: hrm...isn't that what iTV was trying to do before they died? 09:34:38 it's just not a minimal chip. 09:34:41 for example... tathi? WHy did your posting code treat emit and such as syscalls? 09:35:13 it's about what you'd expect when if a "traditional" chip designer designed a stack processor. 09:35:20 just has a lot of features that I don't really need. 09:35:49 PoppaVic: I was basically using syscall as an "extension" opcode. 09:35:53 i thought ignite was shboom 2 09:36:02 and that shboom was designed by chuck 09:36:07 I'm thinking we need - and I've even seen this in C - a console i/o and device i/o table 09:36:28 ..granting there are MANY similarities 09:36:32 who needs that? 09:36:48 or you think that would be an optimization? 09:36:51 thinfu: the new fovm shit I'm cobbling 09:37:34 PoppaVic: and remember that mine was designed to be a layer under herkforth -- which has very modest requirements for interacting with the outside world. 09:37:42 The underlying mc could be nearly identical, but.. I've seen many years of console-ish and then "other" 09:37:50 tathi: exactly 09:38:06 tathi: wasn't sure. That helps, thanks 09:39:12 interesting thing about the bytecode/index-tables: adding layers or even interfacing is no huge chore. 09:39:16 PoppaVic: I was only really planning console i/o, and maybe framebuffer access a la SDL. 09:39:57 yeah. Actual c/asm/mc is not an issue, with a "virtual" interface/engine 09:40:50 thinfu: I don't know about the IGNITE's history. But it feels like it's designed for today's CPU market. 09:40:58 i.e. selling it to people who want all the bells and whistles. 09:41:17 well thats probably true 09:41:25 with the whole focus on the java thing 09:41:25 heh 09:41:33 IIRC it has support for a couple sizes of inline (in the instruction word) literals 09:41:46 and a bunch of stuff about dumping the stack cache out to memory and loading it, etc. 09:41:53 that sort of thing. 09:42:20 hmm... See below, tathi.... 09:42:44 http://rafb.net/paste/results/V1IHCo26.html 09:42:47 I'd like something about halfway between the ignite and chuck's super-minimal designs. 09:42:57 why 09:43:03 whats wrong with super-minimal? :P 09:43:24 given how single and double and fp tables work, do we need the "indirect"? 09:43:25 :) 09:43:48 tathi: so lets say you design a chip, what then 09:44:33 thinfu: I just want a durable little machine that I can carry around in my pocket. 09:44:50 I had a Handspring Visor for a while, but it wasn't quite the right shape for my hands 09:44:59 and it was terrible for developing on -- crash it and you lose everything 09:45:13 I'd like to have a conventional differentiation between temporary/permanent storage. 09:45:26 PoppaVic: sorry, what do you mean by "indirect"? 09:45:49 oops, time for lunch. bbiab. 09:46:34 np, lemme' know when yer back 09:46:51 tathi, it's hard to loose everything crashing a Visor. Can be done, but you really have to work at trashing the memory. 09:47:48 The Palm OS establishes two kinds of heaps, dynamic and storage, and disallows casual writes to storage heaps (where apps and stored data live). 09:48:13 storage is ala' e[e]prom? 09:48:34 good idea, if so 09:48:44 bad term though 09:49:18 No, it's not -- it's RAM. As I understand eeproms they have a finite write capacity, are slow to write to, and take more power to do it. 09:49:29 right 09:50:17 There are eeproms in the majority of Palm devices, where the Palm OS lives, which can be updated. Third party solutions exist for those devices to embed your own software in unused places, so it can't be lost. 09:50:28 eprom means you'd "burn" a chip; eeprom is "inplace" burns. "bubbmem" is slower, but safer than the latter. 09:50:49 All the recent models have SD slots, where you can also store software, so non-volatile storage and backup are pretty easily managed. 09:50:58 It's hard to stay abreast of developments of chips 09:51:14 The LifeDrive has a built-in 4Gb hard drive that backs the memory store. 09:51:17 usb-drives, for example 09:51:46 "keychain drives" 09:51:56 I know 'em; I use them for backup. 09:52:16 I think we got a wealth of hardware, but the barest utility for sw 09:52:40 I'd need to know what you mean by 'utility', there -- what is it you want to do but can't? 09:52:50 or rather "A plethora of dumb-assed sw" 09:53:42 Quartus: I've got no issues myself, but then I have never written an OS or the source to r/w - portably - devices like the usb-keychains 09:53:49 Well, sure. Like we have a plethora of dumb-assed books, and a plethora of dumb-assed art. 09:53:55 sure 09:54:42 BUT, when we talk about "new chip" or "new os", I'd like to see some resolutions that matter. Rather than "Now, I am topdog in the kennel" 09:55:08 I'm of a different mind about all that. 09:55:40 oh? how? what? where? why? 09:56:16 Because I don't care to start the whole OS/kernel/microcode/code war. 09:56:18 I think too much light and heat is generated by the race for the next 'new' thing. More effort should be spent writing software that does something useful; more focus should be put on educating programmers to write good code with an eye to portability. 09:56:34 ahhh 09:56:46 define "portable" and then "code" ;-) 09:57:20 you can't - not well, anyway 09:57:58 I'm not speaking of 'portable' in some kind of magic-bullet sense, just the writing of applications ("code", in the vernacular) in well-defined languages with the machine/OS-specific part clearly marked for ease of porting. 09:58:03 Which is why I'll stick to my self-imposed task 09:58:18 yeah, it's too huge a gap 09:58:34 PoppaVic, it's hard to have a conversation with you when you ask a question and then try to cut me off at the knees while I'm typing my answer. 09:59:26 I think the #openbios boys had an idea, but it's a dead-end. Yes, I know I sometimes smite folks I can't tell if yer reading/thinking or typing, dude. 10:00:48 I don't worry about 'Holy Grail Portability', wherein the same source or binary runs everywhere unchanged. I think that's another place a lot of heat and light is generated without much use. 10:01:06 Given the fact that an ABI is quite unlikely anymore, a "layer" between is the best we will see for a long time. 10:02:27 so, sure: we "emulate" generically - and cpu/sys freaks can optimize/replace routines. No problem. Done cleanly, we can support a variety of platforms. 10:03:33 Well, that doesn't quite jive with how I see the matter, either. 10:03:53 I'm not suprised, today. 10:04:11 Ok, If you don't want to discuss it. 10:04:22 not what I said 10:07:03 In my view, different OSes, even different CPUs, present different metaphors for computing based on their conceptual design. It makes sense to capitalize on those differences when writing software for each platform. To suggest that software should be written generically is to presume that the differences between systems are irrelevant and ignoreable, that there should be some single overriding design that eliminates those differences. 10:07:17 nope 10:07:23 Or, that somehow encapsulates and combines all of the differences, which is, I believe, impossible. 10:07:44 In every single case, they perform similar jobs. 10:08:01 Similar, yes. 10:08:05 yep 10:08:19 "similar" is where a VM/engine shines. 10:08:29 Quartus: mine would often crash so that you had to do a hard reset, and then all the programs were gone. 10:08:34 Not identical. And the way in which different systems perform a task is what I'm talking about. It's subtle, but important. 10:08:47 tathi, that must have been some hardcore bit-bashing you were doing. :) 10:09:34 I don't even think it was me, just various programs. 10:09:52 Of course, that was one of the original Visors, so maybe the ROM was still buggy or something... 10:10:06 A shame you had a bad experience, tathi. Yes, some third party software is pretty nasty stuff, true on non-Palm gadgets too of course. 10:10:08 similar/exact is the VM/language interface. I still fail to see the issue. This sounds like an asm/perl/python argument: it's almost 100% ABI 10:10:52 PoppaVic, I know you like to lump anyone with a divergent opinion into one of your labelled camps of people who 'don't get it', but I don't see it as a productive way to have a conversation. 10:10:57 in fact, add compile/link/load - and the issues get further and further away 10:11:26 Quartus: well, it was obviously a fairly cool platform, in spite of the issues I had :) 10:11:34 I am not discussing asm, or perl, or python. 10:11:37 Quartus: yeah, nor do I enjoy talking with folks that think the universe is machine-code 10:11:51 tathi, I still think so :) 10:12:09 Quartus: it's all approximate. 10:12:28 going anywhere ABOVE the silicon necessitates it 10:12:35 but, so'k 10:13:11 In fact, it's above the silicon that the most important differences exist between systems. 10:15:09 that's for sure. the hardware (for desktop systems) keeps getting more and more the same, AFAICT. 10:15:35 tathi, I think that's a shame, too. I'm for diversity in computing metaphors, top to bottom. Keeps things interesting. 10:15:46 yeah. 10:16:16 This is not to say portability doesn't have its virtues. 10:16:37 yah think? ;-) 10:18:52 Historically, OSes were designed for a CPU. The conceptual underpinnings of the CPU affected the design of the OS. This is evident looking back at 68000-based OSes, and how they differed from Intel-based offerings. 10:19:17 In like manner, the design of an OS affects the design of the software written for it. 10:19:41 "historically", we had BIOS and boot/shell. 10:20:05 this was true of cp/m and others: bios/dos 10:20:13 I'm thinking CPM and IBM PC/AT as it contrasts with the Mac and Amiga. 10:20:19 yep 10:20:26 And I'm not talking about the boot sequence. 10:20:59 it's STILL true, but most systems seem to copy over the "important bits" into ram out of rom 10:22:52 Choice of programming language has a strong effect on software design, too. 10:23:34 In a nutshell, a developer who immerses himself in a certain set of computing metaphors then thinks in those terms, and it dramatically colours what he produces. 10:25:22 It's similar to human languages; different underpinnings lead to characteristically different types of thought. 10:26:56 Of all places, this can't be news to a group of Forth developers, I'm sure. :) 10:27:33 heh 10:28:16 Jean Sammet's History of Programming languages comes to mind. She refused to include Forth (FORTH at the time) in the first version, because it lacked what she considered a syntax, and thus couldn't be considered a programming language! 10:29:42 I'm beginning to suspect "Jimmy Carter Syndrome" 10:30:43 I don't think her brother farmed peanuts. 10:33:18 I could be wrong. :) 10:39:56 Let me amend that note -- I just dug up the reference. Sammet's concern was with including Forth later on -- the first edition was 1969 (got a copy here, with a punched-card for a bookmark no less), which would have made it too early for what we call Forth today. 10:40:15 Here's E. Rather's comments: http://groups.google.com/group/comp.lang.forth/msg/96ac240036c7ab61 10:40:52 interesting 10:41:05 Liz is cute 10:41:51 Forth did make it in to the HOPL-II book, despite Sammet's efforts. 10:42:24 One of the fourteen that did. 10:48:03 Quartus: not to raise a ruckus, but are API+lib "just not on, old boy"? 10:51:06 Sorry, I stepped away. What do you mean? 10:51:32 so'k, I been doing the same 10:52:41 I'm thinking of API/headers and lib/linkers. Very unusual in a forthish universe, worse in MC and oft-used by "asm programmers" 10:53:27 MC? 10:53:37 machine-code - switch-flipping 10:53:49 PoppaVic: AFAIK Quartus Forth allows you to use all of the PalmOS services, and save your programs as full-fledged Palm applications. Does that answer anything? 10:54:27 tathi, right. When you need to use a foreign layer's services, you have to know how; that entails a description of some kind, usually in the form of a header. 10:54:34 tathi: actually, it raises a LOT of questions ;-) 10:55:23 Traditional compilers use linkers, Forth doesn't, as a rule. Quartus Forth doesn't, but it does have a MakePRC facility that recursively creates a standalone executable from an app. 10:55:46 yeah, I suspected something like that. OK. 10:55:54 Suspected what, PoppaVic? 10:56:17 Forth doesn't, as a rule. Quartus Forth doesn't, but it does have a MakePRC facility that recursively creates a standalone executable from an app. 10:56:53 If you write Palm apps using GCC on the desktop, of course you're in linker land. 10:56:56 doesn't; doesn't - and alternatives. 10:57:21 It's "generically" interesting 10:57:49 ..and this from a guy that wants to thrash macosx/dynlibs and elf 10:58:20 You're attributing things to me I haven't stated, PoppaVic. 10:58:22 It all implies several interesting things 10:58:33 * PoppaVic sighs 10:58:58 Quartus: do you have a mac? 10:58:59 In fact I can't remember ever forming, let alone stating, an opinion on dynlibs and elf. And I don't want to thrash the macos. For the record. Are you confusing me with somebody else? 10:59:09 I have a couple of them, tathi. Older ones. 10:59:09 Quartus: when I pasted yer statement, I did not kibitz. Geezus. The implications remain the same. 10:59:39 I never said you - I implied myself, geezus-keerist. 11:00:00 Ok, PoppaVic. Sorry, that wasn't clear. 11:00:19 argh. I may need a nap - or a spanking or something.. 11:01:29 Quartus: please recall, while coding and editing - I'm suffering ##C and #fohrt, ok? ;-) I've just stopped with #asm because you can't get any 2 non-cpu-mates to agree on dick ;-> 11:01:45 fohrt/forth 11:03:44 I'd think you'd enjoy the arguments there. :) 11:03:51 oh, lord 11:04:09 Yeah, it does make me want to go visit my turret-press 11:05:01 Apparently, no one on the planet seems to realize we have cpu/platform/os. 11:05:23 so, yeah - I get a touch "stressed". 11:06:09 "so? write it in asm" is right up there with "write it in forth", for the last few decades. 11:06:18 I don't follow. 11:06:31 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 11:07:26 s'ok, I'm about "A Beer Too-Far" today to explain it, but I'll bet tathi can. I apologize. Tommorrow I'll be better-able to cope. 11:09:22 I think it may have to do - from my own upbringing - with editors:ascii:forth/C:libs/OS, etc. 11:10:53 I just tend to get peeved over the whole "language" underpins/layers gig 11:40:49 tathi: I'd like to recommend a review of 'syscall' versus CCcall. Not important today, but please consider it. 11:43:05 think I can answer that off the top of my head... 11:43:35 I don't need CCall, but as a generalized system, your system should quite possibly do CCall instead of 'syscall'. 11:43:36 ok. 11:43:48 certainly seems more flexible 11:43:59 yeah. trying to see diffs 11:44:17 ..it seems to be a "stack" versus stack issue 11:44:47 anyway, do me the courtesy of letting it percolate. 11:44:50 yup. 11:45:12 it sure sounds like an ABI-issue 11:45:45 ok, gotta' split - stay well (each and every one) 11:45:49 --- quit: PoppaVic ("Pulls the pin...") 12:20:35 --- join: madgarden (n=madgarde@London-HSE-ppp3545852.sympatico.ca) joined #forth 12:24:46 --- quit: tathi ("leaving") 12:29:05 --- quit: warpzero ("leaving") 12:29:21 --- join: warpzero (n=warpzero@wza.us) joined #forth 12:34:42 --- quit: virsys (Read error: 110 (Connection timed out)) 13:25:18 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 13:25:39 --- quit: ayrnieu (Nick collision from services.) 13:25:45 --- nick: ayrnieu_ -> ayrnieu 13:48:10 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-157-034.arcor-ip.net) joined #forth 14:00:30 --- quit: Snoopy42 (Nick collision from services.) 14:00:39 --- nick: snoopy_16 -> Snoopy42 14:58:56 --- quit: qFox ("this quit is sponsored by somebody!") 15:46:00 --- quit: Snoopy42 (Nick collision from services.) 15:46:45 --- join: Snoopy42 (i=snoopy_1@dsl-084-058-144-108.arcor-ip.net) joined #forth 16:04:41 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 16:04:57 --- quit: ayrnieu (Nick collision from services.) 16:05:25 --- nick: ayrnieu_ -> ayrnieu 16:30:59 --- join: virsys (n=virsys@or-65-40-182-100.dyn.sprint-hsd.net) joined #forth 17:03:07 --- join: amca (n=plump@as-bri-1-158.ozonline.com.au) joined #forth 17:16:00 --- quit: crc (Read error: 110 (Connection timed out)) 17:38:04 --- join: crc (i=crc@pool-70-16-148-101.phil.east.verizon.net) joined #forth 17:38:22 --- mode: ChanServ set +o crc 17:45:01 --- quit: virsys ("bah") 18:18:01 --- nick: ayrnieu -> nleavrh 18:41:59 --- join: amca_ (n=plump@as-bri-4-1-24.ozonline.com.au) joined #forth 19:01:18 --- quit: amca (Read error: 113 (No route to host)) 19:01:50 --- nick: amca_ -> amca 19:08:40 --- join: nleavrh_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 19:08:54 --- quit: nleavrh (Nick collision from services.) 19:09:02 --- nick: nleavrh_ -> nleavrh 19:27:39 --- nick: nleavrh -> ayrnieu 19:40:11 --- quit: saon (Nick collision from services.) 19:40:20 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 19:51:55 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 20:31:42 --- quit: amca ("d34d") 20:32:50 --- join: Snoopy42 (i=snoopy_1@dsl-084-058-138-033.arcor-ip.net) joined #forth 20:45:55 --- quit: madgarden ("?OUT OF DATA ERROR") 20:47:18 --- join: madgarden (n=madgarde@London-HSE-ppp3545852.sympatico.ca) joined #forth 21:33:01 --- quit: Quartus (Remote closed the connection) 21:34:29 --- quit: ayrnieu ("X") 21:39:36 --- join: Quartus (n=trailer@ansuz.pair.com) joined #forth 21:44:20 Hey all. 23:59:59 --- log: ended forth/05.09.05