00:00:00 --- log: started forth/08.04.17 00:42:37 --- quit: ecraven ("bbl") 01:04:41 --- quit: arke (Read error: 110 (Connection timed out)) 01:19:25 --- join: ygrek (i=user@gateway/tor/x-d5e92f9b99ac6fa9) joined #forth 01:19:42 --- join: Maki (n=Maki@adsl-224-84.eunet.yu) joined #forth 01:50:36 --- quit: ygrek (Remote closed the connection) 02:13:05 --- quit: nighty^ ("Disappears in a puff of smoke") 04:25:45 hi slava 04:42:53 --- join: tane`weq (n=tane@p57903AE3.dip.t-dialin.net) joined #forth 04:57:12 --- quit: tane (Read error: 110 (Connection timed out)) 05:00:18 --- join: ecraven (n=nex@140.78.42.119) joined #forth 05:31:26 --- join: nighty^ (n=nighty@p5025-adsau17honb13-acca.tokyo.ocn.ne.jp) joined #forth 05:49:28 --- quit: ecraven ("bbl") 06:36:52 --- join: JasonWoof (n=JasonWoo@unaffiliated/herkamire) joined #forth 06:36:52 --- mode: ChanServ set +o JasonWoof 06:38:18 yay :) fronds' new event handling system now has a working "execute word" dialog 06:38:42 perhaps "input mode" is far more accurate than "dialog" 06:45:51 --- join: forther (n=forther@c-67-180-150-67.hsd1.ca.comcast.net) joined #forth 06:58:58 --- join: Malfermi1aKodo (n=kansu@xdsl-78-34-137-212.netcologne.de) joined #forth 06:59:05 --- quit: MalfermitaKodo (Nick collision from services.) 06:59:10 --- nick: Malfermi1aKodo -> MalfermitaKodo 07:07:08 and now it has search! 07:15:42 and now it uses the new event handling by default :) 07:15:49 great to have a sane keybinding system 07:17:03 For a long time (since I worked on BeOS 10 years ago) I've wanted to have a GUI-wide service for handling input. 07:17:59 Basically a program would publish a list of commands (with default key bindings) that it knew how to handle. 07:18:47 The system would manage a stack of these command lists, and allow the user to edit the bindings in a central location. 07:19:05 I made a bunch of constants that represent "commands" such as "go up", "follow link", "go back", "quit" etc 07:19:20 then I made a keybinding system with tables to map key presses to those constants 07:19:35 different tables for different input modes 07:19:59 ie if you're holding down the modifier key, pressing S has a different command-constant than without the modifier key down 07:20:48 Same sort of deal, but doing systems work at the time I wanted to normalize it for all apps on the OS. 07:21:11 then, there's another set of tables that map these commands to actual code, according to what you're editing/looking at 07:21:35 yep 07:21:55 that would be awesome 07:22:01 's what I'm going for 07:24:51 always bugged me that it was only convention, that had common key-sequences be the same between programs 07:25:41 the really common stuff, like cut/copy/paste/print/save is generally the same 07:26:17 but less common things like panning, zooming, preferences, etc are quite incensistant 07:26:32 and it's not like it's nice for the programmer either 07:27:00 it's a lot of work to get your app to "behave" well (ie be consistent with the OS norms) 07:27:31 my goal is to make it difficult to make something that does _not_ behave well 07:30:04 if you want to add a new thing that the system can edit/view, just write a function to display it, and a few to navigate it, and put the navigation/editing words in a table with the command constants 07:32:06 --- join: Malfermi1aKodo (n=kansu@xdsl-78-34-146-21.netcologne.de) joined #forth 07:38:27 --- quit: MalfermitaKodo (Nick collision from services.) 07:38:33 --- nick: Malfermi1aKodo -> MalfermitaKodo 07:38:52 --- quit: TreyB (Read error: 110 (Connection timed out)) 07:56:26 --- quit: timlarson__ ("Leaving") 08:10:08 --- quit: forther (Read error: 110 (Connection timed out)) 08:27:50 --- quit: proteusguy (Connection timed out) 08:28:38 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 08:53:10 --- quit: Baughn ("Kernel update") 08:55:17 Hi. 09:01:17 --- join: Baughn (n=svein@084202038064.customer.alfanett.no) joined #forth 09:07:13 hi quartus 09:12:21 When base is 0 some wierd things happen :( 09:14:58 --- join: forther (n=forther@207.47.34.100.static.nextweb.net) joined #forth 09:21:08 --- quit: forther ("Leaving") 09:27:33 I bet :) 09:29:05 wow, my fronds VM image contains only 1436 bytes of compiled code 09:31:48 wow 09:32:35 the image is 69KiB 09:32:41 mostly data/source 09:32:45 that's pretty small 09:32:54 the compiled code is pretty much just the compiler 09:32:59 jeff fox still thinks its bloated though 09:33:46 hehe 09:34:09 it would probably compress well 09:35:00 yeah, the 69KiB gzips down to 27KiB 09:36:36 not bad for an interactive source browser that can compile and execute things for you 09:37:06 now that I've got a decent event handling system set up I've gotta make it so you can actually edit the code 09:38:36 If I keep up this rate, it'll be there in a month 09:38:36 screenshots? 09:38:49 sure, one sec 09:54:35 --- quit: tane`weq ("Leaving") 10:01:22 http://jasonwoof.org/fronds 10:01:42 they're too big for the page. Catch it quick if you want to see it without thumbnails 10:03:50 looks cool 10:13:51 thanks 10:14:19 took me a while because I wanted to fix the comments first 10:14:40 i tweaked factor's compiler a bit, now it's about 4x faster on one benchmark 10:14:45 the cross compiler (from herkforth) wasn't getting the stack comments for primitives 10:14:51 sweeet 10:15:05 I'll have to play with factor again one of these months 10:15:42 I'm so glad to hear that you continue to make it faster, since I'm on pretty low-end hardware, and have little patience 10:15:54 now I've got 128MB of RAM and pentium 500Mhz 10:16:02 my goal is to be in the top 10 of the shootout 10:16:16 what shootout? 10:16:42 http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all 10:17:03 the one where bigForth is in 19th place :) 10:38:58 interesting that free pascal has by for the lowest memory usage on mandelbrot 10:44:37 JasonWoof: Do you have any information about your keybinding system on the web? I have been hacking on VIBE, but adding multi-character commands (d5w to "delete five words") may require quite a bit of reengineering. I am wondering if your system might simplify the problem. 10:48:42 nope 10:50:33 I don't know if it would help 10:50:46 seems like a different paradigm 10:52:28 command parsing in vim seems complex to me 10:52:54 maybe it's something similar, in that you must parse first for meaning, and then by context see what to do with that 10:52:55 The current VIBE paradigm sounds similar to how you have described Fronds, but the paradigm that it would need to handle multiple-character commands is probably pretty different. VIBE has specially-named words ($$i41 for "A" [hex 41] when in "i"nsert mode) and then FINDs those at runtime based on the mode and the character that was pressed. 10:53:44 scarry 10:54:04 Yeah, I'll probably have to do something like that. Chain word executions together in a hierarchy or perhaps just have some words specify that they take an optional count and type (word, line, character). 10:56:17 you could have a variable for the argument 10:56:31 and flag it as empty somehow, maybe with the value -1 or a seperate variable 10:57:05 pressing number keys clears the flag and increases the arg variable 10:57:51 That's an interesting idea. I guess I need to make a matrix of the commands that I am supporting and their potential arguments. "x", the "delete character" command takes an optional numeric argument as a prefix (4x for "four character delete"). The movement commands do the same thing. But then some commands specify the command first and then the count and type ("d4w" for delete four words). 10:58:05 I'd think the hard part would be dealing with a word like "d" which doesn't do anything right away until you do a movement 10:58:44 see, "w" takes an argument of 4 10:58:46 Right, d, r, etc. would be tough. You would need to have them consume additional arguments until they got everything they needed or found something that they don't understand. 10:59:02 tricky thing with movement keys, is that they either move, or they pass a range to another command 10:59:11 OOh, I think I may have it: 10:59:16 Right, that is one of the unfortunate complexities. 10:59:46 you have a variable that holds a command. by default it's "move" but it can be changed to eg "delete" (by the d key) 11:00:17 commands like w calculate a range/movement (as data) and pass it to the command in the variable. then reset the variable to the standard "move" command 11:00:35 mmm r is different 11:00:39 Ah, that is very clever! 11:00:50 Well, r could immediately change the command. As could c. 11:01:11 r could just call KEY to get the replacement 11:01:19 Err... wait, does r take arguments? I always use c for replacing words. 11:01:22 ^V might call KEY too 11:01:39 Yeah, I don't think I am going to get into the whole selection business... :) 11:01:41 you can do 6rx 11:01:54 but I don't think a numeric argument to r is important. 11:02:06 no, control V 11:02:10 Ah, right. Not sure how useful that is in Forth blocks though. But it's good to keep in mind. 11:02:19 oh wait.. 11:02:47 I meant ^V in input mode, or when entering commands at the : 11:02:58 the thing for entering special characters 11:03:30 Oh right, that could be useful I suppose. Although I mostly just put those in as their raw values. 11:03:32 in normal mode ^V does to rectangular selection. Which is very cool... but surely more than you want to deal with :) 11:04:02 never mind it, I was just thinking of something off the top of my head that wants to read in keypresses without the usual bindings 11:04:12 That's pretty much my feeling as well. :) Besides, blocks are so small that how much do you *really* need to select. :) 11:04:50 Presumably you could create some sort of escape mechanism where a word takes over processing it is defined. But that sounds a bit complex and hopefully unnecessary. 11:05:14 it's not complex, just call KEY yourself 11:05:40 I really like the "default to move" idea though, that might be the trick to making all of this work without having to code up each word with knowledge of its keybindings. 11:06:31 I meant that the override part felt complex. Ideally the words would continue to be defined based on their letter keybinding and the keystroke interpreter would do all of the argument-processing, handing off count and type values on the stack. 11:07:28 lost me there. you may only need to call KEY to implement "r" 11:11:15 My theory is that the outer keystroke reader/processor (the thing that calls KEY) would have some way of determining what additional arguments a word could accept. It would then loop as necessary to consume those arguments and abort (beep, really) if something else comes along. The target word itself (the one that implements "r" or "d" or whatever) would get called with a count and type (line, word, character) on the stack. This way only a single word n 11:14:26 tooo long... cut off "this way only a single word n" 11:14:39 needs to invoke KEY and all of the parsing logic is abstracted away from the execution of the editing operation. 11:15:17 Sorry about that; I didn't know that there were limits in IRC. Serves me right for talking in paragraphs I guess. 11:15:46 hehe :) this is the 21st century! everything must be in short pithy soundbytes 11:16:11 you could do it that way, but I suspect it would be quite difficult 11:18:53 i'm working on optimizations for converting generic arithmetic to machine arithmetic 11:18:58 this has been an ongoing project for the last few years 11:19:03 Which part do you think would be difficult? 11:20:07 malyn: knowing what syntax is valid, and what it means 11:20:16 malyn: for each command 11:24:29 Hmm... I have visions of a defining word for each action that stores the valid arguments in the data space for the word, which are then considered post-FIND, pre-EXECUTE by the key-reading code. That feels like it should work, given that all of the suffix-selection (move) commands only take a numeric argument. 11:27:00 good lord 11:27:14 do the simplest thing that could possibly work 11:28:21 While I absolutely agree with that statement, I also don't want to have to sprinkle argument-decoding logic throughout all of the action words. I'd rather have one block of code that knows how to process arguments and then have lots of super-simple action-handling words. 11:29:09 But maybe I am crazy and none of this will work. I'll have to actually try coding it up and seeing if it looks elegant or like something that is too clever to be a good idea. 11:29:28 http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html 11:30:07 you don't have to have the logic everywhere 11:30:10 you factor it out 11:30:32 obviously words that take an optional argument will have to check if it is present 11:30:39 Isn't that what the defining word and keystroke processor are doing, factoring out the logic? 11:30:49 although, in the case of the movement words, you can make it default to 1 11:31:11 : num-arg-or-1 num-arg? if v-num-arg @ exit then 1 ; 11:32:15 : move-left-handler num-arg-or-1 vibe-here 1+ move-to ; 11:32:19 oops 11:32:28 : move-left-handler num-arg-or-1 vibe-here + move-to ; 11:33:02 then MOVE-TO can make sure it's a valid range (doesn't go past the end/begining of the block) and if so act on it 11:33:12 either move the cursor, or finish a delete command or whatever 11:33:41 malyn: yes, but that's not the only way to factor it out 11:34:13 you're talking about attaching data structures to all key handlers 11:34:22 I'm saying just call a word or two from each that does the appropriate thing 11:34:34 I agree, there are many ways to factor it out. I tend to focus on minimizing duplication and making the stuff that I have to write lots of (command handlers) much simpler than the stuff that I only write once (the thing that parses keystrokes). 11:35:05 : d-handler ['] range-delete [is] movement-handler ; 11:35:25 me too 11:36:01 I rarely write definitions that don't fit nicely on one line 11:36:14 and I porposely didn't put in a "copy" feature in my editor 11:36:21 I can easily move definitions, but not copy 11:36:37 this further discourages me from creating duplication 11:37:28 I hear you on that. Make an operation painful and people will try and avoid that, even if it means thinking harder to come up with a way to avoid the situation. 11:37:48 : reset-movement-handler ['] -move-to [is] movement-handler ; 11:37:59 : move-to movement-handler reset-movement-handler ; 11:38:04 i don't believe in artifical restrictions 11:38:36 it's not to restrict others 11:38:46 I'll put it in eventually. 11:38:59 it's an experiment in my personal coding style 11:39:22 I didn't bother implementing copy, or ELSE or a couple other things, just to see how my coding changed in their absense 11:39:58 I don't see forcing others to do this. 11:40:01 maybe... 11:40:09 would probably alianate too many people 11:41:09 heh, when I consider forcing it on others, it's not that I won't let them have an ELSE, but that I might be very strict about what kind of code I'll accept into the main distro 11:41:40 I like things which encourage me to make many small definitions 11:42:01 not using ELSE does this 11:42:08 not having copy/paste does this 11:42:32 JasonWoof: Does Fronds use blocks or text files? 11:42:39 malyn: no 11:43:57 No blocks or no text files? Or something else entirely? 11:44:35 wow, I really haven't documented fronds hardly at all, not even locally 11:44:56 I have special data structures for the source 11:44:59 --- join: Malfermi1aKodo (n=kansu@xdsl-78-34-136-126.netcologne.de) joined #forth 11:45:04 --- quit: MalfermitaKodo (Nick collision from services.) 11:45:09 I have a set of large arrays for the dictionary 11:45:09 --- nick: Malfermi1aKodo -> MalfermitaKodo 11:45:15 for the different "fields" 11:45:24 one for the CFAs, one for the word names, one for comments, etc 11:45:29 one for source 11:45:46 source is a pointer to data object (type, length, data) 11:45:59 contents of source data object is a series of source tokens 11:46:53 a token is in index into the dictionary of a word, and a few bits saying what to do with it (run it at compile time, run time, postpone, nothing (comment), etc) 11:47:13 this has a couple big advantages: 11:47:22 1) compiling is FAST (no dictionary lookups) 11:47:35 2) compiler can track dependancies, and compile them for you 11:51:11 The source almost sounds like it is compiled itself in a sort of indirect threaded manner. 11:52:58 something like that 11:53:08 makes the compiler simple 11:53:17 makes adding advanced features to the editor quite simple 11:53:23 like "jump to definition of this word" 11:54:05 I can imagine. Do you still support shadowed words in the Forth-style "hyperstatic global environment"? 11:54:56 shadowed? 11:55:02 you mean two words with the same name? 11:55:22 Right, so if I define foo, then bar uses foo, then I define another foo, will bar still use the first foo? 11:55:35 you can't have two words with the same name 11:55:38 that makes no sense 11:55:44 i don't have the luxury of a simple compiler 11:55:57 with dynamic typing, a trivial compiler gives you trivial perforamnce 11:56:17 my performance is probably not impressive 11:56:36 for good performance, I hope to have a JIT some day 11:56:42 I assume that you are only referring to Fronds specifically? Standard Forth lets you shadow definitions. 11:57:35 or, perhaps some way for fronds to say to the host "optomize this code fragment" and then it could call that fragment in native code though a syscall-like mechanism 11:57:52 I'm talking about fronds 11:58:03 in fronds you do not say what order things are compiled in 11:58:09 compilation happens for you 11:58:38 there is no way for a word to have two different definitions 11:58:50 each word has a dictionary entry, with a reference to a definition 11:59:59 Ah, I see. Okay, that makes sense. 12:00:21 If I'm not careful with my editor functions that allow you to create or rename words, you would be able to create two words that look exactly the same (same name) but are not the same word, and thus have different definitions 12:00:26 but that would be stupid 12:02:26 Does Fronds support namespaces / vocabularies / modules / etc. or do you find that name collisions are rare? 12:02:53 I use prefixes 12:03:11 I might at some point add an editor feature that would hide prefixes when they are obvious 12:04:33 name conflicts won't cause hard-to-find bugs 12:04:41 because the editor won't let you enter it if it's already in there 12:04:45 I'm torn on the whole global names thing. I like the ability to reuse the same name in different contexts, but I am not sure how I feel about having to manually specify the "link order" of my application. 12:04:57 you find out immediately, before you even hit the space bar, that it's an existing word name 12:05:02 Yes, that is also the reason that I am not necessarily a fan of the shadowing feature in standard Forth. 12:05:49 In any event, it is interesting to hear the different perspectives of the Forth community. I appreciate you taking the time to answer all of my questions about Fronds. 12:05:52 my assumption is that the shadowing thing is primarily just a side-effect of the way that forths are generally implemented 12:06:09 it works out that way easily, and some people take advantage of it, others avoid it 12:06:23 sure 12:06:29 That's an interesting point; it does feel more like a side-effect than a conscious choice. 12:06:31 I'm here to share and learn too 12:20:28 in making fronds I'm very much in my own little world. it's nice to talk about my crazy ideas here, and see if others are compatible with them 12:20:59 for example, I realized that you don't need ELSE. I've done loads of programming without it 12:21:02 works great for me. 12:21:16 but people seem to get upset without it 12:21:37 some types of personal preference run deep 12:22:04 These two are equivalent: 12:22:16 : foo if bar else baz then ; 12:22:26 : foo if bar exit then baz ; 12:24:01 my forth compiler is not state-full, so there's no difference between ; and EXIT, so I just use ; all the time 12:24:04 makes it nice and short: 12:24:10 : foo if bar ; then baz ; 12:24:42 also, I have conditional exits, like ?; and 0; 12:24:49 which can make thins read nicely: 12:26:12 : ?leg-fix leg-broke? 0; leg-set ; 12:26:31 sometimes stack juggling spoils the fun: 12:26:54 : ?leg-fix dup leg-broke? 0if drop ; then leg-fix ; 12:27:35 naming conventions are incredibly useful too 12:27:58 Eventually I want something in my editor that will explain the prefixes 12:28:14 well, that will explain the prefix of the word you're looking at 12:28:31 not sure how to squeeze that in yet. that comes later anyway 12:28:42 ? prefix means maybe do something 12:28:56 eg ?leg-fix will either call leg-fix or do nothing 12:29:18 ? suffix means it returns a bool 12:35:27 huh... wonder why I don't automatically compile a "return" at the end of every definition 12:35:45 I'm accustomed to seeing ; at the end, but it's quite redundant 12:50:59 hmmm... I might have started putting them at the end originally because I was having trouble getting postpone to work 13:17:42 --- join: soyrochus (n=kvirc@24.Red-83-56-33.dynamicIP.rima-tde.net) joined #forth 13:42:07 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 13:42:07 --- mode: ChanServ set +o tathi 13:47:32 malyn: when I was messing around with vi-like editors, my edit commands that could take a range would save the current position, then invoke the 'command reader' again, then use the range from old position to new position... 13:47:42 IIRC it worked fairly well 13:47:58 though probably not exactly like vi's parsing, which is ridiculously complex, and I don't totally understand it. 13:48:11 JasonWoof: I, too, like the idea of getting rid of ELSE and just using ; for exiting. Very similar to ColorForth. 13:48:46 tathi: That's an interesting suggestion. So basically play the movement command through the editor and then operate on the range that was selected? 13:50:09 --- quit: soyrochus (Read error: 104 (Connection reset by peer)) 13:50:34 yeah 13:52:27 vi seems to do something more complicated, like maybe propagating the counts down? 13:53:01 for instance d3f and 3df have exactly the same effect, even if you only have two occurrences of on the current line. 13:53:12 er...vim, not vi (haven't tried an old vi) 13:53:36 Yeah, nothing like that seems (I hope...) necessary. I like the idea of abstracting away the counting logic. Maybe I can build that into my keystroke processor and have all of the command words take a range. 13:54:08 Yeah. 13:54:41 I started off having the keystroke processor call the command word multiple times, but I think I ran into trouble with that. 13:54:52 Can't remember where; it was a while ago. 13:55:14 That would probably cause trouble for commands like c, where you want to c4w (change four words) as a single operation, not as four separate change word operations. 13:55:42 ah, right. 13:56:01 er... 13:56:10 well, something like that. 13:56:46 c4w wouldn't have been a problem, 'c' would mark the start of the range, call the command interpreter to do '4w', then get the end of the range, delete it, and enter insert mode. 13:57:00 But something similar might cause problems. 13:57:46 Ah, right, but I thought you said that your first implementation called the word multiple times? Seems like cw, cw, cw, cw would not be the same as passing a 4w range to c..? 13:58:47 sure. but that would be '4cw', not 'c4w'. 13:59:26 my command interpreter just accepted an optional count, then a one-character command, then called the command word. 13:59:40 Got it, that makes sense. 13:59:56 Any sub-commands would be handled by the command word re-invoking the command interpreter. 14:00:13 Anyway, just saw the logs and thought I'd chime in... 14:00:46 I appreciate that, thanks! 14:01:03 ok, time to go take care of the animals 14:01:06 The editor that #forth built, right? 14:07:59 --- join: arke (n=arke@p57A75F3F.dip.t-dialin.net) joined #forth 14:07:59 --- mode: ChanServ set +o arke 14:13:28 who's #forth? 14:14:38 The #forth IRC channel. It was a not-entirely-successful joke, apparently. 14:31:34 It has been nearly a week with no reply from intellasys. 14:31:45 haha 15:16:46 I'm shocked 15:45:54 --- quit: JasonWoof ("Leaving.") 15:56:14 --- quit: Maki ("Leaving") 17:29:03 Hm, wikipedia says the dictionary is a linked list. 17:29:05 I find that odd. 17:29:10 I expected a hashtable. 17:29:22 hashtables are too bloated for jeff fox 17:29:44 Who cares about him, what about moore? 17:31:09 He agrees? 17:33:16 I would assume so since he made forth. 17:33:28 But I think it would be beneficial for a very large forth. 17:36:20 most forths use hashtables 17:38:20 Oh. 17:38:48 Wikipedia failure then. 17:39:29 It doesn't even say "usually a linked list" it says "the dictionary is a linked list" and gives an exact format and whatnot. 17:54:39 I don't like the controls structures so much. 17:54:50 I think I would prefer goto, but that isn't so important. 17:56:20 Deformati: failure of people who like to post about Forth in public places. :) 17:57:03 tathi: ? 17:57:06 The traditional implementation of Forths from the 80s and before is the only one worth mentioning. :) 17:57:10 Oh, the wikipedia thing. 17:57:30 Ya. 18:04:06 --- quit: Quartus` (Read error: 104 (Connection reset by peer)) 18:11:11 --- join: Quartus` (n=Quartus`@205.205.50.2) joined #forth 18:13:31 Deformati: you would prefer goto? 18:18:47 I like goto for some reason. 18:19:25 I like making my own looping structures, or in C I usually do like while(true){ ... if(condition)break;} 18:19:31 It is ugly I know. 18:19:45 But it is more confertable for me. 18:21:39 --- quit: modesto (brown.freenode.net irc.freenode.net) 18:21:39 --- quit: xian (brown.freenode.net irc.freenode.net) 18:21:41 --- join: xian (n=xian@nconc.de) joined #forth 18:21:49 --- join: modesto (n=geoperry@147.202.40.21) joined #forth 18:23:40 --- quit: gnomon (brown.freenode.net irc.freenode.net) 18:23:40 --- quit: madgarden (brown.freenode.net irc.freenode.net) 18:23:53 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth 18:58:53 --- join: madgarden (n=madgarde@bas2-kitchener06-1096652780.dsl.bell.ca) joined #forth 19:09:22 --- quit: tathi ("leaving") 20:25:51 --- join: snoopy_1611 (i=snoopy_1@dslb-088-068-197-209.pools.arcor-ip.net) joined #forth 20:33:54 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 20:34:10 --- nick: snoopy_1611 -> Snoopy42 20:45:05 --- quit: gnomon (brown.freenode.net irc.freenode.net) 20:45:07 --- quit: aspect (brown.freenode.net irc.freenode.net) 20:45:07 --- quit: tarbo (brown.freenode.net irc.freenode.net) 20:45:08 --- join: aspect (i=aspect@burns.dreamhost.com) joined #forth 20:50:12 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth 21:28:29 --- quit: proteusguy (Remote closed the connection) 22:38:33 --- join: Malfermi2aKodo (n=kansu@xdsl-78-34-130-239.netcologne.de) joined #forth 22:45:14 --- quit: MalfermitaKodo (Read error: 110 (Connection timed out)) 22:56:16 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 22:56:16 --- mode: ChanServ set +o Quartus 23:00:23 --- join: ygrek (i=user@gateway/tor/x-967cf27ac3ac432b) joined #forth 23:31:50 --- join: I440r (n=mark4@ip70-190-68-230.ph.ph.cox.net) joined #forth 23:41:03 --- quit: Quartus () 23:42:13 --- join: I440r_ (n=mark4@ip70-190-68-230.ph.ph.cox.net) joined #forth 23:46:53 --- quit: aguai (Connection timed out) 23:59:27 --- quit: I440r_ ("Leaving") 23:59:59 --- log: ended forth/08.04.17