Logs: liberachat/#haskell
| 2021-08-06 20:27:23 | <geekosaur> | I suspect that'd get old quickly |
| 2021-08-06 20:28:21 | <Gurkenglas> | (or debugger states rather than stacktraces) |
| 2021-08-06 20:28:31 | <Gurkenglas> | and when that gets old you improve the debugger UI |
| 2021-08-06 20:28:42 | × | silverwhitefish quits (~hidden@47.202.102.10) (Ping timeout: 250 seconds) |
| 2021-08-06 20:32:49 | × | fendor quits (~fendor@77.119.214.156.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-08-06 20:34:15 | → | Pickchea joins (~private@user/pickchea) |
| 2021-08-06 20:35:10 | → | jgeerds joins (~jgeerds@55d45555.access.ecotel.net) |
| 2021-08-06 20:37:42 | <sm> | Gurkenglas: to be clear, you want to debug the state of the compiler when it reports a compile error in your program here, not debug your program - right ? |
| 2021-08-06 20:38:28 | <Gurkenglas> | yep :) |
| 2021-08-06 20:38:34 | <Gurkenglas> | can't debug my program if it won't compile |
| 2021-08-06 20:38:40 | <sm> | would that be because you're a ghc developer, or because ghc's error messages are too hard to understand ? |
| 2021-08-06 20:39:14 | <Gurkenglas> | the latter. i expect that to happen whenever one has advanced libraries and a strong type system. |
| 2021-08-06 20:39:29 | <sm> | I think the "automatic" world you want is one where the errors are simply easy to understand, like Elm |
| 2021-08-06 20:39:35 | <geekosaur> | I hyave to imagine that if the compile error is too hard to understand, the backtrace will be no better and probably worse |
| 2021-08-06 20:39:36 | <sm> | (reputedly) |
| 2021-08-06 20:40:10 | <sm> | way worse.. |
| 2021-08-06 20:40:30 | <Gurkenglas> | geekosaur, I imagine that as you get more advanced libraries in the same type system, the errors get harder to understand faster than the backtraces |
| 2021-08-06 20:41:24 | <sm> | an "EXPLAIN" mode for ghc errors, where it tries to walk you through them in more detail, sounds useful, more than backtraces of ghc's terrifying internals |
| 2021-08-06 20:42:53 | <sm> | ie, something designed for human comprehension, rather than a direct reflection of the implementation structure |
| 2021-08-06 20:43:24 | <sm> | but sure, both, all, would be great to have |
| 2021-08-06 20:43:42 | <sm> | and I'm sure it's doable with some #ghc magic |
| 2021-08-06 20:44:12 | <sm> | just stick a printCallStack into ghc's error display code |
| 2021-08-06 20:44:17 | → | Atum_ joins (~IRC@user/atum/x-2392232) |
| 2021-08-06 20:49:50 | <dsal> | Gurkenglas: Do you have an example of this sort of thing? |
| 2021-08-06 20:50:16 | <dsal> | Most of the time when I have a sufficiently bad type error, it's because I've underspecified things and the guesses/constraints start getting too broad. |
| 2021-08-06 20:50:44 | <c_wraith> | another way of saying that is "overuse of classes" |
| 2021-08-06 20:51:14 | <dsal> | Yeah. Sometimes you can get really far by just saying what the thing is that you expect to see at a particular site. |
| 2021-08-06 20:51:15 | <Gurkenglas> | lens errors, i would guess |
| 2021-08-06 20:51:33 | <dsal> | People who don't like lens errors tend to favor optics. :) |
| 2021-08-06 20:53:23 | × | ham2 quits (~ham4@d8D8627D5.access.telenet.be) (Read error: Connection reset by peer) |
| 2021-08-06 20:53:28 | <lbseale_> | I am trying to build a GHC package without using cabal or stack, I see I need to define this unit-id hash value in the package info, but I don't know how to generate it. Does anyone? |
| 2021-08-06 20:53:31 | <c_wraith> | at least lens errors mean you did something wrong. As opposed to the errors of the form "this is too polymorphic and I can't figure out what you meant" |
| 2021-08-06 20:55:40 | × | azeem quits (~azeem@dynamic-adsl-94-34-48-122.clienti.tiscali.it) (Remote host closed the connection) |
| 2021-08-06 20:55:49 | → | ham2 joins (~ham4@d8D8627D5.access.telenet.be) |
| 2021-08-06 20:55:49 | → | azeem joins (~azeem@dynamic-adsl-94-34-48-122.clienti.tiscali.it) |
| 2021-08-06 20:56:33 | ham2 | is now known as ham |
| 2021-08-06 20:56:37 | × | ham quits (~ham4@d8D8627D5.access.telenet.be) (Changing host) |
| 2021-08-06 20:56:37 | → | ham joins (~ham4@user/ham) |
| 2021-08-06 20:57:27 | <dsal> | TBH, I bat around at lens errors sometime because I sometimes like not thinking. |
| 2021-08-06 20:59:34 | <monochrom> | lens is a case of very leaky abstraction therefore errors require familiarity with implementation details and coding tricks. |
| 2021-08-06 20:59:55 | <c_wraith> | Honestly, I don't even see lens as an abstraction |
| 2021-08-06 21:00:26 | <c_wraith> | It's a swiss-army knife. It doesn't remove needing to understand things, but it gives you very precise tools for doing exactly what you need |
| 2021-08-06 21:00:36 | <monochrom> | OTOH lens not exposing that information is also a strength in being very adaptable, so I don't really complain. |
| 2021-08-06 21:00:51 | <monochrom> | err! s/not // |
| 2021-08-06 21:01:08 | <monochrom> | (I wasn't making up my mind between "not hiding" and "exposing" heh) |
| 2021-08-06 21:01:27 | <monochrom> | <-- quantum superposed typist |
| 2021-08-06 21:02:00 | <monochrom> | Yeah swiss-army knife nails it. |
| 2021-08-06 21:02:31 | <monochrom> | Generally if you have very interesting type aliases instead of newtypes, you expect this. |
| 2021-08-06 21:02:59 | <monochrom> | C++ takes this practice to the level of daily bread. |
| 2021-08-06 21:03:51 | <monochrom> | and butter and peanut butter and nutella. :) |
| 2021-08-06 21:05:08 | <lbseale_> | Update: the documentation is in a comment in the GHC Main.hs source code >_< |
| 2021-08-06 21:05:11 | <lbseale_> | https://github.com/ghc/ghc/blob/master/ghc/Main.hs |
| 2021-08-06 21:05:29 | <monochrom> | In which case actually wanting a type checker execution trace is barking up the wrong tree. You think the algorithm actually understands sh*t? |
| 2021-08-06 21:05:37 | × | _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-08-06 21:08:21 | <monochrom> | John Searle missed the opportunity for coining "The Unification Room". >:) |
| 2021-08-06 21:13:42 | × | pgib quits (~textual@173.38.117.81) (Quit: 00 PC LOAD LETTER) |
| 2021-08-06 21:17:49 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 2021-08-06 21:18:20 | × | markpythonicbitc quits (~markpytho@2601:647:5a00:35:a8c6:4beb:a469:3f6e) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-08-06 21:22:08 | × | __monty__ quits (~toonn@user/toonn) (Quit: leaving) |
| 2021-08-06 21:24:18 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-08-06 21:27:54 | × | lavaman quits (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-08-06 21:29:22 | × | jiribenes quits (~jiribenes@rosa.jiribenes.com) (Ping timeout: 240 seconds) |
| 2021-08-06 21:33:29 | → | jiribenes joins (~jiribenes@rosa.jiribenes.com) |
| 2021-08-06 21:36:53 | → | arkho joins (~ccc@dynamic-acs-24-112-153-241.zoominternet.net) |
| 2021-08-06 21:36:55 | × | arkho quits (~ccc@dynamic-acs-24-112-153-241.zoominternet.net) (Remote host closed the connection) |
| 2021-08-06 21:37:30 | × | neceve quits (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) (Ping timeout: 258 seconds) |
| 2021-08-06 21:40:16 | <raehik> | Got a C library that I want to make some Haskell bindings for, and have work on Windows and Linux, but not sure how to build the lib in GHC/Cabal (which I saw a relevant pkg for a simpler lib) |
| 2021-08-06 21:40:56 | × | zebrag quits (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-08-06 21:41:13 | <raehik> | I've got some function calls working from Cabal, but I don't get how linking will work. How do I tell GHC to link against a dynamic library? Is this a bad idea/what's the alternative |
| 2021-08-06 21:41:23 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-08-06 21:42:38 | <geekosaur> | it will link against dynamic C libraries by default; it's shared libraries that are the problem |
| 2021-08-06 21:42:43 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-08-06 21:42:55 | <sclv> | raehik: take a look at some bindings for things like curl to see how they're set up https://hackage.haskell.org/package/curl-1.3.8/curl.cabal |
| 2021-08-06 21:43:03 | <geekosaur> | (because there's no portable way to do that without also linkingf libc shared, which will break glibc) |
| 2021-08-06 21:43:53 | <raehik> | sclv: thank you! was looking for more examples |
| 2021-08-06 21:44:16 | <raehik> | geekosaur: I don't think I know what the diff between a dynamic and shared lib is. |
| 2021-08-06 21:44:38 | <raehik> | are they both .so / .dlls? |
| 2021-08-06 21:45:14 | <sclv> | network has a more complex cabal that can show a bit more stuff off too, like cbits, platform specific conditionals, etc https://hackage.haskell.org/package/network-3.1.2.2/network.cabal |
| 2021-08-06 21:45:22 | <geekosaur> | they're the same thing, just different names for it |
| 2021-08-06 21:45:30 | <janus> | geekosaur: are you saying it is more portable when linking libc shared? why would that be the case? surely it using musl statically should be more portable than glibc, just because you can link it statically |
| 2021-08-06 21:46:07 | <monochrom> | geekosaur, I think you had a typo in "dynamic is default, shared is the problem" in which it should be s/shared/static/ |
| 2021-08-06 21:46:11 | <geekosaur> | janus, the problem with glibc is it will insist on loading some stuff dynamically anyway (notably nss) and that will break between glibc versions |
| 2021-08-06 21:46:19 | <geekosaur> | yes, sorry |
| 2021-08-06 21:46:42 | <geekosaur> | static is the problem because glibc doesn't like being static.l which is why musl is recommended for static builds |
| 2021-08-06 21:47:16 | <janus> | right, ok, so with the correction it makes more sense. static is perfectly portable (except musl doesn't run on windows) , if you can get it built |
| 2021-08-06 21:49:48 | <raehik> | I thought this (tiny) pkg built the C functions into it rather than being dynamic https://hackage.haskell.org/package/lzo |
| 2021-08-06 21:50:44 | <raehik> | is that correct. apologies I'm unclear on what goes on during linking in GHC |
| 2021-08-06 21:55:39 | × | gehmehgeh quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-08-06 21:55:44 | × | lbseale_ quits (~lbseale@user/ep1ctetus) (Ping timeout: 272 seconds) |
| 2021-08-06 21:56:20 | <geekosaur> | that package includes the entirety of the C minilzo package, yes. this is usually done to make things easier on Windows, where it can be hard ti locate and use C libraries |
| 2021-08-06 21:57:19 | → | lbseale joins (~lbseale@user/ep1ctetus) |
| 2021-08-06 21:58:35 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-08-06 22:00:40 | → | dermato joins (~dermatobr@cpe-70-114-219-76.austin.res.rr.com) |
| 2021-08-06 22:00:55 | <raehik> | got it, thank you. I want to use the full lzo2 library and weighing up my options |
| 2021-08-06 22:01:27 | × | Tuplanolla quits (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-08-06 22:01:59 | → | roboguy__ joins (~roboguy_@2605:a601:afe7:9f00:6574:78ba:36fc:f777) |
| 2021-08-06 22:03:23 | → | _73 joins (~user@pool-96-252-123-136.bstnma.fios.verizon.net) |
| 2021-08-06 22:05:30 | × | roboguy_ quits (~roboguy_@2605:a601:afe7:9f00:c77:b134:29be:aae9) (Ping timeout: 256 seconds) |
| 2021-08-06 22:05:56 | ← | _73 parts (~user@pool-96-252-123-136.bstnma.fios.verizon.net) () |
| 2021-08-06 22:11:45 | × | roboguy__ quits (~roboguy_@2605:a601:afe7:9f00:6574:78ba:36fc:f777) (Remote host closed the connection) |
All times are in UTC.