<     May 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 31
00:06 modlin joined
00:21 hphuoc25 joined
00:26 mizu_no_oto_work joined
00:31 shayan_ joined
00:32 FoxM joined
00:34 mizu_no_oto_work joined
00:35 hiratara joined
00:40 Durbley joined
00:47 dni- joined
00:51 hiratara joined
00:52 louispan joined
01:03 louispan joined
01:42 irclogger_com joined
01:42 Topic for
01:51 conal joined
02:06 systemfault joined
02:09 ali_bush joined
02:09 ali_bush joined
02:13 conal joined
02:14 ExpHP joined
02:20 hel-io joined
02:22 hphuoc25 joined
02:33 modlin joined
02:35 exferenceBot joined
02:36 dni- joined
02:40 hexagoxel joined
02:50 shayan_ joined
02:53 takle joined
02:56 mizu_no_oto_work joined
03:01 lukesp joined
03:11 takle joined
03:13 Pupnik_ joined
03:19 takle joined
03:21 louispan joined
03:21 lukesp joined
03:56 moei joined
03:58 mizu_no_oto_work joined
04:00 gspia joined
04:04 takle joined
04:05 geekosaur joined
04:06 hazyPurple joined
04:11 takle joined
04:18 takle joined
04:23 hphuoc25 joined
04:24 crave_ joined
04:25 dni- joined
04:25 malaclyps joined
04:26 systemhalted joined
04:37 takle joined
04:38 shawn_lu joined
04:38 hazyPurple joined
04:45 aqualogic joined
04:54 takle joined
04:56 prophile joined
04:58 geekosaur joined
05:11 conal joined
05:12 takle joined
05:18 ebw joined
05:19 louispan joined
05:31 takle joined
05:33 ebw joined
05:42 takle joined
05:56 conal joined
05:57 shawn_lu left
05:57 cschneid_ joined
05:59 Pupnik joined
06:00 takle joined
06:07 geekosaur joined
06:07 takle joined
06:11 shawn_lu joined
06:13 dni- joined
06:24 hphuoc25 joined
06:27 fluffystub joined
06:42 nickolay joined
06:48 nobodyzxc joined
06:51 takle joined
06:54 Hjulle joined
07:10 takle joined
07:12 pbrant joined
07:17 takle joined
07:40 fluffystub joined
07:40 haskelleksah joined
08:03 dni- joined
08:13 louispan joined
08:22 hazyPurple joined
08:25 hphuoc25 joined
08:27 Kuros` joined
08:34 takle joined
08:39 pranitbauva1997 joined
08:40 albertus1 joined
08:49 yellowj joined
08:50 takle joined
08:50 Gurkenglas joined
09:07 Levex joined
09:15 thc202 joined
09:18 Pupnik_ joined
09:22 hazyPurple joined
09:25 dni- joined
09:26 moei joined
09:27 Levex joined
09:28 Durz0 joined
09:40 fotonzade joined
09:55 zero_byte joined
10:08 netheranthem joined
10:08 takle joined
10:18 govg joined
10:19 delexi joined
10:23 Pupnik joined
10:25 kritzcreek joined
10:26 hphuoc25 joined
10:35 reptar_ joined
10:37 Levex joined
10:41 geekosaur joined
10:46 hazyPurple joined
10:50 mizu_no_oto_work joined
11:01 hrnz joined
11:02 trolling joined
11:06 Gloomy joined
11:07 prophile joined
11:16 hrnz joined
11:19 modlin joined
11:21 hazyPurple joined
11:22 conal joined
11:28 hphuoc25 joined
11:37 reptar_ joined
12:02 contiver joined
12:07 eacameron joined
12:14 Gloomy joined
12:16 binaryplease joined
12:29 hrnz joined
12:47 geekosaur joined
13:00 wildlander joined
13:07 malaclyps joined
13:08 hazyPurple joined
13:09 ralu joined
13:12 reptar_ joined
13:20 pilne joined
13:26 bydo joined
13:29 hphuoc25 joined
13:38 eacameron joined
13:48 crave joined
14:05 modlin joined
14:22 shainer_ joined
14:30 Gloomy joined
14:44 contiver joined
14:45 modlin joined
14:53 yellowj joined
15:00 lfish joined
15:01 pixelfog_ joined
15:02 <lfish> hello, I was doing some exercises with Enum typeclass and noticed it doesn't require Eq... how do you implement enumFromTo without Eq or Ord?
15:03 binaryplease joined
15:05 <glguy> lfish: it's a method is the type class, so it knows all about the type
15:07 deank joined
15:07 <glguy> when you're writing an Enum instance for some type that implements Eq you can use ==
15:08 efm joined
15:09 <lfish> glguy: yes, my question was how do you know when to stop enumerating if you're implementing Enum for a type that doesn't implement Eq, or Ord
15:11 <lfish> I've just realized enumFromTo isn't a required for the minimal implementation, could it be because of that?
15:14 efm joined
15:19 <glguy> if your type doesn't support Eq or Ord you'd use some other functions to decide when to stop
15:19 <glguy> when you stop just depends on the particular type you're making an instance for
15:26 <lfish> that's totally it, thank you! I was just using types with obvious comparisons and I didn't think of that
15:30 hphuoc25 joined
15:37 Deide joined
15:38 delexi joined
16:00 mstruebing joined
16:03 t_feynman joined
16:05 acarrico joined
16:08 Tene joined
16:13 meandi_2 joined
16:19 shawn_lu joined
16:20 <shawn_lu> Hi friends, got a quesetion regarding GHC, If I do this it will work $ stack ghc -- -prof -fprof-auto -rtsopts -O2 profile.hs, but not this: $ stack ghc -- -02 profile.hs, the error message is ghc: unrecognised flag: -02
16:21 <geekosaur> did you notice the difference between -O and -0?
16:21 <shawn_lu> good point
16:21 <shawn_lu> good point
16:22 <shawn_lu> thx
16:24 Lowl3v3l joined
16:30 texasmynsted joined
16:31 davs joined
16:33 Gloomy joined
16:40 malaclyps joined
16:41 takle joined
16:48 Uniaika joined
16:50 takle joined
16:54 Uniaika joined
17:07 <nickolay> question about spreading the "let" statement across several lines: http://lpaste.net/355295
17:08 <nickolay> I'm a bit puzzled, because in one place in my code I have "let" statement formatted as in the top part of the paste
17:08 <nickolay> "let" and "in" on separate lines
17:08 <nickolay> and it is accepted by the compiler fine
17:08 <nickolay> but when I'm trying to use the same style in other place - it fails with syntax error, how so?
17:09 <geekosaur> explicit semicolons are not a good idea if you're not disabling layout completely
17:09 <geekosaur> ; is not a terminator, it is a separator. so the one at the end of the binding for index told it to expect another binding, but it saw "in" instead
17:09 <nickolay> I'm not (don't know how actually), semicolons were just experiment
17:10 davs_ joined
17:10 <geekosaur> and wen using layout, line endings act like semicolons, which can lead to other oddnesses
17:10 <nickolay> same error w/o semicolons
17:10 <geekosaur> (but contextually, they depend on what follows)
17:10 <geekosaur> that said, you are doing this inside a do, so the in is incorrectly indented
17:11 <geekosaur> it needs to be indented beyond the start of the "let", otherwise it *terminates* the "let" according to the layout established for the outer "do"
17:12 <geekosaur> it's also unnecessary since "let" inside "do" can insert its own "in"
17:12 davs joined
17:12 <nickolay> intending "in" further fixed that.. but I don't get it still..
17:13 <nickolay> I guess its related to outer "do" as you mentioned
17:13 <geekosaur> because it was at the indentation level of the preceding "do" lines (segments, mbParentDomNode) it ended the "let"
17:13 <geekosaur> so now it's trying to be syntax valid inside "do", and "in" isn't valid there
17:13 <nickolay> ah..
17:15 <nickolay> ok, I guess the rule will be to not use "in" for "let" statements inside "do" :)
17:15 <nickolay> geekosaur: thanks for the help!
17:15 <geekosaur> it's implicit anyway, when you write it the way you did an "in" gets inserted for you
17:16 mizu_no_oto_work joined
17:17 <geekosaur> layout is described here https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-210002.7
17:17 <geekosaur> it's a fairly mechanical (and dumb, which is why you sometimes need to be careful with semicolons) translation
17:20 crave_ joined
17:20 systemfault joined
17:23 crave_ joined
17:24 davs joined
17:27 romank joined
17:27 crave_ joined
17:30 NeverDie joined
17:31 hphuoc25 joined
17:32 crave_ joined
17:33 <nickolay> geekosaur: I see, thanks
17:37 rfvizarra joined
17:41 Mutter joined
17:44 crave_ joined
17:45 davs joined
17:50 madjestic joined
17:51 crave_ joined
17:51 romank joined
17:52 shayan_ joined
17:56 crave_ joined
17:58 <madjestic> hey guys, is there a good example of a 'key being pressed', using Yampa and SDL2?
17:58 <madjestic> (a fairly recent example)
18:00 crave_ joined
18:05 crave_ joined
18:09 crave_ joined
18:12 zero_byte joined
18:12 crave_ joined
18:15 romank joined
18:17 crave_ joined
18:20 romank joined
18:22 crave_ joined
18:23 govg joined
18:24 davs joined
18:26 crave_ joined
18:30 crave_ joined
18:31 mengu joined
18:35 crave_ joined
18:39 crave_ joined
18:41 davs joined
18:43 crave_ joined
18:45 Uniaika joined
18:47 NeverDie joined
18:48 crave_ joined
18:53 fotonzade joined
18:54 <fotonzade> vin-ivar,
18:54 <fotonzade> wrong channel
18:58 malaclyps joined
19:04 Uniaika joined
19:19 davs joined
19:20 haskelleksah joined
19:21 acarrico joined
19:30 ralu joined
19:32 hphuoc25 joined
19:34 ebw joined
19:42 tshelburne joined
19:43 davs joined
19:53 <tshelburne> Hi all, new to stack - is there a way to look up which resolver I should use based on a version of a package (in this case, base >= 4.7 && < 4.8)?
19:53 Levex joined
19:54 <tshelburne> Everything seems top-down from the resolver, which is useful until you have an old package with specific requirements
19:56 <MarcelineVQ> good question, for base there's a straightforward way but other than slogging through an lts diff or something https://www.stackage.org/diff/lts-6.30/lts-6.31 I'm not sure for other packages
19:57 ebw joined
19:57 <MarcelineVQ> for base you can look up the ghc version that coprresponds to your base https://wiki.haskell.org/Base_package and then click the 'latest lets per ghc version' here https://www.stackage.org/
19:59 <tshelburne> That's a very useful page. The stack approach is cool, but a bit intimidating when coming from something like npm or bundler.
19:59 <tshelburne> Thanks for the help!
19:59 <geekosaur> shouldn't stack init do that? maybe with --solver
20:00 <tshelburne> this is in an existing project - is there a way to have the CLI auto-solve the problem while ignoring existing installations?
20:00 <tshelburne> because that would be waaay more useful
20:01 <MarcelineVQ> geekosaur's suggestion is appropriate for that problem
20:02 <tshelburne> ok, so that i'm 100% here - in an existing project with active packages, run `stack init --solver` to override the previous setup?
20:03 <MarcelineVQ> hmm that depends on the previous steup. a project with a cabal file and without a stack.yaml can be given an appropriate yaml with stack init --solver
20:04 <geekosaur> copy the old stack.yaml out of the way, stack init --solver, compare the result to the original as necessary, perhaps
20:04 <tshelburne> it looks like if you run `stack init --solver --force`, it will attempt it for you
20:08 <tshelburne> ok, it chokes a bit when you have packages in cabal that will have to be extra deps, but this gets it much closer
20:08 <tshelburne> thanks again!
20:22 eacameron joined
20:56 ubsan joined
21:05 modlin joined
21:18 pixelfog_ joined
21:20 mizu_no_oto_work joined
21:22 mizu_no__ joined
21:23 eacameron joined
21:25 aqualogic joined
21:26 cur8or joined
21:33 hphuoc25 joined
21:50 modlin joined
21:52 hiratara joined
22:00 yellowj joined
22:03 eacameron joined
22:11 efm__ joined
22:11 Quintasan joined
22:11 Quintasan joined
22:12 efm__ joined
22:15 foton joined
22:21 karce- joined
22:21 thang1_ joined
22:21 Sornaensis_ joined
22:21 Majoo joined
22:21 aarvar joined
22:21 efm__ joined
22:22 eacameron joined
22:22 govg joined
22:23 Elsi joined
22:23 gpolitis joined
22:23 mniip joined
22:33 cschneid_ joined
22:35 Kuros` joined
22:40 sudoreboot[m] joined
22:42 modlin joined
22:42 majoh joined
22:42 pixelfog_ joined
22:42 hrnz joined
22:42 ego joined
22:42 mbrcknl joined
22:42 Cir0X joined
22:42 redcedar joined
22:42 dmj` joined
22:42 Nikotiini joined
22:42 CARAM__ joined
22:43 dmj` joined
22:45 CARAM__ joined
22:45 sivs joined
22:46 texasmynsted joined
22:48 cschneid_ joined
22:48 jle` joined
22:48 jle` joined
22:53 eacameron joined
22:55 shayan_ joined
22:57 viralstitch joined
22:58 eacameron joined
23:00 cschneid_ joined
23:05 dni- joined
23:09 eacameron joined
23:13 Levex joined
23:15 acarrico joined
23:22 eacameron joined
23:23 mizu_no_oto_work joined
23:27 eacameron joined
23:34 hphuoc25 joined
23:36 bobbytables joined
23:42 louispan joined