00:00:00 --- log: started forth/19.03.10
00:21:29 --- join: proteusguy (~proteusgu@2600:1702:f20:7ba0:b192:cf6:97a6:6719) joined #forth
00:21:29 --- mode: ChanServ set +v proteusguy
00:45:18 --- quit: zy]x[yz (Read error: Connection reset by peer)
00:46:19 --- join: zy]x[yz (~corey@unaffiliated/cmtptr) joined #forth
00:49:01 <the_cuckoo> reworked the docs for rpany-pi a little - https://gitlab.com/lilo_booter/rpany-pi/blob/master/README.md - need to expand to show how the wiring of the led is done i guess (and show other stuff - motors and the like)
00:50:05 <the_cuckoo> if anyone cares to proof read, i'd appreciate any feedback (normal "not interested in debating the c++ implementation" caveat of course :))
01:03:33 --- quit: ashirase (Ping timeout: 250 seconds)
01:07:25 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
01:16:47 --- quit: proteusguy (Ping timeout: 252 seconds)
01:37:23 --- join: proteusguy (~proteusgu@2600:1700:d930:1ae0:b192:cf6:97a6:6719) joined #forth
01:37:23 --- mode: ChanServ set +v proteusguy
01:51:30 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
04:32:56 --- join: arrdem_ (sid333803@gateway/web/irccloud.com/x-ixvhuzpwlqhrcybh) joined #forth
04:34:52 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
06:26:58 <WilhelmVonWeiner> Got mu
06:27:27 <WilhelmVonWeiner> *Got my ergodox working today
06:27:54 <WilhelmVonWeiner> I have to learn to type again
06:29:01 <presiden> corecode, about the discussion of control flow the other day, it seems that there's section in the ANS FORTH draft that mention it (control-flow stack), https://www.taygeta.com/forth/dpans3.htm#3.2.3.2
06:32:18 --- quit: proteusguy (Remote host closed the connection)
06:44:49 <corecode> yes, i use the normal stack as control flow stack
06:45:10 <corecode> and if there is stuff on the stack after ; i issue a warning
07:08:20 --- quit: xek (Ping timeout: 246 seconds)
07:13:14 <presiden> yeah, it says if it exist, it may be, but need not be, implemented using the data stack
07:46:43 <crc> WilhelmVonWeiner: how are you liking the ergodox?
07:54:19 <crc> I'm still working on the keymap for mine. 
08:42:45 <WilhelmVonWeiner> it's quite good
08:43:04 <WilhelmVonWeiner> zealio purples
08:43:16 <WilhelmVonWeiner> are nice
08:44:22 <WilhelmVonWeiner> need to change a couple of binds for ISO when I can be bothered
08:52:46 <WilhelmVonWeiner> something like this https://a.uguu.se/iGHK2p0ngu4e_2019-03-10-155008_983x488_scrot.png
08:53:56 <crc> I have a dvorak based layout: https://configure.ergodox-ez.com/layouts/AND6/latest/0
08:55:13 <WilhelmVonWeiner> I will be switcj
08:55:56 <WilhelmVonWeiner> *switching to a colemak inspired layout soon
08:56:48 <WilhelmVonWeiner> two semicolons, huh
08:57:52 <WilhelmVonWeiner> I do think reaching to the inner large keys might get stressful
08:58:46 <crc> base layout tries to stay close to standard, but I use semicolon/colon enough to make having it on the home row worth the redendancy
08:59:31 <crc> I've not used the inner large keys yet.
08:59:50 <WilhelmVonWeiner> I agree, I am thinking of mapping qwerty ; to be a colon on a long press
09:00:22 <WilhelmVonWeiner> to avoid my nemesis, the shift key
09:00:31 <crc> I'm using autoshift on all keys
09:01:00 <WilhelmVonWeiner> is that what I just described
09:01:15 <crc> Yes
09:01:22 <WilhelmVonWeiner> if so i'll have to enable it
09:01:26 <WilhelmVonWeiner> ta 
09:01:44 <crc> long press any key to get the shifted version
09:04:04 <WilhelmVonWeiner> might come up with a Forth macro layer...
09:07:07 <crc> I'm cnsidering that as well, once I get a VM set up for compiling QMK
09:08:36 <WilhelmVonWeiner> it compiles on OPenBSD
09:08:55 <WilhelmVonWeiner> in fact it might not for the EZ. I have the infinity
09:09:39 <crc> I'll probably try later this week
10:45:42 <chunkypuffs> Is it correct to state that forth could be a superior language when implementing many of the things that C++ tries to implement?
10:46:01 <chunkypuffs> For example, simple rotation, a transformation matrix, 3d stuff
10:46:19 <chunkypuffs> Like how performant would Doom be in Forth vs in C
10:46:21 <chunkypuffs> C++, rather.
10:46:44 <zy]x[yz> performance is generally not a quality of the language
10:47:01 <chunkypuffs> But it must be, in some way.
10:47:10 <zy]x[yz> it isn't
10:47:12 <WilhelmVonWeiner> zy]x[yz: false
10:47:27 <chunkypuffs> So why do people talk of python as "slow"
10:47:29 <chunkypuffs> I understand why it's slow
10:47:32 <WilhelmVonWeiner> wtf are you talking about
10:47:35 <zy]x[yz> because the python VM is slow
10:47:44 <zy]x[yz> that's a quality of the python implementation, not the language
10:47:45 <chunkypuffs> Right, so you're referring only to compiled languages when you say that?
10:48:01 <WilhelmVonWeiner> then it;s
10:48:03 <chunkypuffs> Like not Java, not Python or Ruby?
10:48:27 <chunkypuffs> In fact, how does Ruby work? I don't know anything about it, other than it's somewhat like python without caring about whitespace.
10:48:31 <chunkypuffs> Is there a Ruby VM?
10:48:52 <zy]x[yz> i've never used ruby
10:48:52 <WilhelmVonWeiner> *then any apparent slowness in forth is due to your chosen implementation
10:49:24 <chunkypuffs> Right, whereas in other languages, things can be slow because of things outside of your control
10:49:43 <chunkypuffs> Whereas C++ and Forth are as close to the hardware as you can possibly be, but one's closer because it literally looks like CPU instructions
10:50:00 <chunkypuffs> like rot, what would be required to do rot in C++?
10:50:04 <WilhelmVonWeiner> `potentially same with Forth, I just don't know what zy]x[yz is talking about that it isn't performant
10:50:10 <zy]x[yz> both c++ and forth are abstractions from the hardware
10:50:18 <zy]x[yz> they're definitely not as close to hardware as you can be
10:50:24 <chunkypuffs> Forth is one step away from assembly
10:50:28 <chunkypuffs> C++ is ???
10:50:35 <WilhelmVonWeiner> rot has no equivalent in c++ because it's a completely different philosophy
10:50:36 <chunkypuffs> Are they the same in that regard?
10:50:41 <WilhelmVonWeiner> there's no implicit state
10:50:52 <zy]x[yz> they're both high-level languages if that's what you mean
10:51:01 <WilhelmVonWeiner> Forth is low level 
10:51:04 <chunkypuffs> I do mean that, but one's lower level than the other, right?
10:51:13 <zy]x[yz> WilhelmVonWeiner, in this context, forth is high-level
10:51:18 <WilhelmVonWeiner> forth is low level and you can build high level abstraction very quickly
10:51:22 <chunkypuffs> zy]x[yz, That can't be true.
10:51:34 <chunkypuffs> If you go on github and look at the stm8 implementation of forth, it's absurdly low level.
10:51:40 <zy]x[yz> you just admitted yourself that they're removed from assembly
10:51:45 <chunkypuffs> You get to see the assembly that creates forth.
10:52:01 <WilhelmVonWeiner> zy]x[yz: Check out Machine Forth
10:52:06 <chunkypuffs> and everything is compiled on the thing, whereas with C++, you have basically no real control over the way things are compiled unless you're a genius.
10:52:24 <WilhelmVonWeiner> I gotta eat real quick.
10:52:29 <chunkypuffs> You could understand every compiler flag you want, and you'll never get the optimizations you'll get on an STM8 with forth, right?
10:52:41 <zy]x[yz> nothing either of you are saying disputes that forth is a high-level language compared to assembly
10:52:54 <chunkypuffs> Forth is assembly-like though 
10:53:06 <chunkypuffs> It's written in assembly, and you can see the code that creates forth (in assembly)
10:53:10 <zy]x[yz> what does "assembly-like" mean?
10:53:11 <chunkypuffs> it's tiny, it's like 10KB
10:53:40 <zy]x[yz> "written in assembly" is irrelevant
10:53:43 <chunkypuffs> If you want to add a new thing to forth, and make a new forth, you just add to the assembly that's on github for the STM8, for example.
10:53:48 <chunkypuffs> And it's not even out of the question to want to do such a thing
10:53:57 <chunkypuffs> whereas with C++ it totally is
10:54:00 <Kumool> A thing you can do is go to project euler and compare implementations in different forths, you'll see most of them are not performant as compared to others. not even gforth is good at performance
10:54:05 <zy]x[yz> the language the compiler is written in is completely irrelevant to this discussion
10:54:53 <zy]x[yz> if i wrote an assembler in python, does that make the assembler high-level?
10:55:02 <zy]x[yz> if i wrote a python vm in assembly, does that make python low-level?
10:55:22 <chunkypuffs> hmmmm
10:55:24 <chunkypuffs> Good point
10:55:36 <chunkypuffs> Thanks for explaining that 
10:55:43 <crc> chunkypuffs: forth systems generally don't perform anywhere near as much optimization as a C or C++ compiler
10:55:46 --- quit: nighty- (Quit: Disappears in a puff of smoke)
10:56:03 <chunkypuffs> crc, so again, the optimizations are done by someone else
10:56:14 <chunkypuffs> for example, the guy who made the STM8 forth?
10:56:23 --- quit: dave0 (Quit: dave's not here)
10:56:52 <crc> if this forth does optimizations, then yes
10:57:04 <chunkypuffs> well what does it mean to "do optimizations"
10:57:15 <chunkypuffs> Not in the same sense as a JIT?
10:57:24 <Kumool> it means using 2* instead of 2 *
10:57:36 <Kumool> and things of that nature
10:57:46 <chunkypuffs> Oh so like when you see that weird javascript that's all scrunched together 
10:57:53 <Kumool> bitshifting when you can
10:57:55 <Kumool> and so on
10:58:37 <chunkypuffs> zy]x[yz, So, an assembler is a concept.
10:58:47 <chunkypuffs> This concept is low level, and on a very specific plane, a very specific level
10:58:54 <chunkypuffs> how it's implemented doesn't matter, that's correct to say?
10:59:40 <chunkypuffs> In the same way as there are layers to the internet, and things are on specific layers.
10:59:41 <crc> the forth compiler could just be laying down a series of addresses to call. an optimizing compiler might selectively inline things, or generate a jump table instead of a bunch of branches for if/then, etc
11:02:01 <chunkypuffs> crc, such a compiler might take more time to do its thing right?
11:02:12 <crc> yes
11:02:35 <chunkypuffs> Could you have a compiler give you some straight up code to put on an stm8 for example?
11:02:48 <chunkypuffs> compiled code that would then be compiled on the stm8 (when defined) which would run better?
11:04:03 <crc> I'm not familiar with the stm8
11:04:48 <chunkypuffs> It's slow bea
11:04:54 <chunkypuffs> wrong thing in clipboard lol
11:04:58 <crc> the optimizing forth compilers I've encountered are mainly for x86 (vfx, iforth) 
11:05:04 <chunkypuffs> I'm using i3 lately and forget ctrl + c isn't what it used to be in KDE
11:05:09 <chunkypuffs> https://github.com/TG9541/stm8ef
11:06:40 <chunkypuffs> Using Forth to actually do stuff in the real world with microcontrollers, that's interesting as hell to me
11:07:34 <chunkypuffs> mainly because of the lack of stuff you need in order to accomplish a goal
11:07:43 <chunkypuffs> no arduino ide, no weird dependencies just do it.
11:08:08 <chunkypuffs> No libraries, you just have to interact with the hardware for real, which turns out to be not even that bad.
11:23:15 <crc> I typically deal with forth at a higher level than the raw hardware
11:24:05 * crc has a forth os for x86, but mostly works under BSD, Linux, and iOS
11:24:30 <chunkypuffs> There's am OS written in forth?
11:26:00 <crc> there are a few
11:26:07 <Kumool> no functional ones
11:27:38 <crc> forthos.org https://github.com/davazp/eulex https://sites.google.com/site/forthoperatingsystem/home
11:27:59 <crc> Kumool: what is needed for it to be functional?
11:29:34 <Kumool> probably support usb for one
11:29:39 <crc> mine is useable for some things. I have ATA support, a block editor, serial port, keyboard, and VGA text mode display drivers. Will work on more as time and RSI allows.
11:29:43 <Kumool> wifi
11:30:52 <WilhelmVonWeiner> good luck with that...
11:31:56 <Kumool> basically what a raspberry pi supports
11:32:19 <chunkypuffs> Imagine if you could run a forthOS on a raspberry pi
11:32:22 <chunkypuffs> that'd be pretty powerful 
11:33:46 <WilhelmVonWeiner> zy]x[yz: Forth's being  "low level" is due to the simplicity of defining new code words and (potentially interactively) interfacing at a low level with the machine
11:34:55 <WilhelmVonWeiner> when written in assembler you avoid calling conventions, you avoid memory management, you avoid the kind of cruft you need to run on an OS
11:35:04 <WilhelmVonWeiner> all with simple and simply extensible syntax
11:38:55 <zy]x[yz> low-level and high-level are obviously relative terms
11:39:20 <zy]x[yz> in the context of the discussion, the reference point was assembly languages.  relative to that, forth is a high-level abstraction
11:40:39 <WilhelmVonWeiner> I see
11:41:02 <chunkypuffs> yeah but the contrast isn't that massive
11:41:07 <chunkypuffs> it's higher level, but it's only one step away
11:41:23 <zy]x[yz> how many steps away do you think c is?
11:41:34 <chunkypuffs> More than one.
11:41:36 <chunkypuffs> Whereas forth is literally one.
11:41:39 <chunkypuffs> Is this false?
11:41:39 <zy]x[yz> how many?
11:41:46 <chunkypuffs> two
11:41:54 <chunkypuffs> because you need a compiler, right?
11:41:56 <zy]x[yz> i don't know, because i'm not clear on how you're defining those steps
11:42:01 <zy]x[yz> forth also has a compiler
11:42:07 <chunkypuffs> it does, but it's so transparent
11:42:14 <chunkypuffs> I guess I'm just ignoring it.
11:42:23 <chunkypuffs> So they're identical.#
11:42:26 <zy]x[yz> yeah, it seems like every time i make a point the goalposts shift
11:42:48 <chunkypuffs> So they're identically placed languages?
11:42:58 <chunkypuffs> in terms of level.
11:43:21 <zy]x[yz> sure, why not
11:44:04 <chunkypuffs> The only difference is that one is stack based, and all the things that come along with that are the benefits I'm espousing, I guess.
11:44:34 <crc> Kumool: I may take a stab at that (at least USB); I'm thinking about attempting a port of my system to RPi 
11:45:16 <WilhelmVonWeiner> zy]x[yz: what goalposts? What's your point, you also compile Forth?
11:45:33 <WilhelmVonWeiner> Why would anyone deny Forth is compiled?
11:45:40 <zy]x[yz> my original point was that talking about performance with respect to a language is meaningless
11:45:42 <chunkypuffs> I just haven't yet experienced needing to think about compiling forth
11:45:46 <chunkypuffs> so therefore I ignored it.
11:45:46 <zy]x[yz> they're orthogonal
11:45:49 * crc is thinking about using something like https://www.usconverters.com/serial-rs232-wi-fi-adapter
11:46:25 <WilhelmVonWeiner> Performance with respect to the situationally best implementation of a language is not meaningless
11:46:53 <zy]x[yz> how in the world do you define the situationally best implementation of forth?!
11:47:21 <WilhelmVonWeiner> The Forth you prefer to use, or one you've built for a given purpose? Not hard
11:47:37 <zy]x[yz> well then nobody can answer that for him but himself
11:47:51 <WilhelmVonWeiner> Well, one can provide their own opinion based on their experience
11:48:08 <WilhelmVonWeiner> Can nobody tell me how well a given car handles because they might be a lesser driver
11:48:27 <WilhelmVonWeiner> Your point just seems weird
11:48:38 <zy]x[yz> nobody can tell you how well *car* handles when car is not defined
11:49:11 <WilhelmVonWeiner> I guess, whatever.
11:49:30 <john_cephalopoda> Hmm, what base words do you use for the inner compiler/interpreter loop? "find" obviously.
11:49:31 <WilhelmVonWeiner> Language implementation A > language implementation B > C etc etc
11:49:47 <WilhelmVonWeiner> it's ordinal
11:50:01 <zy]x[yz> i don't think my point is weird at all.  comparing the performance of /languages/ is a meaningless comparison.  which language bakes a cake faster: english or french?
11:50:12 <WilhelmVonWeiner> Compiled C is more performant than CPthon, obviously
11:50:40 <WilhelmVonWeiner> When someone says $language they mean $most_performant_implementation_of_language
11:51:00 <chunkypuffs> It's a thing, to ignore that it's a thing is being semantic in my opinion.
11:51:15 <chunkypuffs> I'm not being correct, but it's still true that languages are naturally more or less performant than others for certain tasks.
11:51:19 <chunkypuffs> Only by default.
11:51:45 <chunkypuffs> There's some languages in the world that don't allow you to suggest cardinal directions (north east south west) without knowing for sure objectively where that langauge is.
11:51:50 <chunkypuffs> Which impede conversation 
11:52:00 <chunkypuffs> where that direction is*
11:52:08 <zy]x[yz> but now you're talking about expressiveness, not performance
11:52:25 <chunkypuffs> Leads to a performance disparity
11:52:40 <chunkypuffs> imagine speaking that langauge in the military, you wouldn't be able to approximate or communicate properly.
11:52:47 * the_cuckoo follows and his currently siding with zy]x[yz
11:52:52 <chunkypuffs> It'd impede performance if you couldn't express things in the military.
11:53:22 <chunkypuffs> I'm not saying this is in any way relevant other than it proves there are differences that ultimately relate to performance.
11:53:35 <chunkypuffs> And the differences mightn't be clear, but there's a reason people think python is slow.
11:53:57 <chunkypuffs> micropython uses more ram, you can't accomplish the same things on microcontrollers that you can with C
11:54:01 <WilhelmVonWeiner> Nobody means "The Backus-Naur notation of C is faster than the Backus-Naur notation of Python" which is what I think you think people are saying
11:54:38 <chunkypuffs> Trying to find a way to use micropython on a microcontroller in the same way you would use C (update a display) would end up with you writing more code than ever.
11:55:04 <chunkypuffs> So it'd be moot to try and complete a certain task in micropython, because to make that possible, you'd need to re-implement it in a way that allows for it.
11:55:42 <chunkypuffs> Whereas in C the overhead doesn't exist, but you have to implement things from the ground up gradually, rather than having something implemented for you (which ultimately needs to be dug out and reimplemented)
11:56:10 <chunkypuffs> I think that's pretty much it, isn't it. It's the amount of things that are done for you that defines the speed of a language.
11:56:34 <chunkypuffs> How many things are implemented for you, that you don't have to implement yourself. That's the defining factor, no?
11:57:28 <chunkypuffs> Same with libraries. Sometimes a library might do something silly and bottleneck the performance of the task, which means you need to dig it out and re-implement it yourself anyway
11:57:55 <zy]x[yz> scroll up and look at everything you've just typed.  do you see now why there is no simple answer to your question?
11:58:09 <chunkypuffs> Yes, but I'm fixating on "it depends on the implementation"
11:58:17 <chunkypuffs> I think the simple answer is that it depends on the implementation
11:58:27 <zy]x[yz> that was my answer
11:58:27 <chunkypuffs> That is a simple answer to the question though.
11:58:41 <chunkypuffs> Well I've found a way to make use of it now that I understand it :)
11:58:48 <the_cuckoo> it was what zy]x[yz said, and what i agreed with :)
11:58:52 <chunkypuffs> I'll just look at how much stuff is done for me, before assuming that things will be performant/optimal
12:03:25 <the_cuckoo> i would focus on correct and understandable at the level you're coding before concerning yourself about the optimal behaviour of what's running it - but that isn't a shared opinion around here :)
12:07:05 <chunkypuffs> Right, but I understand now at least why people do the whole "my language is faster" thing
12:07:50 <chunkypuffs> It's still correct, IMO, if all the implementations follow a trend, that manifests itself as it does, your language is slow for that reason.
12:09:03 <chunkypuffs> I guess that matters more for languages like python though..
12:09:50 <chunkypuffs> The thing that allows python to run is the thing that has overhead, so therefore your code can only be so optimal. Is this incorrect?
12:10:24 --- quit: Zarutian (Read error: Connection reset by peer)
12:10:45 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
12:10:51 <the_cuckoo> i just don't think that optimal from the outset is the most important thing - define a solution in any language, check that your ins and outs match your expectations - then concern yourself with optimisation
12:11:17 <the_cuckoo> and only if you really need to
12:13:46 --- quit: gravicappa (Ping timeout: 245 seconds)
12:31:58 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
12:46:10 --- quit: Zarutian (Ping timeout: 255 seconds)
13:06:34 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
13:19:28 --- join: proteusguy (~proteusgu@drake204.d.subnet.rcn.com) joined #forth
13:19:28 --- mode: ChanServ set +v proteusguy
14:10:25 --- quit: xek (Ping timeout: 245 seconds)
14:25:41 <the_cuckoo> woot - multiple video windows correctly handled ... now comes the fun with audio :(
14:36:57 <the_cuckoo> am sure no one is interested :), but what the hell - this is my take on audio and video :) - we'll start with the basics - keep the maths simple - audio with a sampling rate of 48khz and video at 25fps 
14:39:07 <the_cuckoo> 48khz just says there are 48000 samples per second per channel, 25 fps just says there are 25 images per second - hence, 48000 25 / = 1920 samples per channel per frame
14:42:51 <the_cuckoo> in my system, each frames comes with image and audio objects, and the audio objects hold the 1920 samples per channel - so it should just be a case of showing the image and pushing the audio samples to the player and continue to the next frame 
14:43:50 <the_cuckoo> but of course, it isn't that simple - the audio buffers associated to playout tend to be a power of two sized thing - like 512, 1024 or 2048 etc samples per channel
14:48:00 <the_cuckoo> assume it's 2048 - it means we need 2 frames to fill the first buffer (ie: 1920 2 * = 3840 so we get the 2048 necessary to start) - hence we need the concept of a preroll 
14:51:08 <the_cuckoo> but video isn't well behaved - it tends to be delivered at different rates - amongst them 29.97fps (actually 30000 1001 /) and 23.97fps (actually 24000 1001 /) - taking the first of those and the 48khz above - samples per frame is 48000 30000 1001 / / which is a lovely 1601.6 samples per second
14:51:49 <the_cuckoo> gonna stop there with a question to see if anyone is interested - how do you represent a fractional sample?
14:55:22 <the_cuckoo> correction to "samples per second" - should have been "samples per frame" of course (or nothing since i cited that upfront :))
15:06:39 <the_cuckoo> ... or to put it another way, if anyone is considering writing a video player, these are the things they will have to know :)
16:34:25 <the_cuckoo> tough crowd :D - https://www.youtube.com/watch?v=yrbv40ENU_o
16:52:00 <the_cuckoo> https://youtu.be/zxFCQplZgKI?t=294
17:44:30 --- quit: john_cephalopoda (Ping timeout: 240 seconds)
17:50:10 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
17:58:03 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
19:12:47 --- join: TCZ (~Johnnnyas@ip-91.246.67.134.skyware.pl) joined #forth
19:39:46 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
19:40:11 <dave0> hi
19:41:23 --- quit: dddddd (Remote host closed the connection)
20:02:06 --- quit: TCZ (Quit: Leaving)
20:09:38 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
20:12:56 --- quit: MrMobius (Ping timeout: 245 seconds)
20:12:56 --- nick: [1]MrMobius -> MrMobius
20:40:10 --- join: gravicappa (~gravicapp@h37-122-113-40.dyn.bashtel.ru) joined #forth
23:09:38 --- quit: dave0 (Quit: dave's not here)
23:59:59 --- log: ended forth/19.03.10