00:00:00 --- log: started forth/14.11.16 00:37:41 --- quit: ehaliewicz (Remote host closed the connection) 02:10:24 --- join: rixard_ (~rixard@90-229-190-197-no63.tbcn.telia.com) joined #forth 02:10:36 --- quit: rixard (Ping timeout: 244 seconds) 02:10:37 --- nick: rixard_ -> rixard 02:25:12 --- join: xyh` (~xieyuheng@125.94.36.160) joined #forth 02:38:46 --- quit: xyh` (Ping timeout: 255 seconds) 02:43:24 --- quit: proteusguy (Ping timeout: 258 seconds) 02:54:56 --- join: xyh` (~xieyuheng@125.94.36.160) joined #forth 02:56:27 --- join: proteusguy (~proteusgu@ppp-110-168-229-247.revip5.asianet.co.th) joined #forth 02:59:47 --- join: DocPlatypus (~skquinn@c-76-31-212-235.hsd1.tx.comcast.net) joined #forth 03:08:11 --- quit: proteusguy (Remote host closed the connection) 04:04:13 --- quit: xyh` (Ping timeout: 255 seconds) 04:15:11 --- join: fox (~fox@220.113.12.99) joined #forth 04:20:02 --- quit: fox (Ping timeout: 255 seconds) 04:21:18 --- join: DGASAU (~user@p50993595.dip0.t-ipconnect.de) joined #forth 04:27:06 --- quit: DGASAU (Remote host closed the connection) 04:28:44 --- join: DGASAU (~user@p50993595.dip0.t-ipconnect.de) joined #forth 04:41:04 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 04:42:20 --- quit: Zarutian (Read error: Connection reset by peer) 04:42:29 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 04:45:14 --- join: samrat (~samrat@123.236.183.195) joined #forth 04:46:52 is there a subroutine threaded forth implemented in C? 05:01:32 What's the point? 05:06:42 --- quit: samrat (Ping timeout: 244 seconds) 05:09:29 --- join: samrat (~samrat@123.236.183.195) joined #forth 05:16:20 --- quit: samrat (Quit: Computer has gone to sleep.) 05:18:19 DGASAU: for fun! silly goose 05:33:17 He doesn't believe in fun. 05:33:27 Well, except for sitting in channels of languages he hates so he can snipe. 05:33:39 I guess that's his idea of fun. Takes all kinds I guess. 05:34:18 --- join: samrat (~samrat@123.236.183.195) joined #forth 06:08:10 --- join: Bahman (~Bahman@188.159.27.208) joined #forth 06:17:02 --- join: vanila (~user@unaffiliated/vanila) joined #forth 06:17:12 --- quit: Zarutian (Quit: Zarutian) 06:28:05 so why then is F-PC relegated to the dust heap of dos? 06:32:24 Because Forth sucks. 06:34:52 hahah. Trolls suck a little more, i think. 06:44:55 --- quit: samrat (Quit: Computer has gone to sleep.) 06:45:22 --- quit: fantazo (Ping timeout: 250 seconds) 06:50:52 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 06:54:01 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 06:54:57 --- quit: Zarutian (Read error: Connection reset by peer) 06:55:00 --- join: Zarutian_ (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 06:58:48 No we established this yesterday, bjorkintosh. He's not a troll. He's literally insane. 06:59:06 Ah. 06:59:42 Since the guy I was talking with didn't want to label him a troll, insanity was the only other reason I could come up with that would explain someone sitting in a channel of a language he hates just to snipe at it. 07:00:26 DGASAU is probably a prophet misunderstood? he's come from the future to warn us. 07:00:39 DGASAU, what are excellent languages then? 07:04:20 one question: why is the dictionary sometimes split into two parts? Code part and names part? 07:09:49 Zarutian_: IMO, names part are fix length, while Code part is not, if you split Code part into another heap, then the dictionary will be a array. 07:10:09 * names part as word header ? 07:13:19 jab: imagining a subroutine threaded forth implemented in C, how would the C calling convention be handled ? 07:14:35 jab, is what you're looking for listed somewhere here? http://www.forth.org/compilers.html 07:15:38 hey xyh 07:16:10 jab: I guess, in C, it will not be subroutine threaded code 07:16:16 vanila: hi :) 07:16:36 Zarutian_: because names are not essential for program execution. 07:16:39 I want to implement FIND in forth now 07:17:43 xyh: by not using C stack. 07:19:15 ill first maybe write a thing that prints all words just by following the path 07:19:20 linked list dictionary 07:19:32 Pf. 07:21:58 vanila: will you push your code first? :P 07:22:05 --- join: samrat (~samrat@123.236.183.195) joined #forth 07:22:10 yeah, but it's almost nothing at the moment 07:22:15 I have a lot of work to do ... 07:22:16 ok 07:24:11 vanila: some general helper functions to visit the various kinds of fields of the words in the dictionary will be helpful 07:24:29 yeah, I could se advice on which words to use - 07:24:34 first I have @ already 07:24:52 and I can have a function to print a dictionary entry name 07:25:20 ill have to add conditionals and loops... 07:27:07 vanila: just use "branch" & "false?branch" at first will be ok, IMHO 07:27:43 DragonForth implements "find" in Forth for ages. 07:28:20 ok, thank you 07:28:22 Time stamp on one of files is from 2007. 07:28:26 vanila: "loop" can be done by recursive tail-call 07:28:41 i don't have tail calls :( 07:28:45 i dont even have recursion I think 07:29:24 vanila: I remember, you get recursion for free in jonesforth 07:30:56 I will have to get tail calls maybe 07:31:02 that could be good 07:31:11 vanila: a "call" at the tail position of a function body is "tail-call", you are having it now 07:31:13 ok thanks - I will look into tail calls now :) 07:31:14 but 07:31:23 can i use a special tailcall operator? 07:31:29 otherwise I'd have to recognize tail calls 07:32:08 otherwise my return stack will fill up 07:33:19 vanila: you can design your way of implementation. TCO is a little tricky, TCO should be done in the inner interpreter 07:34:39 will that make the inner interpreter more complex? 07:34:46 yes 07:34:48 I like that it's only two instructions! 07:35:21 then I don't know how to to TCO, maybe there is a way 07:35:31 * to do TOC 07:35:34 * TOC 07:35:51 xyh: this is bullshit. 07:35:59 lol 07:36:40 vanila: I quote the SICP :: ``to do TCO is to recognize the tail position in the function body, when you do the interpreting.'' 07:38:01 i should use explicit tail call operator rather than EXIT, or a LOOP construct? 07:38:09 vanila: find a way to let your inner interpreter recognize the tail position in the function body will be ok. do not implement "exit" as a function-call. 07:38:18 hmm 07:38:24 but why not? 07:38:45 xyh: SICP's "interpreting" does not relate to inner interpreter. 07:39:22 if "exit" is a function, the tail-call will always call "exit". 07:39:24 At least, it's not the only interpretation. 07:40:12 DGASAU: two interpreters, same idea to me. 07:40:35 No. 07:40:52 SICP's "interpreting" isn't about Forth's inner interpreter. 07:40:53 vanila: explicit "branch" will call the function "branch" right ? 07:41:04 It is about external interpreter actually. 07:41:24 xyh, I don't really know yet - i'm a bit lost 07:42:00 vanila: please don't :P my bad if it is not clear. 07:42:57 okay ;) 07:43:11 im only a beginner at forth 07:43:17 so I don't understand much yet, 07:43:18 vanila: I ll do an example for you 07:43:21 I'm reading Starting Forth too 07:46:33 yo 07:49:22 --- quit: samrat (Quit: Computer has gone to sleep.) 07:54:09 vanila: https://www.refheap.com/93457 at the end of "help__find", there are "help__find" and "Exit", if "Exit" is implemented as a function to be called, then the interpreter is not TCO-ed. 07:57:24 vanila: if, when executing every functions in the function-body, the interpreter see the next word to find whether it is the "Exit". then, at the "help__find", the interpreter will recognize that it is at then end of the function body. 07:58:04 vanila: the interpreter just do not push the return-stack at the end of the function-body, then the interpreter is TCO-ed. 07:59:23 xyh, thank you very much im studying it :D 08:00:01 I see about exit.. 08:00:05 nice technique 08:00:10 but could it slow down forth? 08:00:20 having to check for exit 08:00:56 you will see it is actually not very good, for the macro "next" is getting larger. 08:05:44 "_false?branch" is called "?branch" traditionally. 08:06:03 Alternative names in some implementations are "zbranch" or "0branch". 08:06:28 --- quit: xyh (Ping timeout: 265 seconds) 08:08:54 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 08:09:15 sorry about my connection 08:09:31 wb xyh 08:09:36 i sent you a PM? 08:09:46 yes, it will slow the interpreter ( by constant time factor ) 08:09:59 vanila: I see the github page 08:10:16 vanila: IM(very)HO, to achieve TCO in ITC this cost is a must. but if you use STC, you can achieve TCO without this cost. 08:10:29 STC? 08:10:35 vanila: maybe you can find a better way to achieve TCO in forth, then teach me back :) 08:10:39 haha 08:10:58 vanila: STC is to compile "call function-address" into function body 08:11:41 vanila: I ll find you a link about threaded-code 08:12:07 vanila: http://www.complang.tuwien.ac.at/forth/threaded-code.html 08:13:05 I believe this link have been posted 100+ times in this channel. 08:13:24 ill read about it :) 08:18:22 vanila: and this :: http://www.bradrodriguez.com/papers/ 08:48:51 --- quit: xyh (Remote host closed the connection) 08:59:38 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 09:11:35 --- join: samrat (~samrat@123.236.183.195) joined #forth 09:14:35 --- quit: Bahman (Ping timeout: 244 seconds) 09:18:08 --- join: PoppaVic (~pops@unaffiliated/poppavic) joined #forth 09:38:52 --- quit: samrat (Quit: Computer has gone to sleep.) 09:40:07 --- join: fantazo (~fantazo@2001:858:5:3a41:99d8:b33b:fce0:c986) joined #forth 09:43:04 I wonder what the implications of ANS forths cell and char types are for portability. I once read somewhere that the C language was developed with that issue in mind and that cell sized types were rejected. I'm not sure if that is true. 09:44:58 in C, you've numeric "sizes"; the size of char is a minimum size (and also numerical), and there is a CHAR_BIT value that specifies the bits of a char. From there, everything else is sizeof. 09:46:11 so, the forth standard (iirc) has similar size-specs built-in for runtime use. 09:46:14 fantazo: It doesn't matter much for portability. 09:47:06 PoppaVic, I know, actually I have used C for quiet some time. still wondering about design decisions. 09:47:07 fantazo: I think that major change in that respect wrt C's predecessor is that you've got more integer types that single "one-cell" integer. 09:48:17 DGASAU, well more built in types. 09:48:27 --- join: samrat (~samrat@123.236.183.195) joined #forth 09:49:17 but ans forth also defines the double cell, so we got cell, char, string and double cell. also if we use the float vocab then we have the float type too. 09:49:31 yup 09:50:40 "Double cell" is deficient. 09:51:59 it's a double-wide integer. akin to long (or long long, depending on yer viewpoint) 09:52:22 No, it isn't. 09:52:29 yes, it is. 09:52:33 No it isn't. 09:52:39 yes, it is. 09:52:40 "Double cell" lacks operations. 09:52:57 Show me multiplication operation in the standard. ;) 09:55:57 See? 09:56:29 In C you can multiply "long" integers with standard operation. 10:09:22 in the standard you also have special operations for multiplying float values, so it is consistent there. 10:10:17 and on bare metal ("assembler language") you treat double integers also with different operations. 10:10:52 so forth is more "true" to machine reality than say C. 10:11:06 (in this regard) 10:13:39 forth was often the first thing ported to new boards. Typically cobbled up from assembly. The usefulness of forth is not really the question.. Although the standard remains semi-laughable. 10:14:21 --- quit: samrat (Quit: Computer has gone to sleep.) 10:16:23 In the standard you don't have operations for multiplying double values. 10:16:32 In Forth. 10:16:48 Thus "double-cell" is deficient type in Forth. 10:17:02 In C you have all arithmetic operations defined for all integer types. 10:17:39 Hence, C's "long" or "long long" is not equivalent to Forth's "double-cell." 10:18:06 DGASAU, that is not true, there is the D2* primitive, which is used for multiplying double cells 10:18:16 "D2*" is irrelevant here. 10:18:21 You don't have "D*" and "UD*". 10:18:52 That Forth is <> is bullshit. 10:19:12 Most machines are register-based these days. 10:20:04 DGASAU, I would say you are bullshit. I know that todays machines are more register based these days. 10:20:38 DGASAU, I added after writing that "(in this regard)" 10:22:21 it was just a site note. both languages are based on a theoretical model of a stack machine machine model. 10:23:26 I feel offended by you. 10:24:06 --- quit: jab (Read error: No route to host) 10:33:50 --- quit: xyh (Remote host closed the connection) 10:35:18 --- join: jabb (~grue@54027CF7.dsl.pool.telekom.hu) joined #forth 11:02:56 what I haven't yet understood is that in forth or lisp communities it is near impossible to implement something like a standard library. everbody does his own versions. 11:06:13 yep 11:06:26 that was why they argued for that 'standard' 11:07:23 (well, and folks were all adither over the FIG words) 11:10:00 They're doing reasonably well in CL community these days. 11:14:40 last time I checked, they didn't. 11:14:59 but well better than forth community 11:20:24 fantazo, it's too easy to 'roll your own', that's why. 11:20:33 lisp is used mainly to write lisp... 11:20:41 and forth similarly suffers the same fate :) 11:20:49 i know, a bit simplistic. but uhhh. 11:21:30 bjorkintosh, yeah I know, but still I don't know it. maybe because a lot of implementation don't have enough buzz. 11:22:00 fantazo, because there are 1001. 11:22:30 a self fulfilling prophecy then. oh kybernetic.. 11:40:01 --- join: Bahman (~Bahman@188.159.27.208) joined #forth 11:57:48 --- join: proteusguy (~proteusgu@58.185.7.202) joined #forth 12:04:36 --- join: _spt_ (~jaat@host-92-30-230-21.as13285.net) joined #forth 12:04:36 --- quit: _spt_ (Changing host) 12:04:36 --- join: _spt_ (~jaat@unaffiliated/-spt-/x-5624824) joined #forth 12:08:03 --- join: Mat3|coding (~Mat3@ip5b414c9f.dynamic.kabel-deutschland.de) joined #forth 12:08:09 hello 12:16:45 --- join: samrat (~samrat@123.236.183.195) joined #forth 12:19:56 --- quit: proteusguy (Remote host closed the connection) 12:22:18 --- join: proteusguy (~proteusgu@58.185.7.202) joined #forth 12:31:16 --- quit: jabb (Ping timeout: 240 seconds) 12:32:21 --- join: jabb (~grue@54029ECF.dsl.pool.telekom.hu) joined #forth 12:57:17 --- quit: fantazo (Ping timeout: 265 seconds) 12:58:49 --- join: pgomes (~pgomes@ipb2182f12.dynamic.kabel-deutschland.de) joined #forth 13:07:41 --- quit: bbloom (Quit: Textual IRC Client: www.textualapp.com) 13:08:02 --- join: bbloom (~bbloom@cpe-68-175-72-82.nyc.res.rr.com) joined #forth 13:15:27 --- quit: Bahman (Quit: Ave atque vale) 13:24:35 --- join: jabb_ (~grue@5400AF5B.dsl.pool.telekom.hu) joined #forth 13:25:57 --- quit: pgomes (Quit: Leaving) 13:27:24 --- quit: jabb (Ping timeout: 256 seconds) 13:34:07 --- join: spt_1 (~jaat@host-92-30-230-21.as13285.net) joined #forth 13:38:10 --- quit: _spt_ (Ping timeout: 256 seconds) 13:45:40 regarding multiplying doubles: there is a way to bootstrap a D* using (among other words) UM* and D+ 13:46:27 yeah, the standard-crying was elsewhere. Certainly it's doable. 13:46:27 it depends on whether you expect just a double, or if you think you might need to handle something larger. I've written the code to handle larger than doubles, and it can get very ugly very fast 13:47:26 btw I had no real reason for writing it, I just got bored and wanted to see if I could pull it off 13:47:34 I AM sorta' suprised that I've never seen an implementation of multibyte math words. Sorta' seems a natural, (even if they end up writing primitives) 13:47:39 but as it turns out some of the words are a bit useful in some contexts 13:47:56 PoppaVic: maybe I should polish up what I have and let you look at it 13:48:28 DocPlatypus: sure, maybe archival at the least. Written in secondaries it'd be something "portable" and useful. 13:48:28 I have words to multiply unsigned up to quads (four-cell numbers) into an octo (eight-cell number) 13:48:51 heck I think I even cobbled together a D+ assuming only the CORE wordlist 13:48:52 jabb: Subroutine threading is not implementable in ANSI C because there is no way generate direct calls though an application at my knowledge 13:49:10 generally, I just get peeved and holler "Fine, use a float - I'll ignore less than 1!" 13:49:11 I needed it for another word I had which relied on D+ 13:49:22 sorry, that was jab 13:49:43 the problem with floats is you can't add 1 or a similar small number to something very large and get an accurate result 13:49:58 --- quit: samrat (Quit: Computer has gone to sleep.) 13:50:00 yeah, the accuracy-issue is true. 13:50:33 DocPlatypus: needs a forth arbitrary-precision-library ;-) 13:50:39 I think one exists 13:50:44 need to go find it again 13:51:14 seems it would be useful to have such a thing stored in a channel/topic wiki. 13:51:38 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 13:54:33 It is possible to implement + with xor, and, and one-bit left shift. 13:54:43 Yet nobody does that. 13:59:46 DGASAU, you never answered me. Which language(s) do you actually like and use? 14:17:34 --- quit: spt_1 (Quit: irc- et) 14:20:54 Mat3|coding: yeah, I figured. I thought I saw one and I thought there was something like inline assembly 14:25:55 its easy doable. You simple need to declare a byte buffer, mark it as executable and compile the machine code for direct calls. This requires only one CPU dependent macro definition at best so the porting effort would be minimal 14:29:00 the real problem is call-frame elimination as compiler dependent feature, so I do not know one example implementation in C (whereby you can find assembler implementations) 14:32:24 however I found out the FreePascal compiler support a special pragma for ensuring this, so a Pascal implementation would be advantageous in my opinion 14:37:47 (if you are in search for a platform independent assembler) 14:52:37 --- join: fantazo (~fantazo@089144226206.atnat0035.highway.a1.net) joined #forth 15:00:03 --- part: Mat3|coding left #forth 15:07:55 --- quit: fantazo (Quit: Verlassend) 15:10:33 --- quit: TodPunk (Read error: Connection reset by peer) 15:10:55 --- join: TodPunk (Tod@50-198-177-186-static.hfc.comcastbusiness.net) joined #forth 15:47:12 --- quit: jabb_ (Ping timeout: 250 seconds) 15:47:29 --- join: jabb (~grue@4E5C53BA.dsl.pool.telekom.hu) joined #forth 16:02:51 --- join: gabriel_laddel (~user@c-67-161-28-199.hsd1.ca.comcast.net) joined #forth 17:15:04 --- quit: vanila (Quit: Leaving) 17:41:52 --- quit: gabriel_laddel (Ping timeout: 240 seconds) 17:54:56 bjorkintosh: He will never answer that question because that would open him up to sniping. This is now how he rolls. He snipes. He doesn't present a target. 17:55:07 s/now how/not how/ 18:01:12 * Zarutian_ notes that there isnt such as thing as a platform independent assembler. 18:01:40 --- quit: Zarutian_ (Quit: Zarutian_) 18:02:58 you could come close with a pcode-engine, but totally true 18:06:17 --- quit: xyh (Remote host closed the connection) 19:10:54 --- quit: proteusguy (Remote host closed the connection) 19:32:55 bjorkintosh: DGASAU doesn't answer questions like that. 19:33:04 ah 19:36:19 --- join: samrat (~samrat@123.236.183.195) joined #forth 20:26:53 --- quit: samrat (Quit: Computer has gone to sleep.) 20:44:57 I think bjorkintosh asked DGASAU a legitimate question. that he refused to answer or even give a response stating why he wouldn't asnwer certainly looks like bad faith to me 20:45:50 not saying how anyone who might have ops should run things... but honestly, I've been banned from channels for less of a show of bad faith and it wasn't intentional on my part 21:09:20 --- quit: DKordic` (Quit: ERC Version 5.3 (IRC client for Emacs)) 21:27:45 --- join: samrat (~samrat@61.12.96.226) joined #forth 22:49:49 --- quit: ErhardtMundt (Ping timeout: 256 seconds) 22:53:07 --- join: ErhardtMundt (~quassel@93-43-163-57.ip92.fastwebnet.it) joined #forth 23:10:46 --- quit: ErhardtMundt (Ping timeout: 264 seconds) 23:13:56 --- join: ErhardtMundt (~quassel@93-43-163-57.ip92.fastwebnet.it) joined #forth 23:16:20 --- quit: PoppaVic (Ping timeout: 250 seconds) 23:26:31 --- quit: ErhardtMundt (Read error: Connection reset by peer) 23:30:20 --- join: ErhardtMundt (~quassel@93-43-163-57.ip92.fastwebnet.it) joined #forth 23:51:51 --- join: cataska (~cataska@118-163-69-1.HINET-IP.hinet.net) joined #forth 23:59:29 --- quit: jabb (Read error: Connection reset by peer) 23:59:39 --- join: proteusguy (~proteusgu@49.230.89.30) joined #forth 23:59:59 --- log: ended forth/14.11.16