| 2021-07-25 00:00:37 +0200 | <maerwald> | well, there was great drama around it, so my impression was CLC acted more out of pressure there |
| 2021-07-25 00:00:41 +0200 | <geekosaur> | that said davean has me wondering how correct it is |
| 2021-07-25 00:00:54 +0200 | <davean> | maerwald: oh? |
| 2021-07-25 00:01:01 +0200 | <davean> | maerwald: I'm really upset anyone approved 1.2 |
| 2021-07-25 00:01:11 +0200 | <davean> | maerwald: I can't even see what was gained |
| 2021-07-25 00:01:24 +0200 | <davean> | I was litterly already doing everything with 1.1 1.2 has |
| 2021-07-25 00:01:40 +0200 | <maerwald> | I've had my own share of drama the past 2 months, so I won't argue against random 1.2 :p |
| 2021-07-25 00:01:46 +0200 | <davean> | maerwald: is there somewhere to file an objection? |
| 2021-07-25 00:01:51 +0200 | <dminuoso> | 23:59:48 davean | we went from a type class with some meaning to one where you can't even be sure you can call the functions in the type class |
| 2021-07-25 00:02:04 +0200 | <maerwald> | davean: for what? It's too late |
| 2021-07-25 00:02:07 +0200 | <davean> | I'm really worried about the CLC approving 1.2 |
| 2021-07-25 00:02:09 +0200 | <dminuoso> | Maybe Im missing something, but can you give some examples? Im not seeing anything immediately obvious that's wrong with it |
| 2021-07-25 00:02:16 +0200 | <davean> | maerwald: the CLC's leadersihp franly |
| 2021-07-25 00:02:25 +0200 | <davean> | dminuoso: split - is it defined or not? |
| 2021-07-25 00:02:36 +0200 | <davean> | "maybe" |
| 2021-07-25 00:02:47 +0200 | <davean> | How do you know? |
| 2021-07-25 00:02:50 +0200 | <davean> | Uh, call it and find out! |
| 2021-07-25 00:02:54 +0200 | Cajun | (~Cajun@ip98-163-211-112.no.no.cox.net) |
| 2021-07-25 00:03:52 +0200 | <davean> | maerwald: Frankly I tihnk the only correct move is to mark 1.2 broken |
| 2021-07-25 00:04:32 +0200 | <dminuoso> | davean: Mmm. So why didn't they just make it.. a subclass? |
| 2021-07-25 00:04:47 +0200 | <dminuoso> | The usual way to further constrain a type by additional mechanisms.. |
| 2021-07-25 00:04:56 +0200 | <davean> | dminuoso: because that was the essence of the class |
| 2021-07-25 00:05:06 +0200 | <davean> | dminuoso: I have no idea what happened with 1.2 |
| 2021-07-25 00:05:20 +0200 | <davean> | I came across 1.2 a few days ago updating stuff and was horrified it ever was approved |
| 2021-07-25 00:05:31 +0200 | <dminuoso> | davean: No I meant, couldn't they just have added a RandomGenSplit typeclass with RandomGen as a superclass, and be done with it? |
| 2021-07-25 00:06:01 +0200 | <davean> | dminuoso: I mean if they'd tried, sure - though I'd suggest mots of those functions don't belong in class persay |
| 2021-07-25 00:06:43 +0200 | <davean> | One might use them for optimization |
| 2021-07-25 00:06:54 +0200 | <janus> | davean: have you previously voiced your concerns in a forum that isn't as ephemeral? (not rhetorical, just curious) |
| 2021-07-25 00:07:24 +0200 | <davean> | janus: what, email the CLC who approve this disaster? |
| 2021-07-25 00:07:37 +0200 | <davean> | No, because they're the ones who I have a problem with clearly |
| 2021-07-25 00:07:42 +0200 | <davean> | I have no diea who I'd voice this to |
| 2021-07-25 00:07:46 +0200 | geekosaur | subscribed tp the CLC list precisely to see what kind of things were in the pipeline |
| 2021-07-25 00:07:50 +0200 | <maerwald> | davean: they're not very responsive on emails either |
| 2021-07-25 00:07:57 +0200 | <davean> | maerwald: no they aren't |
| 2021-07-25 00:08:04 +0200 | <davean> | I'm subscribed and they don't reply to most tihngs |
| 2021-07-25 00:08:09 +0200 | <geekosaur> | but I missed this one |
| 2021-07-25 00:08:15 +0200 | <maerwald> | I'm not blaming ppl for having no time... but if you don't have time, ask for help |
| 2021-07-25 00:08:37 +0200 | <davean> | I have no idea who I'd complain to that I think the CLC has gone off the tracks |
| 2021-07-25 00:08:58 +0200 | <davean> | But I very much don't trust their leadership after seeing random 1.2 and they get to change a lot of important stuff |
| 2021-07-25 00:09:54 +0200 | <davean> | I'm worried about every other change they might make |
| 2021-07-25 00:09:55 +0200 | mikoto-chan | (~mikoto-ch@ip-193-121-10-50.dsl.scarlet.be) (Ping timeout: 265 seconds) |
| 2021-07-25 00:10:06 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 250 seconds) |
| 2021-07-25 00:12:04 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) (Remote host closed the connection) |
| 2021-07-25 00:12:16 +0200 | <davean> | geekosaur: Did you see the thing about Data.List also? I completely didn't see any discussion of that and am rather worried |
| 2021-07-25 00:12:20 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Quit: ran away) |
| 2021-07-25 00:12:42 +0200 | <oso> | do you have a link or a term to search? just Data.List CLC? |
| 2021-07-25 00:12:44 +0200 | <davean> | As far as I can tell CLC is acting unilaterally without discussion or I'm bad at reading emmail |
| 2021-07-25 00:12:46 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) |
| 2021-07-25 00:12:47 +0200 | <geekosaur> | I found out about it from #ghc |
| 2021-07-25 00:13:06 +0200 | <davean> | Has the CLC become a lose cannon out of control? |
| 2021-07-25 00:13:13 +0200 | <maerwald> | davean: there was a huge thread about random |
| 2021-07-25 00:13:19 +0200 | <maerwald> | libraries ML I think |
| 2021-07-25 00:13:30 +0200 | <maerwald> | lots of drama etc |
| 2021-07-25 00:14:57 +0200 | <davean> | maerwald: I guess I don't really care how it happened - the result is one I consider unacceptable |
| 2021-07-25 00:15:11 +0200 | <davean> | so I can't be ok with random 1.2 no matter what discussion happened |
| 2021-07-25 00:15:43 +0200 | <maerwald> | ok great, I can't fork process and use it in cabal.project, because of cabal not having any way to run autoreconf |
| 2021-07-25 00:16:14 +0200 | <davean> | maerwald: hum? |
| 2021-07-25 00:16:30 +0200 | <maerwald> | yes |
| 2021-07-25 00:16:50 +0200 | <davean> | can't you run autoreconfig manually? |
| 2021-07-25 00:17:18 +0200 | <maerwald> | how would you do that? Cabal clones the repo in some private dir and builds stuff, then fails |
| 2021-07-25 00:17:46 +0200 | <davean> | If you do it by reference, not if you do it by inclusion |
| 2021-07-25 00:17:53 +0200 | <davean> | make process a submodule |
| 2021-07-25 00:18:00 +0200 | <maerwald> | urg |
| 2021-07-25 00:18:30 +0200 | <davean> | I didn't say it was nice |
| 2021-07-25 00:18:38 +0200 | <maerwald> | time cabal gets hooks |
| 2021-07-25 00:18:42 +0200 | <jumper149> | maerwald: Use nix ;) |
| 2021-07-25 00:18:46 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 00:18:48 +0200 | <maerwald> | jumper149: no |
| 2021-07-25 00:18:49 +0200 | <davean> | maerwald: it has cooks |
| 2021-07-25 00:18:55 +0200 | <maerwald> | what's a cook? |
| 2021-07-25 00:19:08 +0200 | <davean> | maerwald: You'd have to make it be in Setup.hs though |
| 2021-07-25 00:19:16 +0200 | <maerwald> | that's not a user hook |
| 2021-07-25 00:19:39 +0200 | <maerwald> | https://github.com/haskell/process/issues/51 |
| 2021-07-25 00:19:41 +0200 | <maerwald> | oops |
| 2021-07-25 00:19:46 +0200 | <maerwald> | my clipboard is broken |
| 2021-07-25 00:19:51 +0200 | <maerwald> | good nothing weird coming out of it |
| 2021-07-25 00:19:56 +0200 | <maerwald> | this https://github.com/haskell/cabal/issues/7394 |
| 2021-07-25 00:20:16 +0200 | <maerwald> | that would solve 2000 and 1 problems |
| 2021-07-25 00:20:23 +0200 | <maerwald> | seems it's WIP |
| 2021-07-25 00:20:31 +0200 | <davean> | maerwald: I mean your problem here is that the process library isn't a proper cabal package really |
| 2021-07-25 00:20:39 +0200 | <davean> | maerwald: I'm troubled by solving it externally for that reason |
| 2021-07-25 00:20:47 +0200 | <maerwald> | davean: yeah, let me argue with Snoyman real quick about it... |
| 2021-07-25 00:20:50 +0200 | <maerwald> | or... not |
| 2021-07-25 00:21:06 +0200 | neightchan | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-07-25 00:21:07 +0200 | <maerwald> | (because stack runs autoreconf) |
| 2021-07-25 00:21:07 +0200 | <davean> | maerwald: I know, I've never gotten even remote exploits fixed from that crowd so yah |
| 2021-07-25 00:21:19 +0200 | <maerwald> | (so I can infer his first 3 replies to my issue) |
| 2021-07-25 00:21:40 +0200 | <davean> | maerwald: But I'd prefer stuff be properly packaged than patch it ad-hoc everywhere else |
| 2021-07-25 00:22:05 +0200 | <maerwald> | autoreconf is generally a controversial thing, even in source distros |
| 2021-07-25 00:22:51 +0200 | <maerwald> | if you have old buggy macros, you get problems... if you run it unconditionally, you have roughly 10% of failures |
| 2021-07-25 00:23:16 +0200 | <davean> | yah, its a bad solution to the problem bu tthe best thats at hand a lot of hte time |
| 2021-07-25 00:23:27 +0200 | <maerwald> | and then you have the "don't ever commit generated files to git" people |
| 2021-07-25 00:24:05 +0200 | <davean> | anyway, I know why you want these hooks, and I tihnk you understand why I don't like them as a solution here - pragmatics might win out |
| 2021-07-25 00:24:18 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) (Ping timeout: 240 seconds) |
| 2021-07-25 00:24:28 +0200 | <maerwald> | hooks are the *perfect* solution for this (and many other things) |
| 2021-07-25 00:24:34 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 240 seconds) |
| 2021-07-25 00:24:44 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 272 seconds) |
| 2021-07-25 00:24:47 +0200 | <davean> | I don't think I should have ot use hooks to depend on a package :/ |
| 2021-07-25 00:25:09 +0200 | <maerwald> | yes, this is dev foo |
| 2021-07-25 00:25:13 +0200 | <maerwald> | process needs to be fixed |
| 2021-07-25 00:25:33 +0200 | azeem | (~azeem@176.201.2.247) (Read error: Connection reset by peer) |
| 2021-07-25 00:25:46 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) |
| 2021-07-25 00:25:47 +0200 | <maerwald> | but now I got so annoyed about it that I riled about it here instead of running autoreconf... |
| 2021-07-25 00:25:58 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 00:26:36 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 00:26:56 +0200 | <DigitalKiwi> | at least there was some backtracking on the hpack generated file recommendation... |
| 2021-07-25 00:27:37 +0200 | niHiggim | (~stephen@2600:1700:3d41:8600::f) (Quit: WeeChat 3.2) |
| 2021-07-25 00:27:52 +0200 | tremon | (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) (channel hopping) |
| 2021-07-25 00:29:38 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2021-07-25 00:30:05 +0200 | jumper149 | (~jumper149@80.240.31.34) (Quit: WeeChat 3.2) |
| 2021-07-25 00:31:56 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-07-25 00:32:45 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 244 seconds) |
| 2021-07-25 00:33:17 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-25 00:33:42 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 00:36:14 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-07-25 00:38:55 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 00:40:34 +0200 | dhil | (~dhil@195.213.192.47) (Ping timeout: 272 seconds) |
| 2021-07-25 00:41:15 +0200 | neightchan | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 00:42:30 +0200 | xff0x_ | (~xff0x@2001:1a81:53c2:cd00:dd40:8cef:a8e6:16a8) (Ping timeout: 256 seconds) |
| 2021-07-25 00:43:05 +0200 | xff0x_ | (~xff0x@2001:1a81:53c2:cd00:83d7:3823:c8d1:341c) |
| 2021-07-25 00:45:38 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-25 00:48:41 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-25 00:49:00 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 00:49:18 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) |
| 2021-07-25 00:51:33 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-07-25 00:52:50 +0200 | acidjnk | (~acidjnk@p200300d0c72b958609191ed2d8f7abdf.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2021-07-25 00:56:56 +0200 | enoq | (~enoq@194-208-179-35.lampert.tv) (Quit: enoq) |
| 2021-07-25 00:58:07 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) |
| 2021-07-25 01:02:44 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 01:03:11 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 01:04:57 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 01:05:23 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 01:08:08 +0200 | jmorris | (uid433911@id-433911.stonehaven.irccloud.com) |
| 2021-07-25 01:16:00 +0200 | kubes | (~kubes@188.120.84.109) |
| 2021-07-25 01:17:20 +0200 | kubes | (~kubes@188.120.84.109) (Client Quit) |
| 2021-07-25 01:18:02 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 01:19:13 +0200 | phma | (phma@2001:5b0:211f:6ab8:d4bc:dc6f:9391:c76c) (Read error: Connection reset by peer) |
| 2021-07-25 01:20:27 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 01:22:14 +0200 | spiunx | (~spiun@2a01:4b00:86a9:fb00:adc0:97d9:20d8:cafd) (Ping timeout: 252 seconds) |
| 2021-07-25 01:23:36 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-25 01:24:25 +0200 | <sclv> | davean: what data.list thing? |
| 2021-07-25 01:25:02 +0200 | Ariakenom | (~Ariakenom@c83-255-154-140.bredband.tele2.se) (Quit: Leaving) |
| 2021-07-25 01:25:15 +0200 | <davean> | sclv: Monomorphisation |
| 2021-07-25 01:25:23 +0200 | <davean> | which isn't senseless |
| 2021-07-25 01:25:27 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-25 01:25:38 +0200 | <sclv> | where is discussion? |
| 2021-07-25 01:25:40 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 01:25:51 +0200 | <davean> | Haha thats the funny thing! |
| 2021-07-25 01:25:56 +0200 | <davean> | I was done without discussion :) |
| 2021-07-25 01:26:05 +0200 | <davean> | See the bug tracker for base? |
| 2021-07-25 01:26:15 +0200 | <davean> | GHC people noticed it because stuff broke |
| 2021-07-25 01:26:30 +0200 | <sclv> | ew |
| 2021-07-25 01:26:47 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-25 01:27:22 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 01:31:06 +0200 | wroathe | (~wroathe@96-88-30-181-static.hfc.comcastbusiness.net) (Ping timeout: 240 seconds) |
| 2021-07-25 01:33:43 +0200 | Deide | (~Deide@user/deide) (Quit: Seeee yaaaa) |
| 2021-07-25 01:33:44 +0200 | retroid_ | (~retro@97e2ba5d.skybroadband.com) (Ping timeout: 250 seconds) |
| 2021-07-25 01:35:12 +0200 | BMCC | mnrmnaugh |
| 2021-07-25 01:35:45 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-07-25 01:37:06 +0200 | phma | (~phma@host-67-44-209-90.hnremote.net) |
| 2021-07-25 01:37:11 +0200 | <sclv> | found the discussion, what a mess https://gitlab.haskell.org/ghc/ghc/-/issues/20025 |
| 2021-07-25 01:39:40 +0200 | phma | (~phma@host-67-44-209-90.hnremote.net) (Read error: Connection reset by peer) |
| 2021-07-25 01:43:06 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 276 seconds) |
| 2021-07-25 01:43:30 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 01:43:31 +0200 | <dminuoso> | What I dont get is, how is the CLC already this dysfunctional running only two members out of 7? |
| 2021-07-25 01:45:02 +0200 | Guest22 | (~Guest22@bras-base-orlnon0604w-grc-44-74-12-3-79.dsl.bell.ca) |
| 2021-07-25 01:45:02 +0200 | spiunx | (~spiun@2a01:4b00:86a9:fb00:8779:c06f:3ad1:b557) |
| 2021-07-25 01:46:04 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-25 01:46:17 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 01:46:24 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) (Remote host closed the connection) |
| 2021-07-25 01:47:51 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) |
| 2021-07-25 01:47:52 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-07-25 01:49:39 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-25 01:52:41 +0200 | hololeap | (~hololeap@user/hololeap) |
| 2021-07-25 01:53:25 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-25 01:56:00 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-25 01:56:04 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 01:57:00 +0200 | DigitalKiwi | wonders if the chair of the committee being a chess ai might be part of the problem |
| 2021-07-25 01:58:54 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-25 02:02:04 +0200 | phma | (~phma@2001:5b0:211f:7588:d0bc:3afd:37cf:6fa6) |
| 2021-07-25 02:03:22 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 240 seconds) |
| 2021-07-25 02:03:24 +0200 | phma | (~phma@2001:5b0:211f:7588:d0bc:3afd:37cf:6fa6) (Read error: Connection reset by peer) |
| 2021-07-25 02:03:41 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 02:03:49 +0200 | phma | (~phma@host-67-44-209-47.hnremote.net) |
| 2021-07-25 02:05:17 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2021-07-25 02:05:36 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 02:06:02 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 02:06:06 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2021-07-25 02:08:09 +0200 | <DigitalKiwi> | spoilers; https://en.wikipedia.org/wiki/List_of_Dune_secondary_characters#Daniel_and_Marty |
| 2021-07-25 02:08:15 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 02:09:14 +0200 | chomwitt | (~chomwitt@2a02:587:dc0e:ef00:12c3:7bff:fe6d:d374) (Remote host closed the connection) |
| 2021-07-25 02:11:49 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-25 02:11:54 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2021-07-25 02:14:48 +0200 | Topsi | (~Tobias@dyndsl-091-249-083-202.ewe-ip-backbone.de) (Quit: Leaving.) |
| 2021-07-25 02:18:36 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2021-07-25 02:19:58 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 256 seconds) |
| 2021-07-25 02:25:06 +0200 | peterhil | (~peterhil@mobile-access-b04801-219.dhcp.inet.fi) |
| 2021-07-25 02:28:28 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 02:30:34 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-25 02:30:52 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 02:31:26 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 02:32:07 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-07-25 02:33:36 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 02:35:27 +0200 | nate2 | (~nate@2600:1010:b005:5a54:c5a2:de43:b326:7069) |
| 2021-07-25 02:35:56 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-07-25 02:38:18 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-07-25 02:39:01 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 02:39:48 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 256 seconds) |
| 2021-07-25 02:42:18 +0200 | agua | (~agua@2804:18:4d:af57:1:0:4dec:eb61) |
| 2021-07-25 02:43:30 +0200 | pesada | (~agua@191.177.175.57) (Ping timeout: 250 seconds) |
| 2021-07-25 02:43:56 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2021-07-25 02:48:10 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-07-25 02:49:31 +0200 | Axman6 | (~Axman6@user/axman6) (Remote host closed the connection) |
| 2021-07-25 02:52:05 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Ping timeout: 255 seconds) |
| 2021-07-25 02:54:19 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 02:54:47 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 02:54:57 +0200 | laprice | (~laprice@c-71-238-52-236.hsd1.or.comcast.net) (Quit: Lost terminal) |
| 2021-07-25 02:55:43 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 02:59:11 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-25 02:59:52 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 03:01:19 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-25 03:01:49 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 03:05:08 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 03:05:20 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 03:07:29 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 03:08:03 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 03:09:11 +0200 | Axman6 | (~Axman6@user/axman6) |
| 2021-07-25 03:11:34 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2021-07-25 03:12:42 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2021-07-25 03:15:07 +0200 | pavonia | (~user@user/siracusa) |
| 2021-07-25 03:16:23 +0200 | xff0x_ | (~xff0x@2001:1a81:53c2:cd00:83d7:3823:c8d1:341c) (Ping timeout: 255 seconds) |
| 2021-07-25 03:16:47 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:96d:7043:ac49:cacb) |
| 2021-07-25 03:18:15 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:96d:7043:ac49:cacb) (Client Quit) |
| 2021-07-25 03:18:16 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:97a8:d110:8021:86ce) |
| 2021-07-25 03:18:31 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:96d:7043:ac49:cacb) |
| 2021-07-25 03:20:36 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 256 seconds) |
| 2021-07-25 03:23:22 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 03:23:41 +0200 | econo | (uid147250@user/econo) |
| 2021-07-25 03:28:06 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 03:31:06 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:96d:7043:ac49:cacb) (Ping timeout: 268 seconds) |
| 2021-07-25 03:44:30 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) (Read error: Connection reset by peer) |
| 2021-07-25 03:45:05 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) |
| 2021-07-25 03:46:50 +0200 | Atum_ | (~IRC@user/atum/x-2392232) (Quit: Atum_) |
| 2021-07-25 03:49:30 +0200 | Null_A | (~null_a@2601:645:8700:2290:809c:ae43:df71:6365) (Ping timeout: 256 seconds) |
| 2021-07-25 03:50:24 +0200 | bitmapper | (uid464869@id-464869.tooting.irccloud.com) |
| 2021-07-25 03:51:53 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 258 seconds) |
| 2021-07-25 03:52:43 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:d816:bb5b:d12f:f798) |
| 2021-07-25 03:54:29 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:d816:bb5b:d12f:f798) (Client Quit) |
| 2021-07-25 03:55:19 +0200 | dajoer | (~david@user/gvx) |
| 2021-07-25 03:59:32 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) |
| 2021-07-25 04:01:07 +0200 | thomasjm[m] | (~thomasjmm@2001:470:69fc:105::c6d9) |
| 2021-07-25 04:02:33 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 268 seconds) |
| 2021-07-25 04:03:54 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) (Ping timeout: 240 seconds) |
| 2021-07-25 04:04:09 +0200 | Null_A | (~null_a@2601:645:8700:2290:1:e11e:d55b:188f) |
| 2021-07-25 04:06:45 +0200 | td_ | (~td@muedsl-82-207-238-101.citykom.de) (Ping timeout: 276 seconds) |
| 2021-07-25 04:07:09 +0200 | Topsi | (~Tobias@dyndsl-091-249-083-202.ewe-ip-backbone.de) |
| 2021-07-25 04:08:17 +0200 | fawful | (~guy@c-76-104-217-93.hsd1.wa.comcast.net) (Quit: WeeChat 3.2) |
| 2021-07-25 04:08:19 +0200 | td_ | (~td@muedsl-82-207-238-027.citykom.de) |
| 2021-07-25 04:08:58 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2021-07-25 04:08:58 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-07-25 04:09:25 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-25 04:16:02 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 258 seconds) |
| 2021-07-25 04:17:02 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-25 04:17:32 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 250 seconds) |
| 2021-07-25 04:23:13 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 04:24:28 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 258 seconds) |
| 2021-07-25 04:24:33 +0200 | bin_ | (~bin@user/bin/x-1583188) (Quit: ZNC - https://znc.in) |
| 2021-07-25 04:26:44 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 04:26:52 +0200 | _bin | (~bin@user/bin/x-1583188) |
| 2021-07-25 04:28:57 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-25 04:30:28 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-07-25 04:31:25 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-07-25 04:31:25 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (copper.libera.chat (Nickname regained by services))) |
| 2021-07-25 04:31:25 +0200 | finn_elija | FinnElija |
| 2021-07-25 04:32:26 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 04:33:00 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-25 04:34:02 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-25 04:34:57 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 04:35:25 +0200 | machinedgod | (~machinedg@s72-38-105-27.static.comm.cgocable.net) |
| 2021-07-25 04:39:33 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 268 seconds) |
| 2021-07-25 04:44:44 +0200 | nate3 | (~nate@2600:1010:b014:ea44:558f:f06a:16ea:88da) |
| 2021-07-25 04:46:10 +0200 | nate2 | (~nate@2600:1010:b005:5a54:c5a2:de43:b326:7069) (Ping timeout: 256 seconds) |
| 2021-07-25 04:46:42 +0200 | peterhil | (~peterhil@mobile-access-b04801-219.dhcp.inet.fi) (Ping timeout: 240 seconds) |
| 2021-07-25 04:48:34 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-25 04:51:52 +0200 | sim590 | (~simon@modemcable090.207-203-24.mc.videotron.ca) |
| 2021-07-25 04:53:54 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2021-07-25 04:54:33 +0200 | eltonpin1 | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) |
| 2021-07-25 04:55:57 +0200 | Guest6667 | (~Guest66@pool-173-71-126-18.cmdnnj.fios.verizon.net) |
| 2021-07-25 04:58:01 +0200 | Guest6667 | (~Guest66@pool-173-71-126-18.cmdnnj.fios.verizon.net) (Client Quit) |
| 2021-07-25 05:00:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-25 05:05:37 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-07-25 05:07:33 +0200 | Guest22 | (~Guest22@bras-base-orlnon0604w-grc-44-74-12-3-79.dsl.bell.ca) (Quit: Client closed) |
| 2021-07-25 05:11:06 +0200 | nate3 | (~nate@2600:1010:b014:ea44:558f:f06a:16ea:88da) (Ping timeout: 240 seconds) |
| 2021-07-25 05:17:52 +0200 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2021-07-25 05:21:36 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-25 05:21:45 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Quit: Leaving) |
| 2021-07-25 05:26:39 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 05:28:06 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-07-25 05:29:54 +0200 | alx741 | (~alx741@186.178.108.59) (Quit: alx741) |
| 2021-07-25 05:31:46 +0200 | Guest5 | (~Guest5@50.47.115.102) |
| 2021-07-25 05:35:09 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 05:36:25 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-07-25 05:37:16 +0200 | <Guest5> | Hello! I know that C# has a "using" statement to help correctly use manually managed resources like file readers. Is there a library that adds the same functionality in Haskell? |
| 2021-07-25 05:38:04 +0200 | <eltonpin1> | Do you mean something like "automatically close a file once it goes out of scope"? |
| 2021-07-25 05:38:22 +0200 | eltonpin1 | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) (Quit: WeeChat 3.1) |
| 2021-07-25 05:38:38 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) |
| 2021-07-25 05:38:41 +0200 | <Guest5> | yes |
| 2021-07-25 05:39:10 +0200 | <davean> | Guest5: many systems are structured with "with" functions |
| 2021-07-25 05:39:21 +0200 | <davean> | Guest5: for example, bracket enables that, its pretty normal |
| 2021-07-25 05:40:27 +0200 | <eltonpinto> | https://hackage.haskell.org/package/regions |
| 2021-07-25 05:41:00 +0200 | <Guest5> | Neat, thanks! |
| 2021-07-25 05:41:09 +0200 | <davean> | I'd say the morn usual form is ? -> (a -> m b) -> m b |
| 2021-07-25 05:41:22 +0200 | spiunx | (~spiun@2a01:4b00:86a9:fb00:8779:c06f:3ad1:b557) (Remote host closed the connection) |
| 2021-07-25 05:41:32 +0200 | <davean> | Theres many levels of complexity to flexability of it though, like the regions package, and others |
| 2021-07-25 05:43:10 +0200 | <davean> | withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r for example |
| 2021-07-25 05:47:35 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:97a8:d110:8021:86ce) (Ping timeout: 255 seconds) |
| 2021-07-25 05:48:30 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:ce05:e9a7:78b7:c1fe) |
| 2021-07-25 05:52:59 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 05:53:17 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 05:57:52 +0200 | HarveyPwca | (~HarveyPwc@2601:246:c180:a570:29df:3b00:ad0e:3a06) (Quit: Leaving) |
| 2021-07-25 06:01:36 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-07-25 06:02:26 +0200 | machinedgod | (~machinedg@s72-38-105-27.static.comm.cgocable.net) (Ping timeout: 255 seconds) |
| 2021-07-25 06:05:09 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2021-07-25 06:05:52 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2021-07-25 06:06:05 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2021-07-25 06:08:00 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2021-07-25 06:08:58 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 06:17:03 +0200 | Topsi1 | (~Tobias@dyndsl-095-033-017-171.ewe-ip-backbone.de) |
| 2021-07-25 06:19:32 +0200 | Topsi | (~Tobias@dyndsl-091-249-083-202.ewe-ip-backbone.de) (Ping timeout: 255 seconds) |
| 2021-07-25 06:33:39 +0200 | pera | (~pera@user/pera) (Ping timeout: 258 seconds) |
| 2021-07-25 06:33:55 +0200 | Guest5 | (~Guest5@50.47.115.102) (Ping timeout: 246 seconds) |
| 2021-07-25 06:39:19 +0200 | vonfry | (~user@119.135.206.182) |
| 2021-07-25 06:39:31 +0200 | vonfry | (~user@119.135.206.182) (Remote host closed the connection) |
| 2021-07-25 06:43:51 +0200 | Guest5 | (~Guest5@50.47.115.102) |
| 2021-07-25 06:45:06 +0200 | Null_A | (~null_a@2601:645:8700:2290:1:e11e:d55b:188f) (Remote host closed the connection) |
| 2021-07-25 06:50:11 +0200 | eltonpinto | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) (Quit: WeeChat 3.1) |
| 2021-07-25 06:50:43 +0200 | Guest5 | (~Guest5@50.47.115.102) (Ping timeout: 246 seconds) |
| 2021-07-25 06:53:51 +0200 | slice | (~slice@user/slice) |
| 2021-07-25 06:57:21 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 07:03:58 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-07-25 07:08:06 +0200 | slice | (~slice@user/slice) (Quit: zzz) |
| 2021-07-25 07:13:12 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-25 07:13:59 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 07:14:48 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 07:20:05 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds) |
| 2021-07-25 07:22:52 +0200 | eltonpinto | (~eltonpint@169.109.136.34.bc.googleusercontent.com) |
| 2021-07-25 07:24:03 +0200 | eltonpin1 | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) |
| 2021-07-25 07:24:23 +0200 | eltonpin1 | (~1ntEgr8@2601:c8:c000:3090:20d2:58dd:3f51:cdf0) (Client Quit) |
| 2021-07-25 07:26:36 +0200 | <Cajun> | so one thing thats always peeved me with vectors is making recursive pattern matching functions with them. with lists its easy, but with a vector it feels dirty in a way; it needs -XViewPatterns and even then it feels like it adds an operation to make the benefits of vector (O(1) access) worthless. is there a better way of dealing with recursive |
| 2021-07-25 07:26:37 +0200 | <Cajun> | functions on vectors, or are we stuck with ViewPatterns? |
| 2021-07-25 07:27:29 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-25 07:27:58 +0200 | <Cajun> | and to add on, how can this be done with Repa arrays? |
| 2021-07-25 07:28:20 +0200 | <davean> | whats the problem you have with ViewPatterns here? |
| 2021-07-25 07:28:47 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-07-25 07:28:51 +0200 | <Cajun> | just wondering if thats the only option or if there is a more "natural" (without extensions) way of pattern matching on them |
| 2021-07-25 07:30:11 +0200 | <davean> | I mean you can use guards if you want to avoid patterns, but I don't advocate that |
| 2021-07-25 07:30:45 +0200 | <davean> | ViewPatterns don't give you anything special |
| 2021-07-25 07:31:22 +0200 | <davean> | It all really depends on what your actual technical complaint is |
| 2021-07-25 07:31:31 +0200 | <davean> | For style questions, thats all up to you |
| 2021-07-25 07:31:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-25 07:31:53 +0200 | <davean> | I might think you've got no taste because of the style you pick, but uh, I mean I can't say you're objectively wrong |
| 2021-07-25 07:32:45 +0200 | <Cajun> | im not sure if GHC would optimize it out, but its need for applying some function (like an uncons of some kind) every single time vs the default list's special syntax is what i was getting at, but its also a stylistic complain (to a way lesser degree) |
| 2021-07-25 07:33:07 +0200 | <davean> | I mean, think of waht that code actually means |
| 2021-07-25 07:33:17 +0200 | <davean> | But like, guards do create binds |
| 2021-07-25 07:33:43 +0200 | <davean> | You can look at the core, but yah, I mean it also depends on the type of Vector here for the exact details of what happens |
| 2021-07-25 07:33:52 +0200 | <davean> | clearly "head" of a boxed vector doesn't create anything |
| 2021-07-25 07:34:14 +0200 | <davean> | Things get iffier with one based on Storable instances |
| 2021-07-25 07:34:34 +0200 | <davean> | I know enough to debate you both ways on this, since your problem isn't realyl clear :) |
| 2021-07-25 07:34:55 +0200 | <davean> | The curse of knowlege is most things become more situational |
| 2021-07-25 07:34:56 +0200 | <Cajun> | i was just wondering if there was an easier way of doing it, the other more "real" question is how can this even be done on Repa arrays |
| 2021-07-25 07:35:12 +0200 | <davean> | I have no idea about Repa arrays, never used Repa seriously |
| 2021-07-25 07:35:23 +0200 | <davean> | tried it once or two years, years back |
| 2021-07-25 07:38:16 +0200 | <Cajun> | it seems overly clunky to attempt to pattern match on them, and im not even sure if thats the intended use of them or if they are strictly "bulk operations only" for stuff like image representation. im a complete beginner in terms of Repa |
| 2021-07-25 07:38:46 +0200 | <davean> | I know enough about Vector to talk about that, Repa, eh, uh |
| 2021-07-25 07:40:23 +0200 | <davean> | Cajun: why are you pattern matching down vectors anyway? |
| 2021-07-25 07:40:33 +0200 | <davean> | That seems unnatural |
| 2021-07-25 07:41:24 +0200 | <davean> | Oh right, there was a reason I don't use Repa |
| 2021-07-25 07:41:33 +0200 | <Cajun> | well thats what feels natural coming from the default List, is that just not the intended use case? |
| 2021-07-25 07:41:53 +0200 | <davean> | I mean you can pattern match down them if you have reason to |
| 2021-07-25 07:42:06 +0200 | <davean> | I just don't know many things that Vector is the optimal data structure for where I'd want to |
| 2021-07-25 07:42:22 +0200 | <davean> | I'd usually want a map or a fold in places where vector is appropriate |
| 2021-07-25 07:42:51 +0200 | <davean> | Its nothing hard and fact, I just don't think I've ever actualyl wanted to recurse down - cons and uncons occasionally, but not recurse specificly |
| 2021-07-25 07:43:02 +0200 | <davean> | I'm very much not saying you're wrong |
| 2021-07-25 07:43:37 +0200 | <davean> | I'm saying you're probably using vector in a way I haven't choosen to and I'd like to know what lead you there |
| 2021-07-25 07:44:34 +0200 | <Cajun> | well Vector just seems like the default List but with more emphasis on performance, so it would be nice to get the best of both worlds (easy recursive functions from default lists and performance from vectors) |
| 2021-07-25 07:44:53 +0200 | <davean> | But its not, it has fundimentally different characturistics |
| 2021-07-25 07:45:18 +0200 | <davean> | Like you can't edit the front of a vector, and reuse the tail in constant time |
| 2021-07-25 07:45:43 +0200 | <davean> | this is sorta the core of why I don't tend to use vector for things I recurse down - I'm usually either producing something from all the data, or I'm transforming all the data |
| 2021-07-25 07:45:57 +0200 | <davean> | also you get constant time length, which changes what you can do how |
| 2021-07-25 07:45:59 +0200 | <Cajun> | is this just not the intended use case for vectors? |
| 2021-07-25 07:46:03 +0200 | <davean> | but again, you can recurse down it all you want |
| 2021-07-25 07:46:25 +0200 | <davean> | I don't know - you keep not telling me what you're actually trying to do, so how can I answer? |
| 2021-07-25 07:46:40 +0200 | <davean> | You're litterly asking me about something you're not telling me about |
| 2021-07-25 07:47:17 +0200 | <davean> | I will say, taking the tail of a vector is constructive, unlike of a list where it isn't |
| 2021-07-25 07:47:46 +0200 | <davean> | constructive but O(1) |
| 2021-07-25 07:47:56 +0200 | <Cajun> | well its not about anything specific, its just that whenever i go to use them i hit a brick wall of weird pattern matching. also, what do you mean by "constructive"? |
| 2021-07-25 07:48:07 +0200 | <davean> | I mean it produces new data |
| 2021-07-25 07:48:24 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 258 seconds) |
| 2021-07-25 07:48:30 +0200 | <davean> | as for pattern matching: |
| 2021-07-25 07:48:46 +0200 | <davean> | f v | h <- head v = something with the head h |
| 2021-07-25 07:49:14 +0200 | <davean> | with some vectors head isn't constructive (With some it is, varies by the vector type and optimizations) |
| 2021-07-25 07:49:41 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-25 07:49:55 +0200 | <davean> | I can't really say anything about list vs. vector though because they're so fundimentally different that they're just not alike |
| 2021-07-25 07:50:04 +0200 | <davean> | for some things one is right, for others the other |
| 2021-07-25 07:50:38 +0200 | <Cajun> | well can Vectors from Data.Vector be used for lazy lists? it doesnt mention strictness on the hackage page |
| 2021-07-25 07:50:51 +0200 | <davean> | no, of course not |
| 2021-07-25 07:51:16 +0200 | <davean> | though it can reference lazy values if you use the boxed ones |
| 2021-07-25 07:51:37 +0200 | <davean> | but vectors themselves could never be lazy, the elements in a boxed vector can be though |
| 2021-07-25 07:52:06 +0200 | <Cajun> | im assuming that even a boxed vector of lazy values still cant be infinite right? |
| 2021-07-25 07:52:18 +0200 | <davean> | No, vectors are specificly finite |
| 2021-07-25 07:52:33 +0200 | <davean> | They have to be, by construction |
| 2021-07-25 07:53:42 +0200 | <davean> | but theres a difference between a lazy list and a list of lazy values |
| 2021-07-25 07:54:32 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 258 seconds) |
| 2021-07-25 07:54:34 +0200 | <davean> | vector can only partially match to the second |
| 2021-07-25 07:55:03 +0200 | <Cajun> | what do you mean? |
| 2021-07-25 07:55:31 +0200 | <davean> | so first I want to be clear, theres at least 8 types of Vector |
| 2021-07-25 07:55:40 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) |
| 2021-07-25 07:55:41 +0200 | <davean> | And they've all got different properties |
| 2021-07-25 07:56:13 +0200 | <davean> | but, the one closest in nature to list is the boxed vector |
| 2021-07-25 07:56:53 +0200 | <davean> | It doesn't say anything about strictness, because theres nothing about strictness for it to say |
| 2021-07-25 07:57:08 +0200 | <davean> | if you go over to Data.Vector.Unboxed though, thats a bit of a different story |
| 2021-07-25 07:57:21 +0200 | <davean> | Now for a lazy list vs a list of lazy values |
| 2021-07-25 07:57:32 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) (Client Quit) |
| 2021-07-25 07:57:46 +0200 | <davean> | theres two parts to a "list" in one way of looking at it, the "spine" which is the list constructors, and the "data" which is the 'a' in [a] |
| 2021-07-25 07:57:48 +0200 | derelict | (~derelict@user/derelict) |
| 2021-07-25 07:57:48 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) |
| 2021-07-25 07:57:53 +0200 | <davean> | their laziness is seperate |
| 2021-07-25 07:57:57 +0200 | <Cajun> | lazy list is `_:_` for infinite values vs `_:_:_:_:_:_:_:_:_:....` for list of lazy values yeah? |
| 2021-07-25 07:59:25 +0200 | <Cajun> | well either way, thanks for clearing up my confusion about Vectors :) |
| 2021-07-25 07:59:31 +0200 | PinealGlandOptic | (~PinealGla@37.115.210.35) (Quit: leaving) |
| 2021-07-25 07:59:31 +0200 | <davean> | I hope i helped? |
| 2021-07-25 07:59:42 +0200 | <Cajun> | yeah, i just didnt understand proper use case i guess lol |
| 2021-07-25 07:59:53 +0200 | <Cajun> | always imagined them as a replacement for lists |
| 2021-07-25 08:00:04 +0200 | <davean> | they're not, they can share some use cases but they're not lists |
| 2021-07-25 08:00:28 +0200 | <davean> | cons is O(1) on list, obviously |
| 2021-07-25 08:00:53 +0200 | <davean> | vectors are in a way far more "structured" than list |
| 2021-07-25 08:00:58 +0200 | <davean> | so you get a lot more structural operations |
| 2021-07-25 08:01:07 +0200 | <davean> | Thats REALLY not well defined mind you |
| 2021-07-25 08:01:22 +0200 | <davean> | but lists, for example, you can't tell up front how long they are |
| 2021-07-25 08:01:30 +0200 | <davean> | and they might not even have a definable length |
| 2021-07-25 08:01:38 +0200 | <davean> | their length is a semi-decision problem |
| 2021-07-25 08:01:55 +0200 | <davean> | vectors have an a-prior length by the nature of existing |
| 2021-07-25 08:02:08 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) (Ping timeout: 255 seconds) |
| 2021-07-25 08:02:10 +0200 | <davean> | so you can talk about the definition for every one of their values |
| 2021-07-25 08:02:27 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-07-25 08:02:37 +0200 | <davean> | etc |
| 2021-07-25 08:03:06 +0200 | <davean> | but yah, so about lists |
| 2021-07-25 08:03:27 +0200 | <davean> | [a] is ~ = Cons a RestOfList | EndOfList |
| 2021-07-25 08:03:40 +0200 | <davean> | both a and RestOfList's strictness is seperately defined |
| 2021-07-25 08:03:54 +0200 | <davean> | an infinite list of course must have RestOfList non-strict |
| 2021-07-25 08:04:10 +0200 | <davean> | but the 'a's might always be computed before the next Cons is constructed |
| 2021-07-25 08:04:28 +0200 | <davean> | OTOH, the RestOfLists might all be defined up front, but the 'a's left uncomputed |
| 2021-07-25 08:04:34 +0200 | <davean> | or both might be full computed, or neither |
| 2021-07-25 08:04:43 +0200 | <davean> | a vector, theres onyl one top level constructor |
| 2021-07-25 08:04:56 +0200 | <davean> | so by looking at it at all, the entire spine is done, theres only ever one piece of it |
| 2021-07-25 08:05:30 +0200 | <davean> | a vector, its self, is an atomic entity |
| 2021-07-25 08:06:18 +0200 | <Cajun> | so vector is just a chunk of data vs list being a bunch of "links" which may or may not be computed |
| 2021-07-25 08:06:26 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 272 seconds) |
| 2021-07-25 08:06:37 +0200 | <davean> | yes |
| 2021-07-25 08:06:46 +0200 | <davean> | The data in a vector might not its self be computed |
| 2021-07-25 08:06:53 +0200 | <Cajun> | but its all there |
| 2021-07-25 08:06:57 +0200 | <davean> | but the vector, if you look at it, must be |
| 2021-07-25 08:07:08 +0200 | <davean> | the definitions are all linked to at least |
| 2021-07-25 08:07:27 +0200 | <davean> | in a block |
| 2021-07-25 08:07:47 +0200 | <davean> | you can't just "replace" the first element in a vector like you can in a list for example for that reason |
| 2021-07-25 08:08:23 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 08:08:35 +0200 | <davean> | (I say just, because with the correct conditions you can change it, with a mutable vector in the correct context for example, but now the old version no longer exists - where as with the list that isn't the case) |
| 2021-07-25 08:09:18 +0200 | <davean> | Theres a lot of places lists are miss-used instead of vectors, because lists are closer at hand, but they're fundimentally unrelated datastructures |
| 2021-07-25 08:09:51 +0200 | <Cajun> | ah that makes a lot of sense, i guess that makes pattern matching on them just a foolish idea, considering a new Vector must be made for each recurse, yeah? |
| 2021-07-25 08:09:53 +0200 | <davean> | with entirely different properties |
| 2021-07-25 08:10:15 +0200 | <davean> | well, ... sorta, I mean you can pattern match and pass down an index for example |
| 2021-07-25 08:10:25 +0200 | <davean> | go i v | h <- v ! i = ... |
| 2021-07-25 08:10:46 +0200 | <davean> | right? Like you can walk down it, and look at each value seperately, but why aren't you folding then? |
| 2021-07-25 08:11:03 +0200 | <davean> | go on the tail is of course go (i+1) v |
| 2021-07-25 08:11:08 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-25 08:11:24 +0200 | <davean> | But we've BASICLY just implimented a fold |
| 2021-07-25 08:11:28 +0200 | <Cajun> | well assuming the function constructs a new vector of some kind. im guessing im just using them wrong (as a list replacement) |
| 2021-07-25 08:11:53 +0200 | <davean> | well, depends on what new construction you're making |
| 2021-07-25 08:12:01 +0200 | <davean> | if the construction is of the same time, thats a map or a scan |
| 2021-07-25 08:12:31 +0200 | <davean> | if the construciton is of a known size, then thats a generate with the passed function capturing the origional list |
| 2021-07-25 08:12:41 +0200 | <davean> | if you don't know the length, you're not ready to create a vector yet! |
| 2021-07-25 08:13:05 +0200 | <davean> | and then you'd be using it wrong, or at least you'd have a LOT of book keeping to do to do a good job of using it well (fusion can take care of most of that automaticly for you) |
| 2021-07-25 08:14:19 +0200 | wei2912 | (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-07-25 08:14:51 +0200 | <davean> | Also, I am sorry to anyone watching for my abuse of guards here. |
| 2021-07-25 08:15:13 +0200 | <davean> | For the record I don't actually support that style, it just works and is concies and isn't Viewpatterns and I was making a point |
| 2021-07-25 08:15:30 +0200 | <Cajun> | yeah it helps to make your point more clear lol |
| 2021-07-25 08:15:34 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-07-25 08:16:28 +0200 | <davean> | Cajun: I do expect you should stare at fold, map, scan a bit and consider if they're the actual structure you're implimenting |
| 2021-07-25 08:17:00 +0200 | <davean> | data Vector a = Vector {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !(Array a) |
| 2021-07-25 08:17:10 +0200 | <davean> | BTW if you were interested in what Vector (at least the boxed variant) is |
| 2021-07-25 08:17:12 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds) |
| 2021-07-25 08:17:33 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2021-07-25 08:17:59 +0200 | <davean> | so whats tail? tail (Vector o s a) = Vector (o+1) (s-1) a |
| 2021-07-25 08:18:14 +0200 | machinedgod | (~machinedg@s72-38-105-27.static.comm.cgocable.net) |
| 2021-07-25 08:18:16 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 08:18:23 +0200 | <davean> | I mean with a bunch of bounds checks and stuff |
| 2021-07-25 08:18:34 +0200 | wei2912 | (~wei2912@112.199.250.21) (Client Quit) |
| 2021-07-25 08:18:40 +0200 | <davean> | I'm of course leaving out al the important code :) |
| 2021-07-25 08:19:08 +0200 | <Cajun> | yeah at one point i realized what im essentially doing is reinventing map. though one time i hit the wall was when i was trying to make a function like `chunksOf` from Data.List.Split, and it doesnt seem like a map, fold, or scan would work well there |
| 2021-07-25 08:19:52 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-07-25 08:20:22 +0200 | <davean> | sure, that'll work, you can do that as a fold for example just fine |
| 2021-07-25 08:20:29 +0200 | <c_wraith> | that's more of an unfold |
| 2021-07-25 08:20:56 +0200 | <davean> | I mean yah it is, but you can do it |
| 2021-07-25 08:21:07 +0200 | <Cajun> | well that would imply giving a single value like `Vector a -> a` no? when in reality that function would give `Vector a -> Vector (Vector a)` |
| 2021-07-25 08:21:11 +0200 | <davean> | I mean TECHNICALLY its a combination of a cata and an anna ... |
| 2021-07-25 08:21:15 +0200 | <davean> | But lets just not go there |
| 2021-07-25 08:21:25 +0200 | <c_wraith> | so it's a para. :P |
| 2021-07-25 08:21:25 +0200 | <Cajun> | yeah that went over my head lol |
| 2021-07-25 08:22:07 +0200 | <davean> | Yah I was trying to stickign to being helpful instead of being useful |
| 2021-07-25 08:24:27 +0200 | <davean> | The code with fold on vector is nicely performant but much less pretty than the list one |
| 2021-07-25 08:24:31 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-07-25 08:24:41 +0200 | <davean> | or unfold |
| 2021-07-25 08:24:50 +0200 | <davean> | I think the unfold variant is cleaner frankly, but yah |
| 2021-07-25 08:25:12 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 258 seconds) |
| 2021-07-25 08:28:14 +0200 | burnsidesLlama | (~burnsides@dhcp168-011.wadham.ox.ac.uk) |
| 2021-07-25 08:28:25 +0200 | <davean> | anyway, enough trying to be helpful for me :) |
| 2021-07-25 08:30:09 +0200 | <Cajun> | well you definitely helped me figuring out vectors :) |
| 2021-07-25 08:30:18 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 240 seconds) |
| 2021-07-25 08:30:37 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 08:31:15 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2021-07-25 08:33:22 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 08:35:49 +0200 | <yorick> | class First list x | list -> x -- what's this `|` syntax? |
| 2021-07-25 08:35:50 +0200 | <c_wraith> | I always feel unsatisfied when I write an unfold |
| 2021-07-25 08:36:00 +0200 | <c_wraith> | yorick: functional dependencies |
| 2021-07-25 08:36:04 +0200 | <yorick> | thanks |
| 2021-07-25 08:37:25 +0200 | <c_wraith> | yorick: that says that the type x is uniquely determined by the type list. That has two consequences. One, GHC can assume that if it knows list, it can figure out x. Two, GHC will report an error if you try to write conflicting instances. |
| 2021-07-25 08:37:53 +0200 | <yorick> | excellent, much more googleable :) |
| 2021-07-25 08:38:30 +0200 | retroid_ | (~retro@5ec19a54.skybroadband.com) |
| 2021-07-25 08:38:50 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 250 seconds) |
| 2021-07-25 08:39:09 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 08:42:21 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) |
| 2021-07-25 08:43:41 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 08:45:06 +0200 | stefan-_ | (~cri@42dots.de) (Ping timeout: 240 seconds) |
| 2021-07-25 08:45:31 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 258 seconds) |
| 2021-07-25 08:46:54 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-25 08:47:44 +0200 | derelict | (~derelict@user/derelict) (Ping timeout: 252 seconds) |
| 2021-07-25 08:48:18 +0200 | <c_wraith> | basically, whenever I write an unfold, I wish I had a combinator like (\p f x -> f x <$ guard (p x)) conveniently named someplace already |
| 2021-07-25 08:49:03 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 08:49:54 +0200 | stefan-_ | (~cri@42dots.de) |
| 2021-07-25 08:51:32 +0200 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 256 seconds) |
| 2021-07-25 08:52:32 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 08:52:57 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 08:53:28 +0200 | slice | (~slice@user/slice) |
| 2021-07-25 08:53:48 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2021-07-25 08:55:40 +0200 | burnsidesLlama | (~burnsides@dhcp168-011.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-07-25 08:56:35 +0200 | pesada | (~agua@2804:18:4e:32f1:1:0:51c9:e850) |
| 2021-07-25 08:59:50 +0200 | agua | (~agua@2804:18:4d:af57:1:0:4dec:eb61) (Ping timeout: 252 seconds) |
| 2021-07-25 09:03:22 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-25 09:05:02 +0200 | mei4 | (~mei@user/mei) |
| 2021-07-25 09:07:14 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 272 seconds) |
| 2021-07-25 09:08:44 +0200 | mei | (~mei@user/mei) (Ping timeout: 255 seconds) |
| 2021-07-25 09:08:44 +0200 | mei4 | mei |
| 2021-07-25 09:13:25 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) |
| 2021-07-25 09:18:42 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 09:19:30 +0200 | bitmapper | (uid464869@id-464869.tooting.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-25 09:25:52 +0200 | acidjnk | (~acidjnk@p200300d0c72b958609191ed2d8f7abdf.dip0.t-ipconnect.de) |
| 2021-07-25 09:26:45 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 09:26:46 +0200 | burnsidesLlama | (~burnsides@dhcp168-011.wadham.ox.ac.uk) |
| 2021-07-25 09:27:58 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 09:33:03 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:ce05:e9a7:78b7:c1fe) (Ping timeout: 276 seconds) |
| 2021-07-25 09:33:41 +0200 | xff0x_ | (~xff0x@port-92-195-69-103.dynamic.as20676.net) |
| 2021-07-25 09:41:54 +0200 | radw | (~radw@user/radw) (Ping timeout: 252 seconds) |
| 2021-07-25 09:43:06 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
| 2021-07-25 09:47:05 +0200 | fendor | (~fendor@77.119.223.76.wireless.dyn.drei.com) |
| 2021-07-25 09:47:18 +0200 | codedmart | (~codedmart@li335-49.members.linode.com) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2021-07-25 09:47:33 +0200 | codedmart | (codedmart@2600:3c01::f03c:92ff:fefe:8511) |
| 2021-07-25 09:51:29 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2021-07-25 09:54:16 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 265 seconds) |
| 2021-07-25 09:57:13 +0200 | dagit_ | (~dagit@2601:1c2:1b7f:9fa0:54b1:3520:a1d6:48b1) |
| 2021-07-25 10:00:20 +0200 | dagit | (~dagit@2601:1c2:1b7f:9fa0:445:559:1c8d:e5d1) (Ping timeout: 252 seconds) |
| 2021-07-25 10:01:43 +0200 | burnside_ | (~burnsides@dhcp168-011.wadham.ox.ac.uk) |
| 2021-07-25 10:01:43 +0200 | burnsidesLlama | (~burnsides@dhcp168-011.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-25 10:04:06 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 10:04:27 +0200 | shredder | (~user@user/shredder) |
| 2021-07-25 10:05:06 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Ping timeout: 240 seconds) |
| 2021-07-25 10:05:13 +0200 | slice | (~slice@user/slice) (Quit: zzz) |
| 2021-07-25 10:05:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) |
| 2021-07-25 10:05:47 +0200 | <Hecate> | Cale: lol https://lambdacats.github.io/cale/ |
| 2021-07-25 10:06:05 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-07-25 10:06:42 +0200 | burnside_ | (~burnsides@dhcp168-011.wadham.ox.ac.uk) (Ping timeout: 240 seconds) |
| 2021-07-25 10:08:50 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 244 seconds) |
| 2021-07-25 10:12:35 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-25 10:17:08 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-07-25 10:17:21 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-25 10:17:22 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-25 10:17:47 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-25 10:20:20 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-25 10:22:30 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 10:23:13 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) |
| 2021-07-25 10:26:20 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Ping timeout: 258 seconds) |
| 2021-07-25 10:31:36 +0200 | pera | (~pera@user/pera) |
| 2021-07-25 10:33:44 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-25 10:34:41 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-25 10:37:21 +0200 | <jco> | Anyone know of some library to nicely render HTML in a text console? |
| 2021-07-25 10:37:50 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-25 10:37:50 +0200 | pera | (~pera@user/pera) (Ping timeout: 268 seconds) |
| 2021-07-25 10:38:00 +0200 | pera | (~pera@user/pera) |
| 2021-07-25 10:39:28 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-25 10:39:40 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 10:42:51 +0200 | mnrmnaugh | ID-10-T |
| 2021-07-25 10:43:04 +0200 | ID-10-T | mnrmnaugh |
| 2021-07-25 10:43:50 +0200 | mikoto-chan | (~mikoto-ch@ip-193-121-10-50.dsl.scarlet.be) |
| 2021-07-25 10:43:54 +0200 | mnrmnaugh | BMCC |
| 2021-07-25 10:45:11 +0200 | BMCC | mnrmnaugh |
| 2021-07-25 10:45:52 +0200 | zeenk | (~zeenk@2a02:2f04:a008:d600:18f2:3421:bac6:8f38) |
| 2021-07-25 10:46:52 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-07-25 10:46:53 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) (Read error: Connection reset by peer) |
| 2021-07-25 10:48:09 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 10:48:53 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-25 10:49:54 +0200 | dagit_ | (~dagit@2601:1c2:1b7f:9fa0:54b1:3520:a1d6:48b1) (Ping timeout: 240 seconds) |
| 2021-07-25 10:50:14 +0200 | img | (~img@user/img) |
| 2021-07-25 10:53:14 +0200 | pera | (~pera@user/pera) (Ping timeout: 265 seconds) |
| 2021-07-25 10:56:18 +0200 | radw | (~radw@user/radw) |
| 2021-07-25 10:57:22 +0200 | ubert | (~Thunderbi@178.165.160.247.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2021-07-25 10:59:31 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 265 seconds) |
| 2021-07-25 11:05:13 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2021-07-25 11:07:06 +0200 | yoctocell | (~user@h87-96-130-155.cust.a3fiber.se) |
| 2021-07-25 11:07:23 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 11:08:02 +0200 | slice | (~slice@user/slice) |
| 2021-07-25 11:08:35 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 11:08:38 +0200 | jgeerds | (~jgeerds@55d45555.access.ecotel.net) |
| 2021-07-25 11:10:32 +0200 | <Arahael> | jco: For such an open-ended question, I'd probably just look in to links, w3m, or lynx. |
| 2021-07-25 11:11:54 +0200 | jespada | (~jespada@90.254.247.46) (Ping timeout: 240 seconds) |
| 2021-07-25 11:12:58 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2021-07-25 11:13:10 +0200 | <Hecate> | yep |
| 2021-07-25 11:13:14 +0200 | jespada | (~jespada@90.254.247.46) |
| 2021-07-25 11:14:01 +0200 | <juri_> | we could use a haskell web browser.. if anyone has a giant team of haskellers with nothing to do. |
| 2021-07-25 11:16:41 +0200 | machinedgod | (~machinedg@s72-38-105-27.static.comm.cgocable.net) (Quit: leaving) |
| 2021-07-25 11:17:13 +0200 | <Hecate> | hahaha |
| 2021-07-25 11:20:02 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-07-25 11:26:24 +0200 | <nitrix> | They're still working on the ivory tower. |
| 2021-07-25 11:26:38 +0200 | <nitrix> | Next AI winter maybe. |
| 2021-07-25 11:28:53 +0200 | dextaa7 | dextaa |
| 2021-07-25 11:31:25 +0200 | dhil | (~dhil@195.213.192.47) |
| 2021-07-25 11:38:10 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-07-25 11:38:18 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-25 11:39:11 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 11:46:29 +0200 | jgeerds | (~jgeerds@55d45555.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2021-07-25 11:48:20 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-07-25 11:51:22 +0200 | agua | (~agua@2804:14c:8793:8e2f:8013:a595:bc17:299d) |
| 2021-07-25 11:53:48 +0200 | pesada | (~agua@2804:18:4e:32f1:1:0:51c9:e850) (Ping timeout: 272 seconds) |
| 2021-07-25 12:04:27 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) |
| 2021-07-25 12:06:34 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 240 seconds) |
| 2021-07-25 12:07:03 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2021-07-25 12:13:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-07-25 12:16:13 +0200 | xsperry | (~as@user/xsperry) (Remote host closed the connection) |
| 2021-07-25 12:16:52 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) (Quit: Leaving) |
| 2021-07-25 12:17:59 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 12:19:43 +0200 | zaquest | (~notzaques@5.128.210.178) (Quit: Leaving) |
| 2021-07-25 12:21:24 +0200 | kenran | (~kenran@200116b82bb5e400f1c7c01f9f0a47a0.dip.versatel-1u1.de) |
| 2021-07-25 12:22:14 +0200 | pesada | (~agua@2804:18:48:10d4:1:0:5286:477d) |
| 2021-07-25 12:25:19 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Quit: Konversation terminated!) |
| 2021-07-25 12:25:45 +0200 | agua | (~agua@2804:14c:8793:8e2f:8013:a595:bc17:299d) (Ping timeout: 268 seconds) |
| 2021-07-25 12:35:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 12:36:18 +0200 | darxun | (sid504814@id-504814.tinside.irccloud.com) (Ping timeout: 240 seconds) |
| 2021-07-25 12:36:58 +0200 | whiteline | (~whiteline@c-cda8d954.54725-0-757473696b74.bbcust.telenor.se) (Ping timeout: 240 seconds) |
| 2021-07-25 12:37:33 +0200 | darxun | (sid504814@id-504814.tinside.irccloud.com) |
| 2021-07-25 12:37:39 +0200 | Deide | (~Deide@217.155.19.23) |
| 2021-07-25 12:37:39 +0200 | Deide | (~Deide@217.155.19.23) (Changing host) |
| 2021-07-25 12:37:39 +0200 | Deide | (~Deide@user/deide) |
| 2021-07-25 12:39:22 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-07-25 12:43:52 +0200 | whiteline | (~whiteline@c-cda8d954.54725-0-757473696b74.bbcust.telenor.se) |
| 2021-07-25 12:43:52 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-25 12:44:57 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 12:45:06 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) |
| 2021-07-25 12:46:39 +0200 | andreabedini | (~andreabed@ec2-3-25-98-120.ap-southeast-2.compute.amazonaws.com) |
| 2021-07-25 12:49:46 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
| 2021-07-25 12:51:05 +0200 | pavonia_ | (~user@user/siracusa) |
| 2021-07-25 12:51:17 +0200 | whiteline | (~whiteline@c-cda8d954.54725-0-757473696b74.bbcust.telenor.se) (Read error: Connection reset by peer) |
| 2021-07-25 12:54:38 +0200 | pavonia | (~user@user/siracusa) (Ping timeout: 255 seconds) |
| 2021-07-25 12:54:45 +0200 | pavonia_ | pavonia |
| 2021-07-25 12:58:53 +0200 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2021-07-25 13:00:53 +0200 | pavonia_ | (~user@user/siracusa) |
| 2021-07-25 13:01:14 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2021-07-25 13:01:27 +0200 | pavonia_ | pavonia |
| 2021-07-25 13:01:57 +0200 | slice | (~slice@user/slice) (Quit: zzz) |
| 2021-07-25 13:05:23 +0200 | ahdyt | (~ahdyt@180.246.61.107) |
| 2021-07-25 13:06:38 +0200 | <ahdyt> | map solve problems |
| 2021-07-25 13:07:38 +0200 | AlexNoo_ | (~AlexNoo@178.34.150.234) |
| 2021-07-25 13:08:06 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 13:10:18 +0200 | AlexZenon | (~alzenon@178.34.162.117) (Ping timeout: 240 seconds) |
| 2021-07-25 13:10:18 +0200 | Alex_test | (~al_test@178.34.162.117) (Ping timeout: 240 seconds) |
| 2021-07-25 13:11:10 +0200 | AlexNoo | (~AlexNoo@178.34.162.117) (Ping timeout: 258 seconds) |
| 2021-07-25 13:12:16 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2021-07-25 13:15:32 +0200 | Alex_test | (~al_test@178.34.150.234) |
| 2021-07-25 13:15:44 +0200 | AlexZenon | (~alzenon@178.34.150.234) |
| 2021-07-25 13:17:07 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-25 13:28:25 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 13:29:26 +0200 | agua | (~agua@191.177.175.57) |
| 2021-07-25 13:32:42 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-07-25 13:33:11 +0200 | pesada | (~agua@2804:18:48:10d4:1:0:5286:477d) (Ping timeout: 252 seconds) |
| 2021-07-25 13:38:18 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 13:39:01 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 265 seconds) |
| 2021-07-25 13:41:37 +0200 | ahdyt | (~ahdyt@180.246.61.107) (Quit: Client closed) |
| 2021-07-25 13:41:43 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 13:42:32 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2021-07-25 13:43:51 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 13:44:44 +0200 | <hacker1234> | he |
| 2021-07-25 13:47:50 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 13:48:35 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 13:57:38 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 13:58:25 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 14:03:11 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-07-25 14:04:20 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-25 14:10:26 +0200 | zeenk | (~zeenk@2a02:2f04:a008:d600:18f2:3421:bac6:8f38) (Quit: Konversation terminated!) |
| 2021-07-25 14:12:02 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 14:15:45 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 265 seconds) |
| 2021-07-25 14:18:38 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 14:18:46 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-25 14:21:32 +0200 | Atum_ | (~IRC@user/atum/x-2392232) |
| 2021-07-25 14:22:42 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-07-25 14:32:33 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 14:35:02 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-25 14:39:14 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 14:41:00 +0200 | xsperry | (~as@user/xsperry) |
| 2021-07-25 14:42:40 +0200 | AlexNoo_ | AlexNoo |
| 2021-07-25 14:45:11 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 14:45:52 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 14:49:33 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 14:49:40 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2021-07-25 14:53:06 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-25 14:54:14 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2021-07-25 14:55:40 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 14:56:15 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 15:00:56 +0200 | alx741 | (~alx741@186.178.108.59) |
| 2021-07-25 15:05:01 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 258 seconds) |
| 2021-07-25 15:07:01 +0200 | Atum_ | (~IRC@user/atum/x-2392232) (Quit: Atum_) |
| 2021-07-25 15:10:46 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 258 seconds) |
| 2021-07-25 15:11:56 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2021-07-25 15:16:32 +0200 | <arkanoid> | is it more idiomatic to do not pollute the module by defining function in "where" block of other functions, or there's a better way? |
| 2021-07-25 15:16:32 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-07-25 15:17:49 +0200 | <Hecate> | arkanoid: the module is not polluted as long as you only export what needs to be exported |
| 2021-07-25 15:18:55 +0200 | <arkanoid> | Hecate: right, but is it still considereg good practice to control function visibility within a single module by embedding functions into where blocks? |
| 2021-07-25 15:19:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-25 15:20:37 +0200 | <Logio> | you can't test a non-visible function, so I'd say that's bad practice more than anything |
| 2021-07-25 15:21:40 +0200 | tlaxkit | (~hexchat@170.253.39.204) |
| 2021-07-25 15:22:39 +0200 | Atum_ | (~IRC@user/atum/x-2392232) |
| 2021-07-25 15:24:28 +0200 | <Logio> | unless your function definition depends on the local scope there's hardly any benefits to it, and even then I usually find myself refactoring code to do the opposite, for the aforementioned reason |
| 2021-07-25 15:24:36 +0200 | <[exa]> | arkanoid: if the function doesn't benefit from sharing the parameter context with the bigger function, I'd just leave it at top level. If it looks polluted, add comments. |
| 2021-07-25 15:26:15 +0200 | <Hecate> | arkanoid: what [exa] and Logio said ^ |
| 2021-07-25 15:26:44 +0200 | <Hecate> | don't think too much about this, most of your library's consumers will take what you give them, and your code will largely stay unread |
| 2021-07-25 15:26:46 +0200 | <arkanoid> | it makes sense, an embedded function cannot be tested separately. Thanks! |
| 2021-07-25 15:26:48 +0200 | <[exa]> | there might not even be any extra considerations, except perhaps from possible memoization vs. monomorphism |
| 2021-07-25 15:28:14 +0200 | <[exa]> | well yea, if you can make it parameterless and reuse the result manu times, it might be much better in the where block. :] |
| 2021-07-25 15:33:17 +0200 | <arkanoid> | I've another noob question, if you don't mind. When writing functions I tend to start by using static types and make it work, and then after all the test passes I feel guilty not having used polymorphism and typeclasses. Is it considered "wrong" non using "a -> b" but "Int -> Float"? |
| 2021-07-25 15:33:35 +0200 | <[exa]> | not at all |
| 2021-07-25 15:33:46 +0200 | <[exa]> | that's why we have the typesystems right |
| 2021-07-25 15:34:09 +0200 | <[exa]> | you can always ask the compiler for the most general type using the hole, as `myfunc :: _` |
| 2021-07-25 15:34:32 +0200 | <Hecate> | arkanoid: it is not, and you will gain in runtime perf with monomorphic functions |
| 2021-07-25 15:34:58 +0200 | <[exa]> | (generally, "prototype then polish" is wildly underestimated rule for good programming) |
| 2021-07-25 15:36:12 +0200 | <arkanoid> | good :) thanks. [exa] what do you mean by "ask the compiler for the most general type using the hole"? |
| 2021-07-25 15:36:29 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 15:36:39 +0200 | tremon | (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) |
| 2021-07-25 15:37:25 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 15:38:55 +0200 | <Hecate> | arkanoid: if you literally write a type signature "foo :: _", GHC will try to fill the hole (the underscore) with what it thinks is the best type |
| 2021-07-25 15:39:41 +0200 | <[exa]> | let's try |
| 2021-07-25 15:39:57 +0200 | <[exa]> | % "asd" + [_] |
| 2021-07-25 15:40:03 +0200 | <yahb> | [exa]: [Timed out] |
| 2021-07-25 15:40:12 +0200 | <[exa]> | oh noes |
| 2021-07-25 15:40:59 +0200 | <[exa]> | (I forgot a +, let's retry with lambdabot) |
| 2021-07-25 15:41:04 +0200 | <[exa]> | > "asd" ++ [ _ ] |
| 2021-07-25 15:41:08 +0200 | <lambdabot> | error: |
| 2021-07-25 15:41:08 +0200 | <lambdabot> | • Found hole: _ :: Char |
| 2021-07-25 15:41:08 +0200 | <lambdabot> | • In the expression: _ |
| 2021-07-25 15:41:39 +0200 | <[exa]> | arkanoid: it tells you what type fits there ^. if you put _ instead of the whole function type signature, you'll get a type derived for free. |
| 2021-07-25 15:42:16 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Ping timeout: 265 seconds) |
| 2021-07-25 15:42:53 +0200 | <arkanoid> | very interesting. Is it something that's used by programmers? |
| 2021-07-25 15:43:10 +0200 | <arkanoid> | I mean, whenever you get lost on the type of something, just compile with _ and read the result? |
| 2021-07-25 15:43:39 +0200 | <[exa]> | I do that all the time |
| 2021-07-25 15:44:08 +0200 | <arkanoid> | :D |
| 2021-07-25 15:44:32 +0200 | <[exa]> | like, people invested unbelievable amount of time to make the error messages good, so why not utilize that? |
| 2021-07-25 15:44:34 +0200 | jneira_ | (~jneira_@28.red-80-28-169.staticip.rima-tde.net) (Ping timeout: 240 seconds) |
| 2021-07-25 15:45:03 +0200 | peterhil | (~peterhil@mobile-access-5d6af6-209.dhcp.inet.fi) |
| 2021-07-25 15:45:09 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 15:45:31 +0200 | <arkanoid> | I wonder how many cool tricks are there that I'm missing |
| 2021-07-25 15:45:45 +0200 | wei2912 | (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-07-25 15:46:39 +0200 | <[exa]> | arkanoid: this is priceless: http://dev.stephendiehl.com/hask/tutorial.pdf |
| 2021-07-25 15:46:51 +0200 | <arkanoid> | :D |
| 2021-07-25 15:48:20 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 255 seconds) |
| 2021-07-25 15:48:26 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-07-25 15:48:54 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-07-25 15:49:01 +0200 | oso | (~oso@2601:58c:c080:a950:f275:2530:b398:680b) (Ping timeout: 246 seconds) |
| 2021-07-25 15:50:30 +0200 | jumper149 | (~jumper149@80.240.31.34) |
| 2021-07-25 15:53:29 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-25 15:58:14 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-25 16:02:44 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-07-25 16:03:14 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) (Quit: ubert) |
| 2021-07-25 16:03:27 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-25 16:03:32 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) |
| 2021-07-25 16:03:53 +0200 | <arkanoid> | I'm confused by type IO [Integer] and ([Integer], World) |
| 2021-07-25 16:04:06 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) (Client Quit) |
| 2021-07-25 16:04:22 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) |
| 2021-07-25 16:07:27 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-25 16:07:50 +0200 | jmorris | (uid433911@id-433911.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-25 16:08:22 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) |
| 2021-07-25 16:10:19 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-25 16:10:44 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 16:13:27 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) (Ping timeout: 276 seconds) |
| 2021-07-25 16:13:57 +0200 | <arkanoid> | if feels just like syntax sugar |
| 2021-07-25 16:14:36 +0200 | <geekosaur> | it is, sort of; it ensures you have a data dependency in the invocation and therefore things happen in the right order |
| 2021-07-25 16:15:20 +0200 | ubert | (~Thunderbi@91.141.47.26.wireless.dyn.drei.com) (Ping timeout: 255 seconds) |
| 2021-07-25 16:15:21 +0200 | <geekosaur> | you could do it manually (although the actual type is a little more complicated) |
| 2021-07-25 16:16:44 +0200 | <geekosaur> | but it has nothing to do with IO other than ensuring that ordering |
| 2021-07-25 16:16:58 +0200 | flounders | (~flounders@173.246.200.33) |
| 2021-07-25 16:19:01 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 16:20:43 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 16:20:59 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 16:21:00 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 16:21:14 +0200 | <hacker1234> | hacker hacker |
| 2021-07-25 16:21:49 +0200 | <hacker1234> | :-D |
| 2021-07-25 16:23:29 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 16:24:59 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 16:25:29 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) |
| 2021-07-25 16:25:33 +0200 | hacker1234 | (~weijiafu@2409:8a74:c90:3400:2193:78b:c8a3:31b7) () |
| 2021-07-25 16:26:11 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-25 16:26:12 +0200 | <arkanoid> | geekosaur: if I got it right it is just to ensure that the "world changes" on every IO operation, but this get's properly hidden with bind/do, correct? |
| 2021-07-25 16:27:25 +0200 | <geekosaur> | there is no world :) its size is zero. but otherwise yes |
| 2021-07-25 16:28:21 +0200 | <arkanoid> | ?_? |
| 2021-07-25 16:29:03 +0200 | <geekosaur> | as I said, its whole point is to make sure things happen in the right order, by forcing a data dependency |
| 2021-07-25 16:29:13 +0200 | <geekosaur> | after it's done that, it goes away |
| 2021-07-25 16:30:30 +0200 | shredder | (~user@user/shredder) (Quit: quitting) |
| 2021-07-25 16:30:43 +0200 | <geekosaur> | \(goes away in the sense that the compiler doesn't see it any more, since its representation has size zero it vanishes after the typechecker) |
| 2021-07-25 16:31:19 +0200 | shredder | (~user@user/shredder) |
| 2021-07-25 16:31:31 +0200 | <geekosaur> | I is special because it is IO, not because of RealWorld# |
| 2021-07-25 16:31:41 +0200 | <geekosaur> | *IO |
| 2021-07-25 16:31:49 +0200 | <yushyin> | a bit like a baton that is passed along |
| 2021-07-25 16:32:34 +0200 | <[exa]> | (wasn't that called a token? :D) |
| 2021-07-25 16:33:01 +0200 | <arkanoid> | olympic times, it's a baton now |
| 2021-07-25 16:33:06 +0200 | <arkanoid> | thanks! I got it |
| 2021-07-25 16:33:41 +0200 | <yushyin> | right! :D |
| 2021-07-25 16:33:59 +0200 | <arkanoid> | well, I don't get the "since its representation has size zero" thing, but not sure if I should dive into this now |
| 2021-07-25 16:34:11 +0200 | <geekosaur> | that's an internal compiler thing |
| 2021-07-25 16:34:27 +0200 | <geekosaur> | nut it points up that in reality there's no "world" to be "updated" |
| 2021-07-25 16:34:38 +0200 | <geekosaur> | there's just the baton |
| 2021-07-25 16:37:17 +0200 | nf | (~n@monade.li) (Quit: Fairfarren.) |
| 2021-07-25 16:37:51 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Quit: Leaving) |
| 2021-07-25 16:38:15 +0200 | <arkanoid> | I start to see the Matrix |
| 2021-07-25 16:40:40 +0200 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2021-07-25 16:40:41 +0200 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2021-07-25 16:40:41 +0200 | turlando | (~turlando@user/turlando) |
| 2021-07-25 16:40:44 +0200 | acidjnk | (~acidjnk@p200300d0c72b958609191ed2d8f7abdf.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2021-07-25 16:41:54 +0200 | hexfive | (~eric@50.35.83.177) |
| 2021-07-25 16:43:32 +0200 | nf | (~n@monade.li) |
| 2021-07-25 16:43:54 +0200 | chomwitt | (~chomwitt@2a02:587:dc0e:ef00:12c3:7bff:fe6d:d374) |
| 2021-07-25 16:44:58 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 240 seconds) |
| 2021-07-25 16:49:08 +0200 | <arkanoid> | not sure when I should prefer the "do" and when I should prefer the ">>=/>>" thing |
| 2021-07-25 16:51:20 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-07-25 16:52:21 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 16:58:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-25 17:02:26 +0200 | derelict | (~derelict@user/derelict) |
| 2021-07-25 17:03:22 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2021-07-25 17:03:43 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 244 seconds) |
| 2021-07-25 17:03:45 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) |
| 2021-07-25 17:05:19 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 17:05:21 +0200 | <geekosaur> | I generally use >>= when it's short |
| 2021-07-25 17:05:36 +0200 | <geekosaur> | do notation just looks better for long stuff |
| 2021-07-25 17:08:51 +0200 | <arkanoid> | k, thanks |
| 2021-07-25 17:09:38 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Ping timeout: 256 seconds) |
| 2021-07-25 17:09:59 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 258 seconds) |
| 2021-07-25 17:11:14 +0200 | _xor | (~xor@74.215.232.67) (Quit: WeeChat 3.2) |
| 2021-07-25 17:13:36 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 17:14:11 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 17:14:50 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 252 seconds) |
| 2021-07-25 17:17:27 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 17:24:11 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 17:25:34 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) |
| 2021-07-25 17:27:28 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-25 17:30:09 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:8db8:987d:36eb:f1a6) (Ping timeout: 276 seconds) |
| 2021-07-25 17:33:17 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 17:33:42 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 17:33:57 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 17:34:03 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-25 17:34:05 +0200 | tlaxkit | (~hexchat@170.253.39.204) (Ping timeout: 268 seconds) |
| 2021-07-25 17:34:40 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 17:35:34 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) |
| 2021-07-25 17:37:59 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 17:38:58 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-07-25 17:39:45 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 17:40:16 +0200 | slycelote | (~slycelote@user/slycelote) (Quit: Leaving) |
| 2021-07-25 17:40:51 +0200 | LukeHoersten | nth |
| 2021-07-25 17:45:24 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 17:45:57 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2021-07-25 17:46:47 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Ping timeout: 245 seconds) |
| 2021-07-25 17:46:59 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 17:47:45 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 17:48:35 +0200 | pera | (~pera@user/pera) |
| 2021-07-25 17:48:35 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-25 17:51:34 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2021-07-25 17:51:56 +0200 | _xor | (~xor@74.215.232.67) |
| 2021-07-25 17:59:28 +0200 | <monochrom> | Ah, missed the RealWorld# discussion. |
| 2021-07-25 18:00:13 +0200 | <monochrom> | People need to look at the asm code and see that RealWorld# is compiled to nothing. It's a phantom type. |
| 2021-07-25 18:02:10 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 18:02:56 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 18:02:59 +0200 | tlaxkit | (~hexchat@170.253.39.204) |
| 2021-07-25 18:03:38 +0200 | <geekosaur> | I mentioned that |
| 2021-07-25 18:03:46 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 18:03:47 +0200 | <monochrom> | It's present in IR to prevent the optimizer from re-ordering supposed sequential IO code. That's it. It's just to fool the optimizer. |
| 2021-07-25 18:04:18 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 240 seconds) |
| 2021-07-25 18:04:48 +0200 | <maerwald> | can't the optimizer be type-aware? |
| 2021-07-25 18:04:49 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 18:04:56 +0200 | <maerwald> | I've no idea about the pipeline :) |
| 2021-07-25 18:05:06 +0200 | econo | (uid147250@user/econo) |
| 2021-07-25 18:05:35 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Client Quit) |
| 2021-07-25 18:05:39 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-25 18:06:22 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 18:07:21 +0200 | zebrag | (~chris@user/zebrag) (Remote host closed the connection) |
| 2021-07-25 18:09:41 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 265 seconds) |
| 2021-07-25 18:10:03 +0200 | zaquest | (~notzaques@5.128.210.178) |
| 2021-07-25 18:10:13 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-07-25 18:11:05 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 268 seconds) |
| 2021-07-25 18:11:34 +0200 | zmt01 | (~zmt00@user/zmt00) |
| 2021-07-25 18:11:44 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 18:13:15 +0200 | slycelote | (~slycelote@user/slycelote) |
| 2021-07-25 18:13:56 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-25 18:14:37 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Read error: Connection reset by peer) |
| 2021-07-25 18:16:30 +0200 | zebrag | (~chris@user/zebrag) (Remote host closed the connection) |
| 2021-07-25 18:17:20 +0200 | dajoer | (~david@user/gvx) (Quit: leaving) |
| 2021-07-25 18:18:55 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 18:19:07 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 18:20:19 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 18:20:55 +0200 | <monochrom> | Type-aware optimizer may end up being two optimizers that are similar-yet-different enough that you have to write twice. |
| 2021-07-25 18:21:27 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 18:21:45 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 18:21:55 +0200 | <monochrom> | There is something nice about "the optimizer for pure code works for IO code too if it sees a fictional data dependency". |
| 2021-07-25 18:21:58 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 18:22:12 +0200 | <monochrom> | or code generator |
| 2021-07-25 18:22:41 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Client Quit) |
| 2021-07-25 18:24:46 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 18:32:04 +0200 | lambdap | (~lambdap@static.167.190.119.168.clients.your-server.de) (Quit: lambdap) |
| 2021-07-25 18:32:22 +0200 | lambdap | (~lambdap@static.167.190.119.168.clients.your-server.de) |
| 2021-07-25 18:33:48 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 250 seconds) |
| 2021-07-25 18:34:39 +0200 | <arkanoid> | [x**2 | x <- [1,2,3,4,5]] returns floats. I see that ** accepts Fractional typeclass. Is there a pow operator for Integers? |
| 2021-07-25 18:34:59 +0200 | <monochrom> | ^ |
| 2021-07-25 18:35:12 +0200 | <arkanoid> | thanks! |
| 2021-07-25 18:37:22 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-07-25 18:39:46 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 272 seconds) |
| 2021-07-25 18:40:59 +0200 | jespada | (~jespada@90.254.247.46) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 18:41:14 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 18:46:20 +0200 | nth | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 18:46:26 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2021-07-25 18:47:36 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-25 18:48:23 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 18:49:22 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Read error: Connection reset by peer) |
| 2021-07-25 18:49:34 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 18:49:58 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 18:54:37 +0200 | <arkanoid> | How to deal with overflow errors when using Int? "let foo :: Int -> Int; foo x = x^1000", "foo 7" returns -5479429532463080511 . I'm learning haskell to do scientific calculations, and I'd like to ensure that these kind of problems would arise at least as warnings when importing libs |
| 2021-07-25 18:55:18 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Ping timeout: 276 seconds) |
| 2021-07-25 18:55:31 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 18:56:22 +0200 | abbie | (~abbie@offtopia/offtopian/abbie) (Bye!) |
| 2021-07-25 18:56:58 +0200 | <arkanoid> | I mean, I would use Integer for my own functions, but what about if external module uses Int and returned values overflows without a warning? |
| 2021-07-25 18:57:46 +0200 | <jumper149> | arkanoid: Well, if it's an external module I don't see any way to fix it. |
| 2021-07-25 18:57:47 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 255 seconds) |
| 2021-07-25 18:58:41 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 18:59:24 +0200 | <nitrix> | You cannot deal with the overflow once it happened. You have to check for the _would be_ overflow before hand. |
| 2021-07-25 18:59:26 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Client Quit) |
| 2021-07-25 18:59:33 +0200 | <arkanoid> | this is surprising |
| 2021-07-25 18:59:56 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 19:00:15 +0200 | <nitrix> | What were your expectations? You seem to be fairly aware of that behavior. |
| 2021-07-25 19:00:30 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Ping timeout: 276 seconds) |
| 2021-07-25 19:00:43 +0200 | <lbseale> | Would the Scientific type help you? https://hackage.haskell.org/package/scientific-0.3.7.0/docs/Data-Scientific.html |
| 2021-07-25 19:01:24 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 19:01:48 +0200 | turlando | (~turlando@user/turlando) (Remote host closed the connection) |
| 2021-07-25 19:02:17 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 19:02:41 +0200 | <arkanoid> | I'm aware of it, and I can deal with it within my own code, but this lack of error control or warning makes importing modules unsafe unless checking every internal machinery |
| 2021-07-25 19:05:07 +0200 | jespada | (~jespada@90.254.247.46) |
| 2021-07-25 19:05:58 +0200 | <Cale> | Hecate: I'm not even really opposed to undecidable instances, it's the overlapping ones where things start to get bad. Undecidable ones, the worst that will happen is your build won't finish. |
| 2021-07-25 19:06:13 +0200 | <Cale> | (but the cat is funny :) |
| 2021-07-25 19:06:39 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 19:06:54 +0200 | <davean> | Cale: Its troubling when it might be non-determistic, but yah |
| 2021-07-25 19:06:56 +0200 | pera | (~pera@user/pera) (Ping timeout: 256 seconds) |
| 2021-07-25 19:07:53 +0200 | aliosablack | (~chomwitt@ppp-94-67-193-120.home.otenet.gr) |
| 2021-07-25 19:07:59 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Client Quit) |
| 2021-07-25 19:08:04 +0200 | xff0x_ | (~xff0x@port-92-195-69-103.dynamic.as20676.net) (Ping timeout: 256 seconds) |
| 2021-07-25 19:08:36 +0200 | <nitrix> | It's the behavior chosen for Int and also what distinguishes it from Integer. If the libraries have been using Int, then they presumably think that edge case wont happen or they're satisfied with the behavior. |
| 2021-07-25 19:08:46 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 19:09:47 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2021-07-25 19:09:56 +0200 | chomwitt | (~chomwitt@2a02:587:dc0e:ef00:12c3:7bff:fe6d:d374) (Ping timeout: 255 seconds) |
| 2021-07-25 19:10:15 +0200 | mr-red | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 276 seconds) |
| 2021-07-25 19:11:33 +0200 | <arkanoid> | nitrix: but that's very unsafe |
| 2021-07-25 19:11:52 +0200 | aerona | (~aerona@2600:6c54:4600:f300:2418:37e9:50f:bf32) |
| 2021-07-25 19:12:33 +0200 | <arkanoid> | also, have a look at https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic , the page is proving my point. It says |
| 2021-07-25 19:12:42 +0200 | <arkanoid> | Some programming languages such as Lisp, Python, Perl, Haskell and Ruby use, or have an option to use, arbitrary-precision numbers for all integer arithmetic. Although this reduces performance, it eliminates the possibility of incorrect results (or exceptions) due to simple overflow. |
| 2021-07-25 19:12:58 +0200 | <monochrom> | You know what, asm programmers have access to the "carry flag", they can know that overflow has happened if they want to. |
| 2021-07-25 19:13:00 +0200 | <nitrix> | What is unsafe about it? There aren't side-effects and the program isn't halting. The arithmetic is defined to behave that way, it's predictable. |
| 2021-07-25 19:13:24 +0200 | <monochrom> | Then C goes on to throw away that information and starts a great tradition. |
| 2021-07-25 19:13:30 +0200 | <Cale> | Maybe we could have an erroring-Int |
| 2021-07-25 19:13:43 +0200 | <geekosaur> | also as I read that I think someone misunderstood "integer-simple" |
| 2021-07-25 19:13:45 +0200 | <Cale> | But Int is Z/2^kZ for some k |
| 2021-07-25 19:14:23 +0200 | <monochrom> | OTOH you look at the floating point world, they do have floating-point exceptions. Then people go on to suppress it and turn it into NaN. It's a mess either way. |
| 2021-07-25 19:14:38 +0200 | <arkanoid> | nitrix: not predictable, as overflow is not sign-checked. "let foo :: Int -> Int; foo x = x^1000", "foo 7" returns -5479429532463080511 |
| 2021-07-25 19:14:45 +0200 | <Cale> | The fact that k is unspecified and you have to look at maxBound or similar to figure out which ring you're working in is a bit silly. |
| 2021-07-25 19:15:04 +0200 | <nitrix> | arkanoid, Your argument boils down to "other languages have the option to ...", but ignore that Haskell has that option as well. |
| 2021-07-25 19:15:09 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-25 19:15:35 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 19:16:11 +0200 | <Cale> | arkanoid: 7^1000 = -5479429532463080511 (mod 2^64) |
| 2021-07-25 19:17:45 +0200 | <Cale> | There is a bit of tension here though, I get where you're coming from. People use Int as though it were Integer but faster. |
| 2021-07-25 19:18:48 +0200 | <nitrix> | Choosing Int implies giving away the arbitrary precision and accepting the overflow behavior. |
| 2021-07-25 19:19:13 +0200 | <arkanoid> | Cale: I'm ok with using Integer in all my code, but I'm not ok in importing libraries that could return overflows without warnings or errors. |
| 2021-07-25 19:19:25 +0200 | <Cale> | Probably most users of Int don't really want modular arithmetic |
| 2021-07-25 19:19:37 +0200 | <Cale> | But that is indeed what they get |
| 2021-07-25 19:19:41 +0200 | <c_wraith> | Int is definitely *way* overused |
| 2021-07-25 19:20:35 +0200 | <nitrix> | The libraries where it matters don't make that mistake. I think arkanoid is hunting witches. |
| 2021-07-25 19:20:38 +0200 | <Cale> | On the other hand, I'm not sure I'd be happy if Int just threw exceptions. That's almost scarier. |
| 2021-07-25 19:20:50 +0200 | <arkanoid> | so what I'm asking is if there's a way to raise security level by checking if Int is used or overflow is triggered at runtime in all code, including the imported one |
| 2021-07-25 19:20:59 +0200 | <davean> | Cale: I've really wanted to choose the behaviors for my types :/ |
| 2021-07-25 19:21:04 +0200 | <davean> | I've often wanted saturation |
| 2021-07-25 19:21:05 +0200 | aliosablack | (~chomwitt@ppp-94-67-193-120.home.otenet.gr) (Ping timeout: 258 seconds) |
| 2021-07-25 19:21:06 +0200 | <dsal> | Can someone help me with a type definition? I'm trying to do stuff with `linear` such that I can build out arbitrary ranges of points. i.e., I've got `class Projector a b where project :: a -> b -> [a]` and I want to be able to have a `V a` and a value of `a` and produce a list of `V`s from the given point to point + size in every dimension. |
| 2021-07-25 19:21:32 +0200 | <Cale> | I think if you want to use signalling int, you also probably want an interface to its functionality which is entirely unlike Num |
| 2021-07-25 19:21:32 +0200 | <dsal> | So I've got `instance (Enum a, Integral a) => Projector (V2 a) a` which seems to do the right thing, but requires `AllowAmbiguousTypes` to work. That seems odd to me. |
| 2021-07-25 19:21:40 +0200 | <Cale> | i.e. you want operations which produce Maybe results |
| 2021-07-25 19:22:10 +0200 | <nitrix> | (+?) :: SafeNum n => n -> n -> Maybe n ? |
| 2021-07-25 19:22:28 +0200 | <Cale> | Yeah |
| 2021-07-25 19:22:32 +0200 | johnw | (~johnw@2600:1700:cf00:db0:4d8f:94c5:5bf3:4c24) (Ping timeout: 255 seconds) |
| 2021-07-25 19:23:01 +0200 | <nitrix> | Probably annoying to write expressions in, lifting everything all the time. |
| 2021-07-25 19:23:16 +0200 | <monochrom> | "you would go bind" |
| 2021-07-25 19:23:27 +0200 | Clint | squints. |
| 2021-07-25 19:23:30 +0200 | <arkanoid> | nitrix: I might be hunting witches, but it's a safe thing to do if there's no proof that they doesn not exist |
| 2021-07-25 19:23:41 +0200 | <dsal> | The class definition doesn't seem to imply any dependency between `a` and `b` which there probably should be. |
| 2021-07-25 19:23:50 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2021-07-25 19:24:46 +0200 | <dsal> | Oh, and that's my answer, I just defined a functional dependency. Neat. |
| 2021-07-25 19:25:05 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 19:28:00 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-07-25 19:28:08 +0200 | <arkanoid> | I also see that the fromInteger function does not return Error/Maybe, but just a Num, which Int is, so that means that also conversion in unchecked by default. https://wiki.haskell.org/Converting_numbers |
| 2021-07-25 19:28:23 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) (Ping timeout: 255 seconds) |
| 2021-07-25 19:28:47 +0200 | <geekosaur> | int-cast package |
| 2021-07-25 19:28:50 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 255 seconds) |
| 2021-07-25 19:29:06 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2021-07-25 19:29:19 +0200 | azeem | (~azeem@176.200.214.29) |
| 2021-07-25 19:29:55 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-25 19:31:43 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2021-07-25 19:32:02 +0200 | <arkanoid> | no, I'm not looking for a solution in my code, I'm looking for a solution that checks if the code I'm importing and calling contains these unchecked errors. As for now I have only 2 solutions: test my calling functions for all input domains OR check manually all the imported/called code |
| 2021-07-25 19:32:23 +0200 | <nitrix> | Ideally both. |
| 2021-07-25 19:33:03 +0200 | <dsal> | arkanoid: This is one of the reasons we like property tests. |
| 2021-07-25 19:34:53 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 19:36:05 +0200 | <arkanoid> | it depends on the input domain. I'm dealing with a 25 dimensional model that's already works in python and another imperative language I'm planning to use, but I wanted to learn haskell to get better handle complexity. This is a show stopper to me |
| 2021-07-25 19:36:33 +0200 | <nitrix> | I understand where you're coming from, you now have to trust code written by others instead of relying on the language enforcing these things, which can be frustrating and require additional work if you're the paranoid type. Though, I want to address the "unsafe" you keep bringing up. A mismatch between your expectation and the specification isn't what makes a feature unsafe; it just means your expectations are wrong. |
| 2021-07-25 19:37:21 +0200 | <nitrix> | The code is safe. It exhibits the very behavior it's meant to do -- assuming it's the behavior you wanted. |
| 2021-07-25 19:37:22 +0200 | <arkanoid> | debatable. Overflow check is part of the safe check list |
| 2021-07-25 19:37:40 +0200 | <nitrix> | I disagree. |
| 2021-07-25 19:37:40 +0200 | tlaxkit | (~hexchat@170.253.39.204) (Quit: Leaving) |
| 2021-07-25 19:38:06 +0200 | azeem | (~azeem@176.200.214.29) (Ping timeout: 256 seconds) |
| 2021-07-25 19:38:32 +0200 | azeem | (~azeem@dynamic-adsl-84-220-213-65.clienti.tiscali.it) |
| 2021-07-25 19:38:58 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Ping timeout: 240 seconds) |
| 2021-07-25 19:39:20 +0200 | <arkanoid> | nitrix: just check how other high level languages deal with it. C# for example gives the possibility to enable checked calculations (checked block) |
| 2021-07-25 19:39:38 +0200 | <nitrix> | You're conflating "surprising"/"error-prone" with "safety". |
| 2021-07-25 19:39:53 +0200 | Guest92 | (~Guest92@50.47.115.102) |
| 2021-07-25 19:40:32 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:bb8d:5843:c31e:244e) |
| 2021-07-25 19:41:14 +0200 | <arkanoid> | overflows compromise program's reliability and security, though safe programming wants you to check that |
| 2021-07-25 19:41:18 +0200 | <monochrom> | I used to defend the status quo of wrap-around because it benefitted some of my niche code. But I don't defend it now, my love of "w00t it does mod 2^64" is very, very niche. Most people don't want that. |
| 2021-07-25 19:42:16 +0200 | <monochrom> | But the status quo doesn't need to be defended. It has been settled for so long that it is too costly to change. |
| 2021-07-25 19:43:27 +0200 | <monochrom> | And while add-on is less costly than change, well let me tell you my favourite Aesop fable. |
| 2021-07-25 19:43:34 +0200 | <nitrix> | A knife has a sharp edge and a blunt edge. You use the sharp edge towards the things it needs to cut and the blunt edge to apply pressure. If you accidently use it in the wrong orientation, you'll hurt yourself, and that's surprising. If it's not clear which side is which, then that's error-prone, but the knife isn't more or less safe because of it. It'll cut on it's sharp edge exactly like it's intended to do, whether it's vegetables or your fingers. |
| 2021-07-25 19:44:06 +0200 | <monochrom> | The mice hold an internation mice conference to discuss how to mitigate the threat of cats. |
| 2021-07-25 19:44:20 +0200 | <nitrix> | I've been on both side of the status-quo. I mostly just think that Haskell's safety has zero to do with it. |
| 2021-07-25 19:44:28 +0200 | <monochrom> | They agree on two resolutions. |
| 2021-07-25 19:44:50 +0200 | <[exa]> | arkanoid: this might sound harsh but if you want to do x^1000 outside of modular arithmetic, you want to do it on paper and not on computer |
| 2021-07-25 19:44:59 +0200 | <monochrom> | 1. A bell is to be worn on the neck of the cat so every mouse can hear the cat coming. |
| 2021-07-25 19:45:07 +0200 | <monochrom> | 2. Someone else should do it. |
| 2021-07-25 19:45:51 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 19:46:20 +0200 | Teacup_ | (~teacup@user/teacup) (Quit: Teacup_) |
| 2021-07-25 19:46:28 +0200 | <[exa]> | arkanoid: also, as famously proven in 1930's, where there are large integers, there won't be any provable security. |
| 2021-07-25 19:47:07 +0200 | Teacup | (~teacup@user/teacup) |
| 2021-07-25 19:48:14 +0200 | mr-red | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 19:50:13 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Ping timeout: 258 seconds) |
| 2021-07-25 19:50:36 +0200 | <arkanoid> | point is that while Haskell gives good control on the complexity of the task, gives less safety on the output than other imperative languages |
| 2021-07-25 19:50:48 +0200 | <arkanoid> | while being less performant, too |
| 2021-07-25 19:51:27 +0200 | <nitrix> | Here it comes. |
| 2021-07-25 19:53:08 +0200 | mr-red | (~drd@93-39-151-19.ip76.fastwebnet.it) (Ping timeout: 255 seconds) |
| 2021-07-25 19:53:36 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 265 seconds) |
| 2021-07-25 19:54:11 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 19:55:00 +0200 | <nitrix> | We're thankful of your assessment and will take it into consideration for our next safety training. Safety is very important to us. |
| 2021-07-25 19:55:45 +0200 | [exa] | imports some monadic explosives |
| 2021-07-25 19:58:09 +0200 | dunkeln | (~dunkeln@94.129.69.87) |
| 2021-07-25 19:58:44 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-25 19:58:48 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 19:59:34 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:00:52 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2021-07-25 20:01:32 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-25 20:02:59 +0200 | <nitrix> | head :: [a] -> a, now that's potentially unsafe, though there's very little chance that ever changes. |
| 2021-07-25 20:03:46 +0200 | <Guest92> | Haskell could support truthy and falsy values (for example by using a typeclass that represents values that can be converted to Bool) but it doesn't. Why not? |
| 2021-07-25 20:04:18 +0200 | <dsal> | Guest92: why do you want this? |
| 2021-07-25 20:04:44 +0200 | <dsal> | It's rather nice reducing truth to one possible value and false to another. |
| 2021-07-25 20:05:07 +0200 | <c_wraith> | in python, 0 is falsy. In ruby, it's truthy. Which one of them is correct? |
| 2021-07-25 20:05:18 +0200 | <vaibhavsagar[m]> | Guest92: you could write your own typeclass that implements the truthy/falsy logic |
| 2021-07-25 20:05:28 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-25 20:05:32 +0200 | <vaibhavsagar[m]> | but you haven't. why not? |
| 2021-07-25 20:05:40 +0200 | <Guest92> | that is correct |
| 2021-07-25 20:06:03 +0200 | <Guest92> | I actually did as an experiment |
| 2021-07-25 20:06:11 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:06:11 +0200 | <vaibhavsagar[m]> | the reason we don't do it in Haskell is that it's not actually a good idea |
| 2021-07-25 20:06:27 +0200 | <Guest92> | ok, why not? |
| 2021-07-25 20:06:32 +0200 | <c_wraith> | the broader context is that it's going the wrong direction. Booleans kind of are bad ideas. |
| 2021-07-25 20:06:46 +0200 | <c_wraith> | Treating things as if they were booleans isn't any better. |
| 2021-07-25 20:06:55 +0200 | <nitrix> | You would have to demonstrate the laws hold for things like Eq and that wouldn't be pretty. |
| 2021-07-25 20:06:58 +0200 | <flounders> | Isn't that more like weak typing like what C does with char? |
| 2021-07-25 20:07:07 +0200 | <c_wraith> | You should prefer pattern-matching on domain types |
| 2021-07-25 20:07:19 +0200 | <dsal> | See also: Boolean blindness |
| 2021-07-25 20:08:01 +0200 | <Guest92> | makes sense, thanks! |
| 2021-07-25 20:09:06 +0200 | Guest92 | (~Guest92@50.47.115.102) (Quit: Client closed) |
| 2021-07-25 20:10:31 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 265 seconds) |
| 2021-07-25 20:13:41 +0200 | <arkanoid> | nitrix: https://hackage.haskell.org/package/safeint-0.6/docs/Data-SafeInt.html exist for a reason. Other languages have compiler options to enable overflow check at program level, or better at code level. Where's haskell solution to this? Using Integer in my code is just the tip of the iceberg. Do haskell programmers grep "Int" in all imported code and process it manually? |
| 2021-07-25 20:14:51 +0200 | <dsal> | I don't exactly understand your problem. If you use a data type that doesn't satisfy all of your requirements, then it won't satisfy all of your requirements. |
| 2021-07-25 20:15:16 +0200 | <dsal> | Is it just that you're using Int and that's not an appropriate type for your problem? |
| 2021-07-25 20:16:09 +0200 | <vaibhavsagar[m]> | it sounds like their problem is that overflow might be happening in their dependencies |
| 2021-07-25 20:16:21 +0200 | <vaibhavsagar[m]> | and there isn't a language-level way of preventing this |
| 2021-07-25 20:16:39 +0200 | <arkanoid> | vaibhavsagar[m]: thanks |
| 2021-07-25 20:16:43 +0200 | <[exa]> | apparently some other languages can prevent that |
| 2021-07-25 20:16:47 +0200 | <[exa]> | are there examples? |
| 2021-07-25 20:16:56 +0200 | <vaibhavsagar[m]> | C# apparently |
| 2021-07-25 20:17:05 +0200 | <arkanoid> | https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked |
| 2021-07-25 20:17:20 +0200 | <nitrix> | They're worried about code not under their control that would be responsible to overflow, somehow obsessed on the overflow part and not concerned about any other malicious thing that vendor code could be doing. |
| 2021-07-25 20:17:21 +0200 | Guest57 | (~Guest57@50.47.115.102) |
| 2021-07-25 20:18:00 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 20:18:08 +0200 | <nitrix> | But my stance is the same. As far as Int goes, that's exactly it's behavior. If you don't want that behavior or can't trust people did their homework when they use it, then apply your policy and refuse that code. |
| 2021-07-25 20:18:23 +0200 | <dsal> | I don't understand how this C# thing is any different. So if the code in the dependency uses `checked` that's effectively using the correct data type. |
| 2021-07-25 20:18:24 +0200 | <arkanoid> | https://doc.rust-lang.org/std/primitive.i32.html#method.checked_add |
| 2021-07-25 20:18:28 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) (Remote host closed the connection) |
| 2021-07-25 20:18:47 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:19:01 +0200 | <arkanoid> | dsal: the C# check goes all down the stack and check imported logic too |
| 2021-07-25 20:19:28 +0200 | <dsal> | The rust checked add is basically function I wrote yesterday for a semigroup implementation of a type that ensures addition only goes up to `maxBound` |
| 2021-07-25 20:19:45 +0200 | <nitrix> | Yeah. They mentioned earlier "arbitrary-precision integers in higher-level languages like Lisp, Python, Perl, Ruby" which is again the proper type and Haskell has that too. |
| 2021-07-25 20:20:41 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Client Quit) |
| 2021-07-25 20:20:46 +0200 | <arkanoid> | dsal: but you can enforce it with preprocessing, there are also other tools at type and compiler level. https://doc.rust-lang.org/stable/std/num/struct.Wrapping.html |
| 2021-07-25 20:21:04 +0200 | <arkanoid> | nitrix: you are not seeing the problem, apparently |
| 2021-07-25 20:21:25 +0200 | <vaibhavsagar[m]> | I'm not seeing the problem either |
| 2021-07-25 20:21:26 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:21:29 +0200 | <vaibhavsagar[m]> | use `Integer` |
| 2021-07-25 20:21:31 +0200 | <arkanoid> | having it for MY code doesn't make it into imported logic |
| 2021-07-25 20:21:38 +0200 | <vaibhavsagar[m]> | or `toIntegralSized` |
| 2021-07-25 20:21:47 +0200 | <dsal> | I don't know rust, but nothing you're describing there sounds much different from how I'd do it in Haskell. |
| 2021-07-25 20:21:59 +0200 | <[exa]> | arkanoid: do all rust packages use the checked_add ? |
| 2021-07-25 20:22:03 +0200 | <nitrix> | I understand your problem. "What if someone has a malicious call to exit(), or launchTheNukes() in their library that I'm not expecting". |
| 2021-07-25 20:22:24 +0200 | <vaibhavsagar[m]> | https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Bits.html#v:toIntegralSized |
| 2021-07-25 20:23:08 +0200 | <nitrix> | And I also understand that you're under the impression that this is something that the type system would prevent, but you're misunderstanding the situation. There is _nothing_ to prevent, this is the desired behavior for Int. |
| 2021-07-25 20:23:14 +0200 | <arkanoid> | this is at compiler level https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks |
| 2021-07-25 20:24:06 +0200 | <[exa]> | arkanoid: is downing an airplane because of an overflow better than just continuing on a slightly wrong trajectory? |
| 2021-07-25 20:24:12 +0200 | <dsal> | Does the compiler have checks for other mathematical errors that might exist in the code? |
| 2021-07-25 20:24:14 +0200 | <vaibhavsagar[m]> | that's not a type system check |
| 2021-07-25 20:24:29 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Client Quit) |
| 2021-07-25 20:24:46 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:25:39 +0200 | <vaibhavsagar[m]> | it looks like it checks for division by zero errors: https://stackoverflow.com/questions/42544491/can-i-disable-checking-for-zero-division-every-time-t… |
| 2021-07-25 20:25:39 +0200 | <DigitalKiwi> | [exa]: what if it's a rocket on a slightly wrong trajectory lol |
| 2021-07-25 20:26:08 +0200 | <[exa]> | DigitalKiwi: might be useful tbh :D |
| 2021-07-25 20:26:16 +0200 | <nitrix> | The wrong trajectory is a bad analogy. The result still has to be mathematically correct for Int. |
| 2021-07-25 20:26:47 +0200 | <nitrix> | The difference here is that Int semantics follows modulo-arithmetic, which arkanoid refuses to believe in. |
| 2021-07-25 20:27:18 +0200 | <DigitalKiwi> | https://twitter.com/hdevalence/status/1413559229672165380 |
| 2021-07-25 20:27:18 +0200 | <[exa]> | nitrix: for a programmer who didn't expect the overflow the trajectory is going to be literally the wrong one :] |
| 2021-07-25 20:27:21 +0200 | <dsal> | Does that mean that in C# code that's otherwise correct will start throwing an exceptions under certain contexts? |
| 2021-07-25 20:28:52 +0200 | <DigitalKiwi> | oh yeah this one https://twitter.com/pee_zombie/status/1413567104679387143 |
| 2021-07-25 20:29:12 +0200 | <nitrix> | [exa], Except you would expect the overflow, since you chose Int and you know that it does overflow. |
| 2021-07-25 20:29:22 +0200 | <arkanoid> | checking overflows means that you know when it happens. The effect my vary. May throw an exception, may print a warning, and so on. Surely not return 0 or something else |
| 2021-07-25 20:29:41 +0200 | <nitrix> | That's literally it's behavior. If you don't like the behavior then pick a type with a better behavior. |
| 2021-07-25 20:29:44 +0200 | leeper | (leeper@gateway/vpn/nordvpn/leeper) |
| 2021-07-25 20:29:52 +0200 | <arkanoid> | nitrix: other-people-code |
| 2021-07-25 20:29:56 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 20:30:02 +0200 | <arkanoid> | you keep ignoring the point |
| 2021-07-25 20:30:03 +0200 | <[exa]> | nitrix: yeah but we are talking about the other programmers now |
| 2021-07-25 20:30:13 +0200 | <nitrix> | And yes, people sometimes use Int when they should use Integer. It's acceptable for some programs, for programs that it's not, then of course you don't use those. |
| 2021-07-25 20:30:39 +0200 | slice | (~slice@user/slice) |
| 2021-07-25 20:30:45 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:30:48 +0200 | <DigitalKiwi> | http://www.math.sjsu.edu/~foster/m143m/ariane_rocket_overflow.pdf |
| 2021-07-25 20:30:53 +0200 | <nitrix> | Then don't use the code that's problematic. |
| 2021-07-25 20:31:06 +0200 | <c_wraith> | I pretty much only use Int if it's describing the cardinality of something in memory. |
| 2021-07-25 20:31:07 +0200 | <nitrix> | Why are you making this so complicated. Use what work, don't use what doesn't. |
| 2021-07-25 20:31:24 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Client Quit) |
| 2021-07-25 20:31:40 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:31:47 +0200 | <[exa]> | DigitalKiwi: okay that was the unlucky one |
| 2021-07-25 20:32:37 +0200 | <[exa]> | DigitalKiwi: my airplane overflowed the seatbelt ding statistic counter and somehow survived |
| 2021-07-25 20:32:43 +0200 | <DigitalKiwi> | https://www-users.cse.umn.edu/~arnold/disasters/patriot.html |
| 2021-07-25 20:33:07 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 20:33:25 +0200 | <arkanoid> | I'm really quite surprised that haskell ignores a problem that literally killed people |
| 2021-07-25 20:33:55 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:34:14 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) (Remote host closed the connection) |
| 2021-07-25 20:34:49 +0200 | <nitrix> | There are a multitude of other ways for logic or arithmetic in software to be wrong that Haskell (or any language for that matter) can prove incorrect. |
| 2021-07-25 20:35:01 +0200 | <dsal> | Haskell lets you use types to express problems safely. It also lets you choose the wrong solutions to problems. |
| 2021-07-25 20:35:16 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Read error: Connection reset by peer) |
| 2021-07-25 20:35:28 +0200 | <nitrix> | cannot* |
| 2021-07-25 20:35:55 +0200 | <jumper149> | arkanoid: If you really feel like `Int` is so bad, feel free to create a new Prelude, where all functions take `Integer`. At that point you might as well start to use `Natural` though. |
| 2021-07-25 20:35:56 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-07-25 20:36:05 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:36:36 +0200 | <nitrix> | They said they could; they're worried about "other code". |
| 2021-07-25 20:36:37 +0200 | <DigitalKiwi> | i use peno numbers in all of my rocket guaidance systems |
| 2021-07-25 20:36:58 +0200 | <DigitalKiwi> | peano |
| 2021-07-25 20:37:07 +0200 | <arkanoid> | yeah, I can run quickcheck on the entire problem domain to ensure that the called code doesn not contain Integer to Int conversion or whatever may raise overflow. Grep is more officient on that |
| 2021-07-25 20:37:08 +0200 | <[exa]> | DigitalKiwi: my point was, roughly, would throwing an exception instead of overflowing save anything there? |
| 2021-07-25 20:37:12 +0200 | <nitrix> | Not understanding that the moment they bring vendor code, the "other code" becomes "their code" and therefore their own liability. |
| 2021-07-25 20:37:13 +0200 | <vaibhavsagar[m]> | arkanoid: you might be under the impression that Haskell is the most advanced programming language that enables you to avoid all correctness and safety issues. Unfortunately that will never be tru |
| 2021-07-25 20:37:47 +0200 | <vaibhavsagar[m]> | it's still possible to write awful awful code with glaringly obvious logic bugs |
| 2021-07-25 20:38:03 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Client Quit) |
| 2021-07-25 20:38:18 +0200 | <vaibhavsagar[m]> | we can help avoid some classes of issues, but not others |
| 2021-07-25 20:38:50 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 20:38:59 +0200 | <dsal> | That's generally true. Any language that doesn't let you write bugs doesn't let you write much of anything. |
| 2021-07-25 20:39:40 +0200 | <vaibhavsagar[m]> | but particularly in this case contrasted with e.g. Rust that cares a lot about memory safety but not so much about side effects |
| 2021-07-25 20:39:43 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 20:39:48 +0200 | <vaibhavsagar[m]> | the tradeoffs are different |
| 2021-07-25 20:40:14 +0200 | <nitrix> | For what it's worth, Rust's int types have the same behavior. |
| 2021-07-25 20:40:31 +0200 | <nitrix> | There's tooling to catch it and you can write tests too, but it's the exact same. |
| 2021-07-25 20:40:52 +0200 | <DigitalKiwi> | [exa]: oh yeah also the 737 MAX ;_; |
| 2021-07-25 20:40:56 +0200 | soft-warm | (~soft-warm@2600:8801:db01:8f0:9615:1e45:d06d:2d70) |
| 2021-07-25 20:41:11 +0200 | <dsal> | arkanoid: grep will help you find the one thing you're worried about once. quickcheck will help you ensure your properties hold true. Using the right types will make it difficult to express incorrect logic (e.g. if you use `finite-typelits` you won't be able to have a value outside of your defined range) |
| 2021-07-25 20:41:43 +0200 | <arkanoid> | vaibhavsagar[m]: I had the illusion that having such high level control and math-rooted logic would have been a safer choice over other system programming languages, but I'm actually realising that it's not so different from others, Yeah I was expecting tradeoffs, but not on int overflow. |
| 2021-07-25 20:42:06 +0200 | <vaibhavsagar[m]> | ah, but haskell isn't a systems programming language |
| 2021-07-25 20:42:16 +0200 | <vaibhavsagar[m]> | you can use it to write systems programs |
| 2021-07-25 20:42:24 +0200 | <vaibhavsagar[m]> | but that's definitely not where its focus is |
| 2021-07-25 20:43:04 +0200 | <arkanoid> | I know. https://programatica.cs.pdx.edu//House/ |
| 2021-07-25 20:43:21 +0200 | <dsal> | You can represent all your numbers as `String`s and have all kinds of bizarre problems. Being able to to use the wrong type isn't a bug. |
| 2021-07-25 20:45:06 +0200 | <dsal> | "`Int` does the thing your processor does with ints" doesn't seem like a misfeature. |
| 2021-07-25 20:46:08 +0200 | <DigitalKiwi> | https://en.wikipedia.org/wiki/Boeing_737_MAX#Accidents_and_incidents |
| 2021-07-25 20:46:21 +0200 | <davean> | Just going to say, this seems like the world's most boring argument |
| 2021-07-25 20:46:25 +0200 | <arkanoid> | proving the whole input domain is a solution available in all languages used the industry, but that's not always feasible and kinda last resort. Modern languages use to have checks at program level |
| 2021-07-25 20:46:33 +0200 | <davean> | "Thing that does the thing it was selected to do, doesn't do the thing I want it to do" |
| 2021-07-25 20:46:40 +0200 | <davean> | So, uh, use the thing that does the thing you want it to do |
| 2021-07-25 20:46:52 +0200 | <arkanoid> | davean: you're missing the point |
| 2021-07-25 20:47:17 +0200 | <DigitalKiwi> | davean: https://twitter.com/leftpaddotpy/status/1416279646253895680?s=20 lol |
| 2021-07-25 20:47:31 +0200 | <arkanoid> | Ints do overflow, it's normal. Check that your program does not overflow, that's also desiderable. Doing that early is an indistry requirement |
| 2021-07-25 20:47:41 +0200 | peterhil | (~peterhil@mobile-access-5d6af6-209.dhcp.inet.fi) (Ping timeout: 252 seconds) |
| 2021-07-25 20:47:57 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 244 seconds) |
| 2021-07-25 20:48:12 +0200 | hrnz | (~ulli@irc.plumbing) (Quit: das ist mir zu bld hier; bb) |
| 2021-07-25 20:48:26 +0200 | hrnz | (~ulli@irc.plumbing) |
| 2021-07-25 20:49:30 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2021-07-25 20:49:40 +0200 | <arkanoid> | whatever, I got my answer. Haskell is not better on this than C, but hopefully it is easier to assure later on in production than C |
| 2021-07-25 20:49:41 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-25 20:50:07 +0200 | <dsal> | I don't think that "I'd like to use the wrong type and then also enforce a property that it doesn't have the wrong behavior" is a solution that makes sense. We have different types with different properties. You can't say the entire language is bad because it lets someone use the wrong type for a problem. |
| 2021-07-25 20:50:29 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:50:35 +0200 | <davean> | dsal: as I said, this is the stupidest argument ever |
| 2021-07-25 20:50:52 +0200 | <arkanoid> | language is not bad, lack of compiler option or linter tool to solve this is |
| 2021-07-25 20:51:04 +0200 | <davean> | arkanoid: if you want a tool for this, use liquid haskell? |
| 2021-07-25 20:51:11 +0200 | <davean> | But no, theres no linting or anything that makes sense here |
| 2021-07-25 20:51:17 +0200 | <davean> | Int *is* correct for a bunch of stuff |
| 2021-07-25 20:51:44 +0200 | <davean> | You'd need a spec to show when it might be wrong, I SPECIFICLY overflow Int all the time, on purpose - its a ring |
| 2021-07-25 20:51:51 +0200 | <davean> | if you want a spec, use liquid Haskell |
| 2021-07-25 20:51:56 +0200 | <davean> | then you can check you don't violate it |
| 2021-07-25 20:52:27 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Read error: Connection reset by peer) |
| 2021-07-25 20:53:12 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-25 20:53:26 +0200 | <DigitalKiwi> | davean: https://dpaste.com/8Z6NE5XXT#wrap |
| 2021-07-25 20:54:24 +0200 | <davean> | DigitalKiwi: *cries tears of hours lost to not quite getting something as good as debian via nixos* |
| 2021-07-25 20:54:34 +0200 | <davean> | DigitalKiwi: I've lost production data to having used nix though |
| 2021-07-25 20:54:40 +0200 | <DigitalKiwi> | :( |
| 2021-07-25 20:54:40 +0200 | <davean> | specificly nixpkgs though |
| 2021-07-25 20:54:55 +0200 | <davean> | because IT VIOLATED ALL SANITY AND SPECIFICLY STRIPPED OUT MY DEPENDENCY REQUIREMENTS ON ME |
| 2021-07-25 20:55:17 +0200 | <davean> | TO be specific, I said "I MUST have a version of directory at least as new as this patch level" |
| 2021-07-25 20:55:21 +0200 | <DigitalKiwi> | i have a very much love hate relationship with it |
| 2021-07-25 20:55:30 +0200 | <davean> | and it went "Nah, lier, you'll take what the compiler ships and I'll just do that instead" |
| 2021-07-25 20:56:45 +0200 | <davean> | They claimed all constraints on packages shipped with GHC were bogus and unneccissary and thus to be ignored |
| 2021-07-25 20:56:51 +0200 | <davean> | which is frankly ... insane |
| 2021-07-25 20:57:12 +0200 | <davean> | So instead of not building something, nixpkgs decided it was ok to just force it to build wrong |
| 2021-07-25 20:57:31 +0200 | <davean> | which of *course* it didn't work right under |
| 2021-07-25 20:57:51 +0200 | <DigitalKiwi> | oh yeah i spend a lot of time fighting haskel4nix ;( |
| 2021-07-25 20:57:52 +0200 | <davean> | I required that damn patch because it fixed a bug I was impacted by! |
| 2021-07-25 20:58:29 +0200 | <c_wraith> | I really like the idea of nix, but every time I've tried to use it I end up confused by how they can take a good idea and implement it with so many gotchas |
| 2021-07-25 20:58:46 +0200 | <davean> | c_wraith: yah, nix is a wonderful idea, but the actual implimentation is fucked |
| 2021-07-25 20:58:58 +0200 | <davean> | I want nix's successor |
| 2021-07-25 20:59:02 +0200 | <DigitalKiwi> | https://github.com/pulls?q=is%3Apr+author%3AKiwi+archived%3Afalse+is%3Aclosed |
| 2021-07-25 21:00:34 +0200 | <davean> | c_wraith: I mean, a lot of nix's issues seem to come from its limitations, of not being built *quite* well enough |
| 2021-07-25 21:00:40 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 268 seconds) |
| 2021-07-25 21:00:42 +0200 | <davean> | c_wraith: So like, I get why it has them |
| 2021-07-25 21:00:46 +0200 | <davean> | but that doesn't mean it doesn't have them |
| 2021-07-25 21:00:58 +0200 | <davean> | And I don't know how you fix the core engenering at the bottom of it all |
| 2021-07-25 21:01:25 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 21:01:33 +0200 | <DigitalKiwi> | a lot of the trouble i've had with nix is more directly because of just how broken everything else is >.> |
| 2021-07-25 21:01:54 +0200 | <davean> | DigitalKiwi: fair, theres some of that too |
| 2021-07-25 21:01:59 +0200 | pera | (~pera@user/pera) |
| 2021-07-25 21:03:47 +0200 | dagit_ | (~dagit@2601:1c2:1b7f:9fa0:54b1:3520:a1d6:48b1) |
| 2021-07-25 21:03:47 +0200 | fradet_ | (~fradet@216.252.75.247) (Read error: Connection reset by peer) |
| 2021-07-25 21:03:56 +0200 | <davean> | DigitalKiwi: though I've realized I've got a 3rd problem with nix, and thats that everything is done entirely differently so every time I have to fix something in nix, its always "learn an entire new thing from scratch" because nothing shares approaches in nixpkgs |
| 2021-07-25 21:04:30 +0200 | <davean> | and its not like Haskell where theres some pretty clear cut interface signaling |
| 2021-07-25 21:04:44 +0200 | <DigitalKiwi> | haskell.nix is a lot better than haskell4nix for versions i think |
| 2021-07-25 21:04:49 +0200 | <davean> | you have to get under the hood and into the implimentation of every package, and from there every seperate ecosystem |
| 2021-07-25 21:04:53 +0200 | <davean> | to have a hope of getting anything fixed |
| 2021-07-25 21:05:27 +0200 | dagit_ | dagit |
| 2021-07-25 21:05:40 +0200 | <DigitalKiwi> | yeah like i have a lot of electron apps i maintain and at least 3 different ways they're packaged lol >.> |
| 2021-07-25 21:06:01 +0200 | <davean> | yah, and you maintain those |
| 2021-07-25 21:06:17 +0200 | <davean> | I know of very few nix pkgs that have actually worked for me directly |
| 2021-07-25 21:06:21 +0200 | <davean> | they've ALMOST all had bugs |
| 2021-07-25 21:06:21 +0200 | <juri_> | rewrite electron in haskell. *runs* |
| 2021-07-25 21:06:31 +0200 | <davean> | juri_: I'd prefer to rewrite nix in Haskell |
| 2021-07-25 21:07:01 +0200 | <juri_> | fair enough. |
| 2021-07-25 21:07:16 +0200 | <DigitalKiwi> | https://github.com/haskell-nix/hnix done |
| 2021-07-25 21:07:24 +0200 | <davean> | I think the weaknesses of nix as a language - and as a system - get to the core of a lot of why nix has so many issues |
| 2021-07-25 21:07:28 +0200 | <DigitalKiwi> | (needs work lol) |
| 2021-07-25 21:07:33 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) |
| 2021-07-25 21:07:45 +0200 | <davean> | DigitalKiwi: Thats the language, I mean I think nix as a language spec is a large portion of the problem |
| 2021-07-25 21:08:10 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) |
| 2021-07-25 21:08:14 +0200 | <davean> | There are a lot of things that are hard to solve in it |
| 2021-07-25 21:08:21 +0200 | <davean> | and its very expensive to have a lot of nix code |
| 2021-07-25 21:08:35 +0200 | <davean> | it also doesn't really allow pushing stuff to being data |
| 2021-07-25 21:08:50 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-25 21:09:30 +0200 | <davean> | Its abstraction budget is near zero |
| 2021-07-25 21:11:05 +0200 | <davean> | You really have to translate tihngs *into* nix instead of have nix reference stuff also |
| 2021-07-25 21:11:38 +0200 | <flounders> | I don't have any real experience with either Nix or Guix, but how does Guix compare? |
| 2021-07-25 21:12:04 +0200 | <davean> | flounders: no idea, does anyone have experience with Guix? |
| 2021-07-25 21:12:22 +0200 | <DigitalKiwi> | i know some people do |
| 2021-07-25 21:12:46 +0200 | <DigitalKiwi> | at least one of them seems to like it |
| 2021-07-25 21:13:21 +0200 | <davean> | DigitalKiwi: wow, well thats infinitely more people than I know of even having tried Guix! |
| 2021-07-25 21:15:00 +0200 | berberman_ | (~berberman@user/berberman) |
| 2021-07-25 21:15:54 +0200 | berberman | (~berberman@user/berberman) (Ping timeout: 240 seconds) |
| 2021-07-25 21:16:11 +0200 | zeenk | (~zeenk@2a02:2f04:a008:d600:18f2:3421:bac6:8f38) |
| 2021-07-25 21:16:48 +0200 | drakonis | (drakonis@user/drakonis) |
| 2021-07-25 21:16:49 +0200 | <Clint> | i know more guix people than nix people |
| 2021-07-25 21:16:50 +0200 | <Clint> | different circles |
| 2021-07-25 21:17:25 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-25 21:17:55 +0200 | DigitalKiwi | hugs shapr |
| 2021-07-25 21:18:07 +0200 | <drakonis> | hullo |
| 2021-07-25 21:18:36 +0200 | <DigitalKiwi> | drakonis: here's one now lol |
| 2021-07-25 21:18:39 +0200 | <DigitalKiwi> | bah |
| 2021-07-25 21:18:47 +0200 | <DigitalKiwi> | davean: ^ |
| 2021-07-25 21:18:50 +0200 | <drakonis> | i have been invoked |
| 2021-07-25 21:19:07 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) |
| 2021-07-25 21:19:46 +0200 | oxide | (~lambda@user/oxide) (Ping timeout: 250 seconds) |
| 2021-07-25 21:20:26 +0200 | acro | (~acro@user/acro) (Quit: Bye.) |
| 2021-07-25 21:20:26 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Quit: Bye.) |
| 2021-07-25 21:20:52 +0200 | oxide | (~lambda@user/oxide) |
| 2021-07-25 21:21:00 +0200 | <shapr> | o hi DigitalKiwi |
| 2021-07-25 21:22:38 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-07-25 21:23:08 +0200 | acro | (~acro@user/acro) |
| 2021-07-25 21:23:10 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) (Remote host closed the connection) |
| 2021-07-25 21:23:42 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 21:24:03 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-25 21:24:20 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) |
| 2021-07-25 21:25:38 +0200 | <DigitalKiwi> | drakonis: is guix better than nix/pkgs |
| 2021-07-25 21:26:00 +0200 | <DigitalKiwi> | davean has been burned by haskell4nix as many have ;_; |
| 2021-07-25 21:26:08 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 21:26:09 +0200 | <drakonis> | hmm, i would that it is an improvement in many regards |
| 2021-07-25 21:26:12 +0200 | <drakonis> | say |
| 2021-07-25 21:26:57 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Client Quit) |
| 2021-07-25 21:26:57 +0200 | acro | (~acro@user/acro) (Client Quit) |
| 2021-07-25 21:27:39 +0200 | acro | (~acro@user/acro) |
| 2021-07-25 21:27:42 +0200 | <DigitalKiwi> | davean: there you go 100% of people you know use guix say it's an improvement |
| 2021-07-25 21:28:18 +0200 | <davean> | Apparently |
| 2021-07-25 21:28:22 +0200 | <davean> | Hard to argue with that |
| 2021-07-25 21:28:23 +0200 | <drakonis> | basically, one of the things that i can't say i like about nix is that the underlying language doesnt scale as well as a full language |
| 2021-07-25 21:28:26 +0200 | <DigitalKiwi> | and Clint knows more guix people than nix people so more people like guix than nix |
| 2021-07-25 21:28:27 +0200 | <DigitalKiwi> | qed |
| 2021-07-25 21:28:40 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-07-25 21:28:42 +0200 | Clint | grins. |
| 2021-07-25 21:28:48 +0200 | <davean> | drakonis: I said that! |
| 2021-07-25 21:28:52 +0200 | <drakonis> | there have been a lot of changes to paper over issues with nixlang handing off a lot of tasks to other languages |
| 2021-07-25 21:29:20 +0200 | <drakonis> | guix, being built with guile scheme can avoid these issue |
| 2021-07-25 21:29:22 +0200 | <drakonis> | issues |
| 2021-07-25 21:30:05 +0200 | <drakonis> | it is entirely a set of libraries in scheme that can be reused for other tasks |
| 2021-07-25 21:30:16 +0200 | <drakonis> | so there's a much nicer design |
| 2021-07-25 21:30:58 +0200 | soft-warm | (~soft-warm@2600:8801:db01:8f0:9615:1e45:d06d:2d70) (Ping timeout: 246 seconds) |
| 2021-07-25 21:31:31 +0200 | <drakonis> | heck, i think nix would've been significantly nicer if it was done in ocaml back in the day instead of building a whole new thing just for it |
| 2021-07-25 21:33:15 +0200 | <drakonis> | this is also a strike against the nix language, not just what the package manager is written with |
| 2021-07-25 21:33:55 +0200 | <drakonis> | i'd rather have it built as a dsl of a full language than cooking up a specific language for handling the tasks |
| 2021-07-25 21:34:54 +0200 | pesada | (~agua@2804:18:4f:4b5e:1:0:5480:48f9) |
| 2021-07-25 21:35:43 +0200 | <davean> | So who's rewriting nix? |
| 2021-07-25 21:36:05 +0200 | geekosaur | invokes previously mentioned fable |
| 2021-07-25 21:36:49 +0200 | <maerwald> | davean: lol |
| 2021-07-25 21:36:54 +0200 | <drakonis> | hmm, there's no nix rewrite except for the descendents |
| 2021-07-25 21:37:02 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 265 seconds) |
| 2021-07-25 21:37:23 +0200 | <maerwald> | the biggest problem with nix isn't even the language, imo, but the anarchy of packaging methodologies |
| 2021-07-25 21:37:33 +0200 | <davean> | maerwald: also mentioned that! |
| 2021-07-25 21:37:40 +0200 | agua | (~agua@191.177.175.57) (Ping timeout: 268 seconds) |
| 2021-07-25 21:38:19 +0200 | <drakonis> | there's a nix/guix descendent written in racket but it is too soon to be competitive with nix/nixos/nixpkgs and guix |
| 2021-07-25 21:38:21 +0200 | <DigitalKiwi> | <butterfly meme> is this an echo chamber? |
| 2021-07-25 21:38:32 +0200 | <drakonis> | also tell you what |
| 2021-07-25 21:39:11 +0200 | <maerwald> | drakonis: IDC what language they use... do they have actual QA and non-broken workflows? |
| 2021-07-25 21:39:22 +0200 | <drakonis> | gosh, they sure do |
| 2021-07-25 21:39:29 +0200 | <maerwald> | people treat nixpkgs like hackage, upload whatever |
| 2021-07-25 21:39:42 +0200 | <drakonis> | guix doesnt have nixpkgs' package churn |
| 2021-07-25 21:39:42 +0200 | alx741 | (~alx741@186.178.108.59) (Ping timeout: 250 seconds) |
| 2021-07-25 21:39:48 +0200 | <drakonis> | what's available is generally pretty decent |
| 2021-07-25 21:40:05 +0200 | <drakonis> | there isnt four thousand commits a month but what's there has standards |
| 2021-07-25 21:40:06 +0200 | <sm> | arkanoid: on a practical level, you can forbid use of Int in your code, and audit your libraries, trying to minimize the use of Int there too. hlint might help here, otherwise it shouldn't be too hard to do yourself |
| 2021-07-25 21:40:25 +0200 | <drakonis> | ie: guix doesnt include new langs unless it can successfully bootstrap them all the way to the current release |
| 2021-07-25 21:40:53 +0200 | leeper | (leeper@gateway/vpn/nordvpn/leeper) (Quit: Leaving) |
| 2021-07-25 21:41:27 +0200 | <sm> | arkanoid: also you might like the new Witch lib which helps convert number types safely |
| 2021-07-25 21:41:48 +0200 | <drakonis> | there's also a stronger focus on reproducibility |
| 2021-07-25 21:42:00 +0200 | <drakonis> | also serious talk |
| 2021-07-25 21:42:06 +0200 | <drakonis> | i don't enjoy using the nix lang |
| 2021-07-25 21:42:12 +0200 | <drakonis> | i'd rather write everything in scheme |
| 2021-07-25 21:42:25 +0200 | <drakonis> | its simpler and cleaner to get to where i want |
| 2021-07-25 21:43:22 +0200 | <DigitalKiwi> | i never even learned nix lang real well which is probably part of my problem ;_; |
| 2021-07-25 21:43:39 +0200 | <drakonis> | that's indeed part of the problem |
| 2021-07-25 21:43:53 +0200 | <drakonis> | a thing i've been repeating for a little bit is that working with the nix lang is a lot like banging rocks until it works |
| 2021-07-25 21:44:02 +0200 | <drakonis> | because everything is so poorly explained |
| 2021-07-25 21:44:54 +0200 | <DigitalKiwi> | https://twitter.com/ArchKiwi/status/1249937493308387328?s=20 |
| 2021-07-25 21:45:15 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2021-07-25 21:45:35 +0200 | <drakonis> | so let me start by posting the most important thing about guix |
| 2021-07-25 21:45:37 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-07-25 21:45:41 +0200 | <drakonis> | those docs, they're so good |
| 2021-07-25 21:46:03 +0200 | <drakonis> | the cli, the docs, the repo organization |
| 2021-07-25 21:46:06 +0200 | <drakonis> | its so clean and minty |
| 2021-07-25 21:46:09 +0200 | <DigitalKiwi> | .glirclogs/#haskell/2021-04-29.log:[18:20:18] <DigitalKiwi> i'm not even good at nix lol i just hit shit with hammers until it works |
| 2021-07-25 21:46:11 +0200 | <DigitalKiwi> | lolol |
| 2021-07-25 21:46:11 +0200 | <drakonis> | fresh and minty |
| 2021-07-25 21:46:25 +0200 | <drakonis> | beautiful |
| 2021-07-25 21:46:33 +0200 | <drakonis> | https://guix.gnu.org/en/manual/devel/en/guix.html |
| 2021-07-25 21:46:34 +0200 | mrus | (~mrus@149.28.61.155) (Ping timeout: 240 seconds) |
| 2021-07-25 21:47:09 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2021-07-25 21:47:14 +0200 | <drakonis> | so, one obnoxious nix thing is that there's an severe overuse of wrappers to create execution environments, this has caused nix package interop to be a pain |
| 2021-07-25 21:47:35 +0200 | <drakonis> | rather than cleanly designing packages to not require a lot of cheating during builds to function |
| 2021-07-25 21:48:19 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-25 21:49:56 +0200 | <drakonis> | so you need to install a bunch of ghc packages on nix, you're going to need to invoke haskellpackages.ghcwithpackages |
| 2021-07-25 21:50:14 +0200 | <drakonis> | with guix you just include the packages you want, no weird closure drudgery |
| 2021-07-25 21:50:42 +0200 | <drakonis> | also no programatically generated packages everywhere lol |
| 2021-07-25 21:50:54 +0200 | <drakonis> | you just invoke importers if you need something off hackage |
| 2021-07-25 21:51:12 +0200 | <drakonis> | the importers themselves are available by default and arent written by third parties |
| 2021-07-25 21:51:49 +0200 | burnsidesLlama | (~burnsides@client-8-87.eduroam.oxuni.org.uk) |
| 2021-07-25 21:52:04 +0200 | <drakonis> | https://guix.gnu.org/en/manual/devel/en/guix.html#Contributing maerwald this is for you |
| 2021-07-25 21:52:25 +0200 | <maerwald> | too much work |
| 2021-07-25 21:52:32 +0200 | agua | (~agua@191.177.175.57) |
| 2021-07-25 21:52:36 +0200 | <maerwald> | distros give you burnout :) |
| 2021-07-25 21:52:36 +0200 | <drakonis> | is it ever |
| 2021-07-25 21:52:52 +0200 | <drakonis> | well, the general experience has been pretty smooth |
| 2021-07-25 21:52:55 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Remote host closed the connection) |
| 2021-07-25 21:52:56 +0200 | alx741 | (~alx741@186.178.108.3) |
| 2021-07-25 21:53:18 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2021-07-25 21:53:58 +0200 | ubert | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) |
| 2021-07-25 21:54:25 +0200 | <drakonis> | anyways, life is easier on guix |
| 2021-07-25 21:54:52 +0200 | <drakonis> | it hasnt spired out of control the way nixos has |
| 2021-07-25 21:55:08 +0200 | <maerwald> | does steam work? |
| 2021-07-25 21:55:20 +0200 | <maerwald> | with gpu acceleration |
| 2021-07-25 21:55:26 +0200 | <drakonis> | sure does |
| 2021-07-25 21:55:40 +0200 | <drakonis> | but it requires using nonguix to get the stuff that doesnt go on the mainline repos |
| 2021-07-25 21:55:46 +0200 | <drakonis> | pretty clean affair i suppose? |
| 2021-07-25 21:55:57 +0200 | pesada | (~agua@2804:18:4f:4b5e:1:0:5480:48f9) (Ping timeout: 245 seconds) |
| 2021-07-25 21:56:40 +0200 | <drakonis> | except for nvidia, but that one's because nobody really put a ton of effort on making sure it works seamlessly |
| 2021-07-25 21:56:56 +0200 | <drakonis> | you can install and use it but it has a couple issues that still need ironing out |
| 2021-07-25 21:57:44 +0200 | <drakonis> | the repo is called nonguix |
| 2021-07-25 21:57:56 +0200 | <drakonis> | there's an irc channel with the same name here in libera |
| 2021-07-25 22:00:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-25 22:05:09 +0200 | juhp | (~juhp@128.106.188.220) (Ping timeout: 258 seconds) |
| 2021-07-25 22:06:45 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-07-25 22:08:56 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2021-07-25 22:09:40 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-25 22:09:59 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) |
| 2021-07-25 22:10:58 +0200 | xff0x_ | (~xff0x@2001:1a81:5200:1d00:bb8d:5843:c31e:244e) (Ping timeout: 268 seconds) |
| 2021-07-25 22:11:43 +0200 | xff0x_ | (~xff0x@port-92-195-69-103.dynamic.as20676.net) |
| 2021-07-25 22:12:42 +0200 | ubert | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2021-07-25 22:14:32 +0200 | eagleflo | (~aku@eagleflow.fi) (Remote host closed the connection) |
| 2021-07-25 22:14:37 +0200 | ubert | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) |
| 2021-07-25 22:14:56 +0200 | jeetelongname | (~jeet@host-89-241-98-229.as13285.net) |
| 2021-07-25 22:16:41 +0200 | <janus> | is there a way in haskell to transform do { x<-receive; send x } into StateT $ \case State0 -> do { x<-receive; pure (State1 x, Nothing); }; State1 x -> (State0, Just x) } |
| 2021-07-25 22:17:45 +0200 | <janus> | i suspect not, unless i add a "yield" between receive and send... but even if i do, how would i generate those state constructors automatically? |
| 2021-07-25 22:18:29 +0200 | <janus> | maybe with templateHaskell there is a way to say "stuff every captured binding of the do into a parameter list" ? |
| 2021-07-25 22:18:56 +0200 | <janus> | or maybe with RebindableSyntax? |
| 2021-07-25 22:19:33 +0200 | chomwitt | (~chomwitt@ppp-94-67-193-120.home.otenet.gr) |
| 2021-07-25 22:20:23 +0200 | <janus> | if do notation is "reprogrammable semicolon", what is the "reprogrammable monadic bind" ? |
| 2021-07-25 22:20:47 +0200 | jkachmar[m] | (~jkachmarm@2001:470:69fc:105::c72d) |
| 2021-07-25 22:21:07 +0200 | <xerox> | oh I know that one |
| 2021-07-25 22:21:35 +0200 | <xerox> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/rebindable_syntax.html?highlight=rebindabl… |
| 2021-07-25 22:22:10 +0200 | <yushyin> | QualifiedDo? |
| 2021-07-25 22:22:46 +0200 | <geekosaur> | or in 9.2 https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/qualified_do.html |
| 2021-07-25 22:25:28 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-07-25 22:26:17 +0200 | jkachmar[m] | jkachmar |
| 2021-07-25 22:29:28 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 2021-07-25 22:30:40 +0200 | jkachmar | (~jkachmarm@2001:470:69fc:105::c72d) (Quit: Reconnecting) |
| 2021-07-25 22:30:54 +0200 | jkachmar | (~jkachmar@2001:470:69fc:105::c72d) |
| 2021-07-25 22:31:05 +0200 | acro | (~acro@user/acro) (Quit: Bye.) |
| 2021-07-25 22:31:05 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Quit: Bye.) |
| 2021-07-25 22:31:24 +0200 | jmorris | (uid433911@id-433911.stonehaven.irccloud.com) |
| 2021-07-25 22:31:47 +0200 | acro | (~acro@user/acro) |
| 2021-07-25 22:32:47 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-07-25 22:33:07 +0200 | <arkanoid> | sm: thanks for the answer, that's exactly what I'm planning. I'm also looking into hlint for the option to restrict type usage (it is just hinted in the readme) |
| 2021-07-25 22:38:16 +0200 | <arkanoid> | I'm also considering Safe Haskell https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/safe-haskell.html |
| 2021-07-25 22:39:15 +0200 | chris_ | (~chris@81.96.113.213) |
| 2021-07-25 22:39:30 +0200 | Guest14 | (~Guest14@2a02:1210:601c:a300:5935:4f81:fbf2:115c) |
| 2021-07-25 22:40:35 +0200 | <monochrom> | Safe Haskell only avoids unsafePerformIO and unchecked type casting, not arithmetic overflow. |
| 2021-07-25 22:40:51 +0200 | <janus> | arkanoid: did you see this? https://libredd.it/r/haskell/comments/msa3oq/safe_haskell/ |
| 2021-07-25 22:41:00 +0200 | <monochrom> | Yes one has to eventually realized that everyone defines "safe" differently. |
| 2021-07-25 22:41:18 +0200 | <janus> | yushyin: ooooh i'll check it out.. didn't cross my mind somehow |
| 2021-07-25 22:42:37 +0200 | <janus> | xerox: i think qualifiedDo looks superior to RebindableSyntax.. so i'll check that out first |
| 2021-07-25 22:43:30 +0200 | vicfred_ | (~vicfred@fixed-187-190-192-58.totalplay.net) |
| 2021-07-25 22:45:35 +0200 | <arkanoid> | janus: thanks, I've just met Safe Haskell didn't know about it's background story |
| 2021-07-25 22:45:49 +0200 | <drakonis> | davean: is your issue with nix either technical or social? |
| 2021-07-25 22:45:56 +0200 | vicfred__ | (~vicfred@94.198.42.69) |
| 2021-07-25 22:46:05 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-25 22:46:29 +0200 | <drakonis> | just to be sure |
| 2021-07-25 22:46:34 +0200 | <davean> | drakonis: i'm in a meeting ATM, the conversatio nwas right before you joined |
| 2021-07-25 22:46:35 +0200 | <janus> | arkanoid: i like this quote by Cale |
| 2021-07-25 22:46:38 +0200 | dunkeln | (~dunkeln@94.129.69.87) (Ping timeout: 265 seconds) |
| 2021-07-25 22:46:41 +0200 | <janus> | > Cale: Safe Haskell doesn't mean it's safe to compile the code, it means a bunch of random stuff which has to do with trying to make sure expression evaluation is referentially transparent... |
| 2021-07-25 22:46:42 +0200 | <lambdabot> | <hint>:1:62: error: parse error on input ‘,’ |
| 2021-07-25 22:46:45 +0200 | <drakonis> | ah i see |
| 2021-07-25 22:46:46 +0200 | vicfred | (~vicfred@user/vicfred) (Ping timeout: 272 seconds) |
| 2021-07-25 22:47:04 +0200 | Null_A | (~null_a@2601:645:8700:2290:707f:6ddd:516:dcea) (Remote host closed the connection) |
| 2021-07-25 22:47:13 +0200 | <geekosaur> | quick summary of davean's expressed position: both |
| 2021-07-25 22:47:27 +0200 | <geekosaur> | both issues with the language, and issues with QA/procedures |
| 2021-07-25 22:47:51 +0200 | <davean> | The concept is still a great one |
| 2021-07-25 22:48:03 +0200 | <monochrom> | Technical problems have social origins. Humans are the cause of human problems. |
| 2021-07-25 22:48:05 +0200 | <davean> | drakonis: https://ircbrowse.tomsmeding.com/browse/lchaskell is probably useful though |
| 2021-07-25 22:48:27 +0200 | vicfred_ | (~vicfred@fixed-187-190-192-58.totalplay.net) (Ping timeout: 245 seconds) |
| 2021-07-25 22:48:37 +0200 | Guest14 | (~Guest14@2a02:1210:601c:a300:5935:4f81:fbf2:115c) (Quit: Client closed) |
| 2021-07-25 22:48:52 +0200 | MorrowM | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-25 22:49:18 +0200 | <arkanoid> | monochrom: I know that Safe Haskell was not covering that, but as I'm studying haskell to improve my control over the complexity. I generally like the options to lockdown the language in that direction, as I tend to do the same with every one |
| 2021-07-25 22:49:32 +0200 | jco | (~jco@213-64-226-9-no542.tbcn.telia.com) (Ping timeout: 265 seconds) |
| 2021-07-25 22:50:01 +0200 | Morrow | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 265 seconds) |
| 2021-07-25 22:50:16 +0200 | ub | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) |
| 2021-07-25 22:50:32 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-25 22:51:04 +0200 | acidjnk | (~acidjnk@p200300d0c72b9549b83720658b9c4b74.dip0.t-ipconnect.de) |
| 2021-07-25 22:52:02 +0200 | vicfred__ | (~vicfred@94.198.42.69) (Quit: Leaving) |
| 2021-07-25 22:52:12 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2021-07-25 22:52:17 +0200 | ubert | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) (Ping timeout: 268 seconds) |
| 2021-07-25 22:52:18 +0200 | ub | ubert |
| 2021-07-25 22:52:28 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 22:54:34 +0200 | <drakonis> | davean: fair enough |
| 2021-07-25 22:54:40 +0200 | <drakonis> | i checked the logs |
| 2021-07-25 22:54:52 +0200 | <drakonis> | but yes, i think guix can do much better in both regards |
| 2021-07-25 22:55:00 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-25 22:55:05 +0200 | <davean> | drakonis: I've love more of a conversation when I have the ability to be present |
| 2021-07-25 22:55:30 +0200 | <drakonis> | cool |
| 2021-07-25 22:55:38 +0200 | <arkanoid> | drakonis: I'm a new nix user, may I ask what's the deal? |
| 2021-07-25 22:56:17 +0200 | <drakonis> | nix has grown incredibly fast and hasn't adapted to it |
| 2021-07-25 22:56:36 +0200 | <drakonis> | i'd say its ideas are great but the implementation is archaic |
| 2021-07-25 22:57:08 +0200 | <drakonis> | nix is something that is best implemented inside a complete language instead of rolling out your own |
| 2021-07-25 22:57:16 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Quit: Bye.) |
| 2021-07-25 22:57:17 +0200 | acro | (~acro@user/acro) (Quit: Bye.) |
| 2021-07-25 22:57:55 +0200 | <arkanoid> | drakonis: what scares me is the git commit requirements to keep everything on track. I mean, every package update is a git commit, the effort is massive |
| 2021-07-25 22:58:35 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2021-07-25 22:58:41 +0200 | <janus> | how is that a problem? rebasing is easy |
| 2021-07-25 22:58:59 +0200 | acro | (~acro@user/acro) |
| 2021-07-25 22:59:27 +0200 | <drakonis> | nix routinely has gobs of commits aiming to clean up the inconsistent packaging |
| 2021-07-25 22:59:39 +0200 | meinside_ | (uid24933@id-24933.brockwell.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-25 23:00:01 +0200 | <arkanoid> | I mean that the pressure on admins is huge |
| 2021-07-25 23:00:40 +0200 | <janus> | ah right... yeah i guess that's what they're trying to solve with flakes |
| 2021-07-25 23:00:47 +0200 | <janus> | just to open up another can of worms ;) |
| 2021-07-25 23:01:00 +0200 | <arkanoid> | exactly |
| 2021-07-25 23:01:09 +0200 | <DigitalKiwi> | .glirclogs/#haskell/2021-03-27.log:[00:42:11] <DigitalKiwi> nix is great in that it solves a ton of problems i had, even more i didn't know i had, makes things trivial that i didn't even think were possible or know i wanted, and creates a bunch of problems along the way! (and solves those too though lol) |
| 2021-07-25 23:01:50 +0200 | <drakonis> | flakes is one of those things trying to paper over the issues |
| 2021-07-25 23:02:00 +0200 | <drakonis> | because nix does not do multiple sources all that well |
| 2021-07-25 23:02:06 +0200 | <sm> | arkanoid there's also Liquid Haskell |
| 2021-07-25 23:02:34 +0200 | <arkanoid> | DigitalKiwi: yes but is a moving target. I mean, not your nix-shell, but the project is a huge machine with one million gears that have to be perfectly aligned to work |
| 2021-07-25 23:02:49 +0200 | <drakonis> | arkanoid: it has a rather large amount of leaf packages |
| 2021-07-25 23:02:59 +0200 | <drakonis> | it has very little quality control too |
| 2021-07-25 23:03:28 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-25 23:03:38 +0200 | <janus> | can nix be typed? would it solve the problem of aligning 1M gears? |
| 2021-07-25 23:04:02 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-07-25 23:04:07 +0200 | fendor | (~fendor@77.119.223.76.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-07-25 23:04:25 +0200 | <arkanoid> | drakonis: well hydra does kinda large work for quality control |
| 2021-07-25 23:04:32 +0200 | <drakonis> | guix has cuirass as well |
| 2021-07-25 23:04:41 +0200 | <drakonis> | janus: they tried that once, it became a new lang |
| 2021-07-25 23:04:49 +0200 | <drakonis> | i'm not exactly happy with that but well |
| 2021-07-25 23:04:57 +0200 | <janus> | drakonis: oh, what is that called? |
| 2021-07-25 23:05:01 +0200 | <drakonis> | nickel |
| 2021-07-25 23:05:16 +0200 | <drakonis> | they're going for the config lang crowd lol |
| 2021-07-25 23:05:28 +0200 | <drakonis> | it feels like a vanity project at this point |
| 2021-07-25 23:05:55 +0200 | <drakonis> | hydra is not quality control though |
| 2021-07-25 23:06:02 +0200 | <drakonis> | its for building the archive |
| 2021-07-25 23:06:28 +0200 | <arkanoid> | yeah but at least it tell you which derivation builds |
| 2021-07-25 23:07:04 +0200 | <drakonis> | sure, but when someone's already writing a package for submission, they've already made sure it works to some degree |
| 2021-07-25 23:07:41 +0200 | <maerwald> | heh |
| 2021-07-25 23:07:46 +0200 | <maerwald> | that degree can vary wildly |
| 2021-07-25 23:07:50 +0200 | <drakonis> | indeed it can |
| 2021-07-25 23:07:58 +0200 | <drakonis> | and with how nix works, there are a lot of edge cases |
| 2021-07-25 23:08:01 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 258 seconds) |
| 2021-07-25 23:08:05 +0200 | <drakonis> | so, exhibit A: |
| 2021-07-25 23:08:14 +0200 | <arkanoid> | yeah, but then one dependency gets updated and you're back to hydra until libc get's updated and you rebuild all |
| 2021-07-25 23:08:16 +0200 | <drakonis> | have you noticed that nobody recommends you to use profiles these days? |
| 2021-07-25 23:08:18 +0200 | <monochrom> | Yes, it works on their computer. |
| 2021-07-25 23:08:31 +0200 | <DigitalKiwi> | good luck getting the hydra ui to load before the heat death of the universe |
| 2021-07-25 23:08:38 +0200 | <drakonis> | cuirass is very sane thankfully |
| 2021-07-25 23:08:43 +0200 | <drakonis> | but back to A |
| 2021-07-25 23:09:09 +0200 | <drakonis> | as it turns out, the nix community has pretty much reduced nix-env/profiles to irrelevance |
| 2021-07-25 23:09:11 +0200 | <sm> | I'm hoping tweag's nickel might be nix 2 |
| 2021-07-25 23:09:33 +0200 | <sm> | I assume it's closer to that than guix is |
| 2021-07-25 23:09:35 +0200 | <drakonis> | due to the majority of packages expecting you to run them with nix-shell |
| 2021-07-25 23:09:36 +0200 | <drakonis> | nahhhh |
| 2021-07-25 23:09:36 +0200 | <arkanoid> | to me the best nix feature is nix-shell |
| 2021-07-25 23:09:42 +0200 | <drakonis> | its not going to be nix 2 |
| 2021-07-25 23:09:44 +0200 | <DigitalKiwi> | i'm under the impression nickel is diw |
| 2021-07-25 23:09:50 +0200 | <drakonis> | diw? |
| 2021-07-25 23:09:54 +0200 | <DigitalKiwi> | dead in water |
| 2021-07-25 23:10:08 +0200 | ubert | (~Thunderbi@91.141.46.134.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-07-25 23:10:10 +0200 | <drakonis> | nickel is a vanity project that isnt going to reasonably compete with guix because, first of all |
| 2021-07-25 23:10:24 +0200 | <drakonis> | guile scheme is a general purpose language |
| 2021-07-25 23:10:39 +0200 | <monochrom> | http://math.andrej.com/2008/02/02/the-hydra-game/ also has a chance of not ending until the heat death of the universe :) |
| 2021-07-25 23:11:01 +0200 | <drakonis> | nix-shell is imo a way to corner yourself with package design |
| 2021-07-25 23:11:41 +0200 | <drakonis> | it makes package interop a lot harder than it needs to be |
| 2021-07-25 23:12:10 +0200 | <hendursaga> | drakonis: pardon, what's nickel? |
| 2021-07-25 23:12:31 +0200 | <DigitalKiwi> | https://github.com/tweag/nickel |
| 2021-07-25 23:12:32 +0200 | <drakonis> | https://github.com/tweag/nickel |
| 2021-07-25 23:12:34 +0200 | <arkanoid> | drakonis: I find nix-shell much more convenient than docker environment to make portable/reproducible projects |
| 2021-07-25 23:12:34 +0200 | <drakonis> | thre |
| 2021-07-25 23:12:35 +0200 | <drakonis> | there |
| 2021-07-25 23:12:38 +0200 | <drakonis> | indeed it is |
| 2021-07-25 23:12:56 +0200 | curiousgay | (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 255 seconds) |
| 2021-07-25 23:13:10 +0200 | <drakonis> | however making environments that require package interop can be a pain |
| 2021-07-25 23:13:25 +0200 | <drakonis> | i wanted to try ocaml with nix and as it turns out, there are multiple ways to get ocaml to work |
| 2021-07-25 23:13:38 +0200 | <drakonis> | each one of them has a specific function you have to invoke in order to generate an environment |
| 2021-07-25 23:13:40 +0200 | acro | (~acro@user/acro) (Quit: Bye.) |
| 2021-07-25 23:13:40 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Quit: Bye.) |
| 2021-07-25 23:13:53 +0200 | zeenk | (~zeenk@2a02:2f04:a008:d600:18f2:3421:bac6:8f38) (Quit: Konversation terminated!) |
| 2021-07-25 23:14:30 +0200 | <drakonis> | the way nixpkgs works is that it does not assume you're going to want interop |
| 2021-07-25 23:14:41 +0200 | <DigitalKiwi> | [12:36:15] * DigitalKiwi has 4 SML compilers |
| 2021-07-25 23:14:41 +0200 | <DigitalKiwi> | [12:36:19] * DigitalKiwi rarely writes SML |
| 2021-07-25 23:14:45 +0200 | <drakonis> | lol |
| 2021-07-25 23:14:58 +0200 | <drakonis> | let me find the manual, the new website is uhhh |
| 2021-07-25 23:15:04 +0200 | <drakonis> | not as good as i originally thought it'd be |
| 2021-07-25 23:15:10 +0200 | <monochrom> | haha |
| 2021-07-25 23:15:15 +0200 | <geekosaur> | isn't that always true? |
| 2021-07-25 23:15:17 +0200 | <hendursaga> | arkanoid: have you tried buildah yet? for containers. |
| 2021-07-25 23:15:54 +0200 | <drakonis> | when i was running nixos, i had to turn to running containers, as otherwise i'd have to bang my head against the weird interactions |
| 2021-07-25 23:16:19 +0200 | <drakonis> | https://nixos.org/manual/nixpkgs/stable/#chap-language-support refer to this |
| 2021-07-25 23:16:34 +0200 | <arkanoid> | hendursaga: yeah, tried buildah, podman and others. I'm generally speaking about containers. Nix gives stronger assumptions, also you can build docker images with nix |
| 2021-07-25 23:16:51 +0200 | <maerwald> | I can also build them without nix |
| 2021-07-25 23:17:04 +0200 | <drakonis> | we're in a world where languages have to do interop, heck, even nix has to call out to other languages, since it is so limited |
| 2021-07-25 23:17:11 +0200 | acro | (~acro@user/acro) |
| 2021-07-25 23:17:14 +0200 | Null_A | (~null_a@2601:645:8700:2290:b1d7:1b8a:64ba:1a81) |
| 2021-07-25 23:17:14 +0200 | <DigitalKiwi> | https://christine.website/blog/i-was-wrong-about-nix-2020-02-10 |
| 2021-07-25 23:17:16 +0200 | <drakonis> | 15.25.2.3.2. Python package using maturin |
| 2021-07-25 23:17:22 +0200 | <drakonis> | Python packages that use Maturin can be built with fetchCargoTarball, cargoSetupHook, and maturinBuildHook. For example, the following (partial) derivation builds the retworkx Python package. fetchCargoTarball and cargoSetupHook are used to fetch and set up the crate dependencies. maturinBuildHook is used to perform the build. |
| 2021-07-25 23:17:24 +0200 | <drakonis> | see this lol |
| 2021-07-25 23:17:53 +0200 | <DigitalKiwi> | maerwald: you can build them better with nix lol |
| 2021-07-25 23:18:04 +0200 | <bryan[m]> | Nixpkgs has grown organically and exponentially, and because flakes didn't exist it was all thrown into the same repo to solve the dependency question. Thus multiple ways to package $foolang packages, etc. I think the Nix ecosystem will grow beyond this state of affairs |
| 2021-07-25 23:18:05 +0200 | <hendursaga> | arkanoid: you can build Docker images with Guix too, I've done that, it's pretty good |
| 2021-07-25 23:18:06 +0200 | <drakonis> | there's python packages with rust deps these days, if you want to build something that requries rust, you need to do hoop jumping |
| 2021-07-25 23:18:07 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-25 23:18:11 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-07-25 23:18:21 +0200 | <maerwald> | DigitalKiwi: one of my best decisions was getting rid of nix in a company :p |
| 2021-07-25 23:18:23 +0200 | <drakonis> | bryan[m]: it has to grow beyond that quickly |
| 2021-07-25 23:18:32 +0200 | <drakonis> | because this is not a good state of affairs |
| 2021-07-25 23:18:36 +0200 | <maerwald> | I'd do it again |
| 2021-07-25 23:19:07 +0200 | <bryan[m]> | Ok, sure :) |
| 2021-07-25 23:19:07 +0200 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2021-07-25 23:19:09 +0200 | <drakonis> | basically, i still cant believe i can install some emacs deps and it'll show on my emacs install |
| 2021-07-25 23:19:16 +0200 | <drakonis> | no weird nix-shell magic required |
| 2021-07-25 23:19:30 +0200 | <drakonis> | nix-shell is the root of many of my nix issues |
| 2021-07-25 23:19:42 +0200 | <arkanoid> | how? |
| 2021-07-25 23:19:47 +0200 | <arkanoid> | I'm not following you |
| 2021-07-25 23:19:51 +0200 | <drakonis> | i've already said it a dozen times |
| 2021-07-25 23:19:58 +0200 | <arkanoid> | sorry :( |
| 2021-07-25 23:19:59 +0200 | <drakonis> | half a dozen times, rather. |
| 2021-07-25 23:20:07 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2021-07-25 23:20:09 +0200 | <arkanoid> | joined the discussion late |
| 2021-07-25 23:20:12 +0200 | <drakonis> | https://nixos.org/manual/nixpkgs/stable/#chap-language-support check this chapter in the manual |
| 2021-07-25 23:20:29 +0200 | <drakonis> | count how many times you have to do something like withpackages |
| 2021-07-25 23:20:51 +0200 | <drakonis> | or invoke weird nixlang magic to actually make something work |
| 2021-07-25 23:21:06 +0200 | mikoto-chan | (~mikoto-ch@ip-193-121-10-50.dsl.scarlet.be) (Ping timeout: 250 seconds) |
| 2021-07-25 23:21:12 +0200 | <drakonis> | the issue here is that you have to use nix-shell nowadays because otherwise things dont work as they should |
| 2021-07-25 23:21:16 +0200 | <arkanoid> | I know, I wrote dozen of python derivations for my nix-shells |
| 2021-07-25 23:21:41 +0200 | <drakonis> | you're not expected to mix things together with those environments |
| 2021-07-25 23:21:53 +0200 | <drakonis> | i don't think this is a very pleasant thing to deal with |
| 2021-07-25 23:22:10 +0200 | <DigitalKiwi> | https://github.com/NixOS/nixpkgs/pull/65775/commits this took me several months ;_; |
| 2021-07-25 23:22:11 +0200 | <arkanoid> | much better than pip, conda, or docker |
| 2021-07-25 23:22:15 +0200 | <drakonis> | certainly |
| 2021-07-25 23:22:20 +0200 | <drakonis> | but have you dealt with guix yet? |
| 2021-07-25 23:22:29 +0200 | <arkanoid> | no, not yet |
| 2021-07-25 23:22:35 +0200 | <drakonis> | the python situation there is as simple as dropping into an environment or installing to the profile |
| 2021-07-25 23:22:51 +0200 | <drakonis> | you can run python and it'll work as expected |
| 2021-07-25 23:23:14 +0200 | <drakonis> | let me link to a nixcon talk by a nix contributor that used guix for a while |
| 2021-07-25 23:23:14 +0200 | nate3 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 23:23:36 +0200 | <arkanoid> | drakonis: how are the millions of python packages with their multi-language compiled dependencies handled in guix? |
| 2021-07-25 23:24:24 +0200 | <drakonis> | cleanly, really. |
| 2021-07-25 23:24:31 +0200 | <janus> | DigitalKiwi: why is Nickel dead in the water? still contributed to by Eelco and Tweag, so seems to have official blessing. and similar to the nix language |
| 2021-07-25 23:24:42 +0200 | <drakonis> | janus: you presume people will migrate to it |
| 2021-07-25 23:24:49 +0200 | <janus> | doesn't demand a clean break since it allows dynamic typing also |
| 2021-07-25 23:24:58 +0200 | yoctocell | (~user@h87-96-130-155.cust.a3fiber.se) (Ping timeout: 240 seconds) |
| 2021-07-25 23:24:59 +0200 | <drakonis> | https://guix.gnu.org/manual/en/html_node/Python-Modules.html |
| 2021-07-25 23:25:18 +0200 | <drakonis> | Anything that does not fall in the previous categories goes to inputs, for example programs or C libraries required for building Python packages containing C extensions. |
| 2021-07-25 23:25:51 +0200 | <drakonis> | if i want to build something with rust, all i need to do is add it to inputs |
| 2021-07-25 23:25:52 +0200 | <janus> | drakonis: if Tweag hires a bunch of interns to make a Nickel based Alpine distro, with nickelpkgs full of the some common flakes, many nixpkgs contributors will jump right in |
| 2021-07-25 23:25:59 +0200 | <drakonis> | we'll see about that |
| 2021-07-25 23:26:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-25 23:26:17 +0200 | kenran | (~kenran@200116b82bb5e400f1c7c01f9f0a47a0.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2021-07-25 23:26:25 +0200 | <drakonis> | https://github.com/pjotrp/guix-notes/blob/master/PYTHON.org |
| 2021-07-25 23:26:29 +0200 | <janus> | and written in Rust, can even get all the C++-haters on board |
| 2021-07-25 23:26:32 +0200 | <DigitalKiwi> | comments i've seen by people at tweag lol |
| 2021-07-25 23:27:25 +0200 | <drakonis> | you once again assume that rust will contribute to it |
| 2021-07-25 23:27:38 +0200 | <arkanoid> | drakonis: let's start from the fact that there's no search function on the packages page of the official website :D https://guix.gnu.org/en/packages/ |
| 2021-07-25 23:27:48 +0200 | <drakonis> | ah yes |
| 2021-07-25 23:27:54 +0200 | <drakonis> | but there's on guix-hpc i guess |
| 2021-07-25 23:27:56 +0200 | <drakonis> | hold on |
| 2021-07-25 23:28:02 +0200 | <janus> | i don't think it will detract from it! so given that nixpkgs "works" as a community, i don't see why there can't be another community around Nickel |
| 2021-07-25 23:28:09 +0200 | <drakonis> | https://hpc.guix.info/browse |
| 2021-07-25 23:29:01 +0200 | <bryan[m]> | It's almost like... all software has flaws... but often manages to provide value anyway. I feel like I walked into a technology roast in here just now. |
| 2021-07-25 23:29:15 +0200 | <arkanoid> | half of the python packages I need are missing. I'm not talking about fringe packages, but important tools used for science by thousands of users. |
| 2021-07-25 23:29:49 +0200 | <drakonis> | oh? |
| 2021-07-25 23:29:52 +0200 | <drakonis> | do tell though |
| 2021-07-25 23:30:05 +0200 | <drakonis> | guix has a decent amount of science users from what i hear |
| 2021-07-25 23:30:31 +0200 | pera | (~pera@user/pera) (Ping timeout: 268 seconds) |
| 2021-07-25 23:30:35 +0200 | <janus> | guix is the preferred build system of bitcoiners |
| 2021-07-25 23:30:40 +0200 | <janus> | religion... even stronger than science |
| 2021-07-25 23:30:45 +0200 | <janus> | ;) |
| 2021-07-25 23:31:39 +0200 | <drakonis> | ha |
| 2021-07-25 23:31:41 +0200 | <drakonis> | idk |
| 2021-07-25 23:31:44 +0200 | <drakonis> | i'm not a bitcoiner |
| 2021-07-25 23:31:51 +0200 | <arkanoid> | but not enough to cover at least the numfocus affiliated projects https://numfocus.org/sponsored-projects/affiliated-projects |
| 2021-07-25 23:32:00 +0200 | <drakonis> | on the other hand, nix has quite a lot of bitcoin adjacent packages |
| 2021-07-25 23:32:01 +0200 | pera | (~pera@user/pera) |
| 2021-07-25 23:32:07 +0200 | <janus> | ok but seriously, one thing i don't understand about guix: people say it is good to use a general purpose programming language. but why? i don't see many mainstream algorithms used in nixpkgs |
| 2021-07-25 23:32:23 +0200 | <janus> | so why are they useful in guix? this is _not_ general-purpose computing |
| 2021-07-25 23:32:33 +0200 | <drakonis> | janus: because it lets them reuse the code for a variety of tasks |
| 2021-07-25 23:32:45 +0200 | <drakonis> | its not a language running on top of a c++ runtime |
| 2021-07-25 23:32:45 +0200 | <bryan[m]> | I'm following this email thread about open source foundations, and it's making me realize how long I've been tracking open source stuff as a user or occasional contributor, and how things have changed in that time. I think it's interesting that whether OS lives or dies is now seen as depending on which companies support it and pay people to work on it. I think that's been the case for a long while, but I never really thought about it |
| 2021-07-25 23:33:07 +0200 | <drakonis> | arkanoid: maybe it would help if someone packaged them i suppose |
| 2021-07-25 23:33:08 +0200 | <janus> | drakonis: python is a language running on top of a C runtime. why does the runtime matter so much? |
| 2021-07-25 23:33:16 +0200 | <drakonis> | because its scheme |
| 2021-07-25 23:33:26 +0200 | <drakonis> | the ability to reuse code is very much useful |
| 2021-07-25 23:33:36 +0200 | <janus> | why can't you reuse a nix function? |
| 2021-07-25 23:33:39 +0200 | <maerwald> | bryan[m]: what thread? |
| 2021-07-25 23:33:53 +0200 | <janus> | what makes a scheme function more reusable than a nix function? |
| 2021-07-25 23:34:04 +0200 | <drakonis> | because nix isn't as capable as a scheme procedure |
| 2021-07-25 23:34:17 +0200 | <drakonis> | one moment |
| 2021-07-25 23:34:31 +0200 | <arkanoid> | drakonis: so the point stands, AFAIKS the science community that shares my shoes are better served with nix ... still |
| 2021-07-25 23:34:33 +0200 | <bryan[m]> | There's an email list ostensibly for members of foundations (Linux Foundation, Apache Foundation, etc etc) |
| 2021-07-25 23:34:45 +0200 | <drakonis> | hpc loves guix right now |
| 2021-07-25 23:34:51 +0200 | <davean> | janus: My claim earlier was you didn't see such things used in nix because effectively you *couldn't do them in nix* |
| 2021-07-25 23:34:55 +0200 | <davean> | not because you didn't want to |
| 2021-07-25 23:35:03 +0200 | <drakonis> | ^ |
| 2021-07-25 23:35:16 +0200 | <drakonis> | its not a matter of not using, its a matter of being unable to. |
| 2021-07-25 23:35:39 +0200 | <drakonis> | also, adding new features to nix requires going through the underlying c++ code used to write the package manager |
| 2021-07-25 23:35:53 +0200 | <Hecate> | Cale: yes, overlapping instances are terrible |
| 2021-07-25 23:36:08 +0200 | <janus> | but it is a system that generates a bunch of calls to a shell, why do you need a large runtime? |
| 2021-07-25 23:36:11 +0200 | <drakonis> | also i'm not sure how it is better served by nix when its goals do not align with the science community's |
| 2021-07-25 23:36:22 +0200 | <drakonis> | that's the problem lol |
| 2021-07-25 23:36:24 +0200 | <drakonis> | calls to a shell |
| 2021-07-25 23:36:41 +0200 | <drakonis> | https://hpc.guix.info/blog/2021/05/hpc-reproducible-research-in-guix-1.3.0/ |
| 2021-07-25 23:36:55 +0200 | <drakonis> | scheme's runtime isnt large, its very minimal btw |
| 2021-07-25 23:37:02 +0200 | <drakonis> | it is very powerful however. |
| 2021-07-25 23:37:12 +0200 | <janus> | ok but i don't wanna rewrite the build systems of every single package. they are more or less all written in shell |
| 2021-07-25 23:37:35 +0200 | <drakonis> | you want to implement something new in guile? you can do it in a very reasonable amount of time and share that across other libraries |
| 2021-07-25 23:38:01 +0200 | <drakonis> | the deployment code in guix reuses existing guix library code |
| 2021-07-25 23:38:12 +0200 | <monochrom> | Any haskell discussion? |
| 2021-07-25 23:38:55 +0200 | <drakonis> | monochrom: c'mon |
| 2021-07-25 23:38:56 +0200 | <drakonis> | dont end the fun |
| 2021-07-25 23:39:20 +0200 | <monochrom> | Take note that I haven't raised it for, what, hours. |
| 2021-07-25 23:39:20 +0200 | <maerwald> | I think it was more of him begging us to talk about haskell |
| 2021-07-25 23:39:25 +0200 | <drakonis> | perhaps we should continue on #haskell-offtopic? |
| 2021-07-25 23:39:25 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Remote host closed the connection) |
| 2021-07-25 23:39:28 +0200 | <drakonis> | idk |
| 2021-07-25 23:39:33 +0200 | <arkanoid> | drakonis: yeah, sure, it says to have "upgraded Scipy to 1.6.0", but as you can see from the webpage https://www.scipy.org/ it says "Large parts of the SciPy ecosystem (including all six projects above) are fiscally sponsored by NumFOCUS". Point is that most of the NumFocus projects are still not in guix, so that's "scipy is in guix" is a false statement |
| 2021-07-25 23:39:43 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2021-07-25 23:39:50 +0200 | <drakonis> | uh |
| 2021-07-25 23:39:50 +0200 | <maerwald> | #haskell-nix? |
| 2021-07-25 23:39:52 +0200 | <drakonis> | but it is on guix |
| 2021-07-25 23:40:01 +0200 | <drakonis> | what do you mean scipy isnt |
| 2021-07-25 23:40:30 +0200 | <maerwald> | I wish pattern matches were first-class |
| 2021-07-25 23:40:42 +0200 | <arkanoid> | I think we're offtopic here, what about continuing somewhere else? |
| 2021-07-25 23:40:54 +0200 | <davean> | I support taking over nix channels with chat about improvements over nix |
| 2021-07-25 23:41:05 +0200 | <monochrom> | heh |
| 2021-07-25 23:41:07 +0200 | <drakonis> | we can take it to #nixos-chat instead |
| 2021-07-25 23:41:15 +0200 | <drakonis> | or the guix owned channels, i dont know |
| 2021-07-25 23:41:38 +0200 | <arkanoid> | whatever |
| 2021-07-25 23:41:41 +0200 | <monochrom> | #haskell-offtopic is a good place on count of "same set of people" |
| 2021-07-25 23:41:49 +0200 | <drakonis> | to haskell-ofttopic then |
| 2021-07-25 23:41:56 +0200 | <arkanoid> | k |
| 2021-07-25 23:44:14 +0200 | <DigitalKiwi> | monochrom: fun hater ;( |
| 2021-07-25 23:45:20 +0200 | pera | (~pera@user/pera) (Quit: leaving) |
| 2021-07-25 23:45:37 +0200 | hgolden | (~hgolden2@cpe-172-114-84-61.socal.res.rr.com) (Quit: Konversation terminated!) |
| 2021-07-25 23:46:25 +0200 | slice | (~slice@user/slice) (Quit: zzz) |
| 2021-07-25 23:53:09 +0200 | jumper149 | (~jumper149@80.240.31.34) (Quit: WeeChat 3.2) |
| 2021-07-25 23:56:46 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-25 23:59:32 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |