00:00:00 --- log: started forth/03.06.22 00:58:16 --- join: deluxe (~deluxe@pD9E59D8D.dip.t-dialin.net) joined #forth 01:20:51 --- join: anli (abc123@c-eeb470d5.018-16-67766c2.cust.bredbandsbolaget.se) joined #forth 02:25:12 --- join: anli2 (abc123@c-eeb470d5.018-16-67766c2.cust.bredbandsbolaget.se) joined #forth 02:25:24 /kick anli 02:39:16 --- join: a7r (~a7r@206.72.82.135) joined #forth 02:44:10 --- quit: anli (Read error: 110 (Connection timed out)) 02:47:46 --- nick: anli2 -> anli 03:32:11 --- join: deluxe_ (~deluxe@pD9EE1BAD.dip.t-dialin.net) joined #forth 03:49:20 --- quit: a7r (Read error: 113 (No route to host)) 03:54:46 --- quit: deluxe (Read error: 110 (Connection timed out)) 05:04:02 --- quit: anli () 05:32:32 --- quit: MalBi (Read error: 110 (Connection timed out)) 05:35:47 --- join: MalBi (~jesus@pD9E66D34.dip.t-dialin.net) joined #forth 06:17:20 --- join: ASau (~asau@158.250.48.196) joined #forth 06:17:59 Good evening! 06:18:56 Well, I can see myself. 06:19:16 That's good. Now it works. 06:19:29 Maybe, I'll come later. 06:19:35 --- quit: ASau (Client Quit) 06:30:48 --- quit: deluxe_ (Read error: 110 (Connection timed out)) 07:28:21 --- quit: Robert (Read error: 110 (Connection timed out)) 07:34:58 --- join: Robert (~snofs@h138n2fls31o965.telia.com) joined #forth 07:43:53 --- join: deluxe_ (~deluxe@pD9EE1BAD.dip.t-dialin.net) joined #forth 07:47:39 --- quit: deluxe_ (Client Quit) 08:56:29 --- join: anli (abc123@c-e2b470d5.018-16-67766c2.cust.bredbandsbolaget.se) joined #forth 09:07:05 --- join: mur (jukka@baana-62-165-185-52.phnet.fi) joined #forth 09:28:50 piip 09:28:57 HI 09:31:54 moi 09:38:55 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth 09:38:55 --- mode: ChanServ set +o kc5tja 09:48:47 What is meant with a "compile only word"? 09:50:13 It's a word that can only be used while compiling. 09:50:34 I thought forth was interpreted 09:50:35 IF is an example of a compile-only word. 09:50:43 ?do seemded to be compile only 09:50:53 Forth is both interpreted and compiled. 09:51:24 ok 09:51:29 Depending on the Forth environment, it could compile to a representation that is later interpreted (as Perl does). 09:51:39 I tried to put the code in a file and ran it with gfort file.fs, same thing 09:51:46 ok 09:51:52 Most modern Forth environments don't bother with that, though -- they just compile to raw machine language, and let the CPU directly execute the compiled software. 09:51:55 Most interpreted languages works in that way 09:52:06 ok 09:52:18 Can gforth create an executable file? 09:52:43 I believe there is a way to create a turn-key system with it, but it isn't directly executable in the "binary" sense of the word. 09:52:47 ok 09:53:03 gforth produces code that must be interpreted -- it uses direct threading for its implementation. 09:53:11 So how do I use compile-only words? Putting them in a file was equivalent to putting them in the forth prompt 09:53:14 ok 09:53:21 You have to put them inside a colon definition. 09:53:28 oh 09:53:34 gforth can save whole dictionary images, but they still require the gforth binary 09:53:35 Colon is Forth's code compiler. 09:53:49 So I can only use conditions inside definitions? 09:53:58 Yes. 09:54:05 Is there a thought behind that? 09:54:10 anli: unless your forth supports [if] and friends 09:54:13 ok 09:54:32 Seemed like [if] was supported 09:54:38 anli: yes because it keeps them simpler since if usually compiles to some blank space that is filled in by then 09:55:09 There is also a [?do], it seems 09:55:12 anli: and interpreting one token at a time, the interpreter wouldn't know how far forward to skip if the flag is false 09:55:20 Yes. Words like IF, ELSE, THEN, BEGIN, UNTIL, etc. are compiler words -- they cause specific sequences of code to be compiled. When using them in interpret-mode, they'll cause bytes to be stuffed in the dictionary, but otherwise no observable effect. To the user, there would be no observable effect. 09:55:25 XeF4: oh 09:56:34 hehe, I had to use [i] instead of i 09:57:00 The implementation of words like [IF], [DO], and [I] frighten me. 09:57:41 heh 09:57:45 ok 09:57:52 How can [?do] know things that do dont? 09:57:56 * kc5tja has zero intentions of supporting them for FS/Forth. :) 09:58:01 heh 09:58:10 anli: That's precisely why their implementation frightens me. :) 09:58:14 haha 09:58:19 But they surely do their work 09:58:25 Is that also frightening you? :) 09:58:49 hm, how do I write a newline, I tried ." and " on the next line 09:58:51 anli: To get such words to work, they basically have to count words, constantly keeping track of nesting, constantly checking for [...] words, etc. 09:58:59 anli: CR 09:59:07 (short for Carriage Return) 09:59:48 ah 09:59:51 * XeF4 points to the [...] mess as yet another reason for pre-parsed source and retreats 09:59:56 Can a forth program always be put in one line? 10:00:10 anli: For sufficiently long lines, yes. :) 10:00:13 heh 10:00:26 When loading programs from files, you do not need to keep things on one line. 10:00:35 The one-word-one-line rule of thumb serves two purposes, though: 10:00:41 anli: some forths have line-length limits though (usually same as counted string length limit (which is usually 255)) 10:00:49 1) It helps the user force himself into factoring the software better, and, 10:00:53 What is the purpose with a line length limit? 10:00:58 2) It helps improve the readability of the code. 10:01:00 yeah 10:01:06 of course it makes the code more readable 10:01:20 I only wondered if there are keywords that cant be used in the middle of a line 10:01:25 anli: To prevent the system from overflowing its buffers and corrupting its own memory. To put it in other terms, "to prevent any possibility of a root attack." 10:01:48 anli: Yes -- any word which expects a word to follow it cannot be used across lines. 10:01:58 Otherwise, it's entirely freeform. 10:02:00 Such overflow will only occur if a really dumb programming was doing the implementation :) 10:02:04 ok 10:02:19 anli: but that's patently not true. 10:02:36 The only way a dumb programmer could permit such a system from being created is if he doesn't impose a maximum line length. 10:03:18 kc5tja: I can only see the use of a maximum line length limit if the implementor was using a readline function 10:04:06 How would you implement a system that doesn't have a maximum line length limitation? 10:04:13 anli: the implementor usually uses a readline function because interactively, the interpretation starts when the user hits enter 10:26:17 But if he doesnt use a readline function, he can parse arbitrary length rows 10:26:52 There are only two ways to do that. 10:27:08 One is to read the input stream character by character by character. This is extremely slow. 10:28:03 The other is to manage a 1024-byte buffer (at least), and index into it. It'll be relatively fast until you reach the end of the buffer, where you need to determine: 1) Is this the end fo the file? 2) Is the word I'm currently reading complete, or do I have to shift the contents of the buffer to read more of the word? 10:28:04 Reading 4096 bytes at a time must be better 10:28:28 kc5tja: You dont have to index into the buffer, you parse the buffer until it ends, then you read more 10:28:37 And parsing requires indexing. 10:28:40 The parse results is stored in STL containers 10:28:50 STL? 10:28:59 If the implementor uses c++ then 10:29:14 That's disgusting. I wouldn't touch STL with a 2-mile long pole. But I digress. :) 10:29:21 hehe 10:29:24 The point is, you don't need STL. 10:29:40 Not if you use a readline function, right 10:29:45 You can do an in-place parse (this is how Forth has always done it, and indeed, how Yacc and Bison work too). 10:29:52 yeah 10:30:02 The problem is in managing the buffer. 10:30:16 Not a huge problem however 10:30:35 Well, I thought loading from blocks wasn't a huge problem until I tried to implement it with my existing parser code. 10:30:54 If there is data that continues in the next read, move the data to the beginning of the buffer 10:31:06 Right. 10:31:08 Then read the buffer full again 10:31:23 Is not too hard when you have done it once 10:31:29 But you don't know a priori that the data continues, so you have to be conservative -- you *always* have to move the word-in-progress to the beginning of the buffer and read from there. 10:31:39 yeah 10:31:53 The issue isn't technical feasibility -- it's relative payoff. 10:32:25 Yes, and to not have a limited linelength is a payoff, I think 10:32:40 How often are you going to use such long lines though? 10:32:58 When you say it :) 10:33:01 anli: you also lose the convenient ability to represent line length with a count byte at the start of the line 10:33:12 When I say it? I don't understand. Say what? 10:33:22 How often are you going to use such long lines though? 10:33:31 And I kind of agreed 10:34:20 I am doing an implementation where speed is not cruical, its a debug environment 10:34:34 A way to learn forth meanwhile :) 10:35:07 I will be implementing a parser almost exactly what you describe for one of my first FS/Forth applications under Linux. It's an XML parser for auto-generating static website content. 10:35:16 ok 10:35:26 Is it really static then? 10:35:32 Yes 10:36:06 I modify the XML files, I run it through the processor, and it spits out raw .html files, which I then upload to the web hosting provider. :) 10:36:29 ah, ok :) 10:36:59 I will definitely be researching more dynamic website content creation techniques, especially in conjunction with ColorForth-like source markup. 10:37:16 But that's a long-term goal, at best. 10:43:25 Forth might actually be fast enough to provide dynamic content at static HTML speeds. 10:44:29 Anyway, I need to run some errands. Be back in a bit. 10:44:30 --- quit: mur ("rebboot") 10:44:47 --- nick: kc5tja -> kc-afk 10:48:29 --- join: mur (murr@baana-62-165-189-104.phnet.fi) joined #forth 11:28:45 --- join: PoppaVic (~pfv@s120.waters.gtlakes.com) joined #forth 11:31:10 --- part: PoppaVic left #forth 11:41:07 --- join: crc (~crc@AC859CBE.ipt.aol.com) joined #forth 11:58:17 --- quit: crc ("I was using TinyIRC! Visit http://www.tinyirc.net/ for more information.") 12:09:24 --- join: divgrad (~wer@81.25.33.222) joined #forth 12:13:29 --- quit: divgrad () 12:34:03 --- join: a7r (~a7r@206.72.82.135) joined #forth 12:34:25 --- nick: kc-afk -> kc5tja 12:34:36 * kc5tja feels stupid -- I thought today was Monday. 12:35:15 Got most of my errands done; the only thing left is depositing my unemployment check, which is how I discovered it's Sunday, not Monday. Bank was closed. :) 12:35:57 Heh :D 12:36:22 morning 12:37:04 kc5: what was stupid is I thought Thursday was already midsummer eve so I didn't go to the grocer because I thought they were already closed 12:37:34 Heh 15:03:43 yoh 15:11:27 Here a hint: NEVER, EVER, EVER hit ALT-HOME while in any mozilla product. 15:11:41 If you're typing text into any text boxes of any kind, you WILL lose all your data, irreparably. 15:12:27 burn 15:12:53 No shit. 15:13:04 I just spent 15 minutes yelling and screaming at the computer. 15:13:15 I know it doesn't actually help, but it lets me blow steam. 15:13:26 Considering I'd just spent 45 minutes typing in an e-mail response. 15:19:20 --- join: deluxe (~deluxe@pD9E593BE.dip.t-dialin.net) joined #forth 15:22:29 terve deluxe! :) 15:24:41 terve mur! :-) 15:26:58 mur: coding forth atm? 15:27:35 * deluxe is playing a computer game 15:27:49 called java 15:28:10 heh 15:28:12 naah 15:28:14 * mur is sad :( 15:28:26 Why? 15:29:04 many reasons 15:29:09 i dont know all myself even :( 15:31:14 not hangover from juhannus? 15:31:51 * deluxe sings a few bars of 'no women no cry' 15:32:33 XeF4 i'm absolutist, i dont drink alco at all :) 15:33:08 pervert :-) 15:44:25 --- quit: anli () 16:05:34 --- quit: Robert (Read error: 104 (Connection reset by peer)) 16:08:13 --- join: Robert (~snofs@h138n2fls31o965.telia.com) joined #forth 16:09:17 re ro 16:09:35 boot bert 16:10:07 :) 16:12:27 i would say, at least a 1ghz box ;-) 16:12:48 ?? 16:17:01 ;) 16:26:00 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 16:27:32 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth 16:27:33 --- mode: ChanServ set +o kc5tja 16:46:16 --- quit: mur ("MURR!") 16:46:16 --- quit: a7r (Read error: 104 (Connection reset by peer)) 16:48:13 --- join: a7r (~a7r@206.72.82.135) joined #forth 16:48:15 yoh 16:48:31 that sucked, I just had an epiphany about voltage dividers, and my desktop crashed. 16:48:39 I think it's a sign. 16:48:59 Heheh :) 16:50:51 I really don't like the way some of these electronics books describe Ohm's law. 16:51:42 I was trying to understand why a resistor is so necessary when using an LED 16:52:06 * kc5tja nods 16:52:27 You kind of have to understand how an LED works first, though. Constant voltage drop devices like diodes aren't easily modeled using Ohm's law. :) 16:52:42 They're called "variable resistance" devices for a reason. :D 16:52:56 yeah, I'm mainly thinking of the current setting resistor that accompanies the LED. 16:53:05 * kc5tja nods 16:53:07 XeF4: 1ghz box recommended for gentoo compiling, somebody said. was speaking w/ mur.. 16:53:38 --- quit: deluxe ("l8er") 16:53:45 --- join: jdrake (jdrake@CPE00045afdd0e8-CM014410113717.cpe.net.cable.rogers.com) joined #forth 16:54:09 kc5tja: I mean, you expect the 1.7 volt drop, and you compute the resistor based on the idea you need 20ma across the LED 16:55:32 If you have, say, 9V for your power, then the diode consumes only (say) 2V of that, you need something else to suck up that extra 7V. That's the resistor's job. 16:55:40 yeah 16:56:00 but it's tough, because the resistor doesn't really 'suck up' the voltage right? 16:56:06 Yes, it does. 16:56:22 well, you're routing it to ground, and that is where it goes. 16:56:28 The resistance provides just enough current flow through it to develop a 1.7V drop on the LED. 16:56:37 the resistor itself doesn't make all that charge disappear. :) 16:56:45 No, it just slows it down. 16:56:54 yeah, so that was my confusion. 16:56:55 That's what a reduction in current is -- slowing the flow of electricity. 16:57:07 but that's not what I'm talking about. 16:57:28 I'm talking about exact phrases like the resistor 'sucking up' the excess voltage. 16:57:36 * kc5tja sighs 16:57:41 It does. :) 16:57:52 If you take a voltmeter, and put it across the resistor, it'll read 7V. 16:57:58 (there abouts) 16:58:17 This is where terms like "voltage drop" comes from. 16:58:45 Assuming a 9V supply, of course. 16:58:57 If you're using a 5V supply, then it'll obviously be a smaller value. 16:59:07 yeah, but the voltage doesn't just up and disappear. It's slowed by the resistor, as it 'proceeds to ground' 16:59:17 No. 16:59:21 You're confusing current and voltage. 16:59:24 They are different concepts. 16:59:36 Current is the actual flow of electricity. 16:59:44 and voltage is the potential. 16:59:59 Voltage is how strong held-up electricity wants to push -- the "potential." 17:00:27 So if you put a resistor in a circuit, it'll resist the flow of electricity (reduces the current). But since the current really does want to flow, it'll develop a voltage across it. 17:00:52 The larger the resistance, the larger the voltage. 17:01:02 at a given current 17:01:08 Yes, at a given current. 17:01:22 But the current through a series circuit (all parts strung together, one after another) is constant. 17:01:29 yeah 17:02:59 And if you think this is tough, wait 'til you get into complex impedances, which is often used in transmission lines and antennas. :) 17:03:23 There, the current and voltages change according to length, frequency of the signal, distance of the antenna/cable from other metallic objects, etc. 17:03:24 ;) 17:03:26 Not fun. 17:03:31 yeah, I can imagine. 17:04:34 okay, here's my confusion 17:04:42 let's say I have a resistor across a voltage source 17:05:16 and I take a multimeter, and read across the resistor, I get the voltage I'm expecting from the source 17:05:25 Correct. 17:06:23 if I hook said multimeter up, without a resistor in place, I get the same voltage levels (i.e. I just take my probes, and attach them to + and GND from the voltage source) 17:06:37 Yes. 17:06:53 so why are they the same if the resistor is sucking up voltage? 17:07:21 I would need to draw it out to fully explain. 17:07:32 The "sucking up voltage" refers to the specific context of that leg of the circuit only. 17:07:50 This is because in a parallel circuit, the voltages across all legs are the same. 17:08:03 The battery and the resistor form a simple parallel circuit (that also happens to be serial). 17:08:11 nod. 17:08:12 The voltage rise is the voltage drop. 17:08:30 The sum total of the circuit's voltage, when viewed from an external frame of reference, is 0V. :) 17:08:34 (believe it or not!) 17:08:45 If it wasn't, you'd be getting shocked every time you touched it. 17:08:53 right 17:09:07 Now let's look at the case where you have a battery and TWO resistors. 17:09:24 To make things concrete, let's use 10V for the battery, and 1000 ohms and 500 ohms for the two resistors. 17:09:27 The resistors are in series. 17:09:48 So, when you measure across *both* resistors, the voltage is 10V, as you would expect. 17:10:16 Now, because the total resistance presented to the battery is 1500 ohms, the current is 17:10:19 oops 17:10:37 Now, because the total resistance presented to the battery is 1500 ohms, the current is 6.7mA (approx). 17:10:56 So, as far as the battery is concerned, all it sees is a single resistor that is 1500 ohms. 17:11:13 Now, within the resistor network, you have several voltages available. 17:11:19 yeah 17:11:40 (bringing in how voltage dividers work) 17:12:06 Because the current across the 500 ohm resistor is 6.7mA, the voltage across it is E = IR = (6.7mA)(500) = 3.4V (also approximate). 17:12:39 6.7mA through a 1000 ohm resistor will produce a voltage of 6.7V. 17:12:40 ah! 17:12:51 Well, in reality, they're 3.35V and 6.65V. 17:13:10 If you sum those up, you'll see that they equal 10V -- precisely what the source voltage says it should. :) 17:13:20 nod. 17:14:09 I have some preconceived notions about voltage I think, that I need to get out of my head. 17:14:17 So, if we replace our 500 ohm resistor with a 2V drop LED, that leaves only 8V "left over" for the 1000 ohm resistor to absorb. 17:14:26 nod. 17:14:53 Hence, you'd get 8mA through the whole circuit, even though it's driven by a 10V source (the LED, to the battery, looks like a 2V battery in reverse). 17:15:13 This concept of "left over" is where "voltage drop" comes from. 17:15:15 okay 17:15:31 The idea being, the sum of the voltage rises (batteries) and voltage drops (everything else in a circuit) must equal zero. 17:15:42 If it doesn't, you're in for an electrifying experience. :) 17:16:06 (actually, it usually means a component is about to go up in smoke, or the circuit just won't work. But sometimes . . . ZOT!) 17:16:16 gotcha. 17:16:40 * kc5tja has lit up at 120V because of accidental accounting errors when working with TV power supplies in the past. 17:16:42 Not fun. :D 17:16:54 haha 17:16:55 I'm lucky to be alive, actually. :D 17:17:16 Thankfully, I touched it with my right hand, and not my left. Otherwise, I could have gone into cardiac arrest. 17:17:22 (at worst) 17:18:24 I'll be thinking some more about this today. 17:18:37 * kc5tja nods 17:18:57 Things get fun when you start working with active devices like transistors. :) 17:19:04 (Especially bipolar transistors.) 17:19:18 Although FETs aren't without their complexities too. 17:19:41 it's weird learning this from Software -> Hardware perspective. 17:20:17 * kc5tja nods 17:20:25 I was kind of lucky in that I learned both software and hardware together. 17:20:51 The disadvantage is that I didn't specialize in any one area. ALthough I'm more software nowadays. 17:24:39 okay, so I guess my last question is: 17:24:58 if I put my multimeter in series with a resistor, and a power supply 17:25:32 and I see some voltage from the end of the resistor.. could that voltage that I see vary depending on the impedance of my multimeter? 17:26:18 The multimeter will be calibrated for its own impedance. 17:26:44 Also, when measuring voltages, place the multimeter in parallel. When measuring current, place it in series. 17:26:55 Failing to do this can potentially damage the multimeter, or worse, the circuit. 17:27:12 This is because, to measure current, it needs a very, very low resistance path to disturb the circuit as little as possible. 17:27:33 yeah, I'm aware of that,. in this case I was just experimenting w/ checking voltages at differing points. 17:27:56 trying to compute the results I'd see. 17:28:14 in this case, of the DMM in series, what is 'setting' the voltage I'm seeing from the resistor? 17:29:42 You should be seeing 0V if the DMM is in series with the rest of the circuit. 17:30:08 When measuring voltage, it tries to keep as large a resistance as possible (again, to disturb the circuit as little as possible) 17:30:17 hrm, that's what I thought I'd see: 17:30:21 it's hooked up like: 17:30:32 + - resistor - DMM - ground 17:30:42 and the DMM is showing like 12.55 volts .. 17:30:57 is that just undefined behavior due to misuse of the tool? :) 17:31:00 Oooh, I see. 17:31:27 It's because the circuit is an open circuit. The DMM is dropping the full voltage of the battery, because zero current is flowing through any other part of the circuit. 17:31:59 Basically, it's like if you have + - resistor - BIG HUGE OH-MY-GOD GARGANTUAN RESISTOR - ground 17:32:00 ;) 17:32:23 Ah! but my original question about it varrying due to impedance is appropriate then right? 17:32:51 like, if the DMM acted like a differently sized giant resistor, I'd see a different voltage 17:32:56 Well, yes, but the DMM is going to be calibrated for its own internal impedance. Only if it gets out of calibration somehow will it vary. 17:33:16 okay, coo. 17:33:18 Why, is it varying? 17:33:28 no, I'm saying if I used a different DMM 17:33:35 Ahh 17:33:36 like, I've got a fluke 87 III hooked up right now 17:33:51 if I did the same with a ratshack shitbox, would I see a different voltage from the DMM? 17:34:06 Possibly, but it'd be only within a few % at best. 17:34:26 just due to the fact a DMM has to have such high impedance? 17:35:00 There's a lot of factors involved actually. Impedance is one such factor. The other is the internal ADC's precision and such, the precision of the software inside the DMM, etc. 17:35:15 * a7r nods. 17:35:23 OKay, so it really is on the 'undefined behavior' side of things. 17:35:38 .. you could define it, but it's not really an appropriate use of the tool. 17:35:43 Well, it'll be true even when measuring the voltage of a circuit element in parallel too. 17:35:50 There is always some element of imprecision. 17:35:55 nod. 17:36:14 Realistically speaking, the differences won't matter that much. 17:36:18 but I'm saying the Voltage returned, when the DMM is put in series like that, is just kind of pointless as far as a measuring tool. 17:36:31 If it's reading 12.55V, then I'd say it's between 12.5V and 12.6V, but you don't know for sure precisely where. 17:36:49 Well, it measures the voltage of the power source. . . :) 17:36:59 But generally, yeah, it's not used in that manner. 17:37:14 brb 17:38:45 back 17:41:02 Oh well. I guess I'll be right back. I'm going to go code on FS/Forth some more. 17:41:14 kc5tja: BTW, thanks again for that colorforth HTML 18:01:46 Yeah, np. 18:01:54 Interesting stuff, the way he goes about and does things. 18:34:10 Hi there :) 18:42:45 Hehe 18:42:47 Hello 18:42:52 and bye -- going to get some food. 18:42:54 be back in a bit. 18:43:06 --- nick: kc5tja -> kc-food 19:11:14 --- nick: kc-food -> kc5tja 19:11:20 back 19:19:08 Hi, and goodbye. I'm going to bed now, night :) 19:20:00 hehehe :) 19:20:13 night Robert 21:11:15 --- quit: jdrake ("beißen Sie mich stark") 21:19:00 --- join: jdrake (jdrake@CPE00045afdd0e8-CM014410113717.cpe.net.cable.rogers.com) joined #forth 22:02:57 hola 22:03:51 re 22:04:03 Note To Self: Never, *EVER*, name important system variables using a single letter. 22:04:15 (e.g., in traditional Forth, the variable containing HERE is named H.) 22:04:19 haha 22:04:33 I just spent about 5 hours debugging a critical failure in FS/Forth because I had reorganized some code blocks. 22:04:58 Problem is, the implementation of DU, the dump utility for debugging purposes, uses a word "H" to print a hex byte. 22:05:19 man. 22:05:23 And since the compiler comes after the implementation of DU, it's use of H referred to the code to display a byte, rather than the HERE variable. 22:05:29 Gahhh.... 22:05:42 But, it works now. I renamed H to &HERE (e.g., "Address of HERE"). 22:05:57 werd. 22:06:16 * kc5tja actually likes that idea -- when rewriting Forth for Linux, I'll prefix all system variables with & to ensure they don't get inadvertently shadowed by subsequent words. 22:07:24 But, at least the parser is block-friendly. I think I can implement LOAD in just a few seconds now. *pant* *pant* *pant* 22:08:54 Yes, folks, there are advantages to having to constantly flush the dictionary on every application load. This is one such reason. >:/ 22:08:59 * kc5tja feels stupid now. :) 22:15:08 YEEEHAAA!!! FS/Forth can finally load/interpret source from block storage!! 22:15:26 * kc5tja does the happy dance. 22:15:36 --- join: Serg_Penguin (Serg_Pengu@212.34.52.140) joined #forth 22:15:40 hi 22:18:43 re Serg_Penguin 22:18:52 FS/Forth finally can load source from blocks. 22:19:00 Unfortunately, it lacks an editor. 22:19:06 That will be remedied shortly though. 22:19:53 Unfortunately, though, it isn't 100% fully functional yet. 22:20:08 It doesn't support comments or strings, and it cannot forget words in the dictionary. 22:20:41 Strings and comments will probably be the next thing I'll implement. 22:20:50 * kc5tja also isn't very happy with the code's organization. 22:21:04 But it works, and I'm happy for that. 22:22:04 Haven't yet tested nested loading of blocks, but the writing of the editor will also serve that purpose. 22:32:58 cool 22:33:17 * Serg_Penguin is slightly split between several tasks 22:43:00 --- quit: Serg_Penguin () 23:27:25 Going to bed. 23:27:36 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 23:59:59 --- log: ended forth/03.06.22