00:00:00 --- log: started forth/05.09.17 00:00:15 think you could port this to a forth? 00:01:42 well there are a few other things i want to code first but i'll keep it in mind 00:02:32 it took me a couple of hours to port to factor 00:03:05 mainly because i kept on making stupid typos and had to keep comparing outputs of various functions with the ocmal code 00:03:51 also some of the stuff there is a pain with a stack 00:04:04 i'd bet 00:04:31 it's a pain to port stuff from other languages cuz it leads to more stack juggling than you'd normally do it 00:04:41 yeah 00:04:44 and trying to figure out a different way to solve the problem can take time.. 00:04:53 i think i can get the running time down to about 10 seconds with little effort 00:05:03 like the circle drawing algorithm 00:05:03 making it faster will be hard work 00:05:13 i tried to do it in a forthish way 00:05:25 pissed me off cuz i couldn't fix the stack juggling problem 00:06:00 gave up and said to myself that i'd get chuck moore to code the forth version of the algorithm :P 00:06:39 maybe i'll try again someday 00:07:08 ocaml runs the code in 1.2 seconds, C++ in 2.4, and sbcl in 5 00:07:40 heh 00:07:55 it runs in 1.0 seconds in forth 00:08:05 i don't think there's a forth faster than ocaml 00:08:05 after completely redoing the algorithm ;P 00:08:16 no, the point of this is to compare compilers, not algorithms 00:08:20 a better algorithm would be much faster 00:08:40 its like that silly recursive fib benchmark, but more sophisticated 00:09:09 --- quit: Quartus (Remote closed the connection) 00:35:43 --- quit: crc (Read error: 110 (Connection timed out)) 00:39:40 --- quit: sproingie (Remote closed the connection) 01:14:09 slava? did you get the link to the 'code'? 01:14:17 yes 01:14:25 ah, ok. 01:17:40 I think I rename it to UIEPIX(Unstable Incomplete Experimental PIX), so that hopefully no moron use it. 01:17:55 or builds a view from it. 01:18:34 don't worry, nobody will use it ;) 01:19:57 in which context slava? pix or xell? 01:20:49 the toy code you posted 01:52:07 did you get a better feeling for xell? I mean do you know now more about xell? 02:15:46 --- join: crc (n=crc@pool-70-20-245-217.phil.east.verizon.net) joined #forth 02:19:46 morning crc :) 02:45:25 --- quit: crc (Read error: 101 (Network is unreachable)) 03:19:49 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 04:25:32 --- join: crc (n=crc@pool-70-110-139-204.phil.east.verizon.net) joined #forth 04:36:21 hi crc, what's shaking? 05:28:57 --- join: PoppaVic (n=pete@0-1pool67-83.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:29:17 G'day 05:52:54 Anyone awake? 05:54:38 * crc is awake 05:54:54 Cool. Wanna' toss an idea around some? 05:55:27 * crc can do that 05:56:04 Outstanding.. I'm considering an alternation to what a "stack" catually contains (below the user-level) 05:56:09 actually, two 05:56:53 What I'm considering is arrays-of-struct, and using a 'tagfield' in them to mark whom is what size. 05:56:58 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:58:12 so, we may have types of 'u', 'n', 'd', 'a')bsolute-address, 'r')elative-address, and whatever else we'd want. 05:58:42 Can you see any huge issue with this? 05:58:58 so a stack that's aware of data types 05:59:00 (or just see a better set of tags?) 05:59:34 right, because our guts-code would want to never store an absolute-address in a struct, only on the stack. 06:00:11 * crc can see how that would be useful, especially while dealing with interfacing to languages other than Forth 06:00:45 Well, I'm thinking it might only be useful where we definitely interface/interactively-compile with humans. 06:01:11 ok 06:01:17 Certainly we should be able to abandon the concept once code is burned or recompiled to native or whateer 06:01:38 I don't see any real issues arising from adding types to the stack 06:02:04 (providing of course that conversions between types can be done easily...) 06:02:25 --- mode: ChanServ set +o crc 06:02:25 ok. Any types you can recommend, as in more or less? I'm not sure, but it seems we'd like it pretty coarse-grained, right? 06:02:45 yeah 06:04:02 An example would be strings. I want to build support for utf8/ascii, but also wchar_t. And, it seems a fine place to differentiate. 06:04:20 I'd say that at a minimum there should be signed and unsigned integers, strings, relative addresses, and absolute addresses 06:04:23 yeah 06:04:32 and reals 06:04:38 (doubles) 06:04:59 * crc considers this a bit... how will a word like "+" operate in a type-aware environment? 06:05:13 I never was too comfortable with doubles and reals running around together. 06:05:51 well, yeah - that too COULD change. Or, we'd be more strict about ( n n -- n') 06:07:55 I think it opens a door to some interesting ideas. 06:08:27 brb 06:14:16 ok. 06:14:35 hmm, yeah.. I think you've hit an intriguing alternative/corollary 06:15:21 * crc recalls strongforth which was a forth with data types 06:15:33 huh. Never seen it before. 06:15:54 http://home.vr-web.de/stephan.becher/forth/ 06:17:25 downloading it *sigh* damned zip-files 06:19:44 http://home.vr-web.de/stephan.becher/forth/intro.htm 06:19:51 has his data-type "tree" 06:22:11 hmm.. And, since I am basically writing code for the lowest-level (opcodes), all we need-do is check or generate. Interesting. 06:23:19 This also suggests we prolly can dump the idea of the extra stack for reals. 06:25:00 "velly inter-estink" 06:27:50 This also suggests, (to me), that we would have to be very careful to insure that we don't madly check the stack after every opcode. And, perhaps we need a "check-input" and "check-output" set of opcodes. 06:29:21 crc: so.. Humph, strongforth would seem to suggest his code really DOES check every step. This doesn't sound optimal, does it? 06:29:57 nope 06:30:09 a lot depends on useage though 06:30:46 * crc doesn't know how the developer of strongforth tends to write code 06:30:51 I can see a bit of code at every entry checking at-entry, for depth, and THEN checking for args. But, it seems only sensible during compile-mode, doesn't it? 06:31:04 yes 06:31:18 interesting. 06:32:20 And, we MIGHT want to add some words so that users colon-defs can do the same, but it seems really unlikely and clumsy. 06:34:18 I don't see an issue with the tagfield idea, though. I suspect we'd want, during a colon-def, to work from some sorta' tracking-structure - discarding when we finish defining the word or using it to help typify the failure. 06:34:46 hmm (and humph) 06:35:27 ahhhh... He MUST do that anyway, because he's got control-flow tags as well. 06:38:54 hmm.. I'm trying to envision this - I just can't see it being a low-level, opcode-issue. 06:39:21 except... ahhhh. 06:39:34 OK, I can see how we involve the 'opcodes'. 06:40:24 All we need is to store a short string like "ii:i" along with the opcode-id "+" 06:40:34 (for example) 06:42:36 Doesn't a "binary operator" vary from a "unary operator" only in the number of arguments? (suggesting the same for "ternary", etc?) 06:42:59 I believe so 06:43:35 hm.. { "2,ii:i","+" } 06:44:32 { "1,A:au", "count" } 06:44:52 interesting. 06:47:35 I think the idea needs wider debate, but yeah.. I can envision storing "rules" with the opcodes or colon defs. Perhaps in the headers. And, it only matters in the headers/lookup pre-execute/compile. 06:49:42 In fact, it seems most likely that only 'start-def' and 'end-def' interpretation cares, tracks, simulates. 06:51:53 as far as I can recall, we'd need affect only ":", "does>", ";" and "is" (deferred) - unless I missed something. 06:55:54 You might need to affect "create" as well 06:56:02 crc: Unless I am horribly confused, then... We need only store some extra data in the interactive-universe, (which suggests headers), and we can simply change the "compiler" behaviors. 06:56:11 Yes, you are prolly quite correct. 06:58:17 OK. This then raises a question which plagued me since the late 70's. Stack-notation... Strongforth seems to have usurped that for his methods. Can you "see" a sensible solution to proper stack-expects/effects w/o mucking the std notes? 06:59:11 Part of the issue is "stack-needs", "stack-result", and "look-ahead" 07:00:11 I'm still trying to find a decent way to write stack comments 07:00:56 yeah, I've never seen a good system for forthish 07:01:02 http://www.forthworks.com/quick_ref.pdf has my current form, which is still evolving 07:01:13 loading 07:01:51 there's still too many places where confusion as to the symbols can arise 07:02:34 yes, I see. 07:03:11 well, dpans also throws C:, D:, R: prefixes at you. 07:03:25 yeah 07:03:35 * crc doesn't like the dpans stack commenting 07:04:07 iirc, I setup commonForth to use a set of macros such as D( a b - c ) 07:04:21 but it is nust unsatisfying. 07:04:26 nust/just 07:05:27 I can also see a form of: ( ...; ... ) - but this STILL seems depressing. 07:06:43 even doing (abc;r1r2r3 --- ;r1) seems a bit confusing. 07:07:59 If we could come up with a decent, consistent notation, we could consider the typed-stacks as a mere option. 07:10:34 (boy, I hope there is a log of this topic today) 07:14:42 there is 07:15:54 cool 07:17:27 http://tunes.org/~nef/logs/forth/05.09.17 07:17:38 excellent 07:19:07 well, if we use "%c%u" for each arg, we've got part of it settled. 07:19:33 I do not really care for intermixing RP and DP info, myself. 07:21:38 ( ; ) _still_ leaves us short an input-string(s) possibility. 07:21:58 hmm 07:23:43 ( ; ; ) gets closer 07:24:52 in fact.. hmm 07:27:00 "variable" ( D:---; R:---; I:w1--- ) // seems sensible. 07:30:50 you would certainly need to suffer some replicated types of %c between the three areas, of course. 07:31:22 ..which strikes me as unpleasant, and almost insufferable. 07:31:51 It'd not be an issue if they meant the same thing across the universe 07:35:24 Can you think of a worst-case depth-requirement? I'm thinking 3 or 4, but not sure. 07:37:15 I mean for a stack-display - I already know things like 'pick' will skew it. 07:38:12 the worst I can think of is 6 (2ROT in ANS) 07:38:19 ok. 07:38:25 Most things don't seem to go beyond 4 though 07:39:09 (actually, with a real "double" data type, 2ROT would only take 3, since doubles in Forth take 2 cells) 07:39:41 If you interface with external libraries, the headache can grow though 07:40:10 Some of the Windows API's take 10+ arguments :( 07:41:33 Right. But, it seems very likely that we need no more than 4 deep x 2 directions x (1 typechar + 1 digitchar) == 16 chars per section-of-info. 07:41:48 TEN ARGUMENTS?!? ARE THEY INSANE?? 07:41:50 sorry 07:41:53 geezus. 07:42:25 well, screw 'em - use structures and an interface-func 07:42:44 :) 07:43:38 crc: you have no goddamned idea how I fight-uphill in C, trying to tell folks that they can use structures (particularly local), to pass less and do more. 07:44:33 the exceptions to this are the sscanf/printf series - va_arg 07:44:53 ..and even that could benefit 07:45:26 yeah 07:45:36 structures are handy :) 07:45:48 I can't work w/o them 07:46:33 Speaking of structs... 07:46:52 Failed to open /DEV/metabuilder/fovm/structs.h for reading: No such file or directory 07:47:06 http://rafb.net/paste/results/S5NinH27.html 07:47:11 dumbass *sigh* spank me. 07:48:53 I've two strz structures: ascii/utf8 and wide. We'd need something new for this type-tracking/stack-effects stuff. Any suggestions are welcome. 07:52:23 I'm even considering restricting wchar_t strings to our usual 1..256 length. 08:03:06 I'm almost positive we need a breakout on this file. I'm beginning to think we need an internalized structs.h and a public-relations version. 08:29:55 Yeah.. I may need a breakout. Most of this stuff is better off in a header under sys/ where a casual-user never sees it. 08:51:22 what's wrong with a casual user seeing this stuff? 08:51:57 I'm not sure. But I am sure it's getting too complicated & involved for casual-use. 08:52:43 maybe I'm just getting defensive and paranoid. *sigh* When yer working by yerself it's a balance between flexible and paranoid. 09:29:52 --- join: PoppaVic_ (n=pete@0-1pool74-167.nas24.chicago4.il.us.da.qwest.net) joined #forth 09:30:44 Goddamned isp 09:30:47 --- quit: PoppaVic (Nick collision from services.) 09:30:57 --- nick: PoppaVic_ -> PoppaVic 09:36:08 --- join: PoppaVic_ (n=pete@0-1pool46-69.nas30.chicago4.il.us.da.qwest.net) joined #forth 09:36:41 --- quit: PoppaVic (Nick collision from services.) 09:36:44 --- nick: PoppaVic_ -> PoppaVic 10:03:40 --- join: crc2 (i=crc@pool-70-110-204-190.phil.east.verizon.net) joined #forth 10:11:36 OK. I give up today. Maybe we'll hear more tomorrow. 10:11:39 --- part: PoppaVic left #forth 10:25:45 --- quit: crc (Read error: 110 (Connection timed out)) 10:28:19 --- nick: crc2 -> crcv 10:28:23 --- nick: crcv -> crc 10:28:23 --- mode: ChanServ set +o crc 10:52:15 --- join: crcv (i=crc@206.148.24.70) joined #forth 10:52:36 --- quit: crc (Nick collision from services.) 10:52:38 --- nick: crcv -> crc 10:52:40 --- mode: ChanServ set +o crc 11:42:36 --- join: gustavderdrache (n=gustav@nat-11.sr.resnet.unca.edu) joined #forth 11:50:49 --- join: crcv (i=crc@206.148.24.105) joined #forth 11:58:33 --- quit: crcv () 12:00:16 --- join: crcv (i=crc@pool-70-110-156-36.phil.east.verizon.net) joined #forth 12:07:14 --- quit: crc (Read error: 110 (Connection timed out)) 12:07:31 --- nick: crcv -> crc 12:17:08 --- part: gustavderdrache left #forth 12:57:29 --- quit: virsys (Connection timed out) 12:57:47 --- join: virsys (n=virsys@or-65-40-176-212.dyn.sprint-hsd.net) joined #forth 15:06:59 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 15:06:59 --- mode: ChanServ set +o JasonWoof 15:07:36 anybody know a good internet phone company for the US? 15:08:56 skype 15:20:36 lol... 15:21:35 hi 15:24:15 virl: what? 15:24:27 I developed a little calendar database for rf. 15:24:38 thinfu? hae? 15:24:48 the lol? what was funny 15:25:00 --- quit: Topaz ("Leaving") 15:25:51 what sort of database is this calendar database? 15:25:56 is it like a schedular? 15:26:06 write down todo notes etc? 15:27:50 yep, that's it. 15:29:10 JasonWoof: there's only a handful internet phone companies that are halfway decent.. there's skype, at&t/bell, and like two others.. 15:38:50 --- part: thinfu left #forth 15:42:56 hi all 15:43:48 hi crc 15:50:57 * crc has been working on a quick reference for retroforth 15:58:06 http://www.forthworks.com/quick_ref.pdf 17:42:38 --- quit: tathi ("leaving") 18:16:37 --- join: tattrdkat (n=virsys@or-65-40-181-88.dyn.sprint-hsd.net) joined #forth 18:19:21 --- quit: virsys (Read error: 104 (Connection reset by peer)) 18:31:59 --- part: slava left #forth 18:44:26 --- nick: tattrdkat -> virsys 20:00:27 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-133-148.arcor-ip.net) joined #forth 20:01:56 --- join: thinfu (i=thin@bespin.org) joined #forth 20:01:56 --- mode: ChanServ set +o thinfu 20:02:39 virsys: do you code forth? 20:03:25 thinfu: not in a couple of decades.... 20:04:22 been trying to get back into it, but.. you know how it goes.. its one or another that keeps me busy.... 20:04:31 virsys: have you checked out retroforth? 20:04:42 i am dling it right now 20:05:04 whats your preferred OS? 20:05:17 linux... 20:05:21 ok good :) 20:18:27 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 20:18:31 --- nick: snoopy_16 -> Snoopy42 20:26:54 yeah so check out retroforth its the sweetest forth right now and probably the most active 20:27:12 new things happening everyday 22:41:07 --- quit: JasonWoof ("off to bed") 23:59:59 --- log: ended forth/05.09.17