00:00:00 --- log: started forth/05.09.06 00:19:45 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 00:21:12 --- quit: snowrichard (Remote closed the connection) 02:26:26 --- quit: crc (Read error: 110 (Connection timed out)) 02:30:36 --- join: amca (n=plump@as-bri-3-184.ozonline.com.au) joined #forth 02:33:27 Quartus: http://www.rafb.net/paste/results/4XgEMa47.html for the results of your challenge :) 05:41:57 --- quit: Snoopy42 (niven.freenode.net irc.freenode.net) 05:41:57 --- quit: warpzero (niven.freenode.net irc.freenode.net) 05:42:00 --- quit: thinfu (niven.freenode.net irc.freenode.net) 05:42:00 --- quit: Raystm2 (niven.freenode.net irc.freenode.net) 05:42:01 --- quit: ianp (niven.freenode.net irc.freenode.net) 05:42:01 --- quit: skylan (niven.freenode.net irc.freenode.net) 05:42:04 --- quit: Quartus (niven.freenode.net irc.freenode.net) 05:42:04 --- quit: madgarden (niven.freenode.net irc.freenode.net) 05:42:04 --- quit: OrngeTide (niven.freenode.net irc.freenode.net) 05:42:04 --- quit: Ray_work (niven.freenode.net irc.freenode.net) 05:42:13 --- join: thinfu (i=thin@bespin.org) joined #forth 05:42:13 --- join: Quartus (n=trailer@ansuz.pair.com) joined #forth 05:42:13 --- join: madgarden (n=madgarde@London-HSE-ppp3545852.sympatico.ca) joined #forth 05:42:13 --- join: Snoopy42 (i=snoopy_1@dsl-084-058-138-033.arcor-ip.net) joined #forth 05:42:13 --- join: warpzero (n=warpzero@wza.us) joined #forth 05:42:13 --- join: OrngeTide (i=orange@rm-f.net) joined #forth 05:42:13 --- join: Raystm2 (n=Raystm2@adsl-68-95-254-73.dsl.rcsntx.swbell.net) joined #forth 05:42:13 --- join: Ray_work (n=vircuser@adsl-66-139-199-228.dsl.rcsntx.swbell.net) joined #forth 05:42:13 --- join: ianp (n=ian@inpuj.com) joined #forth 05:42:13 --- join: skylan (n=sjh@dialup-216-211-47-87.tbaytel.net) joined #forth 05:42:13 --- mode: irc.freenode.net set +o thinfu 05:44:01 --- join: PoppaVic (n=pete@0-1pool65-176.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:44:28 Mornin' 06:36:49 --- join: madwork (n=foo@derby.metrics.com) joined #forth 06:45:35 Morning. 06:45:45 howdy 06:52:15 --- quit: amca (Read error: 113 (No route to host)) 06:53:06 hmm 06:54:01 I'm thinkin' a new engine just about justifies getting a grasp on a decent chars/string-system, let alone console-i/o 06:55:22 Sounds like you're writing a new Forth, more than a new engine. 06:55:33 yep, it does. 06:55:58 Except, forth ain't forth and this is just "forthish" 06:56:23 I guess, since you've got 3 stacks, as I recall it. 06:56:33 heh - more than that, even 06:57:00 data, return, bools, floats, and locals right now. 06:57:23 It's the 'bools' stack that sets it apart. 06:57:51 nahh, that's the tathi '32-bit reg/cell "stacl"' 06:57:54 stack, two 06:58:07 However it's implemented. 06:58:26 I'm still not sure it's a "great" idea, but it seems doable. 06:58:48 From what I understood of the effort at the time, it stood out as a not-great idea to me. 06:59:04 yah, it struck me as adding complication and code. 06:59:54 I figure the usual gymnastics-code and bit-rotation/shift/tests is more than enough gyrations. 07:01:20 It seemed to me it would interfere with branchless decision code. 07:01:41 well, there are a decent assortment of branching ops. 07:02:16 Yes, but it would preclude this sort of thing: : +DIGIT DUP 9 > 7 AND + [CHAR] 0 + ; 07:02:38 but 'branchless-decision' sorta' loses me.. Thinking of - ahhhhh, you mean math-magix and indexing-type code 07:02:56 Yes. That was my thought at the time. 07:05:47 So I wonder what problem it solves. 07:06:19 I dunno. I got a LOT of senseless resistance when I questioned it - And, I was just asking out of curiousity. 07:06:35 Tathi does seem to realize it seems questionable, though 07:06:55 I believe it was jason that went off on me. 07:07:49 Did he suggest what problem it solves? 07:09:10 no, I recall all I heard was "why are you questioning something you don't understand", etc, etc 07:09:24 it was a real porcupine-day 07:10:02 I *think* it boiled down to direct "forget the system" use of as many regs as possible. 07:10:25 (which has always buggedme) 07:12:18 I'm trying to think of situations where flags are 'in the way', as it were. 07:12:48 well, they DO get in the way - but then, the gymnastics are there for all that stuff anyway 07:13:13 I'm almost always testing what's on top of the stack, and then acting on it immediately. 07:13:23 yeppers, me too 07:13:36 maybe... hmm 07:14:02 is there an opposite to 'pick' that sounds good? 07:14:23 stuff? 07:14:32 hmm. 07:14:41 bury 07:15:08 I'm just wondering, since the opcodes reflect C or asm, if such would be useful. I'd think so, in a flag/var rich environment. 07:15:14 I like bury. 07:15:37 then, intstead of pick: use exhume/bury 07:16:07 (idea being: get it out of the way for someone to use later) 07:16:26 dig/budy 07:16:29 bury 07:16:35 Neither pick nor its opposite sound good to me. :) 07:17:39 Juggling never interested me much either. 07:17:41 --- join: derv0 (n=derv0@proxy1.nscl.msu.edu) joined #forth 07:18:44 As much as I abhor PICK, I've never had cause to use its opposite. 07:19:11 ROLL works fine. 07:20:00 or -ROLL rather. 07:20:23 ahh, I forgot roll/-roll 07:21:56 I can imagine a 3-byte swap opcode though, that specifies source and destination stacks and depths. 07:22:30 4 bytes if you put the stack ID's in the second byte. 07:22:52 Not that this has anything to do with whatever you were talking about. 07:23:05 * madwork randomly spews ideas 07:23:32 yeah. The prob is that the datastack ends up playing at "array" occasionally 07:24:07 Sure. 07:24:10 That's a problem? 07:25:22 no.. I meant for ops 07:26:05 http://rafb.net/paste/results/mUpJeK31.html 07:28:05 Ahh, if only Forth was the C preprocessor. :) 07:28:09 Quartus: I think I'll leave in the boolstack notes, but just ignore the idea for now. Some enterprising SOB can rewrite the little support it requires. 07:29:07 madwork: yah.. I generally think in headers/structs first, then start thinking of how-to: things can evolve, but I'm never too shocked. 07:29:34 PoppaVic, won't that be the basis of all your boolean logic words? 07:29:55 Quartus: what? his boolstack? 07:30:00 Yes. 07:30:49 no. His words are marked (thanks, tathi) in the opcodes. And only deal with true zero/one boolean situations. I think it's a fairly simple conditional. 07:32:25 I've 9 words might set a bit... and only the branching ops would know, afaik. I just think the idea is silly anymore. 07:33:17 well, ok... It might be worse than I expected. I believe getting the boolstack nuked seems sensible. 07:34:53 forths don't need PICK at all 07:35:14 and anyone that uses pick should be bitchslapped 07:35:47 It has occasional use when dealing with FFI, but it's ugly even then. 07:36:40 retro doesn't have pick and handles FFI too 07:36:53 no, it handles *A* FFI 07:37:06 It's not in the handling of FFI, it's in managing FFI calls where the call demands, oh, 13 parameters. 07:37:13 I can't be sure who compiles, links and loads what, where. 07:37:45 man for 13 parameters might as well just build an array then load it on stack if necessary right before the call 07:37:55 Quartus: sure - there is no harm in added opcodes. THe harm iswhen folks write crazy-code 07:37:57 thinfu, that's one approach for sure. 07:38:10 PoppaVic, I believe in simplicity. 07:38:20 Quartus: we see this all the time in C. 07:38:38 I like simplicity. I don't like to be straitjacketed by it. 07:39:05 You can implement PICK in high-level code, if you need it. 07:39:16 Quartus: not if you don't have DEPTH either :P 07:39:31 I'd rather see it in the opcode list - it ensures speed when it is needed. 07:39:41 lack of pick & depth is hardly a straitjacket 07:39:58 thinfu, I can't imagine why you wouldn't have DEPTH, but sure. 07:40:41 mechanically, depth is easy. Low-level code can avoid it. 07:41:01 cause depth encourages you to treat the stack like an array and basically cause slow code 07:41:24 the stack is a stack, thats what its good at.. people that feel the need for depth can just create an array :P 07:41:45 there is just no point in writing colon-words for essentials that will be able to work the machine. "depth" is for humans, because you never expose the machine too clearly to them. 07:42:04 Oh. I was thinking DEPTH might be difficult to implement on some architectures. 07:42:16 the *data* stack is an array and structs and pointers and whatever. 07:42:37 see depth 07:42:38 : depth 07:42:38 sp@ sp0 @ swap - cell / ; ok 07:42:57 so, given sp@ and sp0 - tis easy, internalls 07:43:45 yeah retro doesn't have sp either :P 07:43:48 certainly it suggests some convenience/consistency macros for guts-code 07:44:11 now, another issue I wanted to broach.... 07:44:56 Is there any crazy-reasons I've missed as to why dictionary-headers SHOULD be embedded into colon-lists/literals? 07:44:56 I seem to recall discussion of Forth chips wherein it wasn't possible to compute DEPTH with any ease. 07:45:20 Do you mean, is there some reason headers should be in codespace? 07:45:30 yeah - reversed meaning. 07:45:52 Unless you're constrained into doing so, I recommend moving headers out. 07:45:57 I'm thinkin' dictionary/header-space can easily be parallel/disposable 07:46:07 ok, thanks - I thought so 07:46:10 Quartus Forth headers are in a seperate space. 07:46:26 yeah, I've run assorted systems over the years 07:46:58 It's clean. Aliases take no codespace, for instance. 07:47:33 How about "strings"? Do we WANT to force ascii and cstrings and nstrings? 07:48:22 I wouldn't want to mandate string storage format. 07:48:33 I'm of the opinion all code should input and scream ascii, but that applications might benefit from wchars or some silly thing. 07:49:27 in other words: code in ascii-universe, run in perhaps the silly wchar 'unifoo' universe. 07:50:45 shit, Jim is gonna' be here shortly *sigh* 07:50:59 Baden said he kept a series of application-specific words for dealing with Unicode... WCHAR+ and so on. 07:51:20 Yah. There are many ways to deal with them. 07:52:05 I'm thinking that... source should always be ascii + wchar interfaces... And any app-i/o may well benefit from the crazy shit. 07:52:44 which leads me to another issue... 07:52:52 I wonder how easy it is to build a Forth that would allow you to alter the size of a char/cell at will? 07:54:05 At this time, only math/literals/branchings/tests are being opcoded - and syscalls. Would we not benefit from a term/conio and file-io opcode table-set? 07:54:15 So you could say "today, I want 16-bit chars and 64-bit cells". 07:54:56 well, you can't change a BYTE size, but you can change cell/character sizes 07:55:17 ..at least, I'm TRYING to codify such a beast. 07:57:14 That might be interesting. 07:57:46 Yep, and you merely need to compile the engine-support. 08:00:21 My immediate goal is a c-based vm that lets me write forthish as compact and fast as possible, with the ability to decompile/port as close as possible to original code. 08:01:02 given that, we can consider linkers, loaders, cross-compilers - but I then can consider the remains of my project. 08:01:06 It might be useful to write an ANS layer on top of it; you'll get more testers and feedback that way. 08:01:30 I see no reason the ANS-freaks could not write an ANS vocabulary 08:02:25 if it is deemed impossible, then ANS is a bigger mistake than I thought. 08:11:09 It's challenging to converse with you, PoppaVic. I'm not sure how to react well to being called a freak, and the work I do with ANS Forth called mistaken. 08:11:29 hehe 08:11:51 don't feel put-upon, I feel the same about C99 and such 08:13:08 I've just been back and 'forth' thru a variety of tools, cpus, platforms and books for too many years 08:13:14 In that case my input can hardly be of value to you. Good luck with your project. 08:13:26 and to you 08:18:34 back laters.... 08:18:37 --- quit: PoppaVic ("Pulls the pin...") 08:34:19 --- join: madwork_ (n=foo@derby.metrics.com) joined #forth 08:51:09 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 08:52:04 --- quit: madwork (Read error: 110 (Connection timed out)) 08:54:59 --- nick: madwork_ -> madwork 09:11:20 --- quit: Ray_work (Read error: 104 (Connection reset by peer)) 09:11:42 --- join: Ray_work (n=vircuser@adsl-66-139-199-228.dsl.rcsntx.swbell.net) joined #forth 09:38:04 --- quit: tathi ("leaving") 09:45:16 --- quit: virl (Remote closed the connection) 09:54:10 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 10:58:11 --- join: PoppaVic (n=pete@0-1pool46-79.nas30.chicago4.il.us.da.qwest.net) joined #forth 10:58:30 Whee! We got the new rifle cookin' ;-) 12:37:06 laters, guys.. I think it's about ready to code-up. 12:37:10 --- quit: PoppaVic ("Pulls the pin...") 12:43:37 --- quit: derv0 (Read error: 110 (Connection timed out)) 12:45:09 --- join: derv0 (n=derv0@proxy1.nscl.msu.edu) joined #forth 15:06:07 --- join: crc (i=crc@pool-70-16-152-203.phil.east.verizon.net) joined #forth 15:06:25 --- mode: ChanServ set +o crc 15:08:28 --- quit: warpzero ("Lost terminal") 15:18:25 --- join: warpzero (n=warpzero@wza.us) joined #forth 16:18:12 --- join: saon_ (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 16:18:22 --- quit: saon (Nick collision from services.) 16:18:25 --- nick: saon_ -> saon 17:44:08 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 17:47:02 hi 17:57:19 hi slava 17:58:13 * slava is porting the infamous raytracer benchmark to factor 17:58:52 I'm not familiar with any raytracer benchmarks 17:59:51 http://www.ffconsultancy.com/free/ray_tracer/languages.html 18:01:51 somebody should port it to forth 18:03:26 to which forth? ;) 18:03:46 retro of course :) 18:03:52 ahh 18:03:58 it will give you an excuse to add floating point words 18:04:17 I have a partial floating point library in place now 18:04:19 or convert it to fixed point 18:04:40 still working on a >float and f. though 18:04:52 the raytracer only uses +, *, /, negate, and sqrt. 18:05:02 oh, and >float in a few places 18:05:18 isn't >float trivial? i mean x87 has an opcode for loading an integer onto the FP stack 18:05:21 then all I'd need to finish coding would be >float 18:05:54 I have a >f and f> for converting between integers and floating point 18:06:04 oh, >float is for strings? 18:06:07 the raytracer doesn't use this at all 18:06:09 but no parser that encodes things like the decimal places 18:06:12 ahh, cool 18:06:23 it doesn't have any liteal floats in the source. 18:06:43 ideally you'd need 3-vectors too, and vector addition and dot product. 18:06:49 otherwise you'll go nuts with the stack 18:20:27 --- join: warpzero_ (n=warpzero@wza.us) joined #forth 18:20:55 --- quit: warpzero (Read error: 113 (No route to host)) 20:05:36 anyone around? 20:05:47 here is my raytracer, http://paste.lisp.org/display/11440 20:05:59 its a factor port of the ocaml and java versions found at http://www.ffconsultancy.com/free/ray_tracer/languages.html 20:09:09 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 20:16:10 hi 20:22:48 Hi. 20:23:00 anything new? 20:23:28 Here? Nothing to report. Working on demo apps and source samples. 20:23:41 Forth? 20:24:15 for Palm I suppose 20:26:12 Sorry, phone call. Yes. 20:26:16 Quartus Forth. 20:28:33 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-134-150.arcor-ip.net) joined #forth 20:29:27 How many Quartus Developers are there? "Join thousands of satisfied developers around the world!" 20:30:02 There are thousands. It's eight years old now, from its origins as PilotFORTH. 20:30:12 That 20:30:22 anybody up for porting the raytracer to their favorite forth? 20:30:28 That's Great 20:30:47 I wish that I had a Forth that thousands of people have used 20:31:16 It feels good. I hope it's helped raise visibility for the language. 20:31:29 how big is the raytracer? 20:31:31 slava, I looked at the code. Weird choice of languages they've got there. 20:31:50 --- quit: Snoopy42 (Nick collision from services.) 20:31:55 --- nick: snoopy_16 -> Snoopy42 20:32:06 Quartus, the factor code is here: http://paste.lisp.org/display/11440 20:32:19 it should be much easier to port to forth than the ocaml and java. 20:32:34 it took me several hours to write it 20:33:15 slava, maybe easier to port, if you know factor! I think I'd be better of to start with the c++. 20:33:28 fair enough. 20:33:53 factor is a forth though. once you know that [ foo ] [ bar ] ifte is IF foo ELSE bar THEN, you're 90% of the way to figuring it out. 20:34:00 About 90% of the factor source there raises questions for me, coming from Forth. 20:34:06 ok then, never mind. 20:34:22 are you familiar with lisp or ML? 20:34:31 do you know about higher order functions like map, each, reduce, and so on? 20:34:43 I know it's a Forth, slava, not trying to diss it -- but it's substantially different, so I'd have to study factor first, and then do the xlation. 20:34:47 slava, I do. 20:34:53 oh, I wasn't taking it as a diss at all. 20:35:13 just trying to understand your background 20:35:19 have you played with functional languages? 20:36:09 slava, not in much depth. 20:36:18 ok. 20:36:32 do you ever write forth code that takes XTs as inputs, and calls the XT, inside some loop body? 20:36:40 I have. 20:36:40 that's basically the essence of functional programming. 20:37:04 Right, I understand the concepts behind it, I've just never immersed myself in it. 20:37:12 ah. 20:41:43 I'd imagine the port to Quartus Forth would take a fair while to render the scene on a Palm. :) 20:42:10 yeah 20:42:23 How long does the factor port take? 20:42:59 about 50 times slower than ocaml 20:43:46 Yes, it wouldn't be too useful as a Palm benchmark except against the C++, though even that might be difficult to port. 22:07:23 --- quit: onetom (Read error: 110 (Connection timed out)) 22:19:30 --- join: onetom (n=tom@ns.dunasoft.com) joined #forth 22:32:19 --- quit: virl ("Client Exiting") 23:21:31 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.1/20040707]") 23:59:59 --- log: ended forth/05.09.06