<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
30
00:00 suls joined
00:03 NeverDie joined
00:03 Jackoe joined
00:05 eacameron joined
00:06 conal joined
00:10 aoanthony joined
00:10 mojjo joined
00:11 binaryplease joined
00:32 Rodya_ joined
00:34 eacameron joined
00:37 howdoi joined
00:39 andyhoang1 joined
00:48 <qu1j0t3> hasn't that particular expression come up before? isn't it a typo?
00:48 <qu1j0t3> "λx(λy).xyy" this doesn't make sense to me.
00:56 <geekosaur> not seeing it in my log, fwiw
00:57 conal joined
00:57 <geekosaur> but it does look like either a typo or whatever it came from has its own notational conventions that need to be checked to find out what it means
00:57 <qu1j0t3> geekosaur: 19:48:14 CuriousErnestBro | λx.λy.xyy = λx(λy).xyy, what's this notation on the right hand side?
00:57 <qu1j0t3> but i seem to recall this same expression has having been asked about in here before. i could be wrong.
00:58 <geekosaur> yes, I mean in the log from before that
00:58 <qu1j0t3> oh, ok.
00:58 <geekosaur> that's the first hit in the log
00:58 <qu1j0t3> CuriousErnestBro: what's the page # for that expression so that somebody in here or bitemyapp can verify it's not a typo
01:00 Rodya_ joined
01:04 <mounty> Am I clever? https://github.com/mounty1/JackRose/commit/9789d841183e8a04aa7b8aa5c0adb0d141eed3bf
01:04 <mounty> Maybe too clever. As in: Nothing | Just "too clever"
01:05 <* geekosaur> was going to say that looked like it might be the bad kind of clever
01:05 <geekosaur> @quote clever
01:05 <lambdabot> sproingie says: i see a lot of stuff with very clever maps and folds ... it's like functional spaghetti code ... maybe call it origami code
01:05 <geekosaur> bah
01:05 <mounty> Yeah, I fear so, although I have to say I'm quite proud of it.
01:06 <geekosaur> "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
01:07 <geekosaur> (Brian Kernighan)
01:07 <mounty> Good point geekosaur. But I did add a whole nine words of explanatory comment.
01:07 <monochrom> In fact, I did not know that debugging is twice as hard as writing in the first place.
01:08 <monochrom> I thought everyone knew that debugging was 50% as hard as writing in the first place.
01:08 <monochrom> At any rate, I don't understand the code, but it is always wise to replace head by uncons.
01:09 <monochrom> Oh, I think I now see why I disagree with Kernighan.
01:09 <mounty> monochrom: yes; I don't like head either and that was actually one motivation.
01:09 <* qu1j0t3> 's experience agrees with kernighan's
01:11 <monochrom> I am very logical, but not very creative. Creating in the first place is very hard. But bugs being inconsistencies (sometimes just absent-minded, some other times fundamental cognitive dissonance), that's easier to fight.
01:11 <monochrom> But it's true that a lot of people are the other way round.
01:11 <qu1j0t3> to be clear i definitely advocate for more effort up front, because that translates via great leverage to less debugging
01:12 <mounty> Brian Kernighan ... that's the Brian Kernighan who wrote in C ? I'd take as much notice of his advice as that of Brendan Eich.
01:12 <qu1j0t3> which might explain your ratio monochrom
01:12 <qu1j0t3> mounty: the K in K&R, yes.
01:13 <monochrom> P.S. Kernighan autographed my copy of K&R. Also hard cover. :)
01:13 <qu1j0t3> i've never seen the hard cover edition.
01:14 <mounty> I don't understand why people revere such 'luminaries' as Kernighan, E. Raymond and Eich, just because they're famous. Fame /= excellence.
01:14 <qu1j0t3> i'd specifically single out Pike for that objection.
01:14 <monochrom> But I do, at least myself. I am vain glorious, I want their autographs. That's all.
01:15 <monochrom> Apart from that, you're right.
01:15 <qu1j0t3> mounty: however most of the debugging i do is in systems not superior to C, so Kernighan's metric seems to apply well.
01:15 <monochrom> I learned it the hard way, though.
01:16 <monochrom> Once upon a time, I revered Knuth, and enshrined everything he said. Then I revered Dijkstra, and enshrined everything he said.
01:16 <qu1j0t3> mounty: i think it's derived from antique methods and we can do much better, tough.
01:16 <monochrom> Then came the dilemma. They actually said a few mutually conflicting things!
01:16 louispan joined
01:17 <mounty> qu1j0t3: we're discussing this in #haskell-beginners, right? It's a better way.
01:17 <monochrom> So I reasoned it out without enshrining, and concluded: Ah, now I see what's going on: You are both wrong, I am right!
01:17 <monochrom> Henceforth I revered myself only. :)
01:17 conal joined
01:17 <qu1j0t3> mounty: well, yes, i'd agree...
01:17 peterbec` joined
01:18 <mounty> monochrom: I certainly respect both Knuth and Dijkstra. But they're just people, after all. Probably the most visionary have never even achieved recognition. Certainly Alan Turing deserves more recognition for the degree to which he advanced understanding of the science.
01:19 <mounty> All hail monochrom !
01:19 <qu1j0t3> created the science, i'd say.
01:19 <mounty> monochrom: I for one am very grateful for the help you give so freely in this channel.
01:19 <monochrom> You're welcome.
01:20 <* mounty> away from IRC now.
01:24 cschneid_ joined
01:25 cschneid_ joined
01:27 cschneid_ joined
01:34 dni- joined
01:38 Mikan joined
01:42 <MarcelineVQ> qu1j0t3, geekosaur: fwiw I don't see a single example of that form in the lambda chapter, every explicit parens around a lambda include a head and a body.
01:43 <geekosaur> CuriousErnestBro needs to provide a pointer or example of this usage
01:43 <geekosaur> [05 23:48:14] <CuriousErnestBro> λx.λy.xyy = λx(λy).xyy, what's this notation on the right hand side?
01:43 <geekosaur> [05 23:57:03] <CuriousErnestBro> the book is using this all over for some reason
01:45 <qu1j0t3> MarcelineVQ: that's what i feared
01:46 <qu1j0t3> MarcelineVQ: i just had some weird déjà vu, but given my brain, probably unimportant
01:46 <MarcelineVQ> there is what seems to me like odd notation in the Beta reduce section, in order to show you substitutions, so it could be related to that
01:47 <MarcelineVQ> in fact I think it's exactly that given the earlier questions, example 2 of Beta reduce, in secton 1.12
01:48 <MarcelineVQ> for an earlier question anyway, answer 5 for this last one
01:49 <MarcelineVQ> it's not actually odd notation, but it could be odd to see the steps layed out
01:50 <geekosaur> I did mention something liek that culd be involved, [06 00:57:23] <geekosaur> but it does look like either a typo or whatever it came from has its own notational conventions that need to be checked to find out what it means
02:08 louispan joined
02:12 conal joined
02:12 Rodya_ joined
02:13 exferenceBot joined
02:18 hexagoxel joined
02:18 peterbec` joined
02:20 vaibhavsagar joined
02:20 ali_bush joined
02:20 harfangk joined
02:28 tauoverpi joined
02:28 aarvar joined
02:28 bluepixel joined
02:30 conal joined
02:33 <lpaste> tauoverpi pasted “Lambda Calculus Interpreter” at http://lpaste.net/354349
02:35 <tauoverpi> is there anyone who'd be able to help me with a catamorphism problem?
02:40 <Cale> tauoverpi: What's the problem?
02:42 <tauoverpi> cale: I'm trying to write a function that recursively calls itself until input equals the output (can't reduce any further)
02:42 <tauoverpi> my earlier code used Eq for this
02:43 <tauoverpi> but when using catamorphisms via the type system, I'm not sure how to replicate this
02:43 <Cale> Does that evalWhile not work with the new version of eval?
02:43 andyhoang1 joined
02:44 <tauoverpi> no, since the new eval doesn't implement Eq
02:49 <tauoverpi> I'm following the design pattern from https://en.wikipedia.org/wiki/Catamorphism#General_case if that helps
02:53 irons_ joined
02:54 danny_ joined
02:59 bluepixel joined
03:07 <monochrom> Write your own function to compare two expressions.
03:07 louispan joined
03:07 <monochrom> And its name does not have to be "==".
03:08 peterbecich joined
03:08 <tauoverpi> monochrom: ah yeah, thank you :)
03:09 abel-abel joined
03:23 dni- joined
03:26 shayan_ joined
03:28 takle joined
03:46 takle joined
03:49 louispan joined
04:04 myrkraverk_ joined
04:04 \Mike joined
04:05 micro__ joined
04:05 earldoug1as joined
04:05 chindy_ joined
04:08 uglyfigurine joined
04:09 guampa_ joined
04:10 takle joined
04:13 suls joined
04:17 m1dnight_ joined
04:28 alexelcu joined
04:29 takle joined
04:35 sassela joined
04:46 moei joined
04:47 louispan joined
04:52 abel-abel joined
04:52 takle joined
04:53 pbrant joined
05:03 benzrf joined
05:07 andyhoang1 joined
05:10 alexelcu joined
05:12 dni- joined
05:14 takle joined
05:32 Jackoe joined
05:34 Jackoe joined
05:34 takle joined
05:37 Jackoe joined
05:43 abhiroop joined
05:51 Kuros joined
05:52 yellowj joined
05:52 Kuros joined
05:53 louispan joined
05:54 meandi_2 joined
05:55 takle joined
05:57 DataComputist joined
05:57 cur8or joined
06:00 Lokathor joined
06:05 cur8or joined
06:16 Gurkenglas joined
06:25 DataComputist joined
06:31 sherub1 joined
06:33 dni- joined
06:36 geekosaur joined
06:41 takle joined
06:43 thc202 joined
06:46 louispan joined
06:48 dni- joined
06:50 Pupnik joined
07:09 andyhoang1 joined
07:14 azahi joined
07:15 vaibhavsagar joined
07:17 gfixler joined
07:19 <gfixler> anyone remember a writeup about Haskell's optimizer magically improving the time complexity of an algorithm?
07:20 takle joined
07:22 mattyw joined
07:22 Jackoe joined
07:24 alexelcu joined
07:28 louispan joined
07:28 Jackoe joined
07:29 cur8or joined
07:31 jarshwah_ joined
07:32 kritzcreek_ joined
07:33 i-amd3 joined
07:37 azahi joined
07:42 patbecich joined
07:44 zero_byte joined
07:45 abhiroop joined
07:50 Jackoe joined
07:56 govg joined
08:00 shayan_ joined
08:01 andyhoang1 joined
08:06 nil_ joined
08:06 sherub1 joined
08:09 <nil_> Languages with a LISP heritage differentiate between "let" and "letrec". What is the rationale behind this duality? Is it better to have both than only "letrec"?
08:10 dni- joined
08:14 mattyw joined
08:14 grdryn joined
08:16 nacon joined
08:16 nacon joined
08:17 Jackoe joined
08:18 abhiroop joined
08:19 takle joined
08:23 eacameron joined
08:27 salva joined
08:27 govg joined
08:32 eacameron joined
08:34 takle joined
08:35 grdryn joined
08:38 moei joined
08:42 Durz0 joined
08:47 Ferdirand joined
08:50 azahi joined
08:52 eacameron joined
08:56 eacameron joined
08:58 mojjo joined
09:00 eacamero_ joined
09:03 sherub1 joined
09:05 takle joined
09:05 azahi joined
09:10 eacameron joined
09:16 qu1j0t3 joined
09:19 sherub1 joined
09:19 Iceland_jack joined
09:43 eacameron joined
09:43 <rockfruit> So I'm kind of used to having "browse to symbol definition" in whatever editor or IDE I'm using, but I don't know what that looks like in normal daily haskell usage. if I see something like const $ spawnShell >*> 3
09:43 lithie joined
09:43 <rockfruit> (at https://hackage.haskell.org/package/xmonad-contrib-0.11.1/docs/XMonad-Actions-TopicSpace.html ) - how can I see what >*> is, without relevant imports to explore by hand?
09:44 <__rgn> hoogle maybe
09:48 uglyfigurine joined
09:53 <nil_> (Hoogle's not going to be enough, you need Hayoo which indexes a much wider set of libraries.)
09:53 eacameron joined
09:56 <__rgn> til: hayoo. cheers
09:59 abhiroop joined
10:01 abhiroop joined
10:06 Jackoe joined
10:07 mengu joined
10:13 eacameron joined
10:19 mengu_ joined
10:19 merijn joined
10:20 <rockfruit> nil_ thanks that did it. alias for flip replicateM_ (perl junkies are everwhere)
10:34 binaryplease joined
10:38 abhiroop_ joined
10:38 irons_ joined
10:42 pbrant joined
10:42 louispan joined
10:48 <sshine> hi. toying around with Text.MegaParsec.Expr's makeExpressionParser. https://gist.github.com/sshine/6e007079b49723189ff2fb68189d4aba
10:49 <sshine> 'parseTest validName "foo"' works fine, 'parseTest expr "2+2"' works fine, but 'parseTest "2+foo"' doesn't.
10:50 <merijn> What does "lexeme space" do?
10:50 <CuriousErnestBro> geekosaur, page 40, intermission exercises, exercise 2. The answer c is written in that way
10:51 <sshine> merijn, L.lexeme space p = do { x <- p; _ <- many space; return x } or such, I think.
10:51 <merijn> hmmm
10:51 slomo joined
10:51 slomo joined
10:52 <sshine> actually, 'expr' probably shouldn't be wrapped with L.lexeme, since its components all do.
10:54 <sshine> > parseTest expr "2+foo"
10:54 <sshine> Add (Const 2) (Const *** Exception: Prelude.read: no parse
10:54 <lambdabot> error:
10:54 <lambdabot> Variable not in scope: parseTest :: (Expr -> Expr) -> [Char] -> t
10:54 <sshine> so it seems that it's down some branch where it insists on making the operand a Const even though it's not.
10:56 <merijn> sshine: oh, I see the problem
10:56 <sshine> hmm, if I switch the order of Var and Const, it works?!
10:56 <merijn> sshine: posNegInt is using option and many
10:56 <sshine> ahhh!
10:56 <merijn> sshine: So posNegInt is just parsing 0 characters
10:56 <merijn> And then fails because that's not a number
10:57 <sshine> so it succeeds at parsing 0 characters. d'oh.
10:57 <merijn> presumably you want many1
10:57 <sshine> it should be many1. :)
10:57 <sshine> thanks!
10:57 <sshine> well, at least testing led to finding that.
10:57 azahi joined
11:26 gregman_ joined
11:46 alexelcu joined
11:53 Jackoe joined
11:56 ederign joined
12:03 alexelcu joined
12:18 exferenceBot joined
12:45 Iceland_jack joined
12:53 andyhoang1 joined
12:57 nitrix joined
12:59 carlomagno1 joined
13:02 <__rgn> maybe i'm fundamentally confused about something, but if reader is function composition, how is it that the environment doesn't get overwritten in the process of using reader
13:03 <merijn> __rgn: What do you mean overwritten?
13:03 <merijn> Also, reader isn't function composition
13:05 <__rgn> bummer
13:05 <merijn> fmap for reader is function composition-ish
13:08 iAmerikan joined
13:08 <__rgn> fmap :: (a -> b) -> Reader r a -> Reader r b
13:08 <__rgn> fmap f (Reader ra) = Reader $ \r -> f (ra r)
13:09 <__rgn> r is the same value in the signature?
13:09 <merijn> Yes
13:09 <__rgn> how does the r propagate to the new reader that is returned
13:09 <__rgn> all i see the new reader being given is a function that returns some value
13:09 jathan joined
13:09 <merijn> Yes and what does that reader get as input? The same 'r' the original reader would have gotten
13:10 andyhoang1 joined
13:18 abhiroop joined
13:25 mizu_no_oto_work joined
13:32 chlong joined
13:32 abhiroop joined
13:33 vmesons joined
13:49 conal joined
13:53 TCZ joined
13:56 abhiroop joined
13:58 brezel joined
14:02 conal joined
14:08 Ferdirand joined
14:10 c0smo_ joined
14:11 dxld_ joined
14:15 bkonkle joined
14:15 seanparsons joined
14:16 rockfruit_ joined
14:18 tarcwynne_ joined
14:20 Rodya_ joined
14:22 cschnei__ joined
14:29 govg joined
14:31 abhiroop joined
14:35 boris_rh joined
14:38 Gurkenglas joined
14:39 Ferdirand joined
14:45 mengu joined
14:49 taksuyu joined
14:55 abhiroop_ joined
14:59 timdiels left
14:59 abhiroop joined
15:09 uglyfigurine joined
15:13 abhiroop_ joined
15:17 cschneid_ joined
15:19 jathan joined
15:21 <__rgn> how is (>>=) of (r ->) useful?
15:23 <__rgn> > (+2) >>= (*) >>= (+) $ 2
15:23 <lambdabot> 10
15:29 abhiroop joined
15:34 <ski> > (do x <- (+ 2); y <- (x *); (y +)) 2
15:34 <lambdabot> 10
15:34 <__rgn> i was just in the process of figuring out how this works in do-notation
15:35 <ski> @do (+2) >>= (*) >>= (+) $ 2
15:35 <lambdabot> do { a <- do { a <- (+ 2); (*) a}; (+) a} $ 2
15:35 <ski> hrm, it ought to use associative law to flatten that
15:37 <__rgn> how does (+2) >>= (*) desugar to using lambda? (+2) >>= (\x -> (x *)) ?
15:38 <__rgn> right. infinite type error came because of not using $
15:40 <ski> `(+2) >>= (*) >>= (+)' is `((+2) >>= (*)) >>= (+)', eta gives `((+2) >>= \x -> (*) x) >>= (+)'
15:47 abhiroop joined
15:48 t0by joined
15:49 aminb joined
15:49 aminb joined
15:53 freechips joined
15:53 litwol left
16:11 freechips joined
16:17 iAmerikan joined
16:23 alexelcu joined
16:24 horrorcheck joined
16:27 <horrorcheck> hi all, I'm having trouble with deriving Read on a record type -- I show the type and then read it and it doesn't parse?
16:28 <horrorcheck> one of the fields has a custom Read
16:28 <horrorcheck> and that seems to be the problem?
16:28 <horrorcheck> but I'm not sure how to get around it
16:30 bodisiw joined
16:32 <ski> fix the `Read' (or `Show') of the field ?
16:33 iAmerikan joined
16:34 <horrorcheck> but `read(show MyThing)` does parse
16:34 <horrorcheck> it's just if I write `data MyWrapper = MyWrapper { thing :: MyThing } deriving (Read)`, it doesn't
16:35 <ski> how about `(read . show . Just) MyThing' ?
16:36 vmeson joined
16:37 <horrorcheck> Where does `Just` come into it?
16:37 <ski> checking whether they handle precedence correctly
16:37 <ski> ("they" being the `Show' and `Read' instances for `MyThing')
16:40 <ski> (you could also try with `data MyWrapper = MkMyWrapper MyThing deriving Read', if you like)
16:40 <geekosaur> horrorcheck, note that Read often needs to be told what type --- it does not determine the type from the thing read, it determines how to read from the requested typer. and the default type is likely to be Integer in compiled code or unit () in ghci
16:40 <horrorcheck> okay lemme see
16:42 <ski> yea, sorry. i was taking for granted that you knew how to ascribe the expected result type for `read'
16:43 <horrorcheck> yep, the problem isn't that it's not compiling, it's that I'm getting "no parse"
16:43 <ski> .. you could also try showing us the custom `Read' instance
16:43 <horrorcheck> It's all kinda integrated into a larger app so I'm trying to extract a minimal example here
16:44 <* ski> nods
16:44 <horrorcheck> so I might need a minute :)
16:45 abhiroop joined
16:48 chindy joined
16:49 Ferdirand joined
16:51 sherub1 joined
16:51 conal joined
17:10 abhiroop joined
17:18 mando joined
17:19 conal joined
17:20 Ferdirand joined
17:21 blu7 joined
17:25 sherub1 joined
17:29 azahi joined
17:34 abhiroop joined
17:37 uglyfigurine joined
17:40 uglyfigurine joined
17:43 freechips joined
17:44 abhiroop joined
17:46 iAmerikan joined
17:50 Zialus joined
17:51 Ferdirand joined
17:56 abhiroop joined
17:59 yellowj joined
18:01 hoffmeyer joined
18:03 zero_byte joined
18:07 iAmerikan joined
18:09 abhiroop joined
18:14 abhiroop joined
18:16 <__rgn> have a problem implementing (>>=) for Reader
18:17 <__rgn> http://ix.io/pPy
18:17 <__rgn> i need to somehow squeeze the b out of (Reader r b)
18:17 <__rgn> i thought about `join`
18:18 <__rgn> join :: Monad m => m (m a) -> m a
18:19 chlong joined
18:23 iAmerikan joined
18:24 Ferdirand joined
18:26 <__rgn> .. looks like join works after all, must have used it incorrectly first
18:26 <geekosaur> hm. the problem with using join is that join is defined in terms of (>>=)
18:26 <__rgn> yes
18:27 <__rgn> was just thinking about that
18:28 <__rgn> i did (Reader ra) >>= f = (Reader $ \r -> f (ra r)) >>= id
18:28 conal joined
18:28 <Akii> instread of pattern matching there is another way of extracting the function out of a Reader
18:29 <Akii> -r O.o
18:32 Rodya_ joined
18:33 hoffmeyer joined
18:34 t0by joined
18:34 t0by joined
18:34 <__rgn> which is that
18:35 <Akii> http://lpaste.net/354369
18:35 <Akii> Line 2
18:35 <Akii> :t runReader
18:35 <lambdabot> Reader r a -> r -> a
18:36 <__rgn> i should first implement that function myself i guess
18:36 <Akii> which one
18:36 <__rgn> runReader
18:37 <Akii> that function is created with the data type
18:37 <__rgn> oh
18:37 <Akii> data Foo = Foo { bar :: Int } will generate a function bar :: Foo -> Int
18:38 <__rgn> right so it's like accessor or something
18:38 mac10688 joined
18:38 <Akii> yup
18:39 iAmerikan joined
18:39 <Akii> if you use my snipped you get a nice output of variables you've at your disposal as well as their types
18:39 <Akii> I feel like you have all you need now :D
18:40 <Akii> snippet* dang
18:41 MotherFlojo joined
18:42 patbecich joined
18:42 <__rgn> thanks Akii
18:43 <Akii> you're welcome
18:44 <Akii> also added the manual way of implementing runReader
18:44 <Akii> but that just uses pattern matching
18:44 govg joined
18:48 merijn joined
18:49 peterbecich joined
18:50 teppic joined
18:52 mac10688 joined
18:53 uglyfigurine joined
18:54 iAmerikan joined
19:01 peterbec` joined
19:02 abhiroop joined
19:09 Zialus joined
19:10 mengu joined
19:13 nick_h joined
19:16 darthdeus left
19:17 dni- joined
19:19 mac10688 joined
19:24 abhiroop joined
19:27 colt44 joined
19:29 Rodya_ joined
19:30 albertus1 joined
19:31 albertus1 joined
19:37 exferenceBot joined
19:41 exferenceBot joined
19:43 Rodya_ joined
19:43 exferenceBot joined
19:44 exferenceBot joined
19:46 sherub1 joined
19:46 mattyw_ joined
19:46 exferenceBot joined
19:52 Zialus joined
19:55 takle joined
20:06 exferenceBot joined
20:08 exferenceBot joined
20:08 takle joined
20:09 exferenceBot joined
20:09 takle joined
20:10 exferenceBot joined
20:10 ralu joined
20:18 exferenceBot joined
20:19 iAmerikan joined
20:23 Deide joined
20:23 exferenceBot joined
20:25 eacameron joined
20:25 exferenceBot joined
20:25 exferenceBot joined
20:26 iAmerikan joined
20:27 exferenceBot joined
20:31 exferenceBot joined
20:32 peterbecich joined
20:34 exferenceBot joined
20:41 <jle`> __rgn: that implementation is a bit problematic because you're implementing >>= in terms of >>=
20:44 <monochrom> :)
20:45 g1l joined
20:46 <g1l> hi/ciao
20:52 malaclyps joined
20:52 DataComputist joined
20:53 malaclyps joined
20:55 peterbec` joined
21:02 Ferdirand joined
21:11 chlong joined
21:17 govg joined
21:23 louispan joined
21:34 Ferdirand joined
21:36 louispan joined
21:43 govg joined
21:46 freechips joined
21:52 lithie joined
21:52 hiratara joined
21:59 govg joined
22:01 peterbec` joined
22:05 Ferdirand joined
22:05 gpampara joined
22:06 malaclyps joined
22:11 uglyfigurine joined
22:28 leothrix joined
22:31 hiratara joined
22:31 zero_byte joined
22:47 louispan joined
22:49 conal joined
22:55 ego joined
22:56 Robin_Jadoul joined
22:57 conal joined
23:03 peterbec` joined
23:07 myrkraverk joined
23:08 peterbecich joined
23:08 louispan joined
23:15 aarvar joined
23:26 contiver joined
23:43 dni- joined
23:43 aarvar joined
23:44 cschneid_ joined
23:49 mk1 joined
23:59 eacameron joined