00:00:00 --- log: started forth/21.04.13 00:03:28 --- quit: Rakko (Quit: Leaving) 01:35:47 --- join: Keshl_ joined #forth 01:35:49 --- quit: Keshl (Read error: Connection reset by peer) 01:47:40 --- quit: nihilazo (Ping timeout: 240 seconds) 02:00:46 --- quit: rixard (Read error: Connection reset by peer) 02:01:12 --- join: rixard joined #forth 02:15:17 --- join: neuro_sys joined #forth 02:22:38 In a typical threaded implementation CREATE's default code field points to a routine that pushes the value of first parameter cell into stack right? 02:22:48 Just to confirm my understanding. 03:08:52 Morning gents. 03:09:17 neuro_sys: Yes - the address of the parameter area goes to the stack, just like VARIABLEs. 03:09:46 That's needed for the DOES> part of CREATE / DOES> to know where to do its work. 03:13:53 In traditional implementations the parameter area immediately follows the code field, so you can the address by just incrementing the pointer you jumped to code through. 03:14:10 It doesn't have to be that way, though - anything that lets you find a parameter field will work. 03:14:26 I have a pair of pointers for each word - one points to the code, one points to the parameter field. 03:14:44 So primitives don't have that second pointer, since they don't have a parameter field that's separate from their code. 03:15:14 In those traditional systems the code IS the parameter field. 03:15:21 For primitives. 03:17:05 Ah right the address, not the value of the parameter field. 03:17:34 KipIngram: You earlier mentioned that the minimum number of primitives you were able to reduce was around 16? 03:17:58 I am still curious of the smallest possible native/host implementation of a Forth would be where everything is built with threaded code. 03:18:47 Few I checked had around 30+ primitives (native code). 03:19:11 I'm not including the inner/address interpreter to it because it's trivially small and has to be native anyway. 03:21:40 there's sectorforth from a couple of days ago that has 8 primitives and 3 variables... https://github.com/cesarblum/sectorforth 03:22:06 Although it misses a number of features most people would consider to be crucial for Forth 03:25:45 neuro_sys: No, I guessed that I might be able to get down to a dozen or 15 or so. I've never really pushed for that type of optimization. I'm happy to include more primitives if it means superior performance. 03:26:39 I have some "fat families" of primitives, like conditional returns of many different flavors, so I usually wind up with a couple hundred primitives. That's why I'm trying to add this new layer built with macros - build primitives using "portable instructions." I hope to wind up with 50-60 portable instructions. 03:27:14 Well, I think sectorforth is meant as a bootstrapping system. 03:27:26 You'd nearly always build the remainder of your system on top of it. 03:28:04 I read an article once that professed to be a "three instruction Forth." 03:28:17 I didn't really consider it a Forth, but you could use it to make a Forth. 03:28:38 It was essentially offering peek, poke, and execute as remotely tethered instructions. 03:28:49 Sort of a "minimal bringup" system. 03:32:09 To my eye, a Forth system has a data stack and a return stack and is threaded. Indirect and direct threading qualify - I've always had mixed feelings about subroutine threading. 03:32:28 But I'm not going to deny anyone's claim that they've got a Forth just because it's subroutine threaded. 03:33:26 I don't claim any particular philosophical elegance in how I look at it. 03:34:48 Does anyone still experiment with >1 data stack Forths? I know for a few years back in the past that was kind of a hot arena. 04:14:02 If anyone's interested, here's the code I wrote for NUMBER: 04:14:05 https://pastebin.com/bYYV4ZTA 04:14:32 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 04:14:37 I may tidy oup some of the final operations, but I'm happy with the bulk of it. 04:14:44 --- join: Zarutian_HTC joined #forth 04:16:44 No floating point support yet, but it does do arbitrary base up to 62 and offers "syntax sugar" for base 16 and base 2. 04:17:57 For arbitrary base you say :, but for hex you can say x: and for binary b:. 04:18:27 Up through base 36 upper and lower case numbers are case insensitive; starting with base 37 a-z become higher digits. 04:19:54 This is fully debugged; as far as I can tell it completely works. 04:20:33 The debuggingi was kind of fun - figuring out how to insntrument it with only EMIT to work with was... interesting. 04:22:24 It has some aspects of floating point support already in place. If I removed the error trap on . and e then it would get all the way to the end and have a mantissa value and an exponent value and a decimal place count. Only the final processing of that remains to be done, and there's a definite place to tie it in. 04:24:43 What is .: 04:24:49 Or ;; 04:25:20 .: is how I specify a temporary definition. It works the same as : except it marks the definition with a bit in the header. 04:25:41 Later on when I'm through compiling with those words I'll have a word .wipe that unlinks them from the dictionary. 04:25:50 ;; is a double return. 04:25:51 Cool 04:26:07 Yeah, I did that for the first time on my last one, and found it pretty pleasing. 04:26:35 In that one I truly recovered all the space the names too, but I'm not doing that this time - I woundn up with too much memory management complexity in the old one. 04:26:49 RAM is cheap - I don't need to do backflips to recover a few bytes. 04:27:08 I'll probably have .wipe move those words to another list, so I still "have them around." 04:27:18 Maybe. 04:27:32 Do you not have wordlists? 04:28:22 Yes, I will have that. 04:28:30 And yes, that can accomplish the same goal. 04:28:54 The initial setup has one vocabulary, but all the hooks are in place for more. 04:29:03 I'll actually implement those words in Forth later. 04:29:16 FIND already knows how to search a whole list of vocabularies. 04:29:36 I'll have a variable PATH that heads a linked list of vocabularies to search. 04:30:01 I don't know why you'd want to hide many of those words 04:30:11 Like 0-9? for instance 04:30:20 Sure - I might change my mind on some of them. 04:30:47 Particularly the flag management words right at the beginning - they seem useful. 04:30:51 I debated about them. 04:31:06 But I decided because they have a stack frame variable hard coded into them that I'd go ahead and hide them for now. 04:31:14 That makes them slightly less generic. 04:31:35 They'd be reusable only if I use the frame variable s1 for flags. 04:31:50 Which I may decide to accept as a "convention." 04:32:13 Might be better to change it to s0 if I'm going to do that. 04:33:11 Those items that are loaded onto the stack in the word "frame." The { makes them accessible as s4, s3, s2, s1, s0. 04:33:19 Regardless of what else I've done to the stack. 04:33:45 The 4 } drops them. 04:34:05 Well, drops four of them. The first one is the result slot. 04:34:23 How does number refer to pre/digits/post if they haven't been defined yet? 04:34:52 Right. When this becomes real Forth source I'll have to re-order. 04:34:57 Nasm can find the symbols. 04:35:04 Oh righty 04:35:04 So order is irrelevant at the point. 04:35:35 Do you support double numbers? 04:35:48 No; I opted for floating point instead. 04:36:04 I figure with 64 bit to start with, double isn't horribly compelling. 04:36:25 I could tweek it a little and do that, though - it counts digits to the right of the decimal point. 04:36:26 --- quit: Zarutian_HTC (Remote host closed the connection) 04:36:35 It's not it's just a compatibility thing now 04:36:51 Except all the math is 64 bit at the moment, so that would take a little work. 04:36:56 But it is useful for writing code that will run on 64-bit as well as 16/32-bit 04:36:59 Not too much though - that would just be in absorb. 04:37:06 True. 04:37:31 I thought about it. I could do it all if I required floats to have an exponent specified. 04:38:10 Also calculations with more than one operation are more accurate if they're done with 128-bit intermediates 04:38:11 One of my goals is scientific computing, so floating point was of real interest to me. 04:38:25 I do consider floating point necessary for any desktop forth 04:38:26 I understand. 04:38:53 I could still have primitives that maintained 128-bit format internally. 04:38:57 The first proper programming language supported floating point, in 1957 04:38:58 It was just a decision. 04:39:07 It would be a not-so-hard step to change it. 04:39:53 I figure I'll add the rest of floating point after I have the system further along and can debug interactively more effectively. 04:40:24 I'll rip out the error and have it just leave the whole stack frame there, and I can inspect it and make sure it's got the exponent and the decimal count right and so on. 04:40:43 Then use the fpu to make it a properly formatted float. 04:41:00 I've got all that code in my other one, so I can use it to refresh my memory. 04:41:27 What are your thoughts on where floats should reside? 04:41:42 Would you leave a float on the main data stack? Or on the FPU stack? 04:41:52 FPU stack 04:42:19 That's what I did on my old one. But never worked with it enough to learn whether that was the right decision or not. 04:43:04 Since NUMBER will need the FPU to do that work, I think I may save its state off and restore it when I'm done. 04:43:06 --- join: f-a joined #forth 04:43:15 I'd like to have the whole stack for "real" work. 04:43:33 Although I managed to do a hell of a lot with my old HP calculator that only had a 4-deep stack. 04:43:45 You can't just keep adding stacks to make things easier, but with the weird size/alignment concerns if you have a Forth that supports different size arch's it makes far more sense to keep them separate 04:44:06 FPU stack doesn't need to be deep 04:44:20 Right. Even 4 is very useful. 04:45:01 If most arch's have a set of separate reg's for FPU work then we might as well have a separate stack 04:45:29 Could have a float TOS register too 04:45:46 I'm interested in a degree of portability, but I don't obsess over the full gamut of architectures out there. 04:46:03 I'm primarily trying to make sure I'm arranging things so an ARM implemenntation will be good. 04:46:11 Beyond that, I haven't given it a lot of thought. 04:47:02 On the one I did before this I *wanted* that as well (good portability to ARM), but I wound up doing things that made it not turn out so well. 04:47:15 I really didn't know enough about ARM at the time. 04:47:26 This time I've kept its RISC nature in mind better. 04:47:38 --- join: nihilazo joined #forth 04:47:57 I've used macros so that I can exploit the more powerful addressing of the x64 while still having a good pathway to ARM available. 04:51:38 I think your code could do with stack comments at the very least 04:51:56 I plan to have a shadow screen later. 04:52:09 I'll put those in then. 04:52:19 I agree with you, 04:52:37 but I had the code thoroughly in mind and I find it easier to work with without comments spreading it out. 04:53:57 I've tried inline comments, stack effect comments, etc. - somehow they just grate on me. Make the code seem uglier. So shadow screens offer a reasonable compromise. 04:54:18 The editor I wrote for the last one could show me two side-by-side blocks anyway, so that part will work well. 04:54:55 I'm using 4k blocks these days, so 64 64 character lines. 04:55:00 Looks nice on the screen. :-) 04:55:55 You can get quite a lot of code in a 4k block (if you don't use up a lot of the space for comments). That editor fit in one block, and offered full screen navigation with vim-style cursor control and some other nice features. 05:02:21 There is sort of an inverse relationship between readable forth code and 'beautiful' forth code 05:02:42 I won't sacrifice maintainability/readability for beauty 05:03:15 I want things to be readable even if it sacrifices the code looking nicer 05:09:34 I know. I'm not really writing this code for anyone else, though, so as long as I can rememberh how it works I'm fine. I think shadow screens will get me there. 05:11:29 Early in my career I held positions where I had a good bit of authority - engineering executive type stuff. And I functioned sort as the company's "master architect." The owner would drop architecture stuff on me, and of course he had to get what he wanted. But he left the bulk of it to me. Those "glory days" are over and these days I'm sort of a small player in a huge corporation. This Forth is my 05:11:31 sandbox to play in exactly how I please. :-) 05:12:35 I absolutely agree that if my intent was for a team to work with this code it would need comments. 05:21:43 Another thingn I've thought about doing someday is implementing a "comments database." Comments that can be as large or as small as I like, that are "pinned" to specific places in my codebase. An editor keystroke would open the comment associated with any given spot in a separate window. 05:22:11 --- part: f-a left #forth 05:22:22 I conceived that idea as a way of coping with my distaste for inline comments. 05:33:50 Trust me, though - my *hope* for this system is that I use it for decades as the primary software I put on "gadgets" that I build. I don't want to look at some part of it years down the road and have no idea what it's doing. So it needs somethingn. The shadow screens at the very least. 05:34:22 I really like the comments database idea, because then I can just go hog wild and put in very detailed explanations of what's going on. 05:34:36 The resons for the decisions I made, etc. 05:34:54 And it will let me do it without making the code look unpleasant to me. 05:36:51 I'd probably have the editor be able to render the characters at comment locations differently, so I can see where the comments are. But that will be something I can turn on and off. 05:37:46 --- join: jedb__ joined #forth 05:37:55 And if I do that I'll want it to be smart enough to adjust the row and columnn positions of the comments when I make changes to the block. 05:38:06 So there's a bit of work there to get something like that working well. 05:38:46 But I don't wrap at the end of lines, so it won't be *too* intractable. 05:40:26 --- quit: jedb_ (Ping timeout: 268 seconds) 05:42:42 It would also be possible to arrange for some comments to qualify as "inline" comments that I could toggle on and off in the editor. 05:43:05 That would make me feel *totally* different about commenting. 05:50:58 --- quit: dave0 (Quit: dave's not here) 06:02:37 --- join: tech_exorcist joined #forth 06:04:19 Oh, veltas - here's something I'd like your opinion on. 06:04:24 1e6 06:04:28 int or float? 06:22:08 According to standard that's a float 06:22:17 But if a forth made that an int I wouldn't mind 06:22:47 I've initialised stuff like that before in C, where you can convert from a float constant to an int implicitly 06:23:09 KipIngram: Hey look side-by-side comments and code http://gitlet.maryrosecook.com/docs/gitlet.html 06:23:19 Reminded me of what you said about the shadow screen 06:30:58 Actually I would mind because 1E is shorter than 1.0E or 1.E 06:31:07 But if 1. is a float then it's fine 06:37:37 --- join: f-a joined #forth 06:48:25 --- quit: f-a (Quit: leaving) 06:53:32 siraben: I'm thinking about trying out Lisp again, what Lisp do you recommend? 07:06:06 veltas: I'm partial to Scheme, which probably fits the Forther mentality well (roll your own, more minimal than Common Lisp, say) 07:06:31 But Common Lisp is also a common choice, and more recently in the last 10 years, Rackey 07:06:33 Racket* 07:08:18 I guess it also depends one what you want to do/if you want to implement a Lisp as well 07:13:50 --- quit: Kumool (Ping timeout: 252 seconds) 07:15:36 --- join: Kumool joined #forth 07:17:28 --- join: f-a joined #forth 07:25:26 Not sure just window shopping, but thanks siraben that is a useful summary for me 07:27:40 I've never played with Lisp, but just looking at it from the outside I've had the impression that it has a very interesting and elegant engine under the hood. 07:30:40 KipIngram: depends on the specific Lisp of course, but generally yes 07:30:58 the functions of Lisp run all the way to Alzono Church's lambda calculus in the 1930s 07:31:06 foundations* 07:32:47 veltas: there's also the venerable SICP textbook (and excellent 1986 lecture series on youtube), but that doesn't really teach Scheme, instead using it as a vehicle to teach concepts re: computation, compilers, interpreters, streams, message passing, pattern matching etc. 07:33:21 It's funny when they mention other programming languages which mostly are obsolete now (ALGOL, PL/I, COBOL) 07:35:04 KipIngram: In fact for some time the original LISP didn't even have a compiler or interpreter, McCarthy regarded it as a formal system for computation 07:39:29 I think I knew that. Then someone... had a bright idea. :-) 07:40:03 Chuck wrote a book way long ago, in the early days of pre-Forth, that's eye opening regarding it's heritage. 07:40:10 It didn't start out with : definitions. 07:40:19 It operated by text substitution. 07:40:36 Word names were just macros that triggered the insertion of the appropriate text. 07:41:15 --- part: f-a left #forth 07:51:10 heh, computation is just substitution all the way, λ-calculus also proceeds by plain substitution (provided one renames under binders correctly) 07:51:33 KipIngram: which book did Chuck write? 07:54:53 https://colorforth.github.io/POL.htm 07:55:04 Programming a Problem Oriented Language 07:55:50 Yes - that one. 07:55:57 It's an informative read. 08:00:43 You can see the "seeds of what was to come." 08:01:09 And he talks about a number of techniques that faded into obscurity and never made it into what was ultimately Forth. 08:01:58 Touches on what would have to be considered very primitive file systems, built on top of the disk blocks. 08:27:46 --- quit: tech_exorcist (Remote host closed the connection) 08:28:11 --- join: tech_exorcist joined #forth 08:31:23 --- quit: proteusguy (Remote host closed the connection) 08:45:09 --- join: f-a_ joined #forth 08:51:02 --- quit: f-a_ (Quit: leaving) 08:51:19 --- join: f-a joined #forth 09:02:35 --- quit: neuro_sys (Remote host closed the connection) 09:05:10 --- join: neuro_sys joined #forth 09:05:25 --- quit: neuro_sys (Changing host) 09:05:26 --- join: neuro_sys joined #forth 09:05:47 --- quit: tech_exorcist (Remote host closed the connection) 09:06:09 --- join: tech_exorcist joined #forth 09:07:28 I dabbled a bit in Lisp, ended up mostly writing Emacs Lisp. I am far from knowledgable about the depths of Common Lisp. But my first read was Lisp 1.5 Primer by Weissman, as it is very simplistic and builds from the primitives of Lisp (basically a cons tree), which, I guess the modern/later Lisps tend to try to hide away. 09:09:14 It seemed insanely inefficient, but the simplicity/elegance of building a computational system from "cons pairs" and its implications in terms of treating code as data was a pretty exciting realization. 09:10:54 Later when I looked into Common Lisp, I tried out SBCL implementation, which produces pretty efficient machine code, but otherwise the amount of symbols/packages in Common Lisp made me lose interest quickly. 09:19:53 That sounds a bit like how I reacted to LaTeX. When I first sat down to learn it, I thought I was about to learn a "language." But what it really is is a massive toolbox of widgets to achieve various typesetting goals. And there's not really any sort of clean "architectural synthesis." No "principle" you can grasp that makes a large part of the thing apparent to you. You just have to know the tools in the 09:19:55 toolbox. That type of learning is incredibly unsatisfying to me. 09:20:17 Though I highly value what good LaTeX chops allows one to do. 09:20:19 +1 09:20:59 Part of the problem is that that toolbox probably has literally thousands of authors. 09:21:38 neuro_sys: I'd probably enjoy exactly the same aspects of Lisp that you did. 09:23:15 --- join: lispmacs[work] joined #forth 09:31:20 --- quit: mark4 (Remote host closed the connection) 09:31:45 --- join: mark4 joined #forth 09:39:39 I just found that Lisp 1.5 Primer here, for anyone who's interested: 09:39:41 http://www.softwarepreservation.org/projects/LISP/book/Weismann_LISP1.5_Primer_1967.pdf 09:41:05 That is a very antique-looking document... 09:41:30 "LISP is not an easy language to learn because of the functional syntax and insidious parenthetical format" 09:41:40 page vii 09:41:44 hehe 09:42:15 lisp is evil 09:45:26 i use scheme for my desktop projects. but I've not found it to be practical for small microcontrollers 09:45:52 --- part: f-a left #forth 09:46:42 there is microscheme but it is non-interactive development 09:46:48 --- quit: gravicappa (Ping timeout: 240 seconds) 09:49:47 --- join: gravicappa joined #forth 09:58:36 I do have to admit those parentheses are off-putting to me. 09:58:48 But I still suspect there's something underneath that I'd find quite lovely. 10:01:00 Haha - I went to get coffee, read what you quoted above, and then went back to the doc and read the same thing again. I'm just right on your heels. 10:04:38 I think the main touted advantages of lisp are (1) ease of interactive development, and (2) the homoiconicity, i.e., code and data are the same structure, making it easier to add new syntax 10:10:38 but it is problematic in a very resource-limited MC environment, because (1) the challenges of dealing with garbage collection and (2) the challenges of translating the pure lisp ideals into lightwieght compiled code. Also, as Chuck pointed out, lisp doesn't really standardize anything on the level of I/O and memory access 10:11:30 I played around with a lisp that is loadable through the Arduino IDE. It was token based 10:12:43 no, wait, I don't think it was token based 10:12:48 uLisp is what I was thinking of 10:14:35 with 328P MC, you could fill up your ram with about a dozen procedures 11:04:06 --- join: andrei_n joined #forth 11:04:41 --- quit: andrei-n (Read error: Connection reset by peer) 11:14:06 --- quit: mtsd (Quit: Leaving) 11:31:09 --- join: mtsd joined #forth 11:34:38 --- quit: neuro_sys (Remote host closed the connection) 11:37:09 --- join: neuro_sys joined #forth 11:37:12 --- quit: neuro_sys (Changing host) 11:37:12 --- join: neuro_sys joined #forth 11:37:16 I think I was disconnected. 11:37:59 KipIngram: Once you get to the part (earlier in the book) where how a "symbolic expression" is formed and implemented, you will possibly understand the implications in the terms that data and code are the same in Lisp, which opens up things like meta-programming (macro expansions) and runtime code generation (not that I've seen or used this aspect at all). The book is very old, but so clutter-free and the audience is computer-savy. I 11:37:59 like that older books jump straight to the point in general. 11:38:21 But I believe Common Lisp has a world of cool stuff beyond the simple formulation of the language presented in 1.5. 11:47:54 It seems like a good starting point. 11:48:05 Get the key core aspects first. 11:55:38 --- join: Zarutian_HTC joined #forth 11:57:37 siraben: What is a good book for learning Lisp with Scheme (I already learned a bit of elisp but don't mind a slower or faster pace book, I can just read faster) 12:00:17 veltas: Structure and Interpretation of Computer Programs 12:01:00 a book I always recommend regarding Scheme 12:03:34 Thanks but I'm looking for a book that's more of a tutorial for Scheme and not as CS101 12:04:27 I was planning to read R6RS? 12:04:31 At least it's on my reading list. 12:27:57 And which implementation should I use, MIT/GNU Scheme, GNU Guile? 12:38:58 veltas: an argument for GNU Guile is you have a pretty large support base for it at #guile and at #guix, since GNU Guile is the basis for the Guix Gnu/Linux operating system 12:39:57 Gnu Guile is fairly easy to embed in C programs which is something you eventually want to do 12:43:12 Yep 12:52:10 --- join: f-a joined #forth 12:54:17 --- quit: gravicappa (Ping timeout: 252 seconds) 12:58:01 --- quit: andrei_n (Quit: Leaving) 13:29:30 --- quit: chrisb (Quit: leaving) 13:48:44 --- quit: X-Scale (Ping timeout: 252 seconds) 13:49:42 --- join: X-Scale joined #forth 14:02:54 --- quit: mtsd (Ping timeout: 265 seconds) 14:54:38 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 14:55:00 --- join: Zarutian_HTC joined #forth 15:05:15 --- quit: tech_exorcist (Ping timeout: 265 seconds) 15:09:02 --- quit: Zarutian_HTC (Ping timeout: 252 seconds) 15:09:21 --- join: dave0 joined #forth 15:10:10 maw 15:20:11 --- quit: mark4 (Remote host closed the connection) 15:36:33 --- quit: neuro_sys (Remote host closed the connection) 15:56:03 --- quit: f-a (Quit: leaving) 15:58:34 --- nick: jedb__ -> jedb 16:20:51 --- join: Zarutian_HTC joined #forth 17:23:02 --- quit: dave0 (Quit: dave's not here) 18:01:13 --- join: Monev joined #forth 18:01:40 --- quit: Kumool (Ping timeout: 268 seconds) 18:32:27 --- join: boru` joined #forth 18:32:30 --- quit: boru (Disconnected by services) 18:32:32 --- nick: boru` -> boru 18:35:59 veltas: Guile is pretty well maintained 18:36:25 CHICKEN also has good library support and C FFI 18:36:36 --- quit: cp- (Quit: Disappeared in a puff of smoke) 18:37:04 --- join: cp- joined #forth 18:42:53 maintenance is important 18:43:14 especially since scheme is one of those languages that, like forth, have many poorly-maintained implementations 18:44:53 and especially since that once you've chosen a scheme impl you're basically stuck with it, because of little standardization of anything beyond the core language 18:45:16 I'd go with guile if you're ever planning on embedding it in C code 18:45:44 --- quit: cp- (Quit: Disappeared in a puff of smoke) 18:47:48 --- join: cp- joined #forth 19:40:51 --- quit: rpcope (Ping timeout: 260 seconds) 19:46:00 --- join: rpcope joined #forth 19:53:19 --- quit: sts-q (Ping timeout: 265 seconds) 19:59:09 --- join: dave0 joined #forth 20:00:13 maw 20:08:30 --- join: sts-q joined #forth 20:22:54 Evening dave0. 20:31:17 hey KipIngram 20:54:24 --- join: mtsd joined #forth 22:12:37 --- join: gravicappa joined #forth 22:46:22 --- join: andrei-n joined #forth 23:04:52 --- join: jedb_ joined #forth 23:07:35 --- quit: jedb (Ping timeout: 260 seconds) 23:33:27 --- quit: MrMobius (Read error: Connection reset by peer) 23:35:11 --- quit: rann (Read error: Connection reset by peer) 23:35:13 --- quit: ovf (Read error: Connection reset by peer) 23:37:06 --- join: rann joined #forth 23:38:44 --- join: ovf joined #forth 23:50:45 --- join: jedb__ joined #forth 23:53:21 --- quit: jedb_ (Ping timeout: 252 seconds) 23:59:59 --- log: ended forth/21.04.13