00:00:00 --- log: started forth/05.09.18 02:55:01 --- quit: madwork (Read error: 110 (Connection timed out)) 05:33:41 --- quit: madgarden (Read error: 110 (Connection timed out)) 06:35:03 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 06:35:04 --- mode: ChanServ set +o JasonWoof 06:55:32 --- join: PoppaVic (n=pete@0-1pool47-41.nas30.chicago4.il.us.da.qwest.net) joined #forth 06:58:11 G'day, folks 07:29:39 * PoppaVic sighs 07:48:13 --- join: tgunr (n=davecl@66.160.179.246) joined #forth 08:02:34 --- join: amca (n=plump@as-bri-4-1-194.ozonline.com.au) joined #forth 08:12:40 damn.. SLow day. 08:13:17 Hey. What you been up to? 08:13:34 Working on the headers.. Getting to impasse 08:13:58 I'm a trifle concerned about at least 2 issues... 08:14:12 Oh? 08:14:19 Which ones? 08:14:32 1) I wouldn't want 2+ vm's to repeat core-dictionaries/vocs; 08:14:50 2) Our debate the other day on stack-typing 08:15:29 Why would you need 2+ vm's? 08:15:42 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 08:15:44 Doesn't matter, but think of 'threads', etc. 08:16:15 Ah, yes 08:16:30 And could you please refresh my memory about #2? 08:16:47 Imagine 1 program running several vm's - we'd not want their CORE vocs/data to duplicate, and we'd want eachs extensions to remain involate. 08:17:02 * amca nods 08:17:22 http://tunes.org/~nef/logs/forth/05.09.17 08:17:38 Search for PoppaVic in above, and you can sorta' get the feel for it. 08:17:46 ok 08:19:42 So would the stack have the data in it or references/pointers to the structs? 08:19:44 --- join: madgarden (n=madgarde@Kitchener-HSE-ppp3577624.sympatico.ca) joined #forth 08:20:14 the 'stack' would most likely be an array of structs, with a tagfield and CELL 08:21:05 ..and, per our discussion, it seems likely that only the "compiler" would test, and the "interpreter" would just check for the leadins. 08:21:46 Mind you: it looks like it's almost 100% a human/source-input issue. 08:22:21 what do you mean by "human/source-input issue"? 08:24:02 It would not matter to compiled words, except to see req. data on stack; and it wouldn't matter at all to opcodes/primitives. 08:24:32 So, compiling itself slows some, but catches more and checks better. 08:25:15 Wouldnt it be easier to have Forth "structs" only represented on the stack as pointers so that you only are pushing type aware primitive types on the stack? 08:25:43 This also seems to allow us to get control over comma'd and bang'd and fetched data - addresses could be absolute on the stack, and otherwise relative - I think.. 08:26:41 amca: run that past me again, please? I didn't plan on letting the users even know the tags were there. 08:28:25 Well you know how in C with arrays (I dunno about structs) the array parameter is passed as a pointer 08:28:59 ok 08:29:01 Well I was thinking that arrays and structs could be pushed onto the stack as pointers. 08:29:19 Reduce the amount of type logic Forth has to know about 08:29:39 hmm, yes - if I understand you: the typing would allow the STACK to use "absolute" addresses. 08:30:10 embedding literals and within the bytecode, we'd store offsets (relative) addresses 08:30:33 Well I wasnt thinking of the type off addresses - Ill leave that to you ;) 08:31:13 see the 'intro' link on the strongforth url - I think it's overkill-typing, but the same SORT of idea applies. 08:31:59 * amca nods. 08:32:07 amca: the advantage becomes - burning an image, or generating an objectfile or whatever becomes a lot easier - because we'dhave no 'absolutes' to track in the burn and patch in the read. 08:32:07 I clicked on it as I read the log :) 08:32:22 * amca nods 08:32:37 relative addressing does make relocatable code much easier 08:33:03 BUT, unless I am seriously confused, we have to do the typing/conversion/testing all during the source-interpret/compile phase. 08:33:20 * amca shrugs 08:33:37 Sorry. My mind isnt connected enough to know if you are right or not :) 08:34:10 well, it matters WHEN - I was really bothered when I considered every opcode doing the testing. Seems like it is all at the create/colon-def levels. 08:35:22 * amca nods 08:36:27 This would then imply that no primitive gives a rats-ass, we return to "data is data". But, during lookup we peer at requirements, and during compiling it has to be processed. 08:36:46 Any updates to the headers/code on the net? 08:37:00 not on the net, but I can send rafb the latest. 08:37:30 I've been backburnering how I should introduce these concepts and code-changes to the wiki 08:37:43 ah 08:37:46 cool 08:38:35 Should I just start a "concepts-debate" link from the intro, and do attachments of the files? or what? It seems to make a diff. 08:38:54 No idea sorry 08:39:08 It is 1:30am here so I cant think too hard Im sorry 08:39:13 yeah, the "design" of the wiki seems at least as irksome as the other issues 08:39:44 heh 08:40:49 well, between the wiki, the API, the code, and discussion - I run outta' daylight and energy. 08:41:21 So you feel the wiki isnt helping? 08:41:36 no idea - no real feedback 08:42:10 Very little activity, interest I fear. 08:44:31 Little activity in ppl interacting with your wiki page? 08:44:51 yah 08:45:09 I think it's typical of forth as well 08:45:24 42 CAST CHARACTER . <-- yuck 08:45:52 yah 08:46:13 charcast 42 . would be better if you had to cast 08:46:16 IMO 08:46:28 I tend to agree 08:46:49 :) 08:47:43 Did you wanna rafb the code? 08:47:44 I'd love to discuss a decent syntax/idea 08:48:00 even in the wiki or email 08:48:00 with me? 08:48:20 you are interested, sure - others, fine. 08:49:11 Brain dead currently. So if you dont mind me taking it on a superficial level its okay. Otherwise if you prefer I can talk with you about it when brain works 08:49:40 Sure - however it works, dude - I'm not unaware folks get tired ;-) 08:50:43 :) go for it then - expouse :) 08:51:31 right now talking to #3 son, but I'm not sure what and where to say whichever. 08:51:42 hehe 08:52:07 (back from his bear hunt ;-) 08:52:24 hehe 08:59:15 I do think the interpretive-typing is a good idea. 08:59:48 Id have to see good examples to know for sure 09:00:00 yeah, and it's soo conceptual 09:08:29 You ever watch "Yes (Prime) Minister"? 09:08:42 no, not where I live. 09:09:06 Ah 09:09:27 NA, CONUS, MI - A2 area 09:12:03 --- part: PoppaVic left #forth 09:12:09 --- join: PoppaVic (n=pete@0-1pool47-41.nas30.chicago4.il.us.da.qwest.net) joined #forth 09:12:21 that was weird 09:12:26 conn probs 09:12:27 ? 09:12:41 No, xchat detached the tab to a win 09:12:51 anyway... 09:13:16 :) 09:14:03 I'm thinking that the concept is mostly useful for interfacing. I believe it also may be a whore for storing lits and shit or for fetching. 09:14:45 * amca nods. 09:14:52 For foriegn libvraries etc? 09:15:15 No, I was thinking about HOW a var or comma is _intended_ 09:15:47 ok 09:16:07 anyway... Lemme' make a beerrun, and I'll be back. I'll understand if you hit the sack. 09:16:09 --- quit: PoppaVic ("Pulls the pin...") 09:31:42 --- join: PoppaVic (n=pete@0-1pool66-236.nas22.chicago4.il.us.da.qwest.net) joined #forth 09:31:57 back! 09:31:58 wb 09:32:01 Christ, he's STILL ranting on the phone ;-) 09:32:06 thanks ;-) 09:32:07 lol 09:32:52 I guess his buddy acted the bitch during the hunt. *sigh* When he gets into to ranting, you just wait for the energy to run down. 09:33:02 to/the 09:33:13 hehe 09:34:00 Meanwhile... I don't see any issue with adding a tagfield and structure to stacks. I'm pretty sure we can make it totally transparent. 09:34:24 However, the usage/respect of the tagfields does sound like it can become a major whore. 09:34:55 * amca nods 09:35:00 (in fact, we could actually use a char-array to PARALLEL the stack) 09:35:10 May as well add mem management while you are at it 09:35:11 Christ is ranting on the phone? 09:35:31 JasonWoof: Yeah. Pissed off it is not time for him to come again 09:35:31 JasonWoof: no, just one of the disciples 09:37:01 amca: "memory management" suggests multiple issues not necessarily w/i the scope of engine-space. 09:37:49 hmm 09:37:51 I C 09:38:58 One of the reasons I'm not really sure that ANS-compliance, for the engine, matters - is because they tend to discuss/consider the universe as one intermixed space. 09:39:19 * amca nods 09:39:23 Certainly there seems little reason to believe it can't be a layer above the machine. 09:39:45 perhaps a vocabulary? 09:40:19 * amca shrugs 09:44:48 * PoppaVic the ranting continues.... 09:45:04 hehe 09:47:35 hi all 09:47:43 hello 09:47:48 hi crc ;-) 10:02:01 --- quit: crc () 10:02:23 --- join: crc (i=crc@pool-70-110-156-36.phil.east.verizon.net) joined #forth 10:22:20 omg, he finally drifted upstairs (thank you, Geezus!) 10:22:29 hehe 10:22:57 Dude, he's never learned to "tell a story" - it's blow-by-blow from beginning to end. 10:23:27 YOu should see the looks when I suggest "Cut to the chase, dude" 10:23:31 Sounds good to me - nice and logical 10:23:50 I like to know all the details that most ppl leave out 10:24:06 amca: I do NOT want to hear of every minute and interaction for a week RT. I'd rather ask. 10:24:16 RT? 10:24:20 realtime 10:24:24 ah 10:24:33 hehe 10:26:43 amca: I presume you do/have programmed in forth, right? 10:26:50 yes 10:26:55 A newbie though 10:28:05 crc and I discussed this yesterday, but - consider this for awhile. We need a decent stack-effects/io/'typing' semantic. There are too many variants and none look decent or fit the idea of typing. 10:28:17 * amca nods 10:28:34 that is why I said Id have to see good examples to know what I thought of it :) 10:29:11 I've considered/am-considering: ( D:i1u1 --- u2; R:---; I:w1--- ) 10:29:29 --- part: thinfu left #forth 10:29:44 I? 10:29:55 I believe we can get away with far less than Strongforth. 10:30:03 I: "input stream" 10:30:10 Ah 10:30:26 maybe 'S' is better 10:31:01 no, I is good 10:31:28 Although I feel dodgy about using the same stack notation for a queue 10:31:31 for example, a TRUE macro might well look like: ( D;R;S:w1 --- w2) 10:32:03 * amca nods 10:32:26 Yeah, there are so many ways to look at/into it, that I would love to hear some good ideas. 10:32:34 rather than (D: -- w2; R; S: w1 -- )? 10:32:59 perhaps use [] instead of () for the queue notation? 10:33:11 yeah, compacted; and stream (ala' "foo word1") 10:33:36 Well my brain demands sleep right now, so I better obey it 10:33:37 not sure. [] is sorta' preempted' by forth *AND* C 10:33:49 ok, sleep well - get some useful dreams ;-) 10:33:53 {} then? 10:33:58 could be 10:34:09 although {} is usually "locals" 10:34:11 Hopefully Ill catch up with you when brain works and be able to *really* think about your ideas :) 10:34:15 hmmm 10:34:19 ~~? 10:34:28 no idea - sleep on it 10:34:28 || 10:34:32 <> 10:34:37 hehe 10:34:38 night 10:34:43 --- quit: amca ("d34d") 10:34:48 <{ ... }> 10:37:01 crc: I'm even seeing that the low-level opcodes (primitives) need not necessarily 'compile' - just interpret bytecodes and payloads. 10:37:59 This then suggests that a lot of my opsets.h bytecodes are sorted badly. 10:59:20 laters. I give. 10:59:23 --- quit: PoppaVic ("Pulls the pin...") 11:12:29 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 11:57:55 --- mode: ChanServ set +o crc 12:04:20 --- join: aardvarx (n=aardvark@dsl093-238-228.nor1.dsl.speakeasy.net) joined #forth 12:07:18 Greetings, all. 12:11:44 --- quit: docl ("Leaving") 12:23:58 --- join: MBitter (n=malbi@p508E10F0.dip0.t-ipconnect.de) joined #forth 12:34:08 JasonWoof, ping 12:34:28 Does anyone have any suggestions on how to fix "The system has no more ptys" message? 12:35:02 recompile the kernel whith more ptys's 12:35:14 Ah. I thought so. 12:35:30 standart is 256, if i'm right 12:35:39 (256) Maximum number of legacy PTY in use 12:36:00 I have that enabled under Device Drivers -> Character Devices 12:36:13 That, and the option just above it. 12:45:29 --- quit: aardvarx ("leaving") 12:49:49 pong 13:00:18 --- quit: virsys (Connection timed out) 14:00:36 --- join: Quartus (n=trailer@ansuz.pair.com) joined #forth 14:39:38 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 15:27:28 --- join: asymptote (n=weldon@220.muma.nsvl.chcgil24.dsl.att.net) joined #forth 15:37:02 --- quit: asymptote ("Leaving") 16:07:45 --- quit: Topaz ("Leaving") 17:13:36 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby") 17:13:55 --- quit: virl (Remote closed the connection) 18:11:15 --- join: Raystm2 (n=Raystm2@ppp-70-248-35-119.dsl.rcsntx.swbell.net) joined #forth 20:01:05 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-134-181.arcor-ip.net) joined #forth 20:03:27 --- quit: Snoopy42 (Nick collision from services.) 20:03:42 --- nick: snoopy_16 -> Snoopy42 20:19:47 --- join: YoyoFreeBSD_ (n=yoyofree@219.144.159.117) joined #forth 20:40:00 --- join: amca (n=plump@as-bri-4-1-65.ozonline.com.au) joined #forth 20:47:41 --- join: virsys (n=virsys@or-65-40-183-150.dyn.sprint-hsd.net) joined #forth 22:45:27 --- quit: YoyoFreeBSD_ (Read error: 110 (Connection timed out)) 22:56:31 --- quit: sproingie (Remote closed the connection) 23:19:15 --- join: crcv (i=crc@pool-70-110-156-36.phil.east.verizon.net) joined #forth 23:19:16 --- quit: crc (Read error: 104 (Connection reset by peer)) 23:31:20 --- quit: virsys ("bah") 23:40:05 --- join: virsys (n=virsys@or-65-40-178-76.dyn.sprint-hsd.net) joined #forth 23:59:59 --- log: ended forth/05.09.18