Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 816 817 818 819 820 821 822 823 824 825 826 .. 5022
— 502,152 events total
2020-10-23 11:31:25 × alp quits (~alp@2a01:e0a:58b:4920:a54e:d9e5:dae3:56de) (Ping timeout: 240 seconds)
2020-10-23 11:31:41 <hc> merijn: yeah, it is a bit difficult to acclimate to... indeed, the release canditate feature is not-100%-obvious
2020-10-23 11:31:49 <int-e> Hmm, maybe they're using a non-cabal build tool by default :/
2020-10-23 11:32:12 <merijn> hc: candidate is the default, though?
2020-10-23 11:32:15 <hc> then again, adding some checks to reject stuff that doesn't copmile sounds doable
2020-10-23 11:32:23 <merijn> hc: Not really
2020-10-23 11:32:27 <hc> merijn: is it? I always explicitly search for it
2020-10-23 11:32:40 <merijn> hc: Because then anything depending on native libraries that are not on the builders fails
2020-10-23 11:32:48 <merijn> hc: How are you uploading, then?
2020-10-23 11:32:48 <hc> merijn: oh, true.
2020-10-23 11:32:51 <hc> s/compile/type check maybe?
2020-10-23 11:33:04 <int-e> you can't even check whether there's a build plan, because of C dependencies and possible platform-specific packages
2020-10-23 11:33:28 <int-e> (not easily at least)
2020-10-23 11:33:48 <merijn> hc: The hackage upload page (from clicking the link) has them at the bottom (this should perhaps be at the top, before the upload link/button)
2020-10-23 11:33:51 → dbmikus joins (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com)
2020-10-23 11:33:53 <hc> you could require manual review by maintainers for packages that don't compile on "stardard hardware" then?
2020-10-23 11:33:57 <merijn> hc: https://hackage.haskell.org/upload
2020-10-23 11:34:20 <int-e> there is an upload page?
2020-10-23 11:34:23 <merijn> hc: And "cabal upload" requires you to add --publish to upload a non-candidate version
2020-10-23 11:34:28 <merijn> int-e: Yes :p
2020-10-23 11:34:35 <int-e> fancy
2020-10-23 11:34:51 <hc> int-e: yes, it's actually a very open infrastructure imho
2020-10-23 11:34:56 <merijn> Although I just use "cabal upload", since it's integrated with my password manager
2020-10-23 11:34:57 <hc> very low entry bar to contributing
2020-10-23 11:35:51 <int-e> hc: I never went looking for an upload page... I always just used `cabal upload`.
2020-10-23 11:36:03 <hc> ah ok, I see
2020-10-23 11:36:20 <hc> I always used cabal sdist, then find to find the tarball and then uploaded it via the file upload feature
2020-10-23 11:36:27 <hc> much later did I learn there is an upload command
2020-10-23 11:36:33 <int-e> It's just so easy to miss things that you're not looking for.
2020-10-23 11:36:42 <hc> true that!
2020-10-23 11:37:26 <hc> I tend to judge things these days by how easy/hard they make it for me to learn how to do what I am trying to do. (unless, of course, they require me to learn novel new concepts I haven't heard of before and that actually teach me something:)
2020-10-23 11:37:47 <hc> so by this standard, for example, I like hetzner cloud a lot and AWS not so much...
2020-10-23 11:38:17 × Franciman quits (~francesco@host-82-54-10-114.retail.telecomitalia.it) (Quit: Leaving)
2020-10-23 11:38:42 × dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 256 seconds)
2020-10-23 11:39:10 → Franciman joins (~francesco@host-82-54-10-114.retail.telecomitalia.it)
2020-10-23 11:42:29 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-10-23 11:42:51 → alp joins (~alp@2a01:e0a:58b:4920:50ad:3f1d:990d:f833)
2020-10-23 11:44:38 → Gurkenglas joins (~Gurkengla@unaffiliated/gurkenglas)
2020-10-23 11:46:27 → GyroW_ joins (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be)
2020-10-23 11:46:28 × GyroW_ quits (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be) (Changing host)
2020-10-23 11:46:28 → GyroW_ joins (~GyroW@unaffiliated/gyrow)
2020-10-23 11:47:05 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds)
2020-10-23 11:47:14 × GyroW quits (~GyroW@unaffiliated/gyrow) (Ping timeout: 258 seconds)
2020-10-23 11:47:41 × Athas quits (athas@2a01:7c8:aaac:1cf:430f:bcbb:6418:e5a7) (Quit: ZNC - http://znc.sourceforge.net)
2020-10-23 11:48:09 → Athas joins (~athas@2a01:7c8:aaac:1cf:430f:bcbb:6418:e5a7)
2020-10-23 11:50:58 × Lycurgus quits (~niemand@98.4.96.235) (Quit: Exeunt)
2020-10-23 11:52:39 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-10-23 11:54:13 × bitmapper quits (uid464869@gateway/web/irccloud.com/x-odbovwgffdjqqzdy) (Quit: Connection closed for inactivity)
2020-10-23 11:54:16 × stefan-__ quits (~cri@42dots.de) (Read error: Connection reset by peer)
2020-10-23 11:54:26 → stefan-__ joins (~cri@42dots.de)
2020-10-23 11:54:43 <[exa]> ...there's no testing/review in hackage at all?
2020-10-23 11:54:46 → dbmikus joins (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com)
2020-10-23 11:54:54 → nbloomf joins (~nbloomf@2600:1700:ad14:3020:6d96:aec8:3874:14ea)
2020-10-23 11:55:53 → djellemah joins (~djellemah@2601:5c2:100:96c:e008:b638:39fe:6a54)
2020-10-23 11:57:01 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds)
2020-10-23 11:57:01 × xerox_ quits (~xerox@unaffiliated/xerox) (Ping timeout: 246 seconds)
2020-10-23 11:57:23 <infinity0> i have some 3rd-party code that operates lazily on the front of a String, and some other 3rd-party code that operates lazily on the front of a lazy ByteString
2020-10-23 11:57:48 <infinity0> to interoperate the two, i'm keeping my data as a lazy ByteString, but then converting it to a String using LBS.pack/unpack
2020-10-23 11:58:04 <merijn> [exa]: No
2020-10-23 11:58:21 <merijn> [exa]: Who did you imagine would do that?
2020-10-23 11:58:29 <infinity0> however if i do this many many times, i will build up a deep thunk of pack (.. unpack ( .. pack ( ... unpack ) ... etc, is there any way around this?
2020-10-23 11:58:46 <merijn> infinity0: Stop...please...you're going to make me cry
2020-10-23 11:59:00 <infinity0> so is the answer "no"?
2020-10-23 11:59:12 <merijn> The only way that pack/unpack you're using would work is if you are using Char8
2020-10-23 11:59:22 <merijn> And if so, I'm going to have to send my hit squad after you
2020-10-23 11:59:31 <infinity0> i'm using Char8, that's beside the point of my question though
2020-10-23 11:59:33 × dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 260 seconds)
2020-10-23 11:59:50 → thblt joins (~thblt@unaffiliated/thblt)
2020-10-23 12:00:01 × matp quits (~matp@178.162.204.214) ()
2020-10-23 12:02:07 <merijn> I disagree :) Doing that conversion once is evil enough that I'm quoted for hating on it (https://github.com/quchen/articles/blob/master/fbut.md#bytestringchar8-is-bad). Doing it repeatedly is *terribly* broken
2020-10-23 12:02:47 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-10-23 12:03:14 → cristi_ joins (~cristi@86.121.125.90)
2020-10-23 12:03:22 <hc> merijn: lol on that quote
2020-10-23 12:03:37 <merijn> Ideally one (or both) of those 3rd party libraries exposes another way of interacting with it, but that's hard to say without knowing which libraries
2020-10-23 12:03:40 <merijn> hc: #facts
2020-10-23 12:04:13 ← thblt parts (~thblt@unaffiliated/thblt) ("ERC (IRC client for Emacs 27.1)")
2020-10-23 12:04:17 <infinity0> merijn: that problem doesn't apply to my use case, i'm only interested in the issue mentioned in my question
2020-10-23 12:04:29 <arahael> Meh, char8 probably still makes sense in some situations, such as where you have mixed-encoded strings.
2020-10-23 12:04:50 × coot quits (~coot@37.30.51.94.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection)
2020-10-23 12:05:10 <merijn> arahael: No, because then you just have a binary blob and should be operating on ByteString only
2020-10-23 12:05:23 <infinity0> the issue is about interoperating between two pieces of code that expect those two different types, yet it would seem the pack/unpack conversion would become more inefficient the more you interleave the operations, which is a shame
2020-10-23 12:05:28 → coot joins (~coot@37.30.51.94.nat.umts.dynamic.t-mobile.pl)
2020-10-23 12:07:16 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds)
2020-10-23 12:07:20 <arahael> merijn: I really shouldn't engage #haskell when my glenfiddich is running out. ;) But I'll persist! What if you were dealing with an sqlite blob of unspecified encoding?
2020-10-23 12:08:07 <merijn> infinity0: It's not about "more inefficient", but about "is this fundamentally broken?". Either one (or both) of those libraries are exposing the wrong type in their API (in which hopefully there's a right one too) *or* what you're doing is just broken and can't work correctly. I dunno which of those is true. But I don't know the answer to "how can I make the broken thing faster"
2020-10-23 12:08:12 → urodna joins (~urodna@unaffiliated/urodna)
2020-10-23 12:08:19 <merijn> arahael: ByteString
2020-10-23 12:08:28 × coot quits (~coot@37.30.51.94.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection)
2020-10-23 12:08:37 <arahael> merijn: Oh, hang on - char8 isn't actually 8-bit clean is it?
2020-10-23 12:08:42 <merijn> arahael: No
2020-10-23 12:08:53 <arahael> merijn: Well, then that dies right there.
2020-10-23 12:08:53 <merijn> arahael: It's just "lol, let's just drop all non-ascii input"
2020-10-23 12:09:06 <arahael> Yeah, I just realised why it's so bad, again.
2020-10-23 12:09:18 × Chi1thangoo quits (~Chi1thang@87.112.60.168) (Ping timeout: 272 seconds)
2020-10-23 12:09:22 <infinity0> merijn: "this is fundamentally broken" is a subjective judgement, i don't have the time to go into that type of philosophical debate
2020-10-23 12:09:23 <hc> maybe move it to the ByteString.Yolo subpackage to make this more clear?
2020-10-23 12:09:41 <merijn> hc: I have campaigned for it's removal multiple times
2020-10-23 12:10:04 <infinity0> the fact that you had to write a blog post about it means that "for all real-world situations, it results in incorrect behaviour" is not true, i would really just like to focus on my repeated unpack/pack question in terms of efficiency
2020-10-23 12:10:15 → coot joins (~coot@37.30.51.94.nat.umts.dynamic.t-mobile.pl)
2020-10-23 12:10:42 <infinity0> you can think about it in terms of some unspecified types A and B if it makes you more comfortable..
←Prev  Next→
Page 1 .. 816 817 818 819 820 821 822 823 824 825 826 .. 5022

All times are in UTC.