00:00:00 --- log: started forth/05.11.10 00:02:17 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 00:11:38 --- quit: madwork (Read error: 104 (Connection reset by peer)) 01:50:52 --- join: Raystm2_ (n=Raystm2@adsl-69-149-33-138.dsl.rcsntx.swbell.net) joined #forth 01:51:12 --- quit: Raystm2 (Read error: 104 (Connection reset by peer)) 02:01:30 --- join: Raystm2 (n=Raystm2@adsl-69-149-33-138.dsl.rcsntx.swbell.net) joined #forth 02:01:30 --- quit: Raystm2_ (Read error: 104 (Connection reset by peer)) 03:02:37 --- quit: OrngeTide (Remote closed the connection) 04:12:58 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:18:44 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 04:19:33 --- quit: snowrichard (Client Quit) 04:36:51 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 05:13:18 --- part: snowrichard left #forth 05:34:47 --- join: madgarden (n=madgarde@London-HSE-ppp3546877.sympatico.ca) joined #forth 05:48:03 --- join: PoppaVic (n=pete@0-3pool158-99.nas24.chicago4.il.us.da.qwest.net) joined #forth 05:48:34 PoppaVic: you looked at FICL recently, didn't you? 05:48:41 what did you think of it? 05:48:52 Yeah.. Got it to build,too 05:49:13 bitrot? 05:49:14 I was almost inclined to just accept the use of FICL 05:49:32 bitrot? 05:49:45 I mean, did it give you trouble building it? 05:50:03 I think I had to tweak a few thingies 05:50:08 bitrot is the decay that sets in when a program is not maintained. 05:50:13 new compilers get more picky, etc. 05:50:16 ahh. 05:50:33 IIRC, Ficl is just a MAkfile-based, right? 05:50:43 lemme' peek quick. 05:50:45 yeah. 05:51:46 Yeah.. OK, I recall now.. I found the macosx version around, but didn't want the binary-install, and then noticed a few minor changes to make to the Makefile. 05:52:19 The changes the darwinish folks made were not super, but just enough to make shit work 05:53:13 I've got to eventually alter the "shared library build" rules, but as I have those changes documented in a special tarball, tis not a prob 05:53:54 ah, ok. 05:54:12 I was sort of impressed with FICL4, but the feedback from the author was sort of depressing - he'stoo busy to maintain it. 05:54:42 Well, I was looking at ATLAST, and started to write my own... 05:54:51 But this morning it occurred to me to look around and see what else was out there. 05:55:03 FICL looks like it might be exactly what I want. 05:55:07 right.. I understand the desire, believe me. 05:55:32 I don't wholy understand the vocs-stuff of ficl, though 05:57:22 something in particular? 05:57:26 I always was sorta' bothered about the embeddment of the secondaries-text directly into the program.. Seemed like *A* method, but not exactly ideal. 05:57:33 looks like it's pretty much just standard ANS wordslist stuff. 05:57:56 yeah, he never got to the vocs, order, also type-stuff 05:58:17 I usually think of Gforth as my baseline. 05:58:32 err...which version of FICL are you looking at? 05:58:38 ficl4 05:58:56 I downloaded 4.0.13 and it looks like it has all the usual things. 05:58:58 he got order, but not vocs - etc.. Little things 05:59:39 So, once I saw I could either use ficl4 or base something on it, I dropped back to working more on my guess.c program 06:02:36 Once I get some more polish on guess.c, I'll prolly use it in place of autoshit - I'm managing to write some decent C for data-collection, and being able to build and run on slackware as well makes me confident that I must be doing _something_ right. 06:02:44 hmm...embedding text makes it much easier to port. 06:02:57 if you use some kind of binary format, you have to start worrying about endianness and word size and all that. 06:03:10 yeah, but an option to use a /usr/share/ficl4 file would be lovely. 06:03:16 besides, forth source is so compact it's not much of a loss size-wise. 06:03:26 quite possibly true. 06:03:29 oh. yeah, well, that would be easy to add. 06:04:00 actually, if you're worried about size, you could gzip the text. a gzip uncompressor is tiny. 06:04:15 that would seriously compact the executable, and make embedment more attractive, while also allowing root/staff to improve the engine. 06:04:20 right ;-) 06:06:23 http://rafb.net/paste/results/CfSbNz19.html 06:06:37 above is the latest, cleaned-up method for data-collection. 06:07:14 I'm working on a few internal changes and will use ndbm.h to create a key/data "index" file to use this "database" 06:07:35 on the other hand, looks like FICL is over 1MB of source -- I like to think mine would be smaller. 06:08:01 I'd rather have more source and comments than an obfuscated-C winner, though ;-) 06:08:27 but, yeah... His code-breakout is sorta' funky 06:08:47 oh, sure. 06:09:18 I do think his function names are so long as to start being unreadable again though. :) 06:09:28 well, ok, I haven't looked at much of the code yet. 06:09:35 http://rafb.net/paste/results/hwpXhh17.html 06:09:42 above is the plan for the index-file 06:10:03 Yes, I'd noticed that about his source as well 06:13:10 Now, given a tool like guess.c, and the above datafiles... It should be a fairly simple matter to write a nice, simple Makefile. Similar to the Ficl4 idea of simple. 06:13:53 ..and, of course, once you learn enough, portability becomes much, much easier. 06:14:43 I'm tempted to translate the autoshit "config.guess" script, but trying to trace and xlate sh-shource makes me crazy. 06:19:47 tathi: let me know when you start beating or writing your ficl4 parallel, I'd be willing to help, and it's not a bad idea anyway. 06:21:24 ha! he has LZ compression in ficl already. 06:21:26 :) 06:21:37 FICL_WANT_LZ_SOFTCORE 06:21:38 yeppers - in the dict, I believe 06:22:11 He's got some good ideas, for sure. 06:22:44 err...I mean for the embedded text. set that #define, and gets stored LZ compressed. 06:24:03 yeah, well - if he supports it one place; supporting it in another makes sense ;-) 06:25:15 I've even heard of forths with external datafiles as dictionaries. That too seems sensible, where systems have drives. 06:26:11 Anyway, yeah.. Ficl seemed very, very close to what I want. And, I agree with everything you've mentioned as "issues". 06:26:26 yeah, looks like a nice system. 06:26:45 I think I'm going to finish mine anyway. 06:26:53 Not as pretty, but I'm having fun writing it. 06:26:54 ButIreallyHateTheseOverlyLongFuncs() 06:27:10 I'm with you there. 06:27:29 well, let me know when yers is done.. Are you then going to try a variant ala' Ficl or what? 06:27:41 code is more readable with longer names, but it's also more readable if it's small enough that you can see a whole function at once. 06:28:16 pretty much like FICL. 06:28:29 umm... I disagree on the long==readable, but yeah. Judicious naming and leaders_foo() can make a huge diff 06:29:02 oh.. I remember, now.. I had to beat up his main() for ficl. 06:29:08 sorry, I didn't mean looong. I just meant long enough to convey useful information. 06:29:16 right ;-) 06:29:43 I do get awfully tired of folks avoiding vowels in names. 06:30:16 hmm...actually I think I only want one thing that Ficl doesn't do. 06:30:41 I'd like to be able to compile multiple systems with different core capabilities. 06:30:45 And, even in C, I sorta' think of Forth... As pertains names, anyway. str_copy() and str_comp() seem more readable and concise. 06:31:00 tathi: core being..? 06:31:24 It looks like when you do ficlCreateSystem, you always get the base forth system. 06:31:26 you mean vocs or abi? 06:31:34 ahh, yes. I agree 200% 06:31:38 Which is chosen by #defines in ficl.h. 06:32:10 yeah, I never liked ANY forth that shoveled 80% of the system into the baseline 'forth' voc 06:32:12 I'd like, for instance, to have a regular forth interpreter, but at the same time, have one with, say, no file i/o 06:32:20 exactly 06:33:07 well, with Ficl you can build a stripped-down system. 06:33:16 I think it would help if folks could see vocs/wordlists as "namespaces", but the mechanisms to reach them need minor extension. 06:33:25 it just assumes that all the systems that you want to instantiate will be similar. 06:33:42 yep, or even different w/i 06:33:49 But, as he says in his docs, most people just use one system, with the default settings. 06:34:08 well, of course - the way his code is built, it's hard not to 06:34:09 I can see that it wouldn't be a high priority to support it. 06:34:33 well, sure, but most of the time, that IS what you're going to want. 06:34:34 I think. 06:35:12 Something else to consider: I've examined a few vocs and several forths... ANd, it seemed as though no voc every had more than 256 words. Interesting observation. 06:35:18 If you're using it as a scripting language for an application, you may provide multiple consoles, but probably they're all going to be similar in functionality. 06:35:38 I would think so. 256 is a lot of words. 06:35:45 sure, but then too: there is really no reason NOT to write it such that it acts as a metacompiler. 06:36:15 yeah, a lot of 'forth' vocs come really close - and it makes for a PITA to search, let alone read 06:36:22 sure there is -- it's simpler in C to just #ifdef it out than to have to write all the runtime support code to allow people to pick-and-choose at runtime. 06:36:57 I can see that, once one decides that C _is_ the baseline 06:37:13 C is what it is written in. 06:37:21 otoh, there is no reason not to set up to host/target generate. 06:37:43 tathi: I meant forths (plural), ficl definitely impresses me. 06:38:20 Now, otoh... Gforth has a vgen or something - but it's apparently not a cross-compiler or host/target mess: it just loads an image. 06:39:23 The problem gets hugely more complicated if you want to metacompile and save executables or libraries. 06:39:38 I have to look forward to seeing your c-version. Ficl was impressive, and I expect yours to offer other ideas. 06:39:52 yes, I know.. I understand that part. 06:40:21 ok, never mind. I suppose if you go to a vm-generator, you can just as well add native output for only certain platforms. 06:40:30 without dropping support for a generic version. 06:40:34 hmm... 06:41:03 I suspect that relying on the c-compiler to generate the core, (host/target idea), and then generate portable pcode... THis would sorta' obviate the mess. 06:41:53 anyway. I'm not trying for anything fancy here. Don't need to save images or whatnot, I just want a little scripting engine for a game. 06:42:06 And, of course, once you've pcode in a well-documented and portable format, sneaky-bastards can write a filter to really compile native-apps for whatever. 06:42:40 Yeah, a decent scripting-engine is a plus ;-) 06:43:06 The only interesting part is likely to be that it starts out with an empty dictionary, and will have an API for the C initialization code to load whatever core stuff it needs. 06:43:29 That itself is a huge step and sounds very, very interesting 06:45:23 Do you know what the Ficl API is like for writing new primitives? 06:45:47 umm.. Not offhand, doesn't look too ugly (sans the longassed names). 06:46:38 Seems to me that it's mostly about func-type and pointers. 06:47:09 I seem to recall he's got some notes or docs and maybe a sample. 06:48:08 OK, I'll just look then. 06:48:40 Oh, duh. I can just look at primitives.c 06:49:12 hehe 06:49:24 Let me know what yah think of it. 06:49:39 I'm mainly curious about stack checking (overflow/underflow) 06:50:04 He has a macro FICL_STACK_CHECK(stack, popCells, pushCells) 06:50:14 yeah, a lot of forths are either [over/under]kill in that area 06:50:31 I'm pretty sure he just uses arrays 06:50:44 or maybe it was lists.. I can't recall right now 06:51:17 hmm...but he uses ficlStackPushInteger and the like to access stack elements. 06:51:23 I much prefer ATLAST's solution. 06:51:41 oh.. I recall now..He used a variant on my generic-stack stuff. 06:51:50 what did ATLAST do? 06:52:19 it has macros S0, S1, ... giving a pointer to the top elements of the stack. 06:52:34 ahh.. Not much of an issue 06:52:34 so that they're usable as an lvalue or an rvalue. 06:52:48 and then a macro Pop (which is really drop). 06:52:54 right. 06:52:59 I've done that 06:53:15 so...even if you have a union it's "S1 = S1 - S0; Pop;" 06:53:28 instead of two calls to ficlStackPopInteger and one to ficlStackPushInteger. 06:53:38 and it doesn't pop and push the stack unnecessarily. 06:54:21 oops. Ignore the bit about unions there. 06:54:44 S1.int = S1.int - S0.int or something. 06:55:30 --- join: madwork (n=foo@derby.metrics.com) joined #forth 06:55:37 you'd need that, UNLESS you use a "tracker-stack".. This is one of the ideas I've been considering 06:56:42 using a tracker-stack with a char-width would be fine, but you definitely add overhead in remembering/testing/recalling how shit is added 06:56:43 I'd rather just use the traditional forth approach of an untyped stack. 06:56:47 use it as whatever type you want. 06:56:48 right. 06:57:00 sadly, that can get really ugly, really fast 06:57:15 ..because folks want to compile literal addresses 06:57:19 If you've got memory address checking, the worst you can do is trash your own heap. 06:57:54 I don't see how literal addresses are a problem. 06:58:07 Oh. Saving pcode. right. 06:58:11 oh.. my bad: Again, I was thinking of pcode ;-) 06:59:09 Hmm...you could just save the starting address, and relocate anything that looks like an address on load. 06:59:12 I've been mulling alternatives to allow for it, and nothing I've cogitated really seems "great". 06:59:35 It could be that the kicker is to just think in terms of host/target. 07:00:11 Or take a 68K/PPC-like approach and make all addresses relative to a ToC (Table of Contents) register. 07:00:35 Then you can just pretend the start of your image is address 0. 07:00:35 yes, I was thinking of using the "program base" as the one and only "base-address" 07:00:40 right. 07:00:53 or 'main()' or some silly thing 07:00:54 yeah. It seems like the only half-way decent solution. 07:01:34 short of going the "full-tracker" route, like most of the OO languages do. Track the types of everything, so you know where all the pointers are. 07:01:38 well, I'd toyed with the idea of an inacessible (internal) "pointer stack", and referencing from that, too 07:02:16 hmm... 07:02:21 Frankly, I've about concluded we could suffer MORE stacks with less pain. 07:02:56 and, indeed, once that idea grips you, then adding the idea of stack-manager words becomes interesting as well. 07:03:27 int stacks, ptr stacks, "string" stacks, etc. 07:03:32 right. 07:03:47 you can transparently separate out types from one stack to several. 07:04:16 I always felt ANS got a good idea with "wordlists", but then lost it all over with the mixed datastack/returnstack snarfling 07:04:17 err...barring any type conversion, of course. 07:04:21 right. 07:04:35 mixed data/return stack snarfling? 07:04:42 oh, >R R> etc. ? 07:05:04 yeah, mixing types and interops in places that are downright dangerous as often as not 07:05:39 ..ranks up there with casting a string as an int or as a func-ptr and such 07:06:04 yeah...I mostly just use the rstack stuff as a means to get things out of the way. 07:06:10 an alternative to PICK and ROLL and such. 07:06:27 mornin 07:06:37 I'm pretty sure some people do control-flow structures with it though. 07:06:42 morning, sproingie 07:06:53 return stack is used all over the place for control flow stuff 07:07:09 THROW and CATCH use return stack tricks for one 07:07:55 yeah, the rstack is used in a lot of freaked places 07:08:37 I don't see it as being a problem. 07:08:42 it's perfectly sound 07:08:48 But, being a forther, I'm not big on protecting programmers from themselves. 07:09:09 some forths don't have a separate rstack, ans doesn't mandate one 07:09:09 true, and I've never had issues with "scream and die" crashing a user. 07:09:36 sproingie: really? weird - what the hell would they do? 07:09:45 interleave it with the data stack 07:09:46 just like C 07:09:58 call threaded? 07:09:59 stuff like CS-ROLL does need a logically separate control flow stack 07:10:16 threading model is irrelevant, but yes it'd probably be call-threaded 07:10:34 well, it would become relevant, but yeah.. I can see that. 07:10:52 interesting. 07:11:04 CS-ROLL hurts my brane. i can't see how that kind of trickery came to need to be standardized 07:11:16 which is CS-roll? 07:11:20 * Ray_work just saying hi. 07:11:23 stack-effect? 07:11:26 hi ray 07:11:29 does a ROLL operation on the return stack 07:11:31 more or less 07:11:36 ohh.. ahh 07:11:47 most likely use for it is multitasking 07:12:21 well, as I mentioned to tathi - I've never seen a reason not to write portable and extensible stack-shit. 07:12:43 adding stacks and insuring minimal facilities seems pretty trivial. 07:12:44 it never talks about the return stack, just a "control flow stack" which may or may not be the rs ... the standard is awesomely vague 07:13:03 * sproingie has been reading the common lisp hyperspec. now there's the antithesis of vague 07:13:04 yes, I never did fall in love with the ANS stuff. 07:13:14 CLHS is a triumph of anal-retentive overspecification 07:13:21 lisp mandates more, eh? 07:13:36 yeah.. Sometimes that can be good. 07:13:38 not so much what it mandates, as that the precise behaviors of everything is spelled out 07:13:44 yeppers 07:14:10 even the discussions about parts that are vague are themselves in a very standard detailed format 07:14:19 That seems sensible in a universe where umpty-folks can contrib in a uniform, black-boxed fashion 07:14:31 it's over a thousand pages as a result 07:14:33 (which is what forth should be) 07:14:56 sproingie: I doubt the forth CORE and "standards" would go that far. 07:15:00 of course common lisp includes a pretty big base library, forth includes nothing 07:15:07 right 07:16:10 scheme does all right and its spec is only 50 pages 07:17:10 it's vague as hell in spots, but common lisp hasnt been updated since 94, just like forth. scheme is still revising. R6RS is coming out real soon now 07:17:26 * sproingie . o O ( RSN for how many years now ) 07:19:48 tathi: have you a suggestion for a test that will report on alignment/boundaries? 07:19:59 slava's got factor, which is pretty neat. it's a sort of unholy love child of lisp, forth, and apl 07:20:09 ewww 07:20:17 factor is interesting. 07:20:18 it's pretty good actually 07:20:22 Kind of a weird mix, but interesting. 07:20:45 slava's been on a theoretical math kick lately tho .. what i want is for him to make the parser smarter so i can read a quotation and not just a token 07:20:55 what I recall of reading about APL makes me want to run off screaming 07:20:55 yeah, I know. 07:21:06 I wish it had more command-line conveniences and less fancy math stuff. 07:21:06 coz i want to make it smalltalkish. [ foo ] ifTrue: [ bar ] 07:21:10 heh 07:21:24 right now that's almost impossible, since ifTrue: has no way to read the next quotation 07:21:41 quote-stacks ;-) 07:21:55 he's not big on the commandline, the graphical listener is his thing 07:21:56 yeah 07:22:01 Good morning. ANS does mandate a separate return stack. 07:22:03 I had noticed that. 07:22:14 It still doesn't work on my box. 07:22:18 tathi: ideas? 07:22:24 Quartus: it mandates a logically separate one. i thought it was allowed to be interleaved. 07:22:26 I got the contrib/x11 stuff working, but it's pretty slow here. 07:22:43 PoppaVic: not of the top of my head. 07:22:51 sproingie, it's not. Adding an item to the return stack can't affect DEPTH. 07:22:59 PoppaVic: maybe structure sub-elements? 07:23:08 ok, please think about it. Yeah, I was wondering about that 07:23:18 huh. i guess the ones that do interleave it go through some weird gyrations 07:23:26 or maybe they're just not compliant 07:23:33 sproingie, I've never seen an implementation that did; that'd be strange. 07:23:34 struct-memb offsets might report it... How about malloc-type returns then? 07:23:46 PoppaVic: I'll check c99...I'm pretty sure different aligment constraints hold in different places. 07:23:55 cool. Thanks. 07:23:58 Quartus: i've only heard of them being referenced, never actually seen one 07:24:23 IIRC malloc is required to return an address that is aligned well enough for ANY structure or whatever. So it might be useful as a maximum. 07:24:34 Not sure what standard that is (POSIX?) 07:25:00 malloc isn't even part of C, is it? 07:25:15 and posix normally doesn't concern itself with alignment 07:26:53 posix won't care, I'm sure 07:27:02 malloc is libc, not guts. 07:27:26 i wouldn't make assumptions about alignment, especially when it comes to something as frequently-replaced as malloc 07:27:53 i imagine glibc, dlmalloc, and boehm malloc all behave differently 07:28:04 no. I'm thinking of the C-core to my code. 07:29:08 you writing your own? 07:29:44 using C to learn about the platform and C itself before building a ficl or forth, yeah 07:29:46 there's a thought for forth gc. make ALLOCATE call boehm malloc. problem solved 07:30:06 probably not the most efficient approach tho 07:30:26 yeah, the solutions w/i forth itself should be transparent - or black-boxed, anyway 07:37:51 slava's definitely moving away from lisp for factor tho. he's talking about getting rid of conses 07:38:12 as far as I know, tathi's right -- malloc has to return a universally-aligned address. 07:38:28 doing everything with arrays and vectors. feh. wants to become another fortran i guess 07:38:48 sproingie, sounds like another APL 07:39:14 yep. he's definitely going down a APL route with vectors 07:41:19 if vectors are smart enough, they can be as good as lists. even lisp uses vectors whenever they don't really need a recursive structure 08:31:16 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 08:56:14 --- join: OrngeTide (i=orange@rm-f.net) joined #forth 09:23:57 * Ray_work needs to learn more about vectoring. 09:24:12 Hey Ray. Books yet? 09:24:38 They are addressed to my home. I won't know untill end of business. 09:24:42 Ok. 09:25:01 But I can't see them being any later then today or tomorrow. 09:25:24 Let's hope. I'm still waiting on several things from the US, which makes me wonder if there's a slowdown. 09:25:33 * Ray_work is excited and hopes it's today, cuz I go to Waco tomorrow and I won't have time to enjoy opening the box :) 09:29:21 Hope so too! 09:47:58 --- join: segher (n=segher@blueice1n1.de.ibm.com) joined #forth 09:51:01 --- quit: PoppaVic (Nick collision from services.) 09:51:14 --- join: PoppaVic (n=pete@0-1pool47-116.nas30.chicago4.il.us.da.qwest.net) joined #forth 09:51:30 goddamned isp 10:43:07 * PoppaVic harumphs 10:43:09 --- join: humulus (n=humulus@xover.htu.tuwien.ac.at) joined #forth 10:46:06 hmm... Testing is always better than guessing, but I hate calculating sizeof AND padding. 10:56:35 --- part: segher left #forth 11:11:23 I guess I need a book/chow break. I'll call it a knight. tathi: if you get anywhere with ficl4, or your own stuff, talk to me ;-) 11:11:26 --- quit: PoppaVic ("Pulls the pin...") 12:23:54 --- join: snoopy_17 (i=snoopy_1@dslb-084-058-175-147.pools.arcor-ip.net) joined #forth 12:26:34 --- quit: Snoopy42 (Nick collision from services.) 12:27:57 --- nick: snoopy_17 -> Snoopy42 15:25:37 --- nick: Raystm2 -> tiff 15:48:35 --- nick: tiff -> Raystm2 17:15:18 --- quit: tathi ("leaving") 17:35:11 --- quit: lop (Client Quit) 18:54:30 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 19:31:51 --- quit: snowrichard ("Leaving") 19:32:59 --- quit: virl (Remote closed the connection) 19:42:59 --- join: airbrush (n=morph@216-237-213-21-access-r12-ad.northstate.net) joined #forth 19:43:32 hello 20:24:48 anyone here? 21:29:48 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 21:34:34 --- quit: snowrichard (Client Quit) 22:35:40 --- join: amca (n=plump@as-bri-3-33.ozonline.com.au) joined #forth 23:52:11 --- join: Raystm2_ (n=Raystm2@adsl-69-149-32-149.dsl.rcsntx.swbell.net) joined #forth 23:59:59 --- log: ended forth/05.11.10