00:00:00 --- log: started forth/19.03.08
00:26:46 --- join: xek_ (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
00:26:46 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
00:27:52 --- quit: xek_ (Read error: Connection reset by peer)
00:29:12 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
01:23:22 --- quit: DKordic (Ping timeout: 255 seconds)
02:04:21 --- quit: ashirase (Ping timeout: 246 seconds)
02:06:55 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:52:37 <WilhelmVonWeiner> hello forth
03:05:27 <presiden> begin begin begin
03:08:24 --- quit: dave0 (Quit: dave's not here)
03:10:18 --- quit: mtsd (Quit: leaving)
04:08:21 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:54:10 <KipIngram> Morning gents.
04:59:47 <crc> morning KipIngram
05:03:29 <KipIngram> Hey, does anyone happen to know how to disable ctrl-scroll == zoom in Ubuntu (specifically 18.04)?
05:03:53 <KipIngram> On the Linux box I'm constantly zooming my terminator windows by mistake.  :-|
05:04:10 <corecode> setting in the terminal emulator
05:04:24 <KipIngram> It affects Terminator and Firefox, but does not seem to affect the native Terminal application.
05:04:27 <presiden> I wonder if this already exist. A forth implementation with built-in debugger. Where if you're in debugging mode, you can run the forth program step-by-step, put a breakpoint on certain line, inspect the stack(s), etc.
05:04:46 <KipIngram> I'm planning that in my  Forth, presiden.
05:05:16 <KipIngram> I was also hoping for a displayed decompile of the code that highlights the stepping in some way.
05:05:29 <presiden> KipIngram, oh, nice. Is there any repo/link I can follow?
05:06:05 <KipIngram> No, I'm not sharing any of this stuff yet.  But when I get around to working on it I can share a Linux binary with you periodically if you want to comment / make suggestions.
05:06:17 <KipIngram> I also want to include a stack display, "watched" variables, and so on.
05:06:42 <KipIngram> Kind of ambitious, I guess - I'm not very calibrated yet on how hard it will all be.
05:07:43 <KipIngram> I do want to share this code in some way at some point, but I haven't decided exactly to what extent yet.
05:09:04 <KipIngram> In theory Forth is a great language for a single-stepping debugger.  Should be easy enough to track the execution point and just keep replacing the next word with a break word.
05:09:31 <KipIngram> What I thought I might do for that is run the debugger in the alternate text window.  So the application could be doing whatever it wanted with the main screen, and wouldn't get disrupted.
05:09:50 <KipIngram> The break would smcup over to the alternate screen and draw its business each time.
05:10:06 <KipIngram> Then when you "continued" it'd rmcup back for execution of the next bit.
05:11:36 <presiden> what's smcup/rmcup?
05:13:00 <KipIngram> Oh, I don't know how they chose those words.  They're terms used in the ansi control sequence literature for activating / returning from the alternative screen.
05:13:08 <KipIngram> I guess they stand for something, but I'm not sure what.
05:13:40 <KipIngram> You switch to and from that alternate screen just by sending particular <esc>[... strings.
05:14:33 <presiden> ah, the xterm's control sequence
05:14:42 <KipIngram> Yes.
05:15:14 <KipIngram> I take it it's how vim saves and restores the bash screen on entry/exit.
05:16:57 <KipIngram> Anyway, smcup and rmcup were just the terms the docs I read used, so that's what I named my words.
05:17:47 <KipIngram> I'm using them for my block editor - it switches over to draw the block, and back when I exit.
05:18:18 <KipIngram> As far as I can tell the second screen is not maintained when you exit - you have to draw it from scratch every time.
05:26:53 <presiden> well, it would be weird if different runs of program see the previous program's buffer
05:28:22 <KipIngram> I mean even within a run.  Say we're in the debugger on the alternate screen, and we say "ok, single step."  It'll switch back to the (saved) application buffer, do a step, and then come back to second screen for the debugger again - the debugger will have to redraw it's whole screen.
05:28:26 <KipIngram> Every step.
05:29:01 <KipIngram> Whereas the application will get to just pick up where it left off, as though we hadn't engaged the debugger at all.
06:14:36 --- quit: proteusguy (Ping timeout: 245 seconds)
06:30:22 --- join: proteusguy (~proteusgu@mobile-166-175-63-160.mycingular.net) joined #forth
06:30:22 --- mode: ChanServ set +v proteusguy
06:40:37 --- quit: proteusguy (Remote host closed the connection)
06:41:53 <corecode> any suggestions how to warn that control flow words are not matching properly?
06:58:32 --- join: mark4 (~mark4@148.80.255.161) joined #forth
07:04:17 <the_cuckoo> you mean nested if/else/then, do/loop etc?
07:04:26 --- quit: mark4 (Remote host closed the connection)
07:04:40 <the_cuckoo> corecode: ^
07:04:53 <corecode> yes
07:06:05 <the_cuckoo> hmm - well i'm what i do is considered a cheat :)
07:10:26 <the_cuckoo> basically, those types of things are a special kind of thing - i call them parsers - they're like immediate words in some sense, only in theory, they only have access to the dictionary - when i see a token of that type, i run it and that puts the stack into a 'parsing state' - all following tokens are passed directly until the parser is done - when done (ie, the matching then is encountered) it executes the
07:10:29 <the_cuckoo> sequence collated
07:11:49 <the_cuckoo> the twist is that internally it honours other parsing words and essentially creates a stack of them - only when the last is complete does the sequence run
07:13:34 <the_cuckoo> that's probably poorly described - haven't had to actually describe it to anyone since no one has asked :) - either way, i like the approach myself, but the implementation isn't quite as tidy as i'd hoped to achieve
07:14:56 <the_cuckoo> is considered = is probably consisered
07:14:59 <presiden> corecode, so, here my idea.
07:15:12 <presiden> you have "Control Stack"
07:15:45 <presiden> when you encounter if, you push "IF" into this stack
07:16:09 <presiden> if you encounter DO, you push "DO" into it.
07:16:53 <presiden> if you encounter ELSE, you check the top of the control stack, is it an IF?
07:17:24 <presiden> if not, then there's unmatched control structure, if yes, continue
07:17:46 <presiden> if you encoutner THEN, check the top, is it an IF, if yes then pop it.
07:18:36 <presiden> do the same with the other pairs
07:20:32 <the_cuckoo> yeah - my approach is essentially similar - except i don't stack tokens - just the 'parser' objects (and when a parser is done, it's execution sequence is either pushed to the parser below or executed if none exist)
07:21:08 <corecode> yea that prevents you to do novel flow control stuff tho
07:22:15 <zy]x[yz> a cheap method is to just save the stack depth when you enter compilation mode and then check it after you leave compilation mode.  something is probably broken if the stack ever grows during a word definition (but not necessarily if it shrinks)
07:22:33 <the_cuckoo> all such constructs have to be in the parsers, yes - there's some funky mechanisms to allow you to define them in the language, but currently incmplete - and they aren't quite regular words
07:24:03 <presiden> corecode, well, if you also consider doing novel control flow, then in case of finding unmatched control structure, you can just report an error and let them be
07:24:26 <presiden> report an warning*
07:24:32 <presiden> report a warning*
07:25:14 <presiden> zy]x[yz, is there a case when the stack shrink?
07:25:36 <zy]x[yz> 123 : foo stuff stuff LIT stuff stuff ;
07:26:44 <corecode> presiden: yea that's what i do now
07:26:57 <corecode> i report a warning at ; when the stack is not back to 0
07:35:10 --- quit: tabemann (Ping timeout: 240 seconds)
08:36:39 <KipIngram> I thought that was LITERAL.
08:37:00 <KipIngram> Is that just a rename, or are there typically both?
08:37:07 <KipIngram> I like LIT better.
08:37:29 <KipIngram> You can generally bet on me going for the shorter name when there's a choice.
08:38:14 <zy]x[yz> idk
08:38:21 <zy]x[yz> in mine i called it #
08:44:39 <KipIngram> :-)  # usually has another meaning, but yeah, that's my kind of name!
08:45:09 <KipIngram> I didn't implement those usual # words; I'm handling numeric output in a more C-like way.
08:45:16 <KipIngram> Well, formatted numeric output, at least.
08:45:26 <KipIngram> . and (.) are there in the usual way.
08:48:06 <KipIngram> But I have a version of TYPE that also accepts a formatting string address from the stack, and then it consumes numerical parameters as required and prints out the result.
08:48:56 <KipIngram> There's a little byte code engine in there that essentially "executes" the actual format fields in the format string.  Works very nicely and was quite compact.
09:11:25 --- quit: xek (Remote host closed the connection)
09:11:53 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
09:24:07 --- join: mark4 (~mark4@148.80.255.161) joined #forth
09:49:55 --- quit: xek (Remote host closed the connection)
09:50:20 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
10:01:40 --- quit: mark4 (Remote host closed the connection)
10:21:53 <zy]x[yz> i deviated from the norm quite a bit in mine, so i often forget a lot of the traditional words
10:22:38 <the_cuckoo> deviation from the norm - that seems to be the common approach :D
10:43:48 --- quit: nighty- (Quit: Disappears in a puff of smoke)
10:46:53 --- quit: gravicappa (Ping timeout: 250 seconds)
11:19:16 <KipIngram> I think it's quite healthy.
11:24:42 <corecode> had a bug in my cpu
11:24:46 <corecode> fixed the bug in my cpu
11:25:05 <corecode> also compiler had some issues
11:25:25 <zy]x[yz> was it a spectre bug
11:26:02 <corecode> no, poping off rstack would write TOS to top of rstack :)
11:26:48 <zy]x[yz> speculative rpush
11:27:00 <corecode> no, just direct bug
11:27:15 <zy]x[yz> yeah but that's how you sell it
11:27:44 <corecode> i sell it as "there was a bug, but i fixed it"
11:30:11 <zy]x[yz> what are you, an engineer?
11:30:18 <corecode> derp
11:38:55 <KipIngram> ;-)
11:47:41 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
11:48:08 <the_cuckoo> :) - and yeah KipIngram, i totally agree - i feel there's a lot be gained by employing forth concepts in many different ways
12:03:24 <the_cuckoo> hmm - i just had an idea (old idea, different approach)... video stuff, probably has applications elsewhere
12:04:44 <the_cuckoo> in my system, i've got a mechanism to provide a client/server type of thing as well as, and entirely unrelated, the ability to play video
12:06:44 <the_cuckoo> when you play video from your shell, the shell currently blocks - but clearly, it'd be kinda cool to instead drop an object on the stack which is, in turn, running the video
12:08:43 <the_cuckoo> ie: the obect created when you hit play is just a thread - divorced and unrelated to the creator (the shell), and yet, the shell receives a way to address that player - by it dropping it, the player is killed - by it assigning it to a variable, the object is removed from the stack and recallable 
12:09:11 <the_cuckoo> and clearly, i can introduce words with interact with the object 
12:11:57 <the_cuckoo> which brings me back to comms ... if you connect to this system and can, in turn, obtain a reference to that player, you can do the same - eg: <player> pause 100 seek apply-some-effect play etc
12:13:02 <the_cuckoo> than you can write a gui which has buttons which simply send stuff like play, pause, 100 seek etc over the socket
12:15:45 <the_cuckoo> additionally, you can lock a client down to a specific set of words with no ability to do anything else - so, it all becomes are simple from the gui point of view and entirely safe from the servers
12:16:03 <the_cuckoo> too weird?
12:18:17 <the_cuckoo> oh yeah - it also extends to transcode jobs - which is weird but rather cool
12:37:55 --- quit: xek (Remote host closed the connection)
12:38:23 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
12:46:04 * the_cuckoo mumbles apologies about being unclear - but in my defence, i am kinda just joining the dots myself - they should be clearer when i get round to doing it :)
12:57:22 --- quit: nerfur (Read error: Connection reset by peer)
13:00:33 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
13:00:43 <dave0> hi
13:01:32 <the_cuckoo> hey - how goes it?
13:02:12 <dave0> hi the_cuckoo 
13:03:14 <the_cuckoo> how's your friday? :)
13:03:46 <dave0> it saturday morning lol
13:06:18 --- quit: mtsd (Quit: leaving)
13:09:35 <the_cuckoo> :)
13:09:43 <the_cuckoo> where are you located then?
13:11:30 <dave0> australia
13:11:55 <dave0> just got up .. coffee time C4[_]~ C8[_]~ C3[_]~ C2[_]~
13:12:19 <the_cuckoo> :)
13:17:13 <zy]x[yz> austria you say?  I love arnold swartzeneggar!
13:18:22 <dave0> good day mate! throw another shrimp on the barbie!
13:18:39 <zy]x[yz> get to the choppa!
13:19:11 <dave0> lol
13:19:46 <dave0> i should watch predator again, i haven't seen it in ages
13:20:38 <zy]x[yz> i just saw it a few weeks ago.  such a great movie
13:21:19 <bluekelp> stick around - for more forth humor
13:21:24 <zy]x[yz> i think every weekend in high school i was watching one of either blade runner, terminator 2, aliens, or predator
13:21:59 <dave0> all sci-fi
13:22:37 <dave0> t1 was good but t2 was just better
13:23:26 <zy]x[yz> idk, i also watched t1 again recently and think i might have been undervaluing it all these years
13:23:54 --- quit: jedb (Remote host closed the connection)
13:24:24 --- join: jedb (~jedb@176.113.74.187) joined #forth
13:25:02 <dave0> if there was no t1, you wouldn't know that arnie went from bad guy to good guy in t2
13:26:37 <zy]x[yz> you also wouldn't get that glorious stop-motion terminator skeleton action
13:28:44 <dave0> oh good point!
13:29:54 --- quit: jedb (Remote host closed the connection)
13:30:27 --- join: jedb (~jedb@176.113.74.187) joined #forth
13:35:24 <the_cuckoo> i was gonna do a cobber thing but decided not to :)
13:51:55 --- quit: jedb (Remote host closed the connection)
13:52:20 --- join: jedb (~jedb@176.113.74.187) joined #forth
14:20:01 <the_cuckoo> well, hmm - this video stuff is coming together pretty quick
14:20:49 <KipIngram> Oh, T1 was great.  T2 was great.  Together they are greater.
14:20:59 <KipIngram> That's one of the truly amazing "sci fi double features."
14:21:06 <KipIngram> Right there with Alien and Aliens.
14:21:14 <KipIngram> Too bad they didn't make any more movies in that franchise...
14:21:23 * KipIngram snickers
14:21:32 * the_cuckoo smirks
14:21:37 <the_cuckoo> T2 was cool
14:22:08 <the_cuckoo> like both but i thought the follow up was stronger
14:22:19 <KipIngram> I wouldn't argue with that.
14:22:30 <KipIngram> I think if you insist on ranking them then T2 wins out.
14:22:42 <KipIngram> Sarah was just so totally bad ass - it was awesome.
14:23:36 <the_cuckoo> she'd come on a long way from her in the first - she delivered it well :)
14:23:58 <KipIngram> Yes - she seemed so delicate in the first one.  Harsh road.
14:25:02 <KipIngram> Aliens was better than Alien also.  But you need Alien to get the story rolling.
14:25:34 <the_cuckoo> for sure
14:25:35 <KipIngram> That's really the point in both cases - the first of the two movies is "required."
14:25:55 <KipIngram> And thankfully they're also GOOD, in addition to setting up the sequels.
14:26:36 <KipIngram> "You're terminated, fucker."  <-- one of the best lines ever.
14:31:01 <the_cuckoo> nice - i just need to create a general 'player' word to turn the top of the stack graph into a video playing thread - which i can now play or seek and play, and so on - that's kinda cute
14:31:47 <KipIngram> Then of course in the other franchise we have 1) "Get away from her, you BITCH!" as well as "I say we take off and nuke the site from orbit.  It's the only way to be sure."
14:32:10 <the_cuckoo> :)
14:33:05 <KipIngram> the_cuckoo: Your stuff sounds pretty cool.
14:33:28 <the_cuckoo> think it's kinda getting there, yeah
14:36:15 <the_cuckoo> funny i think - the interface to the threaded player is of course a stack evaluation thing
14:36:38 <KipIngram> So, when I exit from the editor, I say UPDATE FLUSH to ensure that my changes are securely on the disk.
14:36:52 <KipIngram> The problem with that is that it happens whether I've changed anything or not.
14:37:02 <KipIngram> I hate the idea of writing unnecessarily, especially on flash storage.
14:37:19 <the_cuckoo> yeah - definitely want to track changes there
14:37:25 <KipIngram> I'm thinking of adding a block hash at the BLOCK level (i.e., not in the editor, but down below).
14:37:59 <KipIngram> I'd compute and save the hash (I have a proper place for it) when I read a block, and then if I get ready to write the block I'll hash again and compare - and not really write if they match.
14:38:04 <the_cuckoo> would probably help - or you just do a diff - write the changes if they exist
14:38:07 <KipIngram> I'd still keep the UPDATE mechanism.
14:38:15 <the_cuckoo> read is cheap after all
14:38:24 <the_cuckoo> and it's easier to track that way
14:38:26 <KipIngram> Because I might want to choose to read in a block, diddle with it, and abandon the changes.
14:38:32 <KipIngram> Actually I think this is easier
14:38:39 <KipIngram> And I feel pretty sure it would be faster.
14:38:41 <the_cuckoo> ok - your call :)
14:38:51 <KipIngram> I already have a table of records that tell me things about my block buffers.
14:38:59 <KipIngram> I can just stuff this hash in there - it fits in very naturally.
14:39:19 <the_cuckoo> sure - probably - depends how you do it - one word change, all dictionary rewrite?
14:39:30 <KipIngram> It should be a very simple change.
14:39:57 <KipIngram> So if I don't UPDATE, it won't get written.  Changed or not.
14:39:58 <the_cuckoo> indeed - track diffs or the whole thing
14:40:12 <KipIngram> If I do UPDATE, but the hash says it hasn't changed, it won't get written.
14:40:19 <KipIngram> Getting a write will require both.
14:40:29 <the_cuckoo> sure - but a 1 word change?
14:40:37 <the_cuckoo> what happens?
14:40:49 <KipIngram> The hash will change and it will get written (if I UPDATE).
14:40:58 <KipIngram> A good hash will pick up a one *bit* change.
14:41:00 <the_cuckoo> the word or everything?
14:41:13 <KipIngram> Oh, you can't write less than a block to the disk.
14:41:19 <KipIngram> All disks have a native page size.
14:41:36 <KipIngram> Writes to smaller units are done as a read-modify-write.
14:42:09 <the_cuckoo> sure - but if you just append the diffs you good too, no? in the file you see everything
14:42:10 <KipIngram> 4kB is very common - that's actually why I made my blocks and my memory pages 4kB.
14:42:27 <KipIngram> Yes, you could create a system that used diffs.
14:42:36 <KipIngram> But then when you read you'd have to scan through the diffs and apply them.
14:42:49 <the_cuckoo> yup - it's an overhead for sure
14:42:58 <the_cuckoo> but a useful one perhaps
14:43:11 <the_cuckoo> you'd get your history :)
14:43:21 <KipIngram> That's true.
14:43:32 <KipIngram> I think that idea probably has a place, but I don't think it's here.
14:43:43 <the_cuckoo> that's fair :)
14:44:09 <KipIngram> Anyway, there's a fast and easy 32-bit hash called Adler32.
14:44:21 <KipIngram> I'm deciding now if I'm content with it or if I want something stronger.
14:44:45 <KipIngram> All hashes have some probability of collision (where a particular change to the page resulted in no hash change).
14:44:54 <KipIngram> You want that probability to be WAY down in the noise.
14:45:19 <KipIngram> I was going to have to make my block buffer records bigger anyway.
14:45:25 <KipIngram> Right now they're 16 bytes for each buffer.
14:45:48 <KipIngram> I'll have to make them 32 to make room for this hash, and that will provide room for the other stuff I already knew I was going to need to add.
14:47:00 <KipIngram> Right now the 16 bytes contains 1) 4 bytes of TSC timestamp info (well, 31 bits; the MSB of that is the UPDATE bit), 2) 4 bytes specifying the block that the record is servicing, and 3) 8 bytes specifying the RAM address of the buffer itself (which I allocate from my memory manager upon first need).
14:47:55 <KipIngram> I do a super-simple hash of the block number that identifies a pair of buffers that are eligible to hold that block.  Then I use the one with the oldest time stamp.
14:48:29 <KipIngram> Time stamp is updated anytime <block> BLOCK is executed.
14:48:43 <KipIngram> So it chooses a buffer from the set of eligible ones via least recently used.
14:49:06 <the_cuckoo> you know this hark backs a couple of days for me - i was considering a secondary dictionary - the primary is what you are given - it's what you know - it's what you can use - if the primary can create the a secondary based on all or a subset of what it knows, then if the secondary is given the ability to define words, it would do so in its own dictionary which would shadow that of the one given by the primary
14:49:12 <KipIngram> I could make that set size larger (say 4 instead of 2, or 8 - though I don't think I'd want to go beyond that, and probably not beyond 4) very very easily.
14:50:05 <corecode> https://cloud.0x2c.org/s/moxgmLKJd58fPAY
14:50:12 <corecode> forth fpga cpu fading led
14:50:16 <KipIngram> My thinking on this tells me that the larger that set is the lower the probability of a thrashing situation.
14:50:46 <corecode> https://gist.github.com/001729257aa48e3874cf212339868b81 <- source
14:50:55 <the_cuckoo> corecode: nice :)
14:51:09 <KipIngram> I keep that table in a memory page (4kB).  So right now there are 256 16 byte records, organized into 128 pairs.
14:51:22 <KipIngram> If I grow the record to 32, I'll just have 128 organized in 64 pairs.
14:51:37 <KipIngram> And I may change that to 128 organized in 32 quads.
14:51:41 <the_cuckoo> corecode: my plans to do that kinda thing tonight have been scuppered :)
14:52:00 <KipIngram> scuppered?  I'm not familiar with that one...
14:55:33 <the_cuckoo> disturbed - not allowed to happen :)
14:56:28 <the_cuckoo> nautical terms - sinking ships is known as scuppering
14:58:00 <the_cuckoo> during the war, the british army scuppered a lot of german ships to provide barriers for other ships for example - worked well in narrow/shallow waters 
14:58:49 <the_cuckoo> anyway - yeah - i wrote some software of the raspberry pi the other day which i haven't tested yet :D
14:59:23 <the_cuckoo> https://gitlab.com/lilo_booter/rpany-pi/blob/master/README.md in case anyone is curious
15:00:02 <the_cuckoo> plan was to see if it actually worked this evening, but got sidetracked by video thing
15:05:11 <the_cuckoo> i'm kinda hoping that i wrote enough notes for myself so that i know how to use it when i do
15:11:13 <the_cuckoo> ... well, i thought it was funny ... easily amused though
15:22:37 --- quit: xek (Ping timeout: 255 seconds)
15:45:36 --- quit: dddddd (Remote host closed the connection)
16:45:30 --- quit: john_cephalopoda (Ping timeout: 240 seconds)
16:59:27 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:29:48 <presiden> morning forthnighter
17:32:08 --- join: tabemann (~travisb@h193.235.138.40.static.ip.windstream.net) joined #forth
17:41:10 <john_cephalopoda> Hey presiden 
17:45:16 <crc> Good evening
17:51:49 * crc is now trying out an ergodox keyboard to see if it will help with RSI issues
18:05:26 <zy]x[yz> your keyboard was causing source index register issues?
18:06:52 --- quit: tabemann (Ping timeout: 255 seconds)
18:12:27 <crc> It was a factor. The root causes go back to when I was a teenager, but the most recent flareups are at least partially due to bad ergonomics. 
18:14:55 <john_cephalopoda> One day I'll finish my forth... One day... Fuuuutuuuuure!
18:16:42 <crc> I made some changes in the last year (going back to using Dvorak, getting a keyboard at work with some better layout [for me]), but the pain isn't stopping, so I continue to seek things to help
19:18:58 --- join: tabemann (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
19:36:56 --- join: gravicappa (~gravicapp@h37-122-113-40.dyn.bashtel.ru) joined #forth
21:00:03 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
21:03:02 --- join: proteusguy (~proteusgu@2600:1700:d930:1ae0:132:2c9:3809:e4c3) joined #forth
21:03:02 --- mode: ChanServ set +v proteusguy
21:39:05 --- quit: proteusguy (Ping timeout: 252 seconds)
21:53:34 --- join: proteusguy (~proteusgu@mobile-166-175-190-90.mycingular.net) joined #forth
21:53:34 --- mode: ChanServ set +v proteusguy
23:59:59 --- log: ended forth/19.03.08