00:00:00 --- log: started forth/08.03.21 00:04:46 --- join: madgarden_ (n=madgarde@bas2-kitchener06-1096652387.dsl.bell.ca) joined #forth 00:09:33 --- quit: madgarden (Read error: 110 (Connection timed out)) 00:25:51 --- quit: madgarden_ (Read error: 110 (Connection timed out)) 00:25:56 --- quit: proteusguy ("Leaving") 01:26:57 --- join: Al2O3 (n=Al2O3@c-76-120-54-133.hsd1.co.comcast.net) joined #forth 01:38:27 --- join: proteusguy (n=proteusg@ppp-124-120-225-240.revip2.asianet.co.th) joined #forth 01:53:46 --- quit: nighty^ ("Disappears in a puff of smoke") 01:55:31 --- quit: nighty__ (Client Quit) 02:08:34 --- quit: Al2O3 (Client Quit) 02:19:27 --- quit: gnomon (Read error: 110 (Connection timed out)) 02:40:09 --- join: Maki (n=veselic@adsl-202-95.eunet.yu) joined #forth 04:21:20 --- quit: Maki () 05:22:00 --- join: nighty^ (n=nighty@p5187-adsau17honb13-acca.tokyo.ocn.ne.jp) joined #forth 05:56:27 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 06:53:58 --- join: ygrek (i=user@gateway/tor/x-d40396d5585519f5) joined #forth 07:25:55 --- join: madgarden (n=madgarde@bas2-kitchener06-1096747640.dsl.bell.ca) joined #forth 07:41:26 --- quit: ygrek (Remote closed the connection) 07:41:46 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth 07:42:19 --- join: ygrek (i=user@gateway/tor/x-9857ac3d99a1e203) joined #forth 07:42:34 --- join: gnomon_ (n=gnomon@CPE0050eb372bdb-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth 07:43:47 --- part: gnomon_ left #forth 07:55:31 --- quit: proteusguy (Connection timed out) 07:56:01 --- join: proteusguy (n=proteusg@ppp-124-120-223-178.revip2.asianet.co.th) joined #forth 08:06:12 --- join: tgunr (n=davec@70-41-248-186.cust.wildblue.net) joined #forth 08:14:47 --- join: Bushmills (n=l@verhau.de) joined #forth 08:14:57 hi 09:01:49 --- join: Maki (n=veselic@adsl-202-95.eunet.yu) joined #forth 09:02:06 hi 09:02:18 Hi. 09:03:00 How are you? 09:03:06 Good thanks. You? 09:03:17 Great :) 09:45:04 --- quit: ygrek (Remote closed the connection) 09:46:12 --- join: ygrek (i=user@gateway/tor/x-83c883af02800a2d) joined #forth 10:34:01 --- join: Quartus` (n=Quartus`@209.167.5.1) joined #forth 10:36:43 --- join: Quartus__ (n=Quartus`@209.167.5.1) joined #forth 10:53:59 --- quit: Quartus` (Read error: 104 (Connection reset by peer)) 10:58:54 --- join: JasonWoof (n=JasonWoo@unaffiliated/herkamire) joined #forth 10:58:54 --- mode: ChanServ set +o JasonWoof 11:02:39 --- quit: Quartus__ (Read error: 104 (Connection reset by peer)) 11:22:12 --- join: ecraven (n=nex@78.104.10.149) joined #forth 11:42:14 --- join: arke_ (n=arke@p57A77BCD.dip.t-dialin.net) joined #forth 11:58:57 --- quit: arke (Read error: 110 (Connection timed out)) 12:10:13 --- quit: ecraven ("bbl") 12:59:09 --- join: kardinal (n=kvirc@e180138012.adsl.alicedsl.de) joined #forth 15:16:24 --- quit: JasonWoof ("Leaving.") 15:26:59 --- quit: ygrek (Remote closed the connection) 15:33:03 --- quit: nighty^ (Read error: 110 (Connection timed out)) 15:33:59 --- join: nighty^ (n=nighty@p5187-adsau17honb13-acca.tokyo.ocn.ne.jp) joined #forth 15:39:26 --- quit: Maki () 16:21:18 --- quit: kardinal ("KVIrc 3.2.4 Anomalies http://www.kvirc.net/") 16:35:34 --- join: mark4 (n=mark4@70.102.202.140) joined #forth 16:35:51 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 16:35:51 --- mode: ChanServ set +o tathi 16:36:09 writing a block editor now, damn i MUST be bored lol 16:37:13 :) 16:37:36 im not adding block file loading tho, i want block files for creating a help system 16:37:45 you CRAZY! 16:37:51 lol 16:38:09 if YOU want to be able to load a block file it should take you about 10 minutes to add the code :P 16:38:33 but other than that err yea :P 16:39:39 this isnt even being done in my linux isforth, i ported isforth to dos and am doing it all there for now 16:46:09 oh quartus are u there? 16:52:51 --- quit: tathi (Read error: 104 (Connection reset by peer)) 16:53:13 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 16:53:13 --- mode: ChanServ set +o tathi 17:14:37 Hey. 17:14:40 Sorry, wandered off. 17:14:57 heh tsok 17:14:59 this is irc :P 17:16:02 one of the "problems" with isforth is that you cant add more that one instance of a given vocab to context 17:16:12 if you try add a voc thats already there that voc is rotated out to the top 17:16:15 I recall. 17:17:26 what this prevents is for you to add and then later remove something without removing it 17:17:41 I see a solution. 17:17:57 ok. well i knew this was a "problem" and had a fix for it which i have just implemented 17:18:09 ive given you the ability to create your own context stack 17:18:18 create an array and say +context mycontext 17:18:32 when you do that the active context is copied into YOUR context and you can add and remove at will 17:18:37 when your done you say -context 17:18:51 and yesterday i thought wow. you could make context stacks a USER variable 17:18:59 and ok. my scenario would be 17:19:12 have a MUD game where the users have one context, admin have another and developers have another 17:19:31 all running within the same forth. just SEAL them into their context 17:19:41 is that the solution you were thinking of? 17:20:19 No. That's adding complexity on top of already unneeded complexity. 17:20:36 its actually very simple 17:21:17 what was your solution? 17:21:36 Going with a search-order implementation that can contain duplicates. The straightforward kind. 17:21:49 The kind that doesn't have the problem you're describing to start with. 17:21:51 slows down compiles 17:22:01 I don't see how it could. 17:22:16 forth root compiler forth compiler root forth forth forth <--- search order 17:22:31 and "prior-check" only tests "was this voc the one we searched last" 17:22:53 Well, if you want to have an inane search order, yes -- so add the complexity into the optimization; don't search a wordlist twice for a given search. Keep a tiny bitmap. 17:23:38 that would need to be cleared for each search sure 17:23:52 but i LIKE my implementation lol 17:24:02 tho if it didnt work right i would scrap it for sure 17:24:07 but i think its more powerful 17:24:14 --- quit: maht (Read error: 110 (Connection timed out)) 17:24:16 i.e. giving each task its own context 17:24:30 each task having its own search-order is independent of the complexity you've added. 17:24:33 --- join: maht (n=maht@85.189.31.174.proweb.managedbroadband.co.uk) joined #forth 17:24:48 erm. not if theres only ONE context 17:24:54 oh i see what you mean 17:25:10 each task could have its own context still yea 17:26:19 with a hashed dictionary implementation, I'd be extremely surprised to find that even a naive search over duplicate wordlists would significantly slow any compile. The only time the whole order needs to be walked is if a non-word is encountered. 17:26:55 isforth is hashed and i also memory map the entire file and call IT tib so compiles are very snappy 17:27:18 i still dislike having more than one instance of a given voc in context 17:27:36 Then don't put them there. 17:27:43 im not 17:27:59 but that means you cant add and then remove safely 17:28:06 I mean, don't rely on your implementation to yank them out, plus whatever other re-ordering it does -- don't put them there, yourself. 17:28:25 I thought you were "I don't want the compiler helping me" guy? 17:28:36 ther compiler isnt helping me :) 17:28:40 i have to TELL it what i want 17:28:55 hey you. i want THIS array to be my context stack 17:28:55 Sure it is. It's carefully making sure you don't accidentally have two identical wordlists in your search order. 17:29:42 its not just doing that lol. its changing the order based on what vocs you state 17:29:58 root compiler forth root makes root the first item 17:30:15 It would, either way. 17:30:25 yup 17:30:41 but in my system if you then say previous root is gone :0 17:30:44 So it's not a particular feature of your implementation. 17:30:50 not a good idea, cuz then your sealed into what ever else is in context 17:30:54 Yes, and that's causing a problem for you. 17:31:07 i see no problem realy 17:31:10 This is what we call a "no-brainer" in Canada, Mark :) 17:31:32 it was never a problem for me, i dont think one should nest includes like that 17:31:50 i,e, include file a which sets its orde4r. then include file b which needs a different order... 17:32:03 i consider it bad coding myself but im not preventing YOU from doing it exactly 17:32:15 I find it odd that you steer clear of optimization elsewhere, but pile it on in this case. 17:32:26 its not a code optimization 17:32:42 its a compile time speed optimization along the same lines as doing hashed vocs 17:32:53 No, not code. I mean, in terms of the compiler 'coddling you', or 'handholding' -- can't remember how you characterized it. 17:32:53 i dont think hashed vocs are a code optimization 17:32:58 they are a process optimization 17:33:11 mommy holding your hand lol 17:33:12 ya 17:33:19 its not that either i dont think 17:33:25 If it's compile-speed optimization you want, not searching the same wordlist twice would be the way to achieve that while not adding any rubber to the walls. 17:33:28 its the compiler protecting itself from you lol 17:34:45 erm not YOU you 17:34:57 If I want to have a wordlist in the search-order twice, and the compiler prevents me -- that strikes me as just the sort of thing you have professed to dislike. 17:36:26 well yes and no. actually, my case construct enforces certain things 17:36:35 you cant do case X of lots of code here endof 17:36:38 cuz there is no endof 17:36:55 it has to be one word referenced per case 17:37:01 per of that is 17:37:49 cept "of" is called "opt" 17:38:06 case: 1 opt do-1 2 opt do-2 ;case 17:38:23 but again, thats not exactly a compiler optimization 17:38:37 thats not the same as "well i input XXXX" and it compiled "YYYYY" 17:39:03 but i see your point, maybe its a double standard lol 17:44:30 Think so. 17:59:56 brb maybe :) 17:59:58 --- quit: mark4 ("Leaving") 18:08:55 --- quit: tathi ("leaving") 18:47:45 --- join: Quartus` (n=Quartus`@209.167.5.1) joined #forth 18:49:13 --- join: mark4 (n=mark4@70.102.202.140) joined #forth 18:56:51 --- nick: mark4 -> I440r 18:56:57 --- mode: ChanServ set +o I440r 19:24:47 --- quit: I440r ("Leaving") 19:47:19 --- join: snoopy_1711 (i=snoopy_1@dslb-084-059-127-178.pools.arcor-ip.net) joined #forth 20:04:39 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 20:05:01 --- nick: snoopy_1711 -> Snoopy42 20:33:28 is thinking forth as amazing as the website says it is? 20:33:39 It's a good book. There's a free PDF. 20:34:30 just good? :) 20:34:44 I don't know what adjectives you're looking for. Are you asking whether it's worth reading? 20:34:55 yes. 20:35:12 If it sounds like it would interest you, I recommend it. 21:16:56 I also recommend it. It's one of those books that can stand to be re-visited from time to time, as well. 21:19:45 "Starting..." "Thinking..." "Programming...". Is this our "gang of 3" :-) or is there a better one. should we add or subtract a book? 21:20:32 STP. 23:59:59 --- log: ended forth/08.03.21