Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 .. 5022
— 502,152 events total
2020-11-02 18:25:37 × alp quits (~alp@2a01:e0a:58b:4920:ad5c:a549:2a77:a525) (Ping timeout: 260 seconds)
2020-11-02 18:25:50 <monochrom> And academically we have found that anyChar needs Selective only, not full monadic.
2020-11-02 18:26:06 <monochrom> Err sorry! s/anyChar/satisfy/
2020-11-02 18:26:14 <davean> dminuoso: so saying they can't isn't quite true
2020-11-02 18:26:27 <davean> dminuoso: Saying there are grammers they can't for is true, but thats kinda always true in a way.
2020-11-02 18:26:41 <davean> Also not really relivent to most parsers
2020-11-02 18:26:51 <daydaynatation> in a type class method, if i write aMethod:: (Random a, V.Unbox a) => ... does it mean a needs to by both Random and V.Unbox ? Or a needs to be one Or the other
2020-11-02 18:27:07 <davean> Both
2020-11-02 18:27:10 <monochrom> Oh sorry again, haha, full CFG still needs unlimited lookahead. LL(k) are the restricted ones that can be done in fixed lookahead.
2020-11-02 18:27:19 <davean> For all a such that a is in Random and in Unbox ...
2020-11-02 18:27:29 → minus[m] joins (minusblobc@gateway/shell/matrix.org/x-hhdwstlyzyfgkvud)
2020-11-02 18:27:41 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-11-02 18:27:47 <daydaynatation> ok
2020-11-02 18:27:48 <monochrom> But yeah we really design our grammars to be LL(k), even LL(1), don't we.
2020-11-02 18:28:01 <davean> monochrom: VERY much so, and on purpose conciously.
2020-11-02 18:28:07 × dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 260 seconds)
2020-11-02 18:28:29 <monochrom> So yeah most parsers don't even need full-on Applicative. Also, I mean s/Applicative/Alternative/
2020-11-02 18:29:12 <monochrom> Gosh does IRC allow me to edit past messages? :)
2020-11-02 18:29:29 <davean> monochrom: No, IRC makes you life with your decisions.
2020-11-02 18:29:39 × ransom quits (~c4264035@c-73-243-2-10.hsd1.co.comcast.net) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-11-02 18:29:47 × conal quits (~conal@198.8.81.68) (Quit: Computer has gone to sleep.)
2020-11-02 18:29:53 <davean> IRC promotes honesty and transparency
2020-11-02 18:29:57 <davean> not lies and deception.
2020-11-02 18:30:54 <dminuoso> davean: fair enough
2020-11-02 18:32:04 × justanotheruser quits (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 268 seconds)
2020-11-02 18:32:05 → conal joins (~conal@198.8.81.68)
2020-11-02 18:32:13 → geekosaur joins (82659a09@host154-009.vpn.uakron.edu)
2020-11-02 18:32:20 <davean> dminuoso: we have Applicative => Monad and Applicative Do
2020-11-02 18:32:23 <davean> dminuoso: etc
2020-11-02 18:32:25 <dminuoso> davean: I mean in principle you could do automatic lookahead inside combinators as far as possible, not quite sure what the runtime penalty is
2020-11-02 18:32:44 × rzmt quits (~rzmt@87-92-180-112.rev.dnainternet.fi) (Ping timeout: 240 seconds)
2020-11-02 18:33:00 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 18:33:02 <davean> Honestly no one tries to write high performance parsers in Haskell because the basics are usually fast enough - look at aeson, its dog slow and no one seems to care.
2020-11-02 18:33:30 <dminuoso> The package description says its "high performance"!
2020-11-02 18:33:34 <davean> The only person maintaining a faster version just abandoned theirs
2020-11-02 18:33:38 <davean> dminuoso: Many people lie.
2020-11-02 18:33:43 <dminuoso> davean: Also, https://github.com/J-mie6/ParsleyHaskell
2020-11-02 18:34:01 <davean> We have Haskell JSON parsers far faster than aeson.
2020-11-02 18:34:02 <dminuoso> So someone is trying to write optimizing high performance parser combinators.
2020-11-02 18:34:04 <dminuoso> :)
2020-11-02 18:34:34 → brisbin joins (~patrick@pool-173-49-158-4.phlapa.fios.verizon.net)
2020-11-02 18:34:36 × mnrmnaugh quits (~mnrmnaugh@unaffiliated/mnrmnaugh) (Quit: Leaving)
2020-11-02 18:35:02 → rzmt joins (~rzmt@87-92-180-112.rev.dnainternet.fi)
2020-11-02 18:35:39 → mnrmnaugh joins (~mnrmnaugh@unaffiliated/mnrmnaugh)
2020-11-02 18:36:10 <dminuoso> davean: But yeah, the example of aeson is pretty good, I notice this in my day job time after time
2020-11-02 18:36:16 <dminuoso> How performance if often not important.
2020-11-02 18:36:32 <tomsmeding> the question is, do we have a json parser library that 1. parses more quickly, and 2. compiles more quickly?
2020-11-02 18:36:41 × cosimone quits (~cosimone@2001:b07:ae5:db26:9217:95c7:973d:d0ad) (Quit: cosimone)
2020-11-02 18:36:46 <dminuoso> We have one project where latency is key, but generally we couldn't care less if aeson takes 5ms to parse some incoming request or not.
2020-11-02 18:37:02 × idhugo quits (~idhugo@80-62-116-101-mobile.dk.customer.tdc.net) (Ping timeout: 256 seconds)
2020-11-02 18:37:03 <dminuoso> tomsmeding: haha, aeson is not good on either metric
2020-11-02 18:37:13 <davean> Right. I know people who DID do high performance JSON stuff in Haskell, etc
2020-11-02 18:37:13 <tomsmeding> my point :p
2020-11-02 18:37:20 <davean> and like they have a ring buffer between cores, etc
2020-11-02 18:37:25 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 240 seconds)
2020-11-02 18:37:27 <davean> and you can do all this in Haskell.
2020-11-02 18:37:37 → christo joins (~chris@81.96.113.213)
2020-11-02 18:37:39 <davean> No one even switches which JSON parsing package they use to get a reasonable one ususally though.
2020-11-02 18:38:10 <dminuoso> Plus, if performance was so critical, I wouldn't touch JSON with a 3.048m pole to begin with
2020-11-02 18:38:13 <davean> tomsmeding: Hum, I think we have ones that are faster in both actually, I'd have to double check, I don't pay attention to compile times because they're so not important but I THINK it does.
2020-11-02 18:38:19 <dminuoso> CBOR would be a far better candidate
2020-11-02 18:38:51 × kritzefitz quits (~kritzefit@212.86.56.80) (Ping timeout: 268 seconds)
2020-11-02 18:39:04 <dminuoso> My only annoyance with aeson is that its interface is bad and typeclass heavy
2020-11-02 18:39:14 → hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net)
2020-11-02 18:39:15 <davean> Honestly I do mind the performance.
2020-11-02 18:39:32 <daydaynatation> is IO action lazy by default? If so how can i force it to be strict?
2020-11-02 18:39:38 <dminuoso> daydaynatation: yes and no
2020-11-02 18:39:43 <tomsmeding> davean: compile times are in nigh-all cases less important than runtime performance, but damn they are annoying :p
2020-11-02 18:39:47 <davean> But thats because the more requests per core per second I can handle the less scaling overhead I get
2020-11-02 18:39:55 <dminuoso> daydaynatation: So Haskell is non-strict in *values*, that is the computatoin of `IO ()` itself can be lazy
2020-11-02 18:40:02 <dminuoso> But the action itself is (in general) strict
2020-11-02 18:40:08 <dminuoso> There are things like lazy IO, which are terrible
2020-11-02 18:40:56 <davean> What the IO action *does* is generally not lazy, how the IO action *gets defined* is non-strict.
2020-11-02 18:41:01 × conal quits (~conal@198.8.81.68) (Quit: Computer has gone to sleep.)
2020-11-02 18:41:09 <daydaynatation> i'm time an action with time :: IO a -> IO a which wraps an anction between CPUTimes
2020-11-02 18:41:31 <daydaynatation> the reuslts doesn't look right, so i'm guessing it could be related to laziness
2020-11-02 18:41:56 <dminuoso> daydaynatation: can you share the code and results?
2020-11-02 18:42:06 <dminuoso> That might be easier than to work with some vague description
2020-11-02 18:42:29 <davean> daydaynatation: Though thats most likely not related to laziness
2020-11-02 18:42:41 <davean> daydaynatation: Why doesn't it look right?
2020-11-02 18:42:45 <daydaynatation> dminuoso: which paste site should I use?
2020-11-02 18:42:48 × jakob_ quits (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de) (Quit: My Laptop has gone to sleep. ZZZzzz…)
2020-11-02 18:43:11 → jakob_ joins (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de)
2020-11-02 18:43:21 × refried_ quits (~textual@pool-108-20-26-90.bstnma.fios.verizon.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…)
2020-11-02 18:43:22 <geekosaur> @where paste
2020-11-02 18:43:22 <lambdabot> Help us help you: please paste full code, input and/or output at eg https://paste.tomsmeding.com
2020-11-02 18:43:34 × jakob_ quits (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de) (Client Quit)
2020-11-02 18:43:58 → jakob_ joins (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de)
2020-11-02 18:44:18 → conal joins (~conal@198.8.81.68)
2020-11-02 18:44:21 × jakob_ quits (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de) (Client Quit)
2020-11-02 18:44:30 × conal quits (~conal@198.8.81.68) (Client Quit)
2020-11-02 18:44:44 <daydaynatation>
2020-11-02 18:44:44 <daydaynatation> https://paste.tomsmeding.com/qgA1JMgU
2020-11-02 18:44:50 → jakob_ joins (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de)
2020-11-02 18:45:07 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 18:45:08 × jakob_ quits (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de) (Client Quit)
2020-11-02 18:45:22 → refried_ joins (~textual@pool-108-20-26-90.bstnma.fios.verizon.net)
2020-11-02 18:45:28 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2020-11-02 18:45:30 → jakob_ joins (~textual@p200300f49f162200f40f209088e2d2f9.dip0.t-ipconnect.de)
2020-11-02 18:45:39 <daydaynatation> result is here: https://paste.tomsmeding.com/hyrFyOzz
←Prev  Next→
Page 1 .. 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 .. 5022

All times are in UTC.