00:00:00 --- log: started forth/16.08.23 00:40:32 --- quit: nal1 (Quit: WeeChat 1.4) 00:56:46 --- quit: mnemnion (Remote host closed the connection) 01:33:01 --- join: true-grue (~true-grue@176.14.223.200) joined #forth 01:36:23 --- join: wa5qjh (~Thunderbi@121.54.58.133) joined #forth 02:09:40 --- quit: nighty (Quit: Disappears in a puff of smoke) 02:49:59 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 04:06:03 --- quit: DGASAU (Read error: Connection reset by peer) 04:06:17 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 04:41:54 --- join: timeslice (~photon@1.128.96.126) joined #forth 05:47:44 reepca: in blocks _no_ character has a special meaning. 05:48:13 Any block is just a single long line of 1024 characters. 06:23:52 --- quit: gordonjcp (Ping timeout: 276 seconds) 06:25:17 --- part: timeslice left #forth 06:25:40 --- join: gordonjcp (~gordonjcp@ilyushin.gjcp.net) joined #forth 07:08:09 --- quit: DGASAU (Ping timeout: 244 seconds) 07:12:43 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 07:18:42 --- quit: DGASAU (Read error: Connection reset by peer) 07:19:32 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 09:01:54 --- join: nal (~nal@adsl-64-237-234-195.prtc.net) joined #forth 09:02:20 --- join: nal1 (~nal@adsl-64-237-233-245.prtc.net) joined #forth 09:06:30 --- quit: nal (Ping timeout: 265 seconds) 09:09:07 --- join: mnemnion (~mnemnion@2601:643:8103:f9d0:44ca:3720:b22b:674e) joined #forth 09:43:28 --- quit: mnemnion (Remote host closed the connection) 10:04:36 --- join: mnemnion (~mnemnion@152.179.131.166) joined #forth 10:05:22 --- join: dk8086 (~quassel@189.102.205.20) joined #forth 10:07:23 --- quit: mnemnion (Remote host closed the connection) 10:07:39 --- join: mnemnion (~mnemnion@152.179.131.166) joined #forth 10:11:32 --- join: leaverite (~Thunderbi@203.111.224.39) joined #forth 10:12:14 --- quit: wa5qjh (Ping timeout: 265 seconds) 10:12:15 --- nick: leaverite -> wa5qjh 10:42:40 DGASAU: So if a \n did end up in a block, it would just be assumed to be part of a word name? 10:48:47 reepca, if your interpreter considers \n to be whitespace then it would be considered the end of a word or just simple whitespace. 10:49:32 so the treatment of \n in blocks is implementation-dependent? 10:49:43 --- quit: wa5qjh (Ping timeout: 276 seconds) 10:49:49 nothing to do with blocks - just your interpreter. 10:50:31 reepca, honestly I don't recall what the various standards say. I generally always wrote my own "forthy" interpreters. Easiest thing to do is try. 10:52:55 My expectation is that a line feed and carriage return would both be treated as whitespace and not part of a word. 10:54:03 I just tested it again and now it seems to be doing the "right" thing with blocks. Must have been some other factor the last time I tried and everything was weird 10:54:19 maybe it was just too late at night 10:54:27 :) 10:56:11 Also, would it make sense to mix code and binary data in a block? For serialization purposes? 10:57:13 I wouldn't put anything in a code block that I didn't want my interpreter to directly deal with. Also it's gonna make displaying unnatural. 11:00:41 --- join: wa5qjh (~Thunderbi@203.111.224.39) joined #forth 11:20:23 --- join: MickyW (~MickyW@p4FE8CF5A.dip0.t-ipconnect.de) joined #forth 11:47:45 I'm sure there's actually an "internal" word defined as a literal 11:47:56 reepca: what exactly are you trying to do? 11:55:22 regarding the "mix code and binary data in block" thing? I guess right now I'm not *trying* to do anything, just thinking out loud for the benefit of quick feedback. 11:57:02 regarding the behavior of \n in blocks, I'd written a word called DO-PARSING{ which took an xt and executed it for each word in input stream until } was found. It threw up everywhere when I tried using it with code in block form, but now it seems to be working okay. I'm not sure what changed. 11:58:15 I've re-implemented that word about 3 times or so now since I keep moving from laptop to desktop and iteratively improving it (I think) each time, so maybe one of those changes fixed it accidentally 11:58:28 right, but overally what's the goal here? 11:58:47 well, the goal was to factor out the defining of lots of words with similar functionality 11:59:10 I could use that to write VARIABLES{ var1 var2 var3 var4 } 12:00:04 the overall-overall goal is to write a getting-feet-wet application that would randomly generate a call of duty 4 class 12:00:18 Which reminds me of something I was going to ask 12:00:39 Should I favor not repeating myself, or making the code look the most like the problem? 12:01:21 For example, the straightforward, fit-the-problem approach would be to do something like 12:01:43 attachments grip red-dot-sight weapon M1014 12:01:56 But several weapons have those same attachments 12:02:35 So I might try writing it as "attachments grip red-dot-sight weapons{ M1014 other etc }" 12:03:22 but then I just end up with a bunch of groups of weapons that are only related because they happen to have the same attachments 12:03:49 it doesn't feel like I'm simplifying the problem, I'm just reducing the amount of code 12:04:29 why not make a word that just means that set of attachments 12:04:47 then you can say standard-attachments weapon M1014 12:05:04 the trick with Forth 12:05:18 and it's something that people coming from Algol-like languages like C or Python lose sight of 12:05:21 the trick is 12:05:26 there aren't really "function calls" 12:05:39 in a function call there's a fucktonne of state to marshal 12:06:01 in Forth, your state is either safely in a variable, or on the stack, or just plain not there 12:06:09 and calling another word is inexpensive 12:06:40 so whereas in C you'd have a distinct penalty for having a bunch of deeply-nested functions, in Forth it doesn't make nearly as much difference 12:07:07 the attachments available don't really correspond to any logical relationship, I suspect the availability differs purely based on game balance decisions. 12:08:02 it may be that Forth isn't a good language to use for this 12:17:09 Also, I'm having trouble thinking about how to store related groups of xts in an array (I think I mentioned this before). I can't easily store those xts all at once without writing out the names all over again. Someone suggested a linked list, but that doesn't seem like a good fit for what is *literally* random-access. 12:17:38 --- join: ASau (~user@netbsd/developers/asau) joined #forth 12:19:02 Perhaps I need to structure the program so that it can first parse through all of the weapons and count how many there are, then parse through again and compile them? 12:19:27 anyway, I need to go for a bit now, will be back in about 3 hours 12:30:53 that might have been me that suggested a linked-list 12:31:01 the dictionary is a linked-list 12:31:14 maybe you can flag up things that want to be in your array somehow when you define them 12:31:31 and then write a word that walks the dictionary enumerating those flagged words 12:56:46 --- quit: dk8086 (Remote host closed the connection) 13:29:13 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 13:30:08 --- quit: Zarutian (Read error: Connection reset by peer) 13:30:14 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 14:20:45 --- join: gyxile (~nick@cpc80309-grim18-2-0-cust167.12-3.cable.virginm.net) joined #forth 14:38:56 --- join: littlegirl (~littlegir@cpe-66-24-80-167.stny.res.rr.com) joined #forth 14:40:23 Hey there, if I create a bunch of cells arrays with something like variable x n cells allot and I later want to know how many cells I had allotted to the x variable, is there a word that will give me that number? 14:46:00 littlegirl: No. 14:48:36 --- quit: littlegirl (Quit: *POOF*) 15:11:46 --- join: karswell` (~user@174.217.113.87.dyn.plus.net) joined #forth 15:30:21 CORDIC: well, they obviously didn't like *that* answer... 15:32:10 You need to build your own array word with counter and stuff. 15:32:15 Now is better? :) 15:34:13 Probably, omitting critics is the new way, to say: Thank you. :-) 15:43:25 --- quit: karswell` (Remote host closed the connection) 15:48:48 --- quit: true-grue (Read error: Connection reset by peer) 15:50:04 gordonjcp: is there a way to traverse the dictionary portably? 15:51:08 probably not, why? 15:51:11 actually, a thought occurs: maybe it makes more sense than I originally thought that one of the first tasks many forthers seem to do is write their own, since the ultimate form of portability is just writing it yourself all the way down... 15:53:35 it seemed a bit pointless aside from the experience gained, but I think I see now that when minimalism is sought, trying to conform to an already-made system is just as limiting as using a library (something that seems rare among forthers) 15:54:54 or, you know, just pick an environment and stick to it 15:55:08 Forth is probably not a good choice as a general-purpose language on very large systems 15:55:24 with say more than a couple of hundred kilobytes of RAM, and a few megabytes of mass storage 15:55:43 say, large enough to have a viable Unix-like operating system 15:57:09 may I ask why it isn't well-suited to large systems? 15:59:37 because there are better things 16:00:24 Why are they better, and how can I make like lisp and absorb their good points? 16:01:24 don't 16:01:38 if you're targeting a large system and want portability, use C 16:01:46 it's literally designed for the job 16:02:05 * gordonjcp -> bed 16:37:51 --- quit: nighty (Remote host closed the connection) 16:41:28 --- quit: MickyW (Quit: Verlassend/leaving) 16:46:03 --- quit: gyxile (Quit: Ex-Chat) 16:55:54 --- quit: mnemnion (Remote host closed the connection) 17:05:33 --- join: mnemnion (~mnemnion@152.179.131.166) joined #forth 17:10:11 --- quit: mnemnion (Ping timeout: 252 seconds) 17:18:15 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 17:18:30 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 17:19:54 --- quit: wa5qjh (Remote host closed the connection) 17:22:39 --- quit: mnemnion (Ping timeout: 250 seconds) 17:32:34 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 17:32:56 * Zarutian recommends OpenBSD with capscium enabled and where all executables are nuxi.nl/cloudabi userspace-kernel-interface compliant 17:33:49 --- join: mnemnia (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 17:34:23 but forths like mecrisp are quite handy on systems-on-chip like Texas Instruments MSP430 FRAM based MCU 17:37:55 --- quit: mnemnion (Ping timeout: 276 seconds) 17:44:54 --- join: wa5qjh (~Thunderbi@203.111.224.39) joined #forth 17:48:15 --- quit: mnemnia (Read error: Connection reset by peer) 17:48:52 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 18:08:58 --- quit: Zarutian (Quit: Zarutian) 18:21:49 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 19:47:49 --- quit: wa5qjh (Ping timeout: 250 seconds) 20:23:15 --- quit: probonono (Quit: Arrgh.. box crashing again!) 20:42:01 --- quit: groovy2shoes (Ping timeout: 265 seconds) 20:59:48 reepca, I think the most reasonable argument is that you don't need "large" systems with forth. The concept of "portability of code/app" imposes an enourmous overhead (at least an order of magnitude, sometimes several) and the power of forth is a) there's nothing between you and the hardware, b) it's not a language, it's a full system - an actual computer, c) its concepts are so portable and codebase small enough that re-implementing to the new 20:59:48 computer costs less than the effort to maintain portability of code/application. 21:00:35 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 21:01:17 reepca, the downside is that there aren't powerful databases, web frameworks, etc. ready made for you to utilize. you're expected to build exactly what you need and no more. that's why forth systems almost never get very large. there just isn't a justification/need for it. 21:02:55 forth actually would perform great in such environments but you have to build it yourself and, if it's too large for one person to know the whole thing then you have to build a team that knows all these things. That effort/investment in the team is what scares people away from large systems in forth and it's probably a reasonable concern. 21:04:49 but considering that only 15% of the cost of any application over its lifespan is the initial development, and that you can get an amazing amount of work done with far fewer resources (people, cpu, memory, etc) in forth, a many cases a strong argument could be made for forth being your platform of choice for certain circumstances. 21:08:46 but you can see now I think why most forth systems are one-man operations. a single person can scale his productivity to match most dev teams. but there is a limit as to how far that can go and that's why you rarely ever see "large" forth systems. it's an incredibly personalized/customized environment written by capable people with strong opinions. :-) 21:12:11 --- quit: groovy2shoes (Ping timeout: 252 seconds) 21:15:06 --- quit: proteusguy (Ping timeout: 260 seconds) 21:15:15 --- quit: mnemnion (Remote host closed the connection) 21:59:55 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 22:01:07 --- quit: nal1 (Quit: WeeChat 1.4) 22:06:12 --- quit: mnemnion (Ping timeout: 250 seconds) 22:49:44 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 22:50:26 --- quit: mnemnion (Remote host closed the connection) 22:54:35 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 22:54:38 --- quit: mnemnion (Remote host closed the connection) 23:07:41 --- join: proteusguy (~proteusgu@180.183.135.227) joined #forth 23:07:41 --- mode: ChanServ set +v proteusguy 23:57:14 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:4941:7b39:5ffd:3a63) joined #forth 23:59:59 --- log: ended forth/16.08.23