Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→
Page 1 .. 369 370 371 372 373 374 375 376 377 378 379 .. 17995
— 1,799,406 events total
2021-06-09 18:37:56 → Bartosz joins (~textual@24.35.90.211)
2021-06-09 18:38:01 <tomsmeding> wonder how that happens
2021-06-09 18:38:37 → Deide joins (~Deide@wire.desu.ga)
2021-06-09 18:38:37 × Deide quits (~Deide@wire.desu.ga) (Changing host)
2021-06-09 18:38:37 → Deide joins (~Deide@user/deide)
2021-06-09 18:41:44 × Bartosz quits (~textual@24.35.90.211) (Client Quit)
2021-06-09 18:42:23 → Bartosz joins (~textual@24.35.90.211)
2021-06-09 18:43:39 → pgib joins (~textual@173.38.117.92)
2021-06-09 18:43:58 → jco joins (~jco@c83-248-173-38.bredband.tele2.se)
2021-06-09 18:44:00 × knu quits (~knu@mue-88-130-62-022.dsl.tropolys.de) (Quit: Connection closed)
2021-06-09 18:44:45 × MQ-17J quits (~MQ-17J@8.21.10.116) (Ping timeout: 252 seconds)
2021-06-09 18:45:03 → MQ-17J joins (~MQ-17J@8.21.10.116)
2021-06-09 18:45:20 <zzz> can i have an IntMap where the keys are newtype T = T Int ?]
2021-06-09 18:45:32 → beka joins (~beka@104.193.170-254.PUBLIC.monkeybrains.net)
2021-06-09 18:46:08 <xerox> zzz: I use this for that purpose https://github.com/minoki/unboxing-vector
2021-06-09 18:47:09 <xerox> (it's not exactly what you asked for if the container being a Map matters more than it being indexed with a newtype transparently)
2021-06-09 18:47:17 <jco> Hello, I'm fooling around a bit with trying to convert .edn to .json. Is there a better way to handle the possibility of error when loading a file, than what I do here: http://ix.io/3pnN? I created a `ExceptT` type alias there, to be able to just `throwError` if anything goes wrong.
2021-06-09 18:50:06 <zzz> xerox: thanks im taking a look. however i really just wanted a newtype indexed IntMap
2021-06-09 18:51:19 × MQ-17J quits (~MQ-17J@8.21.10.116) (Ping timeout: 244 seconds)
2021-06-09 18:51:36 → MQ-17J joins (~MQ-17J@8.21.10.116)
2021-06-09 18:52:02 <lyxia> jco: you could throw the exception in IO
2021-06-09 18:57:01 × zeenk quits (~zeenk@2a02:2f04:a310:b600:b098:bf18:df4d:4c41) (Quit: Konversation terminated!)
2021-06-09 18:57:50 <jco> lyxia: OK, makes it bit simpler yes.
2021-06-09 19:00:33 → v01d4lph4 joins (~v01d4lph4@122.160.65.250)
2021-06-09 19:00:33 × v01d4lph4 quits (~v01d4lph4@122.160.65.250) (Changing host)
2021-06-09 19:00:33 → v01d4lph4 joins (~v01d4lph4@user/v01d4lph4)
2021-06-09 19:01:37 <dminuoso> tomsmeding: I cant help but wonder whether ^ is meaningful to delYsid.
2021-06-09 19:01:53 ← Izem parts (~Izem@bras-base-london1483w-grc-38-65-95-41-91.dsl.bell.ca) ()
2021-06-09 19:02:16 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2021-06-09 19:03:02 <tomsmeding> dminuoso: I wondered that too after sending the message
2021-06-09 19:04:12 → lavaman joins (~lavaman@98.38.249.169)
2021-06-09 19:05:06 × v01d4lph4 quits (~v01d4lph4@user/v01d4lph4) (Ping timeout: 252 seconds)
2021-06-09 19:05:28 × Erutuon quits (~Erutuon@user/erutuon) (Ping timeout: 268 seconds)
2021-06-09 19:05:50 <jco> OK, another question, more related to how to avoid pyramids of doom when doing error handling: http://ix.io/3pnX. There's a better way to write that, right?
2021-06-09 19:08:28 <lyxia> Re the haddock tooltips issue, it's a known issue https://github.com/haskell/haddock/issues/1250
2021-06-09 19:15:14 × Bartosz quits (~textual@24.35.90.211) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-06-09 19:15:51 → danso joins (~danso@modemcable156.91-20-96.mc.videotron.ca)
2021-06-09 19:18:58 × danso quits (~danso@modemcable156.91-20-96.mc.videotron.ca) (Read error: Connection reset by peer)
2021-06-09 19:18:59 → dan-so joins (~danso@modemcable156.91-20-96.mc.videotron.ca)
2021-06-09 19:19:52 → tromp joins (~textual@dhcp-077-249-230-040.chello.nl)
2021-06-09 19:23:00 → wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-06-09 19:23:33 → gehmehgeh_ joins (~user@user/gehmehgeh)
2021-06-09 19:24:05 × gehmehgeh quits (~user@user/gehmehgeh) (Remote host closed the connection)
2021-06-09 19:29:08 × ramon quits (~ramon@user/ramon) (Ping timeout: 264 seconds)
2021-06-09 19:29:44 → jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net)
2021-06-09 19:30:04 → infandum joins (~user@207.44.105.67.res-cmts.all2.ptd.net)
2021-06-09 19:31:02 <infandum> I have converted my program to use optparse-applicative. Upon testing, I noticed I accidentally had "option auto" instead of "option str" (or strOption). Yet this bypassed the compilier. Is there a way to type-check this bug?
2021-06-09 19:31:58 × jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Client Quit)
2021-06-09 19:32:10 <infandum> (there are many, many options and will take a while to test them all)
2021-06-09 19:32:44 × tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2021-06-09 19:33:07 <dminuoso> infandum: By the way, did you get my message regarding optparse-generic?
2021-06-09 19:34:00 <dminuoso> infandum: And no, there's no easy way.
2021-06-09 19:34:48 <dminuoso> I'd just avoid `option auto` to begin with, Read is not what you'd likely want
2021-06-09 19:36:32 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds)
2021-06-09 19:39:23 → tromp joins (~textual@dhcp-077-249-230-040.chello.nl)
2021-06-09 19:41:12 <dminuoso> Recall, that deriving generated Show is supposed to generate syntactically correct Haskell expressions that correspond to the value, and Read that would parse those back into values.
2021-06-09 19:43:16 × hiruji quits (~hiruji@user/hiruji) (Ping timeout: 272 seconds)
2021-06-09 19:45:40 → pretty_dumm_guy joins (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2021-06-09 19:46:38 <xerox> anybody else getting ghcid stuck after the first try, no reload, after upgrading to 8.10.5?
2021-06-09 19:47:18 <xerox> not even printing the "All good."
2021-06-09 19:47:34 <jco> OK, found the answer to my own question. Pyramid of doom avoided with the help of `hoistEither` from the `errors` library. I like it: http://ix.io/3pob.
2021-06-09 19:49:51 → notzmv joins (~zmv@user/notzmv)
2021-06-09 19:49:53 × chexum quits (~chexum@gateway/tor-sasl/chexum) (Remote host closed the connection)
2021-06-09 19:51:05 <infandum> dminuoso: I did (after I just resigned on), but it expired because I took too long. However, I just converted over to optparse-applicative as I could not figure it out and there seemed to be more features with optparse-applicative (but more boilerplate as well).
2021-06-09 19:51:38 <dminuoso> infandum: https://gist.github.com/dminuoso/d68598ffb112cbe61c3759a530e2d837
2021-06-09 19:52:01 <dminuoso> You can use use both together
2021-06-09 19:52:44 → kritzefitz_ joins (~kritzefit@picard.host.weltraumschlangen.de)
2021-06-09 19:52:57 × maerwald quits (~maerwald@user/maerwald) (Ping timeout: 268 seconds)
2021-06-09 19:53:03 × aerona quits (~aerona@2600:6c54:4600:f300:8401:a988:a361:a685) (Quit: Leaving)
2021-06-09 19:54:06 × kritzefitz quits (~kritzefit@picard.host.weltraumschlangen.de) (Ping timeout: 265 seconds)
2021-06-09 19:54:06 kritzefitz_ is now known as kritzefitz
2021-06-09 19:54:23 <ski> @type maybe empty pure
2021-06-09 19:54:24 <lambdabot> Alternative f => Maybe a -> f a
2021-06-09 19:54:25 <ski> @type maybe mzero return
2021-06-09 19:54:26 <lambdabot> MonadPlus m => Maybe a -> m a
2021-06-09 19:54:28 <ski> @type either throwError return
2021-06-09 19:54:28 <lambdabot> MonadError e m => Either e a -> m a
2021-06-09 19:54:51 <infandum> dminuoso: I see, the instances were what I was missing
2021-06-09 19:55:01 <infandum> You should submit that to optparse-generic documentation
2021-06-09 19:55:34 <dminuoso> infandum: The trick is also the newtype wrapper. At that point you might as well submit the code itself.
2021-06-09 19:55:46 → chexum joins (~chexum@gateway/tor-sasl/chexum)
2021-06-09 19:57:43 × jneira quits (~jneira@166.red-81-39-172.dynamicip.rima-tde.net) (Quit: Connection closed)
2021-06-09 19:59:27 → maerwald joins (~maerwald@mail.hasufell.de)
2021-06-09 19:59:42 × dhouthoo_ quits (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.1)
2021-06-09 20:00:07 × tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2021-06-09 20:00:08 <infandum> dminuoso: You seem very knowledgeable on this -- is it possible to have the same option name have different help text (and even type) in different entrypoints in optparse-generic? It's possible in optparse-applicative it seems but not in optparse-generic.
2021-06-09 20:00:36 × maerwald quits (~maerwald@mail.hasufell.de) (Changing host)
2021-06-09 20:00:36 → maerwald joins (~maerwald@user/maerwald)
2021-06-09 20:00:46 <dminuoso> Why shouldn't it be possible?
2021-06-09 20:00:55 → Erutuon joins (~Erutuon@user/erutuon)
2021-06-09 20:00:58 <infandum> like: command subcommand1 --arg string and command subcommand2 --arg int?
2021-06-09 20:01:04 × AgentM quits (~agentm@pool-162-83-130-212.nycmny.fios.verizon.net) (Quit: Leaving.)
2021-06-09 20:01:08 × _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection)
2021-06-09 20:01:12 <dminuoso> I don't see a reason why it wouldn't work.
2021-06-09 20:01:21 <infandum> Because the compiler states that within the same record there are two different definitions
2021-06-09 20:01:26 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) (Remote host closed the connection)
2021-06-09 20:01:34 <infandum> or, between the two
2021-06-09 20:01:37 <dminuoso> Ah I see. Use my Nested newtype wrapper to help out.
2021-06-09 20:02:23 <dminuoso> You'd create a separate data type for each command, call it `data RC1 = RC1 { arg :: Int <?> "fancy number" }` and `data RC2 = RC2 { arg :: String <?> "fancy string" }`
2021-06-09 20:02:40 <dminuoso> With OverloadedRecordFields enabled, these could even reside in the same module
←Prev  Next→
Page 1 .. 369 370 371 372 373 374 375 376 377 378 379 .. 17995

All times are in UTC.