00:00:00 --- log: started forth/17.02.09 00:13:47 --- join: gravicappa (~gravicapp@ppp83-237-172-80.pppoe.mtu-net.ru) joined #forth 01:35:42 --- quit: mnemnion (Remote host closed the connection) 01:40:53 --- quit: impomatic (Quit: http://corewar.co.uk) 02:19:07 --- quit: nighty (Quit: Disappears in a puff of smoke) 02:39:34 --- quit: DGASAU (Read error: Connection reset by peer) 02:42:50 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 02:56:42 --- quit: DGASAU (Read error: Connection reset by peer) 03:03:44 --- quit: beretta (Ping timeout: 264 seconds) 03:35:40 --- join: John[Lisbeth] (~user@2601:601:8f01:a6a0:80f0:1e:8788:a064) joined #forth 04:04:11 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 04:05:09 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:e810:4c13:4d8c:d76b) joined #forth 04:09:26 --- quit: mnemnion (Ping timeout: 255 seconds) 04:43:35 --- quit: DocPlatypus (Quit: Ex-Chat) 04:43:46 --- join: DocPlatypus (~skquinn@2601:2c2:c300:ff70:ddd:87f6:f9e6:97f8) joined #forth 04:49:02 --- quit: DocPlatypus (Ping timeout: 255 seconds) 04:50:06 --- join: beretta (~beretta@cpe-184-58-116-76.columbus.res.rr.com) joined #forth 05:05:46 --- join: DocPlatypus (~skquinn@2601:2c2:c300:ff70:311c:e96f:2cc4:30) joined #forth 05:06:05 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 05:20:09 --- join: john_cephalopoda (~john@unaffiliated/john-minetest/x-5335115) joined #forth 05:50:36 --- nick: crc_ -> crc 05:50:47 --- mode: ChanServ set +v crc 06:56:21 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth 07:04:50 --- join: ChatSharp (~ChatSharp@stc.66.70.188.95.dsl.krasnet.ru) joined #forth 07:04:50 --- part: ChatSharp left #forth 07:10:18 --- join: neceve (~ncv@84.232.162.68) joined #forth 07:10:18 --- quit: neceve (Changing host) 07:10:18 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 07:36:52 --- quit: DocPlatypus (Quit: Ex-Chat) 07:51:40 --- join: GeDaMo (~GeDaMo@212.225.112.221) joined #forth 07:51:44 --- quit: John[Lisbeth] (Ping timeout: 255 seconds) 08:00:09 --- join: skaria (~skaria@h69-21-248-248.crlbnm.broadband.dynamic.tds.net) joined #forth 08:36:10 --- join: MrBusiness (~ArcMrBism@104-50-90-48.lightspeed.brhmal.sbcglobal.net) joined #forth 08:49:49 I finally got it! 08:49:52 : ** DUP 1 = IF 2DROP ELSE 1 - SWAP ROT SWAP DUP SWAP ROT * SWAP ROT RECURSE THEN ; : ** DUP 0 < IF 2DROP -1 ELSE DUP 0 = IF 2DROP 1 ELSE SWAP DUP SWAP ROT ** THEN THEN ; 08:53:47 Raising to the power of? 08:57:03 Yep, it's a power function. x y on the stack, result -1 when y < 0, x^y for y >= 0. 08:57:47 I think that there are more elgant ways to do it, but it works. 08:58:14 https://en.wikipedia.org/wiki/Exponentiation_by_squaring 09:02:19 --- join: impomatic (~impomatic@host81-136-80-177.range81-136.btcentralplus.com) joined #forth 09:11:27 --- quit: gravicappa (Ping timeout: 240 seconds) 09:13:43 --- nick: taij33n- -> taij33n 09:18:09 john_cephalopoda: when you define an "internal" word such as your first "**", the convention is to name it "(**)" 09:22:12 ** has the advantage that it can't simply be called by some program. 09:24:40 Hmm, it's hard to get forced security when any program can simply overwrite anything. 09:36:17 --- quit: neceve (Quit: Konversation terminated!) 09:44:28 john_cephalopoda: I like to avoid control structures entirely, so I will likely make TRUE=1 not -1 in my forth. This allows me to easily do math with a true/false value. For example I can multiply some offset by 1 to make it do something or by 0 to make it do nothing. 09:44:51 For that reason I might implement your ** word like so: 09:45:00 : ** 1 swap 0 max 0 ?do over * loop nip ; 09:46:11 (but that's just me) 09:46:18 pointfree: seen that trick but instead of multiplication AND is used. That way -1 (or 0xFFFF in 16 bit forth) is still TRUE. 09:52:27 Zarutian: I sometimes I even want the -1 such as if I want to flip a bus or not flip it... 09:52:40 $8 $8 FALSE * + . 8 ok 09:52:51 $8 $8 TRUE * + . 0 ok 09:53:15 I see 09:53:19 --- quit: Zarutian (Quit: Zarutian) 10:07:01 That was incorrect. To flip along the nyble boundary: 10:07:47 $4 FALSE * $2 + $4 + $4 FALSE and lshift hex. $6 ok ( low nyble) 10:08:35 $4 TRUE * $2 + $4 + $4 TRUE and lshift hex. $20 ok ( high nyble) 10:10:20 ( mirrors a nyble over the 4 bit boundary) 10:11:42 I use this on the PSoC where port interfaces are split between two logic blocks, etc... 10:19:38 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 10:22:26 pointfree: Cool. 10:25:48 I am trying to write an OS that consists of a Forth interpreter and as much forth code as possible. 10:26:34 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 10:27:02 It's a little difficult though to find out how to prevent programs from just doing anything and breaching security. 10:27:45 A forth interpreter written in forth that is interpreted by a forth interpreter written in asm is kinda overcomplicated. 10:37:53 --- quit: true-grue (Read error: Connection reset by peer) 10:46:10 john_cephalopoda: computer security always comes to access control, that is what process (or task) has access to what, no? 10:50:02 --- quit: ACE_Recliner (Remote host closed the connection) 10:55:40 Zarutian: Yeah. With forth, one can access all memory though. 10:56:11 So all memory access functions must be written in a way that makes it impossible to access out-of-bounds memory. 10:56:28 john_cephalopoda: same with C, basically. 10:57:14 Yeah, in theory. 10:57:52 I can't really imagine though, how to do it in Forth. 10:58:38 why not? 10:59:06 and I am curious on what cpu architecture your are writing this OS ontop of 11:00:14 if you are just doing x86 assembly and implementing a few primitive words then you can do the access checks in @, ! and $NXT, no? 11:01:19 x86 11:01:54 then you can use MMU so not to slow down those three 11:03:06 The OS needs full access to all memory. 11:03:33 Well, the kernel of it does and that is usually what is done 11:07:33 Imagine the implementation of OPEN-FILE. 11:08:26 Of course this could be implemented in plain asm. No problem. But that would kinda defy using Forth for anything. 11:09:24 So let's say that only some low-level functions like memory access are programmed in asm and the disk driver is written in forth. 11:10:13 sure, go on, but note that I havent used an Forth that has OPEN-FILE or any of the file extension vocabulary. (Mainly use Forth on small very portable vm or on middle-stage beefy MCUs) 11:10:32 john_cephalopoda: oh okay, where does the disk driver live? 11:10:40 john_cephalopoda: when it is running that is. 11:11:52 * Zarutian suspects that pointfree already knows where I am going with this ;-Þ 11:12:33 :) 11:12:34 The disk driver is just a row of instructions that access the disk driver controller in some way. I am not sure how to handle interrupts yet though. 11:13:55 az IRQ handler should be in asm 11:14:02 s/az/the 11:14:17 Yeah, probably. 11:14:38 you can't do that in Forth without asm 11:15:29 Anyway, let's say that we got some driver that can read ext4 volumes somehow. 11:16:11 you can write the ext4 driver in Forth, but it'll need some assembly to be able to read disk blocks etc. 11:16:11 basically an filesystem driver that talks or invokes an disk driver 11:16:18 so essentially the low-level part 11:16:26 Yeah. 11:17:07 I am not sure though, how to bring those definitions to userspace programs. 11:17:45 * Zarutian has to do dinner 11:17:47 I could build two dictionaries, one that can only be accessed by the OS and one that contains the standard words. 11:21:51 An ext4 driver could have a function called "ext4-open-file". open-file is then defined as ": IF ext4-open-file THEN ; 11:22:37 When a program is no executed, it should be allowed to execute open-file, it should be allowed to forget open-file, but it should not be able to access ext4-open-file in any way. 11:22:45 *is now executed 11:24:43 john_cephalopoda: tell me, what does the concept of 'user' in this system mean precisely? 11:31:36 Some usually unmodifiable user ID is set on login. 11:33:25 so basically you want to recreate a *nix but ontop of Forth? 11:34:54 It's just an example to demonstrate the problems that could occur. There should be functions that can not be modified by any program running. 11:35:46 in Forth, you usually want to give as much control to your user as you can 11:37:32 john_cephalopoda: but yeah it seems so you are wondering how the program to kernel interface would look like. 11:41:36 z0d: that is the idea, but limit potentially buggy-or-malicious programs in what they can do when run. 11:49:30 for any real multi-user OS you'd implement the forth one just like the others. meaning no shared dict between kernel + user. 11:49:38 you'd make system calls like you do now, etc. 11:50:03 internally the kernel could have its own dict but to the users whether it's written in forth or C or asm doesn't matter 11:50:43 you might be able to get fancy and have the kernel use the user's stack for params to syscalls - assuming the stack location was fixed in the address space, etc. 11:52:28 but the kernel would have to be every bit as defensive as they are now. or you could trust the users and not have kernel protection. that's basically ms-dos. 12:09:11 I can trust the user. But I can't trust his programs. 12:38:24 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth 13:22:49 --- quit: GeDaMo (Remote host closed the connection) 15:01:09 --- quit: dual (Ping timeout: 260 seconds) 15:23:05 --- quit: ACE_Recliner (Remote host closed the connection) 15:36:28 --- join: wa5qjh (~Thunderbi@121.54.90.150) joined #forth 15:37:14 --- join: dual (~bonafide@ip-64-134-96-203.public.wayport.net) joined #forth 15:38:14 --- join: dual_ (~bonafide@ip-64-134-96-203.public.wayport.net) joined #forth 15:41:44 --- quit: dual (Ping timeout: 256 seconds) 15:42:18 --- join: dual (~bonafide@ip-64-134-96-203.public.wayport.net) joined #forth 15:43:26 --- quit: dual_ (Ping timeout: 256 seconds) 15:56:21 Went to https://en.wikipedia.org/wiki/Protection_ring and then to https://en.wikipedia.org/wiki/Capability-based_security trying to get a better understanding of how protections worked, and realized to my horror that "object" has become the programming equivalent of "set": a "thing" that has "things". 15:56:25 --- nick: reepca` -> reepca 15:59:17 An object is more than just a "thing" that has "things". An object is the representation of a concepts with features and methods. 15:59:48 ... so it's even more vague than a set? 16:00:12 A set can contain "A", "B" and "C", but it can't tell what you can do with those. An object can have functions that do things with those sub-things. 16:01:12 In normal programming teminology, an object is an instanced class. 16:02:42 An object, in the sense of capabilities, is any resource that can be accessed, usually a file. 16:05:03 can be, like in seL4, an IPC endpoint which is reifing something conceptual object not supported directly by the enviroment 16:06:32 I suppose that what I meant to say is that "object" is a really overloaded term that has a lot of different meanings in various domains in computer science. "Object" can be an instance of a class, a hash table, a capability, a section of machine code, and any other number of things depending on context. And of course, those trying to describe that domain assume that everyone already knows what their definition of "object" is. 16:06:40 --- quit: dual (Ping timeout: 256 seconds) 16:07:02 *sigh*, so many flaws in today's software. 16:07:50 reepca is correct, though, in that many people think of objects as things with getters/setters. basically just typed maps/value holders. 16:08:03 but good/"real" objects are not that 16:08:12 reepca: think of it as an encapsulated bundle of state and behaviour. (Where state can have references to other such bundle|objects) 16:08:14 anyway, that's not a very forthy topic 16:08:20 Chromium takes ages to compile again... 16:09:08 reepca: heck you can have such 'object' in for by using defining words ;-) 16:09:23 s/for/forth/ 16:09:27 john_cephalopoda: if you can't trust a user's programs then you can't trust the user, effectively. 16:09:42 or you can trust them to write good programs and do without protection. 16:09:56 bluekelp: where does that assumption come from, pray tell? 16:09:59 I dream of a very lean, portable, forth-based OS, which can be easily ported to run anywhere. 16:10:26 bluekelp: that is "if you cant turst a users programs..." 16:10:34 if you trust the user, give them the hardware and let them worry about their programs not crashing the OS 16:10:45 I think it would make sense to have the user be trusted by default but make it convenient for the user to not trust other code - being able to execute other people's code in a safe environment would be nice. 16:11:08 if you want to protect the OS from programs (or programs from each other) you'll need some sort of "real" OS kernel/user separation 16:11:18 reepca: could not put it better myself. 16:12:04 also john_cephalopoda - there are some "bare metal" forthos-es out there for x86. i have never been able to get one of them running 16:12:05 bluekelp: usually done via MMU, interrupts, timer and priveledged-problem cpu state 16:12:07 How difficult would it be to put together a EXECUTE-SAFE word which "sandboxes" a definition? 16:12:20 bluekelp: I want to make one myself, so I learn something 16:12:59 reepca: It's all a matter of OS design. 16:13:06 understood. i have a few half-finished projects like that too 16:13:26 I think that some good planning could actually lead to something, 16:14:26 A core forth interpreter could be written in Assembly. That interpreter would run the OS, which itself contains an interpreter for forth. 16:15:18 The forth interpreter of the OS itself could easily safeguard and track things. 16:15:35 But it would be way slower. 16:16:46 john_cephalopoda: for instance if there is checks in @ and ! provided to userspace code, those checks would make the userspace run dog slow 16:17:49 The problem is, that core words have to be seperate from userspace word, and memory has to be protected. 16:18:07 john_cephalopoda: even said checks is basically looking up from the first nybble of an address into permission bitmaps, which I have and idea how can be written in few words. 16:21:24 say : usr@ ( a -- c ) DUP 0xF000 AND 12 >> USR-READABLE? IF @ ELSE THROW THEN ; or something like it where USR-READABLE? has stack effect ( page_idx -- bool ) 16:21:55 (the userspace program only see usr@ as @) 16:23:05 Yeah, or the system-internal definition could be prefixed with sys, so @ becomes sys@ and userspace uses normal @. 16:25:11 --- quit: nighty (Remote host closed the connection) 16:26:23 * Zarutian attemps : USR-READABLE? ( page_idx -- bool ) 0xF SWAP - USR-READABLE-PMAP @ SWAP >> 0x0001 AND ; 16:27:56 well, the point is that an usr@ takes longer to run that sys@ 16:28:02 s/that/than/ 16:28:21 Of course, since usr@ has checks built-in that ensure that users behave. 16:28:38 not users, but userspace programs 16:28:58 Yeah. 16:29:08 important distinction, that 16:30:13 So wait, is the idea to implement memory protection by restricting the namespace available to userspace programs? Meaning that userspace programs can't be arbitrary machine code, only forth definitions? 16:31:03 Yes, userspace programs can only be forth. 16:33:06 reepca: or anything that runs on top of the dual stackmachine forth specifies. 16:33:34 Zarutian: good point, you could have just about anything compile down to forth 16:33:46 It would be possible to write an x86 machine language interpreter in forth. 16:34:23 Would it be very difficult to utilize hardware memory protection where it's available and fall back to these approaches only where it's not available? 16:34:43 but why do that when it might be much easier to dissasemble an x86 program and reimplement it in forth. 16:35:20 Zarutian: Isn't that just compiling x86 -> forth instead of interpreting x86? 16:35:42 reepca: depends, if you are only going to emulate hardware memory protection in Forth then no, then usr@ just becomes an alias for sys@ when MMU is aviable. 16:36:26 reepca: meant in dissasembling, look it at it and reimplement the functionality in forth 16:37:29 though now I am curious if there is an gcc codegenerator that targets forth as the ISA. 16:37:41 Zarutian: I am not skilled in the ways of reverse-engineering, alas. But the good thing is that I think all of these approaches can probably be implemented pretty easily 16:37:59 I think Koopman had a C compiler for forth machines IIRC 16:38:10 --- join: dual (~bonafide@cpe-74-75-153-119.maine.res.rr.com) joined #forth 16:39:03 the nice thing about Forth as an ISA is that the 'instruction set' is extensible 16:40:09 Hmm, I am still a bit unsure about the implementation details 16:41:25 Somehow, userspace must be able to call some of the kernelspace functions - but not all. 16:41:25 john_cephalopoda: the implementation details depend on the ISA you are writing for and what the exact model you want to implement 16:43:26 john_cephalopoda: hmm... one way is to deliberatly have an page mapped not-executable and jump into at diffrent offset depending on the kernelspace function the userspace is invoking 16:43:26 Let's take x86 as target. 16:43:48 I quite like the idea of an operating system that provides just the basics - a simple language implementation, resource management, and ports to everything. 16:44:25 john_cephalopoda: when the trap-transfer to kernelspace has occured due to it, that code can see the offset and eather do mapping or just allowing it directly. 16:44:50 The kernel could have a "public" dictionary, that can be used by any program and a "hidden" dictionary, that can only be invoked by the public dictionary. 16:45:04 (that is check if the offset is indeed the start of an kernelspace word invokable from userspace) 16:45:15 --- quit: wa5qjh (Remote host closed the connection) 16:45:25 the interpreter for userspace programs is controlled completely by the kernel, right? 16:45:34 yes, and the public directory can use the above mechanism 16:45:58 (that is if hardware memory protection is being utilized) 16:46:33 john_cephalopoda: ^ 16:53:05 It's complicated. 16:53:24 indeed it is ;-) 16:53:36 --- join: roboguy` (~roboguy_@197.59.124.24.cm.sunflower.com) joined #forth 16:53:42 I suppose that in the worst-case, where hardware memory protection isn't available, the interpreter for userspace would have to test if every word was valid before it would execute it - there's always the chance that a program randomly guesses the address of some important kernel definition. 16:55:04 reepca: basically a check in $NXT ? 16:55:08 The interpreter could simply differentiate between kernel code and userspace code. 16:56:20 There will be 3 dictionaries in the end: The userspace program's dictionary (USD), the kernel's public dictionary (KPD) and the kernel's hidden dictionary (KHD). 16:56:31 s/$NXT/$NEXT/ 16:56:52 --- join: wa5qjh (~Thunderbi@121.54.90.150) joined #forth 16:57:42 A userspace program executes "@", which will be found in the KPD. The definition of @ will be hidden deep within the kernel. 16:58:02 (In the KHD). 16:59:16 Ah, but what happens when a userspace program executes 140013378035984 (where @ happens to be in gforth on my system)? 16:59:54 reepca: the check can be as simple as seeing if the next word is in the userspace dictionary range or when in a word inside the KPD before proceeding. (The latter allows KPD words to invoke words in the KHD) 17:00:25 140013378035984 @ is looked up in USD. When it isn't found, it is looked up in KPD. The KPD definition contains a check, if the address is okay to access. 17:00:49 reepca: What Zarutian said 17:01:48 john_cephalopoda: well the check happens in the $NEXT asm subroutine. 17:02:03 The kernel itself will have something like sys@ in its KHD, which allows the kernel to access any memory location. But it can be only accessed via the KPD, which can't be changed by a userspace process. 17:04:07 john_cephalopoda: you going to use the usual singly linked list implementation of dictionaries? 17:04:52 I am not quite sure yet. 17:05:14 In any case, it will work like a singly linked list dictionary. 17:06:14 then USD, KPD and KHD can be simply be sections of such a list, in that search order 17:06:36 I still have to think of a way, how USD can FORGET a KPD word. 17:06:58 It's after 2 am, I should go to bed :þ 17:06:59 antother way to limit Forth programs is to have an USR-FIND and SYS-FIND versison 17:07:05 user-space anti-word-list? 17:07:41 reepca: or simply a linking entry at end of USD that is adjusted to skip past forgotten KPD words 17:09:16 Right, good idea. 17:09:17 (that is instead of pointing to the last KPD word, it points to the one before the forgotten ones) 17:09:52 it'd have to be a list itself consisting of multiple skips, since it's not guaranteed that the words being forgotten will all be at the start of the KPD. You might forget the first KPD word, then forget two of them that are 3 words down the list, and so on 17:10:17 and rearranging the KPD to work with just one skip could cause problems for other userspace programs 17:10:22 reepca: FORGET is outdated anyway. 17:10:29 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 17:10:39 reepca: MARKER is the new thing, and iirc it skips all entries until the marker. 17:10:56 Not 100% sure though. 17:11:22 MARKER wouldn't work very well with a wordlist you're not allowed to touch 17:11:25 using a split name code dictionary makes it even easier as you only need to keep the name entries for KPD in userspace and none in kernelspace (well beside when intializing a new userspace task) 17:12:30 Hate to leave, but it's late x3 17:12:33 but in practice I don't think FORGET or MARKER would be necessary - why not just put your new definition on top of the KPD ones? 17:12:46 john_cephalopoda: eForth uses such split name code dictionary if you are looking for inspiration 17:12:57 reepca: Standard compliance. 17:13:08 See you later~ 17:13:09 --- part: john_cephalopoda left #forth 17:13:16 laters 17:13:23 ¯\_(ツ)_/¯ for what it's worth, gforth seeks standard compliance and it doesn't implement FORGET 17:14:51 I look only at the ANS Forth as inspiration (and something to adapt to own needs because there is a sha256 and aes code in ANS Forth I want to adapt and run) 17:16:11 well this has been nice chat and hopefully illuminating. reepca I hope you werent comeplely put off object-capabilities as an concept to investigate just because of its unfortunate name (it is like the name of computer science) 17:16:35 It keeps bugging me how much of a speed penalty doing a bounds check in NEXT is going to be, but then I remember it only matters on systems without hardware memory protection... and then I forget that a few minutes later and start worrying again 17:17:03 reepca: feel free to ask me or pointfree about this concept if you are interested. 17:17:39 reepca: well the bounds check can be as simple as the usr@ one I wrote above ;-) 17:18:37 9 kernel forth words per user forth word executed... *shudders* 17:19:21 well, the check would be in assembly as $NEXT is an assembler subroutine and not a Forth word ;-Þ 17:19:33 ah true 17:20:10 so the userspace and kernelspace ranges can be hardcoded in 17:21:25 wouldn't that require the amount of memory used by the kernel to be constant? 17:21:27 heck, an Forth on an processor that lacked interrupts used 'interrupt?' checking in the $NEXT assembler subroutine without much slowdown 17:22:04 reepca: well not perhaps used to be constant but yes, there would be constant memory alloted to the kernel 17:22:48 As long as there's enough to write some drivers or something without needing to reboot I guess 17:22:50 but there is a lot you can do in 4-8 KibiCells, no? 17:23:43 Well $NEXT can be assembled when the kernel starts up, right? 17:24:38 nope, but it could have been assembled last time kernel ran or reassembled on kernel startup 17:25:10 it is a rather foundational subroutine for all Forths 17:25:23 well, now I must be off to bed 17:25:27 cya around 17:25:29 alright, later 17:26:25 --- quit: Zarutian (Quit: Zarutian) 18:06:06 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 19:03:38 --- quit: wa5qjh (Remote host closed the connection) 19:49:48 --- join: vsg1990 (~vsg1990@static-72-88-80-103.bflony.fios.verizon.net) joined #forth 19:56:26 --- quit: skaria (Remote host closed the connection) 19:57:56 --- join: skaria (~skaria@h69-21-248-248.crlbnm.broadband.dynamic.tds.net) joined #forth 21:15:37 --- quit: roboguy` (Remote host closed the connection) 21:16:04 --- join: roboguy` (~roboguy_@197.59.124.24.cm.sunflower.com) joined #forth 21:20:32 --- quit: roboguy` (Ping timeout: 255 seconds) 21:23:37 --- join: roboguy` (~roboguy_@197.59.124.24.cm.sunflower.com) joined #forth 21:28:27 --- join: mtsd (4d6e3d64@gateway/web/freenode/ip.77.110.61.100) joined #forth 21:32:21 --- quit: skaria (Ping timeout: 240 seconds) 21:33:20 --- quit: roboguy` (Remote host closed the connection) 21:33:47 --- join: roboguy` (~roboguy_@197.59.124.24.cm.sunflower.com) joined #forth 21:34:54 --- quit: roboguy` (Remote host closed the connection) 21:35:00 --- join: roboguy` (~roboguy_@197.59.124.24.cm.sunflower.com) joined #forth 21:39:58 --- quit: neceve (Quit: Konversation terminated!) 21:45:21 --- join: true-grue (~true-grue@176.14.222.10) joined #forth 22:21:33 --- quit: dual (Ping timeout: 258 seconds) 22:38:11 --- quit: vsg1990 (Quit: Leaving) 23:04:14 --- quit: roboguy` () 23:08:12 --- join: sigjuice (~sigjuice@107.170.193.86) joined #forth 23:32:02 --- join: dual (~bonafide@cpe-74-75-153-119.maine.res.rr.com) joined #forth 23:40:39 --- quit: jyf (Ping timeout: 276 seconds) 23:43:04 --- join: jyf (~weechat@210.73.195.75) joined #forth 23:59:59 --- log: ended forth/17.02.09