| 2022-04-12 00:01:21 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-04-12 00:03:13 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 00:03:36 +0200 | acidjnk | (~acidjnk@p200300d0c7049f6848ba0397e6d6589a.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-04-12 00:04:27 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-04-12 00:06:25 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 00:07:30 +0200 | echoone | (~echoone@2a02:8109:a1c0:5d05:21a1:345:a334:6dac) (Quit: Client closed) |
| 2022-04-12 00:08:12 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 2022-04-12 00:08:22 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-04-12 00:09:14 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-04-12 00:14:04 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 00:15:26 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 00:15:30 +0200 | Midjak | (~Midjak@82.66.147.146) (Read error: Connection reset by peer) |
| 2022-04-12 00:20:40 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 00:22:14 +0200 | alp_ | (~alp@user/alp) |
| 2022-04-12 00:25:42 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) (Ping timeout: 246 seconds) |
| 2022-04-12 00:26:35 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 240 seconds) |
| 2022-04-12 00:27:35 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-04-12 00:27:40 +0200 | xff0x | (~xff0x@om126133209212.21.openmobile.ne.jp) |
| 2022-04-12 00:28:27 +0200 | dextaa | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-04-12 00:33:55 +0200 | hololeap | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-04-12 00:34:09 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 00:34:35 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 00:35:17 +0200 | hololeap | (~hololeap@user/hololeap) |
| 2022-04-12 00:35:54 +0200 | Henson | (~kvirc@107-179-133-201.cpe.teksavvy.com) |
| 2022-04-12 00:38:06 +0200 | <Henson> | hi everyone. I've got some X,Y image point locations I've put into a type called Point2D and I have a list of them, like [Point2D]. Say I want to add some type-based meta data on top of that. Say they're undistorted points from a certain camera. What's the right way to add this extra type-based "tags" to the data? Just use newtypes to have something like (Left_Camera (Undistorted [Point2D]))? |
| 2022-04-12 00:38:07 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 240 seconds) |
| 2022-04-12 00:38:28 +0200 | <Henson> | working with these nested types is kludgy sometimes, so I use Lens to make reaching into and manipulating the "stacks" of data more easily. |
| 2022-04-12 00:38:56 +0200 | <Henson> | but sometimes it's still really kludgy. Is this the right pattern to be using, or is there some other way I should/could be doing it that might be more natural to work with? |
| 2022-04-12 00:39:18 +0200 | <Henson> | and require less wrapping/unwrapping of the data? Admittedly Lens helps out tremendously in this regard. |
| 2022-04-12 00:48:38 +0200 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2022-04-12 00:51:49 +0200 | geranim0 | (~geranim0@modemcable242.171-178-173.mc.videotron.ca) |
| 2022-04-12 00:55:26 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-04-12 00:57:08 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-04-12 00:58:31 +0200 | xff0x | (~xff0x@om126133209212.21.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2022-04-12 01:00:44 +0200 | <Cale> | Henson: Probably not newtypes, right? You'd be newtyping a pair, so there's no advantage over just using 'data' to declare the type. |
| 2022-04-12 01:01:15 +0200 | <Cale> | Or, is there really no other information you're including about the situation |
| 2022-04-12 01:02:08 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 01:03:29 +0200 | <Cale> | If it really is purely type information, it's a good question to ask what properties of the code you're trying to guarantee by using the newtypes. Something like Left_Camera doesn't seem like the kind of thing I'd usually feel like encoding at the type level, but I don't really know your application. |
| 2022-04-12 01:03:53 +0200 | <Henson> | Cale: well for the 2D point it's a data, but I'm wondering about the layers of type-based information on top, like the Undistorted or Camera_Left types, which essentially wrap the data with type-level information. For Undistorted I'm using "newtype Undistorted a = Undistorted { getUndistorted :: a }" |
| 2022-04-12 01:04:23 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) |
| 2022-04-12 01:05:07 +0200 | <Henson> | Cale: for a function that takes two 2D points and uses stereo triangulation to turn that into a 3D point, I want to make it clear at the type level that they're undistorted points and that they belong to the respective camera, so that you can't pass a distorted point for the right camera in when you really should be passing a left camera undistorted point it. |
| 2022-04-12 01:05:24 +0200 | <Cale> | That does seem fair enough |
| 2022-04-12 01:05:45 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-04-12 01:05:53 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 01:06:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 01:07:03 +0200 | <Cale> | So long as it doesn't amount to being applied like: stereoTriangulation (Left_Camera something) (Right_Camera somethingElse) where you could get it mixed up anyway. |
| 2022-04-12 01:07:21 +0200 | <Henson> | Cale: I've just gotten myself into a situation where the layering of type information has gotten ungainly, possibly due to me not structuring it correctly. This is my first big Haskell project, and now I'm starting to see the value is "type engineering" where your choices in type layering is significant in terms of the ease with which you can work with these layered types. |
| 2022-04-12 01:07:25 +0200 | werneta | (~werneta@137.79.198.1) |
| 2022-04-12 01:07:42 +0200 | <Cale> | Yeah, it's always a tradeoff |
| 2022-04-12 01:09:08 +0200 | <Henson> | Cale: ok. But layered data into newtypes seems to be the right thing to do? By defining lenses for the different type layers I can often reach down into the layered data to manipulate things without having to explicitly wrap and unwrap all of the data. |
| 2022-04-12 01:09:19 +0200 | <Henson> | I've come to understand the value of the Lens library! |
| 2022-04-12 01:10:00 +0200 | <Cale> | I don't use lens a lot unless I really need to abstract over a choice of lens, but it might have a role to play |
| 2022-04-12 01:10:48 +0200 | <Cale> | If you're explicitly wrapping and unwrapping the data a lot, then there's a chance you're making mistakes doing that, and it weakens the argument for using the newtype in the first place |
| 2022-04-12 01:11:08 +0200 | <Cale> | Ideally, for each newtype, you also have a lot of operations which act on that type |
| 2022-04-12 01:11:18 +0200 | <Cale> | Or at least, enough operations |
| 2022-04-12 01:11:22 +0200 | <Henson> | Cale: hmmm |
| 2022-04-12 01:13:05 +0200 | <Cale> | Like, how do I know that something of type Undistorted a has not been distorted? If someone unwrapped the data, distorted the points somehow and re-applied the constructor, then it presumably breaks the guarantee we were trying to have there. |
| 2022-04-12 01:14:39 +0200 | <Henson> | Cale: right. But there are other functions that are used to consume and produce these different layered types. So it's totally possible somebody could do that, and indeed within the functions that's often done, but the type signature of the functions is supposed to give you a framework to work with in which they all fit together. Cameras produce images. Object detectors produce distorted 2D... |
| 2022-04-12 01:14:49 +0200 | <Cale> | Not that I really know what the tag means in your case, but perhaps there should only be an exposed way to unwrap Undistorted a values, and the only thing that can make them is something closer to the raw camera feed |
| 2022-04-12 01:15:24 +0200 | <Henson> | points. Undistorters convert distorted 2D points to undistorted 2D points, 3d triangulators convert left and right pairs of 2D points into 3D points in a certain coordinate frame. Coordinate frame transformers convert from one frame to the other, etc. |
| 2022-04-12 01:16:10 +0200 | <Cale> | hmm, okay |
| 2022-04-12 01:18:15 +0200 | <Henson> | does that seem like a correct way to be using this type level meta data? |
| 2022-04-12 01:18:29 +0200 | <Cale> | I think it actually seems pretty much fine |
| 2022-04-12 01:19:12 +0200 | <Henson> | I'm essentially trying to force the programmer to do the right thing as well as be explicit about the inputs and outputs of the function. |
| 2022-04-12 01:19:29 +0200 | <Cale> | I do feel like there's something more evidence-based that could be done about the left/right distinction |
| 2022-04-12 01:20:04 +0200 | <Cale> | Like, maybe combining the data with the implied information about the relative camera position/orientation or something |
| 2022-04-12 01:20:22 +0200 | <Cale> | But maybe that doesn't make sense in your case |
| 2022-04-12 01:21:28 +0200 | <Cale> | (maybe it's also very costly, if that means you end up pushing around lots of references to what are effectively constants in your application) |
| 2022-04-12 01:22:33 +0200 | <Henson> | Cale: I agree. There is a way to make it camera-side-agnostic by including the appropriate information, but I haven't done that in my case. |
| 2022-04-12 01:23:40 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 01:24:08 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Read error: Connection reset by peer) |
| 2022-04-12 01:24:57 +0200 | Neuromancer | (~Neuromanc@user/neuromancer) (Read error: Connection reset by peer) |
| 2022-04-12 01:29:05 +0200 | <Henson> | Cale: thanks for letting me bounce those ideas off you! |
| 2022-04-12 01:31:05 +0200 | <Cale> | btw, there may be options for using something like DataKinds and a phantom type parameter which is a list of tags or something, but then you end up in a situation where you're doing lots of type level computation on lists of tags, and that can be annoying in its own way. |
| 2022-04-12 01:31:29 +0200 | <Cale> | It could get you down to one newtype data constructor at the term level though |
| 2022-04-12 01:32:17 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 256 seconds) |
| 2022-04-12 01:32:23 +0200 | <Cale> | But, there's value in explicitly wrapping and unwrapping the tags, because it gives you a chance to think about what that tag means and whether the operation you're writing really satisfies the invariants |
| 2022-04-12 01:34:20 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-04-12 01:37:14 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-04-12 01:39:05 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) (Ping timeout: 256 seconds) |
| 2022-04-12 01:40:47 +0200 | zeenk | (~zeenk@2a02:2f04:a313:d600:8d26:ec9f:3ff6:fc94) (Quit: Konversation terminated!) |
| 2022-04-12 01:41:08 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) |
| 2022-04-12 01:47:32 +0200 | <Henson> | Cale: thanks for the DataKinds suggestion. I don't think I've used that before, and after taking a quick look at the description, it seems like it's one of those extensions to use when you want to do complex type-level things. Not only do I not really understand how it works, but I'm trying to keep my program relatively free of those complex type-level abstractions to make it easier for... |
| 2022-04-12 01:47:33 +0200 | Guest27 | (~Guest27@2601:281:d47f:1590:768c:7129:aa80:96d9) |
| 2022-04-12 01:47:44 +0200 | <Henson> | Cale: other programmers to grasp. |
| 2022-04-12 01:48:56 +0200 | <Henson> | Cale: but if something like that could simplify what I'm doing, and is the "haskell way" of doing it, then I'd be interested in doing that. Learning Lens to make manipulation of nested types WAY easier to do was certainly worth it, and isn't that difficult to understand once you learn it. |
| 2022-04-12 01:49:10 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 01:50:02 +0200 | <Henson> | Cale: but I've encountered the advice of "don't use crazy type-level extensions unless you really need to". |
| 2022-04-12 01:54:00 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 01:55:08 +0200 | <Henson> | Cale: have you used Arrows before? Do you know what they're useful for? |
| 2022-04-12 01:56:34 +0200 | <Henson> | Cale: I looked into them a while ago, and they seem to be a way of composing functions in ways that are more flexible and complex that currying and partial function application. |
| 2022-04-12 02:01:53 +0200 | Guest27 | (~Guest27@2601:281:d47f:1590:768c:7129:aa80:96d9) (Quit: Client closed) |
| 2022-04-12 02:04:43 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 02:04:55 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 02:07:40 +0200 | werneta | (~werneta@137.79.198.1) (Remote host closed the connection) |
| 2022-04-12 02:11:31 +0200 | chenqisu1 | (~chenqisu1@183.217.201.251) |
| 2022-04-12 02:12:00 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2022-04-12 02:20:08 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) (Ping timeout: 248 seconds) |
| 2022-04-12 02:20:26 +0200 | <Cale> | Henson: I take it you're already familiar with Monad? |
| 2022-04-12 02:20:36 +0200 | <Henson> | Cale: yes |
| 2022-04-12 02:21:02 +0200 | <abastro[m]> | Typelevel extensions are surely discouraged |
| 2022-04-12 02:21:06 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 02:21:18 +0200 | <Cale> | Henson: The one thing about Monad which is a bit of a downside is that whenever you have an expression x >>= f, the f is a function, and functions in Haskell are effectively black boxes |
| 2022-04-12 02:21:50 +0200 | <Henson> | Cale: right |
| 2022-04-12 02:22:01 +0200 | <Cale> | There's nothing the program can do short of running x first and providing its result to f to get a final result when it comes to understanding what it is that f does. |
| 2022-04-12 02:22:25 +0200 | <Cale> | With Arrow, the arguments to the main means of composition are all of a type that you have control over |
| 2022-04-12 02:23:27 +0200 | <Cale> | So in principle, you can capture more information about the structure of a computation and do things to optimise its behaviour. Other than that, it's basically just another sort of structural pattern that combinator libraries might fit into. Not very popular at this point though, but I think with some tweaks it could do better. |
| 2022-04-12 02:25:04 +0200 | <Cale> | It presently kind of undermines this inspectability a little as well, in the end, because while it's true that the basic means of composition have this property of taking arguments of a type that the user has control over, it provides an escape hatch way to turn arbitrary Haskell functions into values of your Arrow type: |
| 2022-04-12 02:25:06 +0200 | <Cale> | :t arr |
| 2022-04-12 02:25:07 +0200 | <lambdabot> | Arrow a => (b -> c) -> a b c |
| 2022-04-12 02:26:21 +0200 | <Cale> | and that basically embeds black boxes into the middle of your computation -- not necessarily a big problem, but there are various basic things which are missing from the abstraction that end up using arr to do them, like swap :: a (b,c) (c,b) and assocL :: a (b,(c,d)) ((b,c),d) |
| 2022-04-12 02:26:27 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 02:27:04 +0200 | <jackdk> | I would love to see arrow rebuilt on top of category/profunctor/product-profunctors, but it'll never happen |
| 2022-04-12 02:27:13 +0200 | <Cale> | yes |
| 2022-04-12 02:27:23 +0200 | <Cale> | I don't think it's unreasonable that it might happen... |
| 2022-04-12 02:27:42 +0200 | <Henson> | Cale: I'm tempted to ask more questions, but I gotta run in just a minute |
| 2022-04-12 02:27:47 +0200 | <Cale> | I think we'd do it at Obsidian if it turns out that certain libraries get sufficiently done to warrant it... |
| 2022-04-12 02:28:15 +0200 | <Cale> | I think it would be nice for our routes library as it stands even... |
| 2022-04-12 02:28:33 +0200 | <jackdk> | You lot keep my dreams alive. I hope to see the commutative-semigroups refactor progress, too |
| 2022-04-12 02:29:51 +0200 | <abastro[m]> | Does it need to be stronger than simple Category? |
| 2022-04-12 02:30:43 +0200 | <Cale> | It's a bunch of extra stuff |
| 2022-04-12 02:30:53 +0200 | <Cale> | (really you want a symmetric monoidal category) |
| 2022-04-12 02:30:56 +0200 | <abastro[m]> | Interesting |
| 2022-04-12 02:31:07 +0200 | <abastro[m]> | Oh |
| 2022-04-12 02:31:24 +0200 | <abastro[m]> | `arr`, the culprit. Meh |
| 2022-04-12 02:31:44 +0200 | <Cale> | arr is kind of the culprit, but it's more the reason that a bunch of important primitives got missed |
| 2022-04-12 02:31:55 +0200 | <Cale> | and arr on its own isn't really a problem, moreso that important stuff is missing |
| 2022-04-12 02:32:03 +0200 | <Cale> | But arr should be in its own class |
| 2022-04-12 02:32:06 +0200 | <abastro[m]> | Hm, yeah |
| 2022-04-12 02:32:23 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 02:32:28 +0200 | <abastro[m]> | I mean, you said how things which deserve to be in class are implemented by arr |
| 2022-04-12 02:32:34 +0200 | <abastro[m]> | And that would be bad |
| 2022-04-12 02:32:35 +0200 | <Cale> | yeah |
| 2022-04-12 02:32:54 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Read error: Connection reset by peer) |
| 2022-04-12 02:33:20 +0200 | <Cale> | At one point, Ryan and I were working on an FRP system for a game we were working on (it never got released, but maybe we'll return to it someday) |
| 2022-04-12 02:33:32 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 250 seconds) |
| 2022-04-12 02:33:34 +0200 | Henson | HensonAway |
| 2022-04-12 02:34:01 +0200 | <Cale> | It used Arrows, and fixing the Arrow class so that it was more like the definition of a symmetric monoidal category made our game run 6 times faster almost immediately. |
| 2022-04-12 02:34:37 +0200 | <Cale> | This because we lost less information about where values were going and had less tupling and untupling (i.e. allocation and dereferencing) to do |
| 2022-04-12 02:39:14 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 272 seconds) |
| 2022-04-12 02:39:43 +0200 | <abastro[m]> | Oh |
| 2022-04-12 02:39:53 +0200 | <abastro[m]> | Btw, what would be the way to improve usability of arrows? |
| 2022-04-12 02:39:56 +0200 | <Cale> | (the edges of the computation graph ultimately became IORefs, but there were various circumstances where we would actually have to let it construct tuples) |
| 2022-04-12 02:40:57 +0200 | <Cale> | Well, these days, I would rebuild the arrow proc/do-notation syntax so that it uses this stuff: https://hackage.haskell.org/package/categories-1.0.7 |
| 2022-04-12 02:41:56 +0200 | <Cale> | But less drastically, you could break up Arrow a little bit and make it look more like the definition of a symmetric monoidal category, specifically by adding the isomorphisms that reassociate the tuples, add/remove identities i.e. () and swap tuples around |
| 2022-04-12 02:42:05 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-04-12 02:42:19 +0200 | <abastro[m]> | But proc-do is quite unergonomic |
| 2022-04-12 02:42:30 +0200 | <Cale> | So then when proc/do needs to rearrange the results of computations so as to be able to apply an arrow to a previously-obtained result, it basically won't have to use arr |
| 2022-04-12 02:42:32 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 02:42:51 +0200 | <Cale> | Well, that's true, but it's a lot more ergonomic than using these combinators directly :D |
| 2022-04-12 02:43:24 +0200 | <Cale> | I guess an even more extreme approach is doing Conal's constrained categories stuff to reinterpret most/all of Haskell in terms of categorical operations |
| 2022-04-12 02:44:49 +0200 | <abastro[m]> | proc-do notation require exactly 1 input per statement, right? |
| 2022-04-12 02:44:51 +0200 | <Cale> | and then you can write stuff that looks like Haskell expressions and turn it into compositions of categorical operations -- which in principle also basically supplants linear and affine types in the style of LinearHaskell, because you can refuse to constrain the type of category for your expression by the classes that let you duplicate or delete information |
| 2022-04-12 02:45:15 +0200 | <Cale> | Yeah, though that can be a pattern match |
| 2022-04-12 02:46:08 +0200 | <dons> | mornining all. |
| 2022-04-12 02:46:36 +0200 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 240 seconds) |
| 2022-04-12 02:46:38 +0200 | <Cale> | oh, the input |
| 2022-04-12 02:46:45 +0200 | <Cale> | the input can be an arbitrary expression as well |
| 2022-04-12 02:46:55 +0200 | <Cale> | Morning dons :) |
| 2022-04-12 02:46:57 +0200 | <Axman6> | o/ |
| 2022-04-12 02:47:05 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 02:47:32 +0200 | <Cale> | abastro[m]: Of course, if you use that ability (and it's not something easy like a tuple), then you're basically forced to use arr |
| 2022-04-12 02:48:47 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-04-12 02:49:01 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) |
| 2022-04-12 02:49:27 +0200 | <abastro[m]> | Could you give an example? |
| 2022-04-12 02:50:29 +0200 | <Cale> | Like, you can write x <- f -< y + z |
| 2022-04-12 02:50:37 +0200 | img | (~img@user/img) |
| 2022-04-12 02:50:46 +0200 | <abastro[m]> | Yep, I mean |
| 2022-04-12 02:50:54 +0200 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-04-12 02:51:21 +0200 | <Cale> | (and that'll be translated into something which uses arr (+)) |
| 2022-04-12 02:51:22 +0200 | <abastro[m]> | You cannot do like |
| 2022-04-12 02:51:22 +0200 | <abastro[m]> | `x <- f` |
| 2022-04-12 02:51:22 +0200 | <abastro[m]> | Or |
| 2022-04-12 02:51:22 +0200 | <abastro[m]> | `x <- f <- y z` |
| 2022-04-12 02:51:36 +0200 | <Cale> | You can of course do x <- f -< (y,z) |
| 2022-04-12 02:51:38 +0200 | xff0x | (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) |
| 2022-04-12 02:51:50 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-04-12 02:53:10 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 02:54:21 +0200 | <abastro[m]> | Yep but that requires constructing tuple |
| 2022-04-12 02:56:24 +0200 | <wmacmil> | is this an error anyone is familiar with : cabal: repl failed for exe:data-processing-hs from data-processing-hs-0.1.0.0. |
| 2022-04-12 02:56:32 +0200 | <Cale> | Oh, true and fair. I forgot that one of the basic additional things that we did was allow replacing the product on objects, and we actually did use that to make stuff like this avoid the tupling... |
| 2022-04-12 02:56:58 +0200 | <wmacmil> | i was just running 'cabal repl' from the root directory a month ago and now i'm getting this error message |
| 2022-04-12 02:57:09 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-04-12 02:57:09 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-04-12 02:57:09 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-04-12 02:57:22 +0200 | lbseale | (~ep1ctetus@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2022-04-12 02:57:26 +0200 | <Cale> | abastro[m]: Actually, I think you can avoid it anyway, if the evaluator for the arrow is fancy enough to build a graph of the computation it's about to run |
| 2022-04-12 02:57:29 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 248 seconds) |
| 2022-04-12 02:57:42 +0200 | <wmacmil> | and it also says "cabal-3.6.2.0: can't find source for Data in app, |
| 2022-04-12 02:57:42 +0200 | <wmacmil> | " |
| 2022-04-12 02:57:49 +0200 | <Cale> | But yeah, it's a lot of work to make good use of Arrow in general |
| 2022-04-12 02:57:51 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 02:58:24 +0200 | <Cale> | and the best applications I've seen have been things that are, if not FRP systems, fairly close in nature to that |
| 2022-04-12 02:59:47 +0200 | <wmacmil> | that also comes up when i just run build |
| 2022-04-12 03:00:06 +0200 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-04-12 03:01:10 +0200 | <abastro[m]> | wmacmil: Sounds quite strange |
| 2022-04-12 03:02:32 +0200 | <Axman6> | wmacmil: without knowing anything about your project, it's very hard to know what could be going wrong |
| 2022-04-12 03:02:53 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 03:03:04 +0200 | <abastro[m]> | Perhaps you could try uninstalling cabal and reinstalling it. |
| 2022-04-12 03:03:41 +0200 | <abastro[m]> | Cale: So how do you usually supply tuple, and somehow pattern match with proc-do w/o arr? |
| 2022-04-12 03:04:20 +0200 | vysn | (~vysn@user/vysn) |
| 2022-04-12 03:04:54 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 03:05:09 +0200 | <wmacmil> | i think i had uncommented the -- other-modules: Data in my cabal actually, but am not sure if i did because i haven't touched the project in a month |
| 2022-04-12 03:05:16 +0200 | <wmacmil> | either way, it worked when i commented that out |
| 2022-04-12 03:05:16 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 03:05:26 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-04-12 03:05:31 +0200 | abastro | (~abab9579@143.248.229.139) |
| 2022-04-12 03:05:35 +0200 | <mikoto-chan> | what is the category theory room's name? |
| 2022-04-12 03:05:40 +0200 | <mikoto-chan> | sorry for asking here |
| 2022-04-12 03:06:00 +0200 | geranim0 | (~geranim0@modemcable242.171-178-173.mc.videotron.ca) (Remote host closed the connection) |
| 2022-04-12 03:07:07 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 240 seconds) |
| 2022-04-12 03:11:28 +0200 | <abastro> | Perhaps ppl here do not know of that |
| 2022-04-12 03:13:21 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 03:18:15 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 03:18:27 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-04-12 03:18:32 +0200 | evanextreme | (~evan@2604:4080:1000:8bf0:c7a1:5d95:53a6:334d) (Remote host closed the connection) |
| 2022-04-12 03:19:23 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-04-12 03:20:07 +0200 | neurocyte8614492 | (~neurocyte@user/neurocyte) (Ping timeout: 240 seconds) |
| 2022-04-12 03:21:09 +0200 | <abastro> | I wish arrow notation is a bit more ergonomic as well, so it could more easily be used |
| 2022-04-12 03:21:15 +0200 | <abastro> | Perhaps new language could do the job better? |
| 2022-04-12 03:22:09 +0200 | [_] | [itchyjunk] |
| 2022-04-12 03:23:22 +0200 | img | (~img@user/img) (Ping timeout: 250 seconds) |
| 2022-04-12 03:27:51 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 03:29:53 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 03:30:35 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) |
| 2022-04-12 03:32:28 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 250 seconds) |
| 2022-04-12 03:34:42 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Ping timeout: 246 seconds) |
| 2022-04-12 03:34:52 +0200 | andrey_ | (~andrey@p200300dbcf112f00ea6a6fd122b4be68.dip0.t-ipconnect.de) |
| 2022-04-12 03:35:12 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-04-12 03:35:12 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-04-12 03:35:12 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-04-12 03:37:14 +0200 | andrey | (~andrey@p200300dbcf10d4000da31d4cf19671e4.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 2022-04-12 03:37:38 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2022-04-12 03:42:42 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-04-12 03:46:33 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 03:48:38 +0200 | <Axman6> | mikoto-chan: I don't know of any specific channels, but you might find answers in #haskell-in-depth |
| 2022-04-12 03:49:22 +0200 | <Axman6> | and/or #haskell-offtopic |
| 2022-04-12 03:51:51 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 03:54:34 +0200 | <sclv> | mikoto-chan: unsurprisingly it is #category-theory |
| 2022-04-12 03:54:41 +0200 | <sclv> | erm #categorytheory |
| 2022-04-12 03:54:43 +0200 | <sclv> | no hyphen |
| 2022-04-12 03:55:34 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 04:00:31 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 04:01:44 +0200 | mud | (~mud@user/kadoban) |
| 2022-04-12 04:04:58 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 250 seconds) |
| 2022-04-12 04:06:16 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 250 seconds) |
| 2022-04-12 04:06:45 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) |
| 2022-04-12 04:08:07 +0200 | axeman | (~quassel@2a02:8109:a380:78:1051:99b3:bcd5:d181) |
| 2022-04-12 04:08:16 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 04:18:02 +0200 | justache | (~justache@user/justache) (Remote host closed the connection) |
| 2022-04-12 04:18:06 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2022-04-12 04:18:59 +0200 | justache | (~justache@user/justache) |
| 2022-04-12 04:23:50 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-04-12 04:24:28 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 2022-04-12 04:31:27 +0200 | sander | (~sander@user/sander) (Quit: So long! :)) |
| 2022-04-12 04:36:09 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 04:40:47 +0200 | sander | (~sander@user/sander) |
| 2022-04-12 04:45:15 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 04:47:15 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-04-12 04:47:16 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-04-12 04:47:16 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-04-12 04:51:20 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) (Ping timeout: 250 seconds) |
| 2022-04-12 04:52:12 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 04:53:20 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 04:58:00 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2022-04-12 05:00:40 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) |
| 2022-04-12 05:00:45 +0200 | awpr | (uid446117@id-446117.lymington.irccloud.com) |
| 2022-04-12 05:01:47 +0200 | slac36439 | (~slack1256@186.11.47.244) (Ping timeout: 240 seconds) |
| 2022-04-12 05:03:39 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) (Ping timeout: 256 seconds) |
| 2022-04-12 05:09:19 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-04-12 05:11:21 +0200 | axeman | (~quassel@2a02:8109:a380:78:1051:99b3:bcd5:d181) (Ping timeout: 248 seconds) |
| 2022-04-12 05:13:08 +0200 | InstX1 | (~Liam@2601:6c4:4080:3f80:2c03:bab3:ea6:cda) |
| 2022-04-12 05:15:10 +0200 | Inst | (~Liam@2601:6c4:4080:3f80:cc5c:b097:5fb3:1fb3) (Ping timeout: 250 seconds) |
| 2022-04-12 05:15:30 +0200 | russruss | (~russruss@my.russellmcc.com) (Ping timeout: 246 seconds) |
| 2022-04-12 05:15:47 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-04-12 05:16:36 +0200 | z0k | (~z0k@39.40.69.197) |
| 2022-04-12 05:17:11 +0200 | chenqisu12 | (~chenqisu1@183.217.202.1) |
| 2022-04-12 05:18:09 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 05:19:20 +0200 | chenqisu1 | (~chenqisu1@183.217.201.251) (Ping timeout: 248 seconds) |
| 2022-04-12 05:26:24 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2022-04-12 05:28:38 +0200 | frost | (~frost@user/frost) |
| 2022-04-12 05:30:12 +0200 | john__ | (~chenqisu1@183.217.201.54) |
| 2022-04-12 05:32:40 +0200 | chenqisu12 | (~chenqisu1@183.217.202.1) (Ping timeout: 248 seconds) |
| 2022-04-12 05:34:40 +0200 | inversed_ | (~inversed@94.13.111.159) (Ping timeout: 272 seconds) |
| 2022-04-12 05:37:16 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 250 seconds) |
| 2022-04-12 05:37:49 +0200 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 240 seconds) |
| 2022-04-12 05:39:21 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 05:41:38 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2022-04-12 05:41:49 +0200 | inversed_ | (~inversed@94.13.111.159) |
| 2022-04-12 05:42:01 +0200 | slack1256 | (~slack1256@191.125.99.201) |
| 2022-04-12 05:44:33 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 05:48:58 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 250 seconds) |
| 2022-04-12 05:49:17 +0200 | chenqisu12 | (~chenqisu1@183.217.200.38) |
| 2022-04-12 05:50:57 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) |
| 2022-04-12 05:51:52 +0200 | john__ | (~chenqisu1@183.217.201.54) (Ping timeout: 248 seconds) |
| 2022-04-12 05:54:01 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2022-04-12 05:54:36 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) (Ping timeout: 250 seconds) |
| 2022-04-12 05:56:03 +0200 | cdman | (~dcm@user/dmc/x-4369397) |
| 2022-04-12 06:04:09 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 06:08:02 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2022-04-12 06:08:21 +0200 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-04-12 06:12:27 +0200 | z0k | (~z0k@39.40.69.197) (Ping timeout: 240 seconds) |
| 2022-04-12 06:13:35 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-04-12 06:16:04 +0200 | bilegeek | (~bilegeek@2600:1008:b018:1362:c691:f6b9:4d9f:bb48) |
| 2022-04-12 06:17:28 +0200 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-04-12 06:19:26 +0200 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-04-12 06:19:35 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-04-12 06:19:52 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 06:20:18 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 06:22:18 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-04-12 06:22:59 +0200 | wmacmil_ | (~wmacmil@108-194-162-159.lightspeed.renonv.sbcglobal.net) |
| 2022-04-12 06:23:42 +0200 | bilegeek | (~bilegeek@2600:1008:b018:1362:c691:f6b9:4d9f:bb48) (Quit: Leaving) |
| 2022-04-12 06:24:56 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 06:25:24 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) (Ping timeout: 240 seconds) |
| 2022-04-12 06:34:58 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 06:35:04 +0200 | z0k | (~z0k@39.40.60.29) |
| 2022-04-12 06:38:36 +0200 | hamishmack_ | (sid389057@id-389057.hampstead.irccloud.com) (Ping timeout: 240 seconds) |
| 2022-04-12 06:40:37 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 06:41:27 +0200 | _0x47_ | (sid508683@id-508683.tinside.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-04-12 06:41:35 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-04-12 06:41:39 +0200 | jackdk | (sid373013@cssa/jackdk) (Ping timeout: 250 seconds) |
| 2022-04-12 06:41:48 +0200 | Adeon | (sid418992@id-418992.lymington.irccloud.com) (Ping timeout: 240 seconds) |
| 2022-04-12 06:41:54 +0200 | hamishmack_ | (sid389057@id-389057.hampstead.irccloud.com) |
| 2022-04-12 06:42:01 +0200 | ephemient | (uid407513@id-407513.lymington.irccloud.com) (Ping timeout: 245 seconds) |
| 2022-04-12 06:42:36 +0200 | kristjansson | (sid126207@id-126207.tinside.irccloud.com) (Ping timeout: 240 seconds) |
| 2022-04-12 06:42:39 +0200 | Unicorn_Princess | (~Unicorn_P@93-103-228-248.dynamic.t-2.net) (Remote host closed the connection) |
| 2022-04-12 06:43:09 +0200 | PotatoGim | (sid99505@id-99505.lymington.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-04-12 06:43:13 +0200 | kristjansson | (sid126207@id-126207.tinside.irccloud.com) |
| 2022-04-12 06:43:16 +0200 | jackdk | (sid373013@cssa/jackdk) |
| 2022-04-12 06:43:24 +0200 | scav | (sid309693@user/scav) (Ping timeout: 240 seconds) |
| 2022-04-12 06:43:36 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 248 seconds) |
| 2022-04-12 06:43:43 +0200 | elvishjerricco | (sid237756@id-237756.helmsley.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-04-12 06:44:29 +0200 | elvishjerricco | (sid237756@id-237756.helmsley.irccloud.com) |
| 2022-04-12 06:44:40 +0200 | PotatoGim | (sid99505@id-99505.lymington.irccloud.com) |
| 2022-04-12 06:44:59 +0200 | Adeon | (sid418992@id-418992.lymington.irccloud.com) |
| 2022-04-12 06:45:05 +0200 | _0x47_ | (sid508683@id-508683.tinside.irccloud.com) |
| 2022-04-12 06:45:06 +0200 | scav | (sid309693@user/scav) |
| 2022-04-12 06:45:17 +0200 | ephemient | (uid407513@id-407513.lymington.irccloud.com) |
| 2022-04-12 06:46:16 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 06:46:47 +0200 | abastro | (~abab9579@143.248.229.139) (Ping timeout: 256 seconds) |
| 2022-04-12 06:51:09 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 06:55:20 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 248 seconds) |
| 2022-04-12 06:55:51 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 07:00:02 +0200 | slack1256 | (~slack1256@191.125.99.201) (Ping timeout: 250 seconds) |
| 2022-04-12 07:05:28 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 07:06:02 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 07:09:52 +0200 | Macbethwin | (~chargen@D964062A.static.ziggozakelijk.nl) |
| 2022-04-12 07:10:01 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 07:11:03 +0200 | coot | (~coot@213.134.190.95) |
| 2022-04-12 07:14:43 +0200 | pavonia | (~user@user/siracusa) |
| 2022-04-12 07:15:37 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 07:20:13 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 07:22:31 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 07:23:24 +0200 | abastro | (~abab9579@143.248.229.139) |
| 2022-04-12 07:23:34 +0200 | odnes | (~odnes@5-203-221-3.pat.nym.cosmote.net) |
| 2022-04-12 07:25:12 +0200 | z0k | (~z0k@39.40.60.29) (Ping timeout: 248 seconds) |
| 2022-04-12 07:25:25 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 07:25:47 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 07:25:57 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 07:26:47 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 240 seconds) |
| 2022-04-12 07:27:01 +0200 | mbuf | (~Shakthi@122.174.160.5) |
| 2022-04-12 07:27:17 +0200 | z0k | (~z0k@39.40.123.226) |
| 2022-04-12 07:30:25 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 07:32:10 +0200 | benin | (~benin@183.82.204.110) |
| 2022-04-12 07:33:46 +0200 | lispy | (~lispy@82.212.119.74) |
| 2022-04-12 07:35:39 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 07:36:16 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 07:37:48 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-04-12 07:38:54 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-04-12 07:39:47 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-04-12 07:40:37 +0200 | ishaan | (~ishaan@122.161.52.79) (Ping timeout: 256 seconds) |
| 2022-04-12 07:41:07 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-04-12 07:41:28 +0200 | ishaan | (~ishaan@122.161.52.79) |
| 2022-04-12 07:42:45 +0200 | abastro | (~abab9579@143.248.229.139) (Remote host closed the connection) |
| 2022-04-12 07:43:01 +0200 | abastro | (~abab9579@143.248.229.139) |
| 2022-04-12 07:47:21 +0200 | benin7 | (benin@gateway/vpn/protonvpn/benin) |
| 2022-04-12 07:48:26 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 07:48:27 +0200 | benin | (~benin@183.82.204.110) (Ping timeout: 240 seconds) |
| 2022-04-12 07:48:35 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 07:48:54 +0200 | robosexual | (~spaceoyst@77.223.90.202) |
| 2022-04-12 07:49:24 +0200 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-04-12 07:49:58 +0200 | robosexual | (~spaceoyst@77.223.90.202) (Client Quit) |
| 2022-04-12 07:50:03 +0200 | benin | (benin@gateway/vpn/protonvpn/benin) |
| 2022-04-12 07:50:27 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-04-12 07:51:06 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 07:51:47 +0200 | benin7 | (benin@gateway/vpn/protonvpn/benin) (Ping timeout: 240 seconds) |
| 2022-04-12 07:52:54 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 07:53:05 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 07:58:22 +0200 | benin2 | (~benin@183.82.204.110) |
| 2022-04-12 08:00:07 +0200 | benin | (benin@gateway/vpn/protonvpn/benin) (Ping timeout: 240 seconds) |
| 2022-04-12 08:00:07 +0200 | benin2 | benin |
| 2022-04-12 08:00:21 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) |
| 2022-04-12 08:07:26 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-04-12 08:07:27 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 240 seconds) |
| 2022-04-12 08:08:31 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 08:08:41 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 08:12:36 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 08:16:42 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-04-12 08:20:27 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 2022-04-12 08:24:37 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-04-12 08:26:36 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 240 seconds) |
| 2022-04-12 08:30:27 +0200 | z0k | (~z0k@39.40.123.226) (Ping timeout: 240 seconds) |
| 2022-04-12 08:31:15 +0200 | mattil | (~mattil@helsinki.portalify.com) |
| 2022-04-12 08:31:31 +0200 | z0k | (~z0k@39.40.123.226) |
| 2022-04-12 08:36:47 +0200 | Macbethwin | (~chargen@D964062A.static.ziggozakelijk.nl) (Ping timeout: 240 seconds) |
| 2022-04-12 08:38:20 +0200 | joo-_ | (~joo-_@fsf/member/joo--) (Quit: Lost terminal) |
| 2022-04-12 08:39:45 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 08:39:53 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-04-12 08:40:39 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 08:40:56 +0200 | ishaan | (~ishaan@122.161.52.79) (Ping timeout: 248 seconds) |
| 2022-04-12 08:41:07 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 08:41:43 +0200 | ishaan | (~ishaan@122.161.52.79) |
| 2022-04-12 08:44:09 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) |
| 2022-04-12 08:44:40 +0200 | jonathanx_ | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 272 seconds) |
| 2022-04-12 08:53:00 +0200 | teehemkay | (sid14792@id-14792.lymington.irccloud.com) (Ping timeout: 240 seconds) |
| 2022-04-12 08:53:17 +0200 | JSharp | (sid4580@id-4580.lymington.irccloud.com) (Ping timeout: 260 seconds) |
| 2022-04-12 08:53:35 +0200 | alp_ | (~alp@user/alp) |
| 2022-04-12 08:54:12 +0200 | sunarch | (sid526836@user/sunarch) (Ping timeout: 240 seconds) |
| 2022-04-12 08:55:51 +0200 | sunarch | (sid526836@user/sunarch) |
| 2022-04-12 08:56:10 +0200 | teehemkay | (sid14792@id-14792.lymington.irccloud.com) |
| 2022-04-12 08:57:24 +0200 | JSharp | (sid4580@id-4580.lymington.irccloud.com) |
| 2022-04-12 08:57:41 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) |
| 2022-04-12 08:59:01 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-04-12 08:59:54 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 09:00:02 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 09:01:13 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 09:06:35 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2022-04-12 09:09:02 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-04-12 09:09:08 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6aaf:d90d:7db8:1a48) |
| 2022-04-12 09:11:28 +0200 | InstX1_ | (~Liam@2601:6c4:4080:3f80:1d4a:af44:f702:f9c0) |
| 2022-04-12 09:11:44 +0200 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-04-12 09:13:06 +0200 | MajorBiscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) |
| 2022-04-12 09:13:56 +0200 | InstX1 | (~Liam@2601:6c4:4080:3f80:2c03:bab3:ea6:cda) (Ping timeout: 250 seconds) |
| 2022-04-12 09:14:37 +0200 | Major_Biscuit | (~MajorBisc@c-001-009-035.client.tudelft.eduvpn.nl) |
| 2022-04-12 09:15:48 +0200 | zeenk | (~zeenk@2a02:2f04:a313:d600:8d26:ec9f:3ff6:fc94) |
| 2022-04-12 09:15:48 +0200 | benin | (~benin@183.82.204.110) (Remote host closed the connection) |
| 2022-04-12 09:15:59 +0200 | vysn | (~vysn@user/vysn) (Quit: WeeChat 3.4) |
| 2022-04-12 09:16:52 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 09:17:00 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 09:18:05 +0200 | MajorBiscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) (Ping timeout: 256 seconds) |
| 2022-04-12 09:18:08 +0200 | chele | (~chele@user/chele) |
| 2022-04-12 09:18:34 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2022-04-12 09:23:15 +0200 | michalz | (~michalz@185.246.204.107) |
| 2022-04-12 09:23:54 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 250 seconds) |
| 2022-04-12 09:24:33 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 09:24:43 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 09:25:25 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 09:25:30 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 09:26:10 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) |
| 2022-04-12 09:26:56 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 09:29:10 +0200 | dextaa | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-04-12 09:29:28 +0200 | wmacmil_ | (~wmacmil@108-194-162-159.lightspeed.renonv.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2022-04-12 09:30:02 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 09:31:27 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 240 seconds) |
| 2022-04-12 09:32:23 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 09:32:32 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 09:32:40 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) (Ping timeout: 248 seconds) |
| 2022-04-12 09:33:58 +0200 | dextaa | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-04-12 09:34:49 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 09:39:02 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 09:42:08 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 09:43:57 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 246 seconds) |
| 2022-04-12 09:48:54 +0200 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-04-12 09:49:46 +0200 | CiaoSen | (~Jura@p200300c9572d40002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-04-12 09:52:12 +0200 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 240 seconds) |
| 2022-04-12 09:55:17 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-04-12 09:56:03 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) |
| 2022-04-12 09:56:36 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 09:57:10 +0200 | vysn | (~vysn@user/vysn) |
| 2022-04-12 09:59:31 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-04-12 10:05:10 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) |
| 2022-04-12 10:06:02 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-04-12 10:08:39 +0200 | razetime | (~quassel@117.254.34.230) |
| 2022-04-12 10:09:23 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 10:14:38 +0200 | <razetime> | is there a way to change operator precedence in Haskell? |
| 2022-04-12 10:16:07 +0200 | <merijn> | razetime: Of ones you define? Or of existing ones? |
| 2022-04-12 10:16:14 +0200 | <razetime> | of existing ones. |
| 2022-04-12 10:16:20 +0200 | <merijn> | No |
| 2022-04-12 10:16:41 +0200 | <[exa]> | can't you hide them from imports and re-declare? |
| 2022-04-12 10:16:51 +0200 | <[exa]> | (not that it would be a lot of fun to do though) |
| 2022-04-12 10:16:59 +0200 | <merijn> | [exa]: That's not changing precedence, that's defining something new with a different precedence |
| 2022-04-12 10:17:08 +0200 | <merijn> | Also, dear god, don't |
| 2022-04-12 10:17:22 +0200 | <[exa]> | yeah that's true ^ |
| 2022-04-12 10:17:25 +0200 | <merijn> | I will find you and haunt you forever |
| 2022-04-12 10:17:54 +0200 | <razetime> | hm alright |
| 2022-04-12 10:18:02 +0200 | <neverwas> | lol |
| 2022-04-12 10:19:57 +0200 | MasseR46 | (~MasseR@51.15.143.128) (Quit: Ping timeout (120 seconds)) |
| 2022-04-12 10:20:04 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-04-12 10:20:12 +0200 | <razetime> | i will find a good hiding spot and attempt this forbidden ritual |
| 2022-04-12 10:20:13 +0200 | MasseR46 | (~MasseR@51.15.143.128) |
| 2022-04-12 10:20:40 +0200 | mattil | (~mattil@helsinki.portalify.com) (Ping timeout: 248 seconds) |
| 2022-04-12 10:20:40 +0200 | little_mac | (~little_ma@2601:410:4300:3ce0::fa0b) (Quit: Leaving) |
| 2022-04-12 10:20:48 +0200 | <merijn> | That's basically "how can I *subtly* change the meaning of widely understood/used operators, effectively turning all seemingly innocent code into booby-trapped territory to scare and confuse any reader" |
| 2022-04-12 10:21:36 +0200 | ccntrq | (~Thunderbi@2a01:e34:eccb:b060:63fb:4f44:a784:526) |
| 2022-04-12 10:22:10 +0200 | <razetime> | i just want to try a plain right to left haskell |
| 2022-04-12 10:22:31 +0200 | <razetime> | i'm not writing anything important, just an experiment |
| 2022-04-12 10:22:42 +0200 | <merijn> | I don't know what that means and I'm not sure I want to know >.> |
| 2022-04-12 10:23:21 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 248 seconds) |
| 2022-04-12 10:23:32 +0200 | <[exa]> | razetime: I assume that's about the order of arguments of (.) ? |
| 2022-04-12 10:24:00 +0200 | <razetime> | no, not really |
| 2022-04-12 10:24:33 +0200 | <[exa]> | or more like support for rtl writing systems? |
| 2022-04-12 10:25:37 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-04-12 10:25:58 +0200 | <razetime> | an APLish evaluation order |
| 2022-04-12 10:26:37 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) (Quit: WeeChat 3.4.1) |
| 2022-04-12 10:26:38 +0200 | bw | (sid2730@user/betawaffle) (Ping timeout: 272 seconds) |
| 2022-04-12 10:27:52 +0200 | <merijn> | razetime: Just to be clear: You're aware that precedence and evaluation order are fundamentally *un*related, yeah? |
| 2022-04-12 10:28:04 +0200 | bw | (sid2730@user/betawaffle) |
| 2022-04-12 10:28:35 +0200 | <razetime> | yes I just don't know the right words, so this is a bit confusing |
| 2022-04-12 10:28:38 +0200 | <merijn> | and changing precedence of operators will have 0 effect on evaluation order |
| 2022-04-12 10:29:40 +0200 | <razetime> | i think i need both |
| 2022-04-12 10:31:48 +0200 | newhoggy | (sid198874@id-198874.helmsley.irccloud.com) (Ping timeout: 240 seconds) |
| 2022-04-12 10:32:42 +0200 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Remote host closed the connection) |
| 2022-04-12 10:32:59 +0200 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-04-12 10:33:00 +0200 | bw | (sid2730@user/betawaffle) (Max SendQ exceeded) |
| 2022-04-12 10:33:03 +0200 | <siers> | how do profunctors generalize functions? the actual instance of a "Profunctor a b" can accept more and return more? |
| 2022-04-12 10:33:05 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-04-12 10:33:38 +0200 | obviyus | (sid415299@user/obviyus) (Ping timeout: 252 seconds) |
| 2022-04-12 10:33:56 +0200 | bw | (sid2730@user/betawaffle) |
| 2022-04-12 10:34:26 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-04-12 10:34:42 +0200 | aria | (sid380617@lymington.irccloud.com) (Ping timeout: 246 seconds) |
| 2022-04-12 10:35:09 +0200 | newhoggy | (sid198874@id-198874.helmsley.irccloud.com) |
| 2022-04-12 10:35:27 +0200 | obviyus | (sid415299@user/obviyus) |
| 2022-04-12 10:35:46 +0200 | systemfault | (sid267009@id-267009.uxbridge.irccloud.com) (Ping timeout: 245 seconds) |
| 2022-04-12 10:36:57 +0200 | <merijn> | siers: What makes you say the *generalise* functions? |
| 2022-04-12 10:37:30 +0200 | <merijn> | That feels like saying "Functor generalises Maybe" or "Functor generalises lists"? |
| 2022-04-12 10:37:35 +0200 | systemfault | (sid267009@id-267009.uxbridge.irccloud.com) |
| 2022-04-12 10:37:47 +0200 | <siers> | fair! |
| 2022-04-12 10:37:51 +0200 | aria | (sid380617@id-380617.lymington.irccloud.com) |
| 2022-04-12 10:38:00 +0200 | <siers> | I guess that's because I cannot imagine a whole lot other than functions that are profunctors |
| 2022-04-12 10:38:47 +0200 | redb | (~nmh@136.49.49.211) (Ping timeout: 240 seconds) |
| 2022-04-12 10:38:59 +0200 | <siers> | well, I can, but they're function-ish |
| 2022-04-12 10:39:08 +0200 | <siers> | in the end there's a function somewhere |
| 2022-04-12 10:39:25 +0200 | <merijn> | My personal intuition for profunctors are something "pipe-ish" |
| 2022-04-12 10:39:32 +0200 | <abastro> | arrow-ish |
| 2022-04-12 10:39:36 +0200 | <abastro> | Imho |
| 2022-04-12 10:40:49 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 10:41:09 +0200 | akegalj | (~akegalj@78-3-32-236.adsl.net.t-com.hr) |
| 2022-04-12 10:41:22 +0200 | redb | (~nmh@136.49.49.211) |
| 2022-04-12 10:42:45 +0200 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-04-12 10:42:52 +0200 | <haskellberryfinn> | https://pastebin.com/9rySbF9F |
| 2022-04-12 10:43:02 +0200 | <haskellberryfinn> | could anyone take a look at this type family issue? |
| 2022-04-12 10:45:03 +0200 | <merijn> | haskellberryfinn: On line 24 you're adding the result of indexl to an Int |
| 2022-04-12 10:45:20 +0200 | <merijn> | haskellberryfinn: Which is a type error, because you can't know that the result type of indexl is Int |
| 2022-04-12 10:45:51 +0200 | <haskellberryfinn> | thankyou merijn . how to make this work? |
| 2022-04-12 10:45:57 +0200 | <merijn> | Simple counterexample: [Char] is ListLike, but 'Elem [Char]' is Char, not Int |
| 2022-04-12 10:46:09 +0200 | <merijn> | Eh, the short answer is: You can't |
| 2022-04-12 10:46:31 +0200 | <haskellberryfinn> | Seems to me that I need to make use of the associated type family somewhere |
| 2022-04-12 10:46:37 +0200 | <merijn> | The longer answer is: It depends on what you're trying to do, because I have no clue |
| 2022-04-12 10:47:08 +0200 | <merijn> | haskellberryfinn: Your code assumes that the element type is Int but your type signature doesn't require that at all |
| 2022-04-12 10:47:29 +0200 | <merijn> | I guess you could do "(ListLike l, Elem l ~ Int) => ..." |
| 2022-04-12 10:47:37 +0200 | <haskellberryfinn> | I want to apply the cutrod function a certain ListLike types whose inner types are Int |
| 2022-04-12 10:48:02 +0200 | pranshukhandal | (pranshukha@envs.net) (Quit: the lounge - https://webirc.envs.net) |
| 2022-04-12 10:48:16 +0200 | <merijn> | My personal hot-take is: This ListLike class is a terrible idea and you shouldn't use it |
| 2022-04-12 10:48:23 +0200 | <haskellberryfinn> | merijn: It works! |
| 2022-04-12 10:48:30 +0200 | pranshukhandal | (pranshukha@envs.net) |
| 2022-04-12 10:48:36 +0200 | sus | (zero@user/zeromomentum) |
| 2022-04-12 10:48:50 +0200 | <haskellberryfinn> | merijn: I have to define cutrod for list and vector |
| 2022-04-12 10:48:59 +0200 | <haskellberryfinn> | that's why i thought of making this class |
| 2022-04-12 10:49:31 +0200 | <merijn> | In fact, you could simply change cutrod to: 'cutrod :: (f a -> Int) -> f a -> Int -> Int' and get 100% of the flexibility with zero percent of the problems |
| 2022-04-12 10:50:00 +0200 | <merijn> | And then use "cutrod (!!)" to use lists and "cutrod (V.!)" to use vectors |
| 2022-04-12 10:50:28 +0200 | <abastro> | Why Listlike type |
| 2022-04-12 10:50:43 +0200 | <abastro> | Oh that one was resolved I guess |
| 2022-04-12 10:50:49 +0200 | <haskellberryfinn> | how to tell if f a is a list or a vector? |
| 2022-04-12 10:51:03 +0200 | <haskellberryfinn> | pattern matching? |
| 2022-04-12 10:51:04 +0200 | <merijn> | haskellberryfinn: https://paste.tomsmeding.com/vjpSi8Z2 |
| 2022-04-12 10:51:14 +0200 | <merijn> | haskellberryfinn: that's inferred from the first argument |
| 2022-04-12 10:51:21 +0200 | <siers> | merijn, what's some example of something pipeish? |
| 2022-04-12 10:51:27 +0200 | <merijn> | ah, wait, slight typo |
| 2022-04-12 10:51:36 +0200 | <merijn> | I guess it should be (f a -> Int -> Int) |
| 2022-04-12 10:51:39 +0200 | <merijn> | for the first argument |
| 2022-04-12 10:52:15 +0200 | <merijn> | haskellberryfinn: If you call "cutprod (!!)" then since "(!!) :: [a] -> Int -> a" it will infer 'f = []' and 'a = Int' |
| 2022-04-12 10:52:18 +0200 | <haskellberryfinn> | nice... this is a much simpler solution |
| 2022-04-12 10:52:42 +0200 | <merijn> | If you call "cutprod (V.!)" then since "V.! :: Vector a -> Int -> a" it infers 'f = Vector' and 'a = Int' |
| 2022-04-12 10:53:45 +0200 | <abastro> | Can anyone help coming up with better solution for this kind of counting? It *should* involve a monoid, at least: https://paste.tomsmeding.com/Nhg5haqd |
| 2022-04-12 10:54:57 +0200 | <merijn> | haskellberryfinn: It's always good to remember that typeclasses can't really do anything more that "just passing in the relevant functions" can't also do. Typeclasses are really just a way to automatically pass some functions in, but 90% of the time just manually passing those functions gets you more flexibility for less effort :) |
| 2022-04-12 10:55:37 +0200 | <haskellberryfinn> | they should put that in the typeclasses wiki:) |
| 2022-04-12 10:56:18 +0200 | <haskellberryfinn> | eye opener |
| 2022-04-12 10:57:08 +0200 | jonathanx | (~jonathan@dyn-4-sc.cdg.chalmers.se) |
| 2022-04-12 10:58:55 +0200 | ubert | (~Thunderbi@p200300ecdf1588e2dc67a3f08aaa94d0.dip0.t-ipconnect.de) |
| 2022-04-12 10:59:23 +0200 | alp_ | (~alp@user/alp) (Remote host closed the connection) |
| 2022-04-12 10:59:25 +0200 | alp__ | (~alp@user/alp) |
| 2022-04-12 10:59:56 +0200 | <abastro> | Perhaps my question is too out of context? |
| 2022-04-12 11:00:30 +0200 | <abastro> | I could add for which algorithm puzzle it is for |
| 2022-04-12 11:01:29 +0200 | <[exa]> | abastro: yeah the goals there are not really obvious |
| 2022-04-12 11:02:19 +0200 | jonathanx_ | (~jonathan@dyn-5-sc.cdg.chalmers.se) |
| 2022-04-12 11:04:56 +0200 | jonathanx | (~jonathan@dyn-4-sc.cdg.chalmers.se) (Ping timeout: 248 seconds) |
| 2022-04-12 11:07:27 +0200 | CiaoSen | (~Jura@p200300c9572d40002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-04-12 11:07:34 +0200 | <abastro> | It's to solve this one: https://leetcode.com/problems/longest-substring-of-one-repeating-character/ |
| 2022-04-12 11:08:21 +0200 | <abastro> | Thought clearly it would be easy (it is just a coding puzzle, you know) but it seems like constructing proper monoid is quite bothersome |
| 2022-04-12 11:08:55 +0200 | <abastro> | Basically the goal is counting longest substring consists of one repeating character |
| 2022-04-12 11:09:11 +0200 | <abastro> | But the string can be locally modified one by one. |
| 2022-04-12 11:09:21 +0200 | <abastro> | Any ideas on cleaner monoid? |
| 2022-04-12 11:09:39 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:10:14 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 11:10:23 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:12:08 +0200 | <[exa]> | any reason to make it so generic? (for the task, the characters can be assumed as anything finite that has Eq, so easily an Int) |
| 2022-04-12 11:13:39 +0200 | <[exa]> | anyway, what time complexity do they expect? for big data you will need something skiplist-ish or tree-ish |
| 2022-04-12 11:14:30 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 11:14:30 +0200 | bahamas | (~lucian@86.120.77.115) |
| 2022-04-12 11:14:50 +0200 | abastro | (~abab9579@143.248.229.139) (Ping timeout: 250 seconds) |
| 2022-04-12 11:14:54 +0200 | <bahamas> | what do you find to be common sources of confusion, especially for beginners? |
| 2022-04-12 11:16:17 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 11:18:53 +0200 | sloorush | (~sloorush@136.233.9.99) |
| 2022-04-12 11:19:00 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 11:19:08 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:20:14 +0200 | <merijn> | bahamas: Number one source of confusion is "wanting to skip the fundamentals to get to the interesting bits". Specifically the "I wanna figure out what Monads *really* are!" line of thinking, but not wanting to invest the time to get comfortable with types/typeclasses first, which then leads to lots of magical thinking |
| 2022-04-12 11:21:06 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 11:21:27 +0200 | <merijn> | bahamas: Another slightly more advanced problem I often see is "overeagerness", which usually manifests as "I just understood typeclasses, I'm gonna make *everything* a typeclass!", "I just learned type level stuff like GADTs/type families, I'm gonna statically check *everything* in the typesystem" |
| 2022-04-12 11:21:28 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 248 seconds) |
| 2022-04-12 11:21:44 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 11:21:47 +0200 | <merijn> | And "IO == bad" is a common source of problems |
| 2022-04-12 11:21:52 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:22:22 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 11:22:37 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:23:11 +0200 | <[exa]> | bahamas: listing a few: the fact that Nothing isn't like java null, equality vs monadic bindings, "monads are impure right?", and various problems with too much recursion and laziness at one place that require some time to wrap the head around (e.g. the zipWith fibonaccis) |
| 2022-04-12 11:23:34 +0200 | synthmeat | (~synthmeat@user/synthmeat) (Quit: WeeChat 3.0) |
| 2022-04-12 11:23:47 +0200 | synthmeat | (~synthmeat@user/synthmeat) |
| 2022-04-12 11:23:54 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 11:24:23 +0200 | <maerwald[m]> | Or the fact that most tutorials on laziness are trash |
| 2022-04-12 11:24:47 +0200 | <merijn> | maerwald[m]: The only one I know is the one by Apfelmus and monochrom both of which I consider quite good? |
| 2022-04-12 11:24:51 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 11:24:58 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-04-12 11:25:01 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:25:05 +0200 | <maerwald[m]> | merijn: yes, those two are the only ones |
| 2022-04-12 11:25:37 +0200 | <merijn> | maerwald[m]: "those are the only ones" as in the only tutorials or the only good ones? |
| 2022-04-12 11:25:46 +0200 | <maerwald[m]> | Yeah |
| 2022-04-12 11:26:08 +0200 | <merijn> | brb, learning Lojban >.> |
| 2022-04-12 11:26:23 +0200 | <maerwald[m]> | The rest shows you [0..] |
| 2022-04-12 11:26:24 +0200 | synthmeat | (~synthmeat@user/synthmeat) (Remote host closed the connection) |
| 2022-04-12 11:26:42 +0200 | synthmeat | (~synthmeat@user/synthmeat) |
| 2022-04-12 11:28:33 +0200 | mason0 | (~bc8147f2@cerf.good1.com) |
| 2022-04-12 11:30:29 +0200 | <bahamas> | [exa]: can you clarify equality vs monadic bindings? |
| 2022-04-12 11:31:33 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 11:31:41 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:31:48 +0200 | synthmeat | (~synthmeat@user/synthmeat) (Quit: WeeChat 3.0) |
| 2022-04-12 11:31:51 +0200 | <[exa]> | bahamas: basically mixing stuff which needs to be bind with >>= and which can't be, e.g. trying `let myString = readLine` or `x <- 1+2+3` and hoping it will work |
| 2022-04-12 11:32:14 +0200 | synthmeat | (~synthmeat@user/synthmeat) |
| 2022-04-12 11:32:19 +0200 | <[exa]> | the latter often "kinda works" with lists, which makes debugging super hard (the type error will not be comprehensible to newbies at all) |
| 2022-04-12 11:32:57 +0200 | robosexual | (~robosexua@77.223.90.202) (Client Quit) |
| 2022-04-12 11:34:16 +0200 | <bahamas> | [exa]: ah, you mean mixing stuff that belongs in a do block with stuff that doesn't |
| 2022-04-12 11:34:42 +0200 | <[exa]> | yes |
| 2022-04-12 11:37:07 +0200 | xff0x | (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) (Ping timeout: 240 seconds) |
| 2022-04-12 11:38:30 +0200 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Quit: WeeChat 3.3) |
| 2022-04-12 11:38:36 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 11:39:11 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 11:39:44 +0200 | dextaa | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-04-12 11:43:20 +0200 | bahamas | (~lucian@86.120.77.115) (Ping timeout: 248 seconds) |
| 2022-04-12 11:44:22 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 11:44:58 +0200 | ubert | (~Thunderbi@p200300ecdf1588e2dc67a3f08aaa94d0.dip0.t-ipconnect.de) (Quit: ubert) |
| 2022-04-12 11:44:59 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 11:45:12 +0200 | ubert | (~Thunderbi@p200300ecdf1588e22aca51cd048e2ffe.dip0.t-ipconnect.de) |
| 2022-04-12 11:47:24 +0200 | InstX1_ | (~Liam@2601:6c4:4080:3f80:1d4a:af44:f702:f9c0) (Ping timeout: 240 seconds) |
| 2022-04-12 11:53:25 +0200 | <abastro[m]> | [exa]: regarding https://leetcode.com/problems/longest-substring-of-one-repeating-character/ |
| 2022-04-12 11:53:47 +0200 | <abastro[m]> | I need O(log n) time for each update. |
| 2022-04-12 11:54:42 +0200 | <abastro[m]> | [exa]: Well also I don't see how specializing the type into `Int` helps with the problem |
| 2022-04-12 11:54:44 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 11:55:14 +0200 | <merijn> | abastro[m]: Your problem is that you're using list |
| 2022-04-12 11:55:28 +0200 | <abastro[m]> | I am not using a list though. |
| 2022-04-12 11:56:02 +0200 | <merijn> | abastro[m]: Your using foldMap on a String |
| 2022-04-12 11:56:08 +0200 | <merijn> | And String is just a list |
| 2022-04-12 11:56:15 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-04-12 11:56:23 +0200 | <merijn> | You're always gonna get O(n) performance using list as input |
| 2022-04-12 11:56:34 +0200 | <merijn> | Because you're gonna traverse the list sequentially |
| 2022-04-12 11:56:40 +0200 | z0k | (~z0k@39.40.123.226) (Ping timeout: 248 seconds) |
| 2022-04-12 11:56:43 +0200 | <abastro[m]> | Oh, you mean the code? |
| 2022-04-12 11:56:43 +0200 | <abastro[m]> | That was to display how it works |
| 2022-04-12 11:57:22 +0200 | <abastro[m]> | To solve the actual problem, I am going to use a specific data structure called Segment Tree |
| 2022-04-12 11:57:28 +0200 | <anomal> | Booleans shouldn't be values, but branches |
| 2022-04-12 11:57:34 +0200 | <anomal> | Do you agree |
| 2022-04-12 11:57:50 +0200 | <abastro[m]> | Wat |
| 2022-04-12 11:57:55 +0200 | <razetime> | is haskell allowed on leetcode? |
| 2022-04-12 11:58:11 +0200 | <abastro[m]> | No, haskell is not allowed on the platform |
| 2022-04-12 11:58:25 +0200 | <abastro[m]> | Ofc, why thet would allow a research language /s |
| 2022-04-12 11:58:41 +0200 | <merijn> | abastro[m]: I'm not sure what you mean by O(log n) time for update, I guess? |
| 2022-04-12 11:58:55 +0200 | <abastro[m]> | I am just toying with it, trying to come up with haskell solution. |
| 2022-04-12 11:59:25 +0200 | <abastro[m]> | Let me explain |
| 2022-04-12 11:59:26 +0200 | <merijn> | Although at first glance the naive linear O(n) is always gonna win for this problem anyway |
| 2022-04-12 11:59:27 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 240 seconds) |
| 2022-04-12 11:59:40 +0200 | abastro | (~abab9579@143.248.229.139) |
| 2022-04-12 11:59:59 +0200 | <abastro> | Basically the goal is counting longest substring consists of one repeating character |
| 2022-04-12 12:00:16 +0200 | <abastro> | So, we have this string `str` |
| 2022-04-12 12:00:22 +0200 | <abastro> | We will change the string n times |
| 2022-04-12 12:00:35 +0200 | <abastro> | For each step, single character of the string will change |
| 2022-04-12 12:01:15 +0200 | <abastro> | The task is to print "length of longest substring of repeated character" for each step. |
| 2022-04-12 12:02:04 +0200 | <abastro> | The goal is to attain `O(n * log (length str))` |
| 2022-04-12 12:02:25 +0200 | razetime | (~quassel@117.254.34.230) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-04-12 12:02:40 +0200 | razetime | (~quassel@117.254.34.230) |
| 2022-04-12 12:02:43 +0200 | <abastro> | merijn, [exa]: Would you like more details? |
| 2022-04-12 12:03:08 +0200 | jespada | (~jespada@2a0c:5c84:1:4000::8dad) (Remote host closed the connection) |
| 2022-04-12 12:03:09 +0200 | <merijn> | I looked at the leetcode site and have decided this problem is merely annoying and not actually all the interesting >.> |
| 2022-04-12 12:03:38 +0200 | <abastro> | Annoying? |
| 2022-04-12 12:04:15 +0200 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Quit: Chai-T-Rex) |
| 2022-04-12 12:04:20 +0200 | <merijn> | abastro: The problem is very artificial (i.e. doesn't really resemble anything reasonable) and is formulated in such a way to make solving maximally frustrating |
| 2022-04-12 12:04:31 +0200 | <abastro> | (Well I think at least many typical hirers would like this kind of questions) |
| 2022-04-12 12:04:50 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-04-12 12:04:58 +0200 | <abastro> | Well yeah, majority of competitive programming puzzles are artificial |
| 2022-04-12 12:05:34 +0200 | <merijn> | artificial in the sense of "does not look like a problem actually occuring in realistic code" |
| 2022-04-12 12:05:46 +0200 | <abastro> | Still, it seems like such solving skills are quite useful for getting hired |
| 2022-04-12 12:06:00 +0200 | <merijn> | as opposed to the Advent of Code puzzles which are still artificial in the sense of "invented for a puzzle" but almost always remind me of *actual* problems |
| 2022-04-12 12:06:01 +0200 | <anomal> | I take it booleans are pretty incontroversial |
| 2022-04-12 12:06:24 +0200 | <abastro> | AoC puzzles are of very rare bunch |
| 2022-04-12 12:06:48 +0200 | <abastro> | That said, I don't think anyone in my region would ever consider AoC when hiring |
| 2022-04-12 12:07:16 +0200 | <abastro> | Would rather hand out sth like this leetcode problem whenever hiring |
| 2022-04-12 12:07:34 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 12:07:41 +0200 | <merijn> | If anyone gave me this problem in an interview I'd just laugh and say "no thanks" :p |
| 2022-04-12 12:07:55 +0200 | <abastro> | Well, not in interview I guess |
| 2022-04-12 12:08:11 +0200 | <abastro> | Rather, in coding test before an actual interview |
| 2022-04-12 12:08:37 +0200 | jespada | (~jespada@2a0c:5c84:1:3000::3b58) |
| 2022-04-12 12:08:39 +0200 | <merijn> | Same response, tbh |
| 2022-04-12 12:09:27 +0200 | <abastro> | Oh. How would you become hired.. oh. I guess companies in your region just knows betteer |
| 2022-04-12 12:10:02 +0200 | <anomal> | merijn: at the same time we have to pass pointless hurdles at all stages of life |
| 2022-04-12 12:10:05 +0200 | <merijn> | The fact that a large number of programmers consider this reasonable is just baffling to me |
| 2022-04-12 12:10:15 +0200 | <anomal> | merijn: all education is just pointless stuff and tests |
| 2022-04-12 12:10:31 +0200 | <abastro> | Yep, tho it is similar for most things |
| 2022-04-12 12:10:46 +0200 | <abastro> | Lots of things in our world are baffling |
| 2022-04-12 12:11:50 +0200 | <abastro> | Another useless problem: https://leetcode.com/problems/largest-rectangle-in-histogram/. Apparently 9578 ppl thought it was a great problem! |
| 2022-04-12 12:12:06 +0200 | <abastro> | (Or perhaps my reality check is skewed and it is actually a good problem) |
| 2022-04-12 12:12:38 +0200 | <merijn> | That one is a lot more interesting, tbh |
| 2022-04-12 12:13:04 +0200 | <abastro> | Hm, I see |
| 2022-04-12 12:13:31 +0200 | <abastro> | Perhaps that problem in specific was the bad one, I guess |
| 2022-04-12 12:13:39 +0200 | <abastro> | I need to fix my reality check now |
| 2022-04-12 12:14:21 +0200 | <merijn> | abastro: The issue is that it tempts you to figure out some "smart" solution, in reality, writing a stupid linear solution and rerunning it after every update is almost certainly gonna be way faster |
| 2022-04-12 12:15:06 +0200 | <abastro> | Oh, I don't think linear solution is faster though. |
| 2022-04-12 12:15:34 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 272 seconds) |
| 2022-04-12 12:16:01 +0200 | <abastro> | This thing called Segmented Tree is just a binary tree with tags on each branch. |
| 2022-04-12 12:16:27 +0200 | <abastro> | Which allows easy recalculation of the statistics over the entire tree, when things locally change |
| 2022-04-12 12:19:43 +0200 | <abastro> | Actually yeah, it is a modification of "Segment Tree" data structure |
| 2022-04-12 12:19:59 +0200 | <abastro> | Actual segment tree is for storing interval where query time takes O(log n) |
| 2022-04-12 12:20:12 +0200 | <abastro> | Anyway, it allows you to explore such novel data structures. |
| 2022-04-12 12:20:47 +0200 | <abastro> | So, merijn, for which specific reason do you think this solution would be slower than stupid linear solution? |
| 2022-04-12 12:21:20 +0200 | <abastro> | (Perhaps relevant: https://stackoverflow.com/questions/17466218/what-are-the-differences-between-segment-trees-interv… ) |
| 2022-04-12 12:26:40 +0200 | <anomal> | Does functional programming arise from lambda calculus, the other way around, or they're unrelated/ |
| 2022-04-12 12:27:44 +0200 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-04-12 12:28:40 +0200 | <abastro> | <del>Problem: what is functional programming</del> |
| 2022-04-12 12:28:40 +0200 | <abastro> | \ |
| 2022-04-12 12:29:05 +0200 | z0k | (~z0k@39.40.7.24) |
| 2022-04-12 12:29:47 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 12:30:04 +0200 | robosexual | (~spaceoyst@77.223.90.202) |
| 2022-04-12 12:30:50 +0200 | <anomal> | Why does haskell have a boolean value types |
| 2022-04-12 12:31:21 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-04-12 12:31:41 +0200 | <anomal> | No CPU does |
| 2022-04-12 12:34:48 +0200 | <pavonia> | A CPU doesn't even know what a type is |
| 2022-04-12 12:35:21 +0200 | <abastro> | I'd like to say, Haskell has boolean type because it can |
| 2022-04-12 12:35:38 +0200 | <abastro> | IIRC `data Bool = False | True` and voila |
| 2022-04-12 12:35:39 +0200 | <Hecate> | C23 will have true and false as keywords, more proof that C is bloated |
| 2022-04-12 12:35:48 +0200 | <Hecate> | abastro: because it must |
| 2022-04-12 12:36:07 +0200 | <Hecate> | there is no alternative universe in which Haskell doesn't have that |
| 2022-04-12 12:36:08 +0200 | <Hecate> | :P |
| 2022-04-12 12:37:58 +0200 | <abastro> | Are you sure? |
| 2022-04-12 12:39:55 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-04-12 12:40:55 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 240 seconds) |
| 2022-04-12 12:41:59 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 12:42:07 +0200 | <abastro> | :P |
| 2022-04-12 12:42:08 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Client Quit) |
| 2022-04-12 12:42:46 +0200 | xff0x | (~xff0x@i121-117-52-147.s41.a013.ap.plala.or.jp) |
| 2022-04-12 12:44:19 +0200 | <anomal> | pavonia: they know what a type is. it knows what a uint64 is |
| 2022-04-12 12:44:46 +0200 | <abastro> | Eh, how does CPU know what uint64 is |
| 2022-04-12 12:44:54 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-04-12 12:44:58 +0200 | <anomal> | abastro: the problem is it encourages using Bool where better enums/unions would fit. |
| 2022-04-12 12:45:17 +0200 | <abastro> | Uhm, which encourages Bool? |
| 2022-04-12 12:45:23 +0200 | <anomal> | absence: registers have a type, operations expect certain types |
| 2022-04-12 12:46:41 +0200 | <tdammers> | hot take: Bool *is* an enum |
| 2022-04-12 12:47:14 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 272 seconds) |
| 2022-04-12 12:47:22 +0200 | <tdammers> | but in all seriousness, the fallacy here is to equate "hardware data type" with "Haskell type" |
| 2022-04-12 12:47:28 +0200 | <tdammers> | the two are almost completely unrelated |
| 2022-04-12 12:47:43 +0200 | <mason0> | or the idea to limit haskell types to only those supported by hardware |
| 2022-04-12 12:48:26 +0200 | <anomal> | tdammers: it is an enum |
| 2022-04-12 12:48:35 +0200 | <tdammers> | and, point in case, even C89's data types don't all correspond to hardware data types |
| 2022-04-12 12:48:44 +0200 | <anomal> | tdammers: it's just a very unfortunate enum everyone tries to cram into their data structures |
| 2022-04-12 12:48:47 +0200 | <abastro> | Bool is an enum, yes |
| 2022-04-12 12:49:13 +0200 | <tdammers> | now, there *is* an actual problem with Bool, called "boolean blindness", but it has absolutely nothing to do with hardware |
| 2022-04-12 12:49:42 +0200 | <anomal> | I don't want to just match hardware, I'm more pointing out it's a red flag that no hardware needs bool types (or equivalent ints) |
| 2022-04-12 12:49:44 +0200 | <abastro> | Wait, did someone said that boolean is bad because it is not in Hardware? |
| 2022-04-12 12:50:01 +0200 | <anomal> | abastro: yes I did. |
| 2022-04-12 12:50:04 +0200 | <anomal> | absence: have at it |
| 2022-04-12 12:50:06 +0200 | <abastro> | Oh. |
| 2022-04-12 12:50:34 +0200 | <anomal> | abastro: I didn't say exactly it's bad BECAUSE it's not in hardware. More like... why do we even have it |
| 2022-04-12 12:50:36 +0200 | <tdammers> | anomal: are you kidding? almost all digital computing hardware uses bools. On the x86 platform, CPU 'flags' are absolutely essential, and they are literally booleans. |
| 2022-04-12 12:50:40 +0200 | Nahra | (~user@static.161.95.99.88.clients.your-server.de) |
| 2022-04-12 12:50:52 +0200 | <abastro> | Wait, right |
| 2022-04-12 12:51:00 +0200 | <tdammers> | You could even argue that boolean is the *only* data type you get to have in hardware |
| 2022-04-12 12:51:07 +0200 | <abastro> | Those are booleans for all intents and purposes |
| 2022-04-12 12:51:14 +0200 | <siers> | merijn, isn't the intuition "pipeish" very close to "function-like" though? |
| 2022-04-12 12:51:17 +0200 | <anomal> | tdammers: having two states in a bit is not "boolean". People often confuse binary and boolean |
| 2022-04-12 12:51:25 +0200 | <abastro> | Boolean, in other words, Bits 8) |
| 2022-04-12 12:51:26 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-04-12 12:51:29 +0200 | <anomal> | tdammers: boolean is binary with specific semantics |
| 2022-04-12 12:51:41 +0200 | <tdammers> | anomal: maybe, but hardware data types don't have semantics |
| 2022-04-12 12:51:53 +0200 | <anomal> | Well, they do... |
| 2022-04-12 12:51:55 +0200 | <tdammers> | (or, more precisely, they don't have "meaning") |
| 2022-04-12 12:51:59 +0200 | <anomal> | Hm |
| 2022-04-12 12:52:10 +0200 | <anomal> | I guess the IEEE spec on floats is not semantics of a float :P |
| 2022-04-12 12:52:18 +0200 | <tdammers> | but anyway, the entire point is that "boolean", as a concept, *does* make sense |
| 2022-04-12 12:52:25 +0200 | <Hecate> | I'd like to remind the audience that no language programs the CPU |
| 2022-04-12 12:52:28 +0200 | <anomal> | as a concept, yes, |
| 2022-04-12 12:52:32 +0200 | <anomal> | As a value no |
| 2022-04-12 12:52:34 +0200 | <Hecate> | they program the C virtual machine |
| 2022-04-12 12:52:43 +0200 | <Hecate> | also: C has a runtime |
| 2022-04-12 12:52:51 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) (Ping timeout: 256 seconds) |
| 2022-04-12 12:52:52 +0200 | <anomal> | As a concept it's cleanly realized as a branch |
| 2022-04-12 12:52:55 +0200 | <anomal> | Church booleans |
| 2022-04-12 12:52:57 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 12:53:29 +0200 | <tdammers> | boolean values make sense too |
| 2022-04-12 12:53:36 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-04-12 12:53:39 +0200 | <Hecate> | (erm, C *abstract* machine, my bad) |
| 2022-04-12 12:53:50 +0200 | <tdammers> | it's just that boolean values as a concept are overused |
| 2022-04-12 12:54:17 +0200 | <tdammers> | pure abstract truthiness is not something you need often; there's usually more meaning attached to it |
| 2022-04-12 12:54:52 +0200 | <tdammers> | but sometimes, you do need first-class pure abstract truthiness values, e.g. when passing a predicate to a filter function |
| 2022-04-12 12:55:08 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-04-12 12:56:00 +0200 | <abastro> | C has a runtime :D |
| 2022-04-12 12:56:10 +0200 | <abastro> | And many ppl gloss over that detail :( |
| 2022-04-12 12:56:23 +0200 | <Hecate> | yup' |
| 2022-04-12 12:56:26 +0200 | <Hecate> | crt0 |
| 2022-04-12 12:57:00 +0200 | <tdammers> | abastro: it's even worse than that. the C abstract machine typically runs on top of a virtual CPU implemented in microcode on a real CPU |
| 2022-04-12 12:57:10 +0200 | <Hecate> | yup' |
| 2022-04-12 12:57:15 +0200 | <Hecate> | modern CPUs are beasts |
| 2022-04-12 12:57:28 +0200 | <Hecate> | but they have to implement this interface that must never change |
| 2022-04-12 12:58:05 +0200 | <anomal> | I'd like to hear when is a boolean better than an enum |
| 2022-04-12 12:58:28 +0200 | <anomal> | You can extend the enum with as many values you need, specific to the domain, and they communicate what the state is |
| 2022-04-12 12:58:31 +0200 | <tdammers> | anomal: Bool *is* an enum; it is better than any other enum when it is used to express "pure abstract truthiness" |
| 2022-04-12 12:58:36 +0200 | <anomal> | A boolean just says "ye" "no" |
| 2022-04-12 12:58:41 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2022-04-12 12:58:44 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 12:59:00 +0200 | <anomal> | tdammers: pure abstract truthiness doesn't make sense, that'd the point. |
| 2022-04-12 12:59:02 +0200 | <Hecate> | anomal: your question makes no sense |
| 2022-04-12 12:59:06 +0200 | <abastro> | Oh, more layers XD |
| 2022-04-12 12:59:09 +0200 | <anomal> | tdammers: can I have you one truth |
| 2022-04-12 12:59:16 +0200 | <anomal> | tdammers: give* |
| 2022-04-12 12:59:21 +0200 | <tdammers> | anomal: but it does, when you're writing abstract code. |
| 2022-04-12 12:59:25 +0200 | <anomal> | Hm no |
| 2022-04-12 12:59:27 +0200 | <abastro> | Hm yea, somehow even Hardware got some consideration for C impls |
| 2022-04-12 12:59:34 +0200 | <tdammers> | anomal: classic example: `filter :: (a -> Bool) -> [a] -> [a]` |
| 2022-04-12 12:59:45 +0200 | <tdammers> | what else can you put there other than Bool? |
| 2022-04-12 12:59:48 +0200 | <anomal> | tdammers: classic example of boolean blindness |
| 2022-04-12 13:00:05 +0200 | <tdammers> | filter :: (a -> Maybe a) -> [a] -> [a] then? |
| 2022-04-12 13:00:07 +0200 | <abastro> | ????? |
| 2022-04-12 13:00:07 +0200 | <anomal> | tdammers: https://runtimeverification.com/blog/code-smell-boolean-blindness/ |
| 2022-04-12 13:00:14 +0200 | <siers> | tdammers, you could put anything two-valued there, no? (what are you guys arguing about, again?) |
| 2022-04-12 13:00:20 +0200 | <mason0> | filter predicate function is not related to boolean blindness |
| 2022-04-12 13:00:31 +0200 | <abastro> | `(a -> MyBool) -> [a] -> [a]` Apparently |
| 2022-04-12 13:00:32 +0200 | <siers> | I've read the last 10 minutes of the convo and I have no idea |
| 2022-04-12 13:00:40 +0200 | <abastro> | Tbh me too |
| 2022-04-12 13:01:05 +0200 | <anomal> | I linked to an article discussing the exact Haskell filter function |
| 2022-04-12 13:01:19 +0200 | <Hecate> | this conversation is obviously going nowhere |
| 2022-04-12 13:01:21 +0200 | <Hecate> | I'm out! |
| 2022-04-12 13:01:22 +0200 | <siers> | anomal, is that your own post? |
| 2022-04-12 13:01:24 +0200 | <Hecate> | see ya, suckers |
| 2022-04-12 13:01:30 +0200 | <tdammers> | tee hee |
| 2022-04-12 13:01:35 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-04-12 13:01:37 +0200 | <anomal> | siers: no |
| 2022-04-12 13:02:27 +0200 | <siers> | post's contribution: expressive renaming |
| 2022-04-12 13:02:34 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 13:02:35 +0200 | <anomal> | Well |
| 2022-04-12 13:02:55 +0200 | <anomal> | In a sort function where we have three states what do we use |
| 2022-04-12 13:02:59 +0200 | <anomal> | 1.5 booleans :P? |
| 2022-04-12 13:03:15 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 13:03:16 +0200 | <tdammers> | anyway, I do acknowledge boolean blindness as a potential smell, but I don't think `filter` is part of the problem |
| 2022-04-12 13:04:04 +0200 | <anomal> | There's this principle I have "if someone says we'll only have one of those, he'll eventually be wrong". This is about singletons |
| 2022-04-12 13:04:07 +0200 | z0k | (~z0k@39.40.7.24) (Ping timeout: 240 seconds) |
| 2022-04-12 13:04:14 +0200 | <anomal> | For booleans there's a similar principle |
| 2022-04-12 13:04:29 +0200 | <anomal> | If someone says we need just two states so a boolean would do, it'll eventually be wrong |
| 2022-04-12 13:04:45 +0200 | <anomal> | Plus |
| 2022-04-12 13:04:53 +0200 | <anomal> | Matching a predicate may be true/false |
| 2022-04-12 13:04:56 +0200 | <tdammers> | Tes, but in the case of filter, there really are only two possibilities - predicate holds, or doesn't hold. That's exactly what Bool expresses. |
| 2022-04-12 13:05:06 +0200 | <anomal> | But keeping or discarding a value from a collection is not true/false |
| 2022-04-12 13:05:20 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 13:05:48 +0200 | <tdammers> | Correct; but that's not what "filter" says. It's not "keep the ones to keep and discard the ones to discard", it's "keep the ones for which the predicate holds, discard the ones for which it doesn't" |
| 2022-04-12 13:05:59 +0200 | <anomal> | Oh well |
| 2022-04-12 13:06:12 +0200 | <abastro> | Yep, exactly |
| 2022-04-12 13:06:18 +0200 | z0k | (~z0k@39.40.132.11) |
| 2022-04-12 13:06:25 +0200 | <anomal> | There's another way to do this |
| 2022-04-12 13:06:28 +0200 | <siers> | I hear it as "filter me those" where those is the adjective good/bad as determined by the predicate |
| 2022-04-12 13:06:29 +0200 | <abastro> | Also, the opposite operation need not exist even |
| 2022-04-12 13:06:34 +0200 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) |
| 2022-04-12 13:06:43 +0200 | <anomal> | You can return a container of the item, or an empty container. |
| 2022-04-12 13:06:44 +0200 | <abastro> | filter' p = filter (not . p) |
| 2022-04-12 13:06:45 +0200 | <anomal> | Flat map it |
| 2022-04-12 13:06:52 +0200 | <anomal> | Now you can do many more things |
| 2022-04-12 13:06:57 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 13:07:04 +0200 | <abastro> | So.. only one version is needed, and you specify which version you decide to keep |
| 2022-04-12 13:07:15 +0200 | <abastro> | Also `filter` is common practice |
| 2022-04-12 13:07:16 +0200 | <anomal> | For example you can insert two items for one item |
| 2022-04-12 13:07:36 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-04-12 13:07:52 +0200 | <abastro> | How is flatmap relevant? |
| 2022-04-12 13:08:05 +0200 | <anomal> | Well I just mentioned how |
| 2022-04-12 13:08:11 +0200 | <anomal> | It can filter but much more flexibly |
| 2022-04-12 13:08:19 +0200 | <timCF> | Hello! Is there any way to use/automate cabal.project as source of overlays for stack.yaml? I'm forced to use stack in yesod project (because yesod-bin tool requires it) but I don't want to duplicate the data from cabal.project in stack.yaml |
| 2022-04-12 13:08:22 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 250 seconds) |
| 2022-04-12 13:08:33 +0200 | jgeerds | (~jgeerds@d5364b87.access.ecotel.net) |
| 2022-04-12 13:08:48 +0200 | <anomal> | Instead of mapping x to x or nothing, you can map x to x, to nothing, to y, or to a, b, c, d, e,f :P |
| 2022-04-12 13:08:49 +0200 | <tdammers> | I mean sure, there are thousands of ways you can do it |
| 2022-04-12 13:09:05 +0200 | <tdammers> | you can also have your predicate return a list, and use >>= |
| 2022-04-12 13:09:14 +0200 | <anomal> | Right |
| 2022-04-12 13:09:23 +0200 | <abastro> | timCF: Overlay for cabal.project? |
| 2022-04-12 13:09:31 +0200 | <abastro> | Do you mean *.cabal file? |
| 2022-04-12 13:09:48 +0200 | <tdammers> | but that's missing the point - the point being, we aren't just programming computers, we're also (or even primarily) expressing intent to a human reader |
| 2022-04-12 13:09:50 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 13:10:15 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 13:10:37 +0200 | <siers> | and that human reader most often is you, the writer himself :D |
| 2022-04-12 13:10:48 +0200 | <tdammers> | I like to think of my future self as someone else |
| 2022-04-12 13:11:35 +0200 | <timCF> | abastro: I mean, I'm using a lot of "source-repository-package" in my cabal.project. But once I've added yesod to my project, I'm forced to create stack.yaml and basically duplicate this data. And I'm thinking how to avoid that |
| 2022-04-12 13:11:45 +0200 | <siers> | tdammers, when my colleagues say some of my work is good and they thank me, I say I did it for myself |
| 2022-04-12 13:11:56 +0200 | <abastro> | Hmm, I personally don't know. |
| 2022-04-12 13:12:00 +0200 | <siers> | half joke, half not |
| 2022-04-12 13:12:27 +0200 | <abastro> | I think there were haskell tooling IRC |
| 2022-04-12 13:12:31 +0200 | <siers> | tdammers, we're programming ourselves and the output of this programming is the syntax/program |
| 2022-04-12 13:12:46 +0200 | <siers> | that's how I look at my girlfriend who's learning to code |
| 2022-04-12 13:12:51 +0200 | <tdammers> | meh, no need to get all philosophical about it |
| 2022-04-12 13:13:00 +0200 | <siers> | haha, I believe I didn't start it |
| 2022-04-12 13:13:10 +0200 | <siers> | https://runtimeverification.com/blog/code-smell-boolean-blindness/ |
| 2022-04-12 13:14:00 +0200 | <Nahra> | Hello. Which to make 'host <- fmap systemName getSystemID' remove FQDN? |
| 2022-04-12 13:15:02 +0200 | <abastro> | When I realize I am truly not my past self: see https://github.com/Abastro/Columnise/blob/main/src/Data/Impl/Named.hs |
| 2022-04-12 13:15:19 +0200 | akegalj | (~akegalj@78-3-32-236.adsl.net.t-com.hr) (Quit: leaving) |
| 2022-04-12 13:15:25 +0200 | <abastro> | Idk how I expected even myself to understand the code |
| 2022-04-12 13:15:38 +0200 | <Nahra> | Or perhaps is there another way to get only short hostname? |
| 2022-04-12 13:15:42 +0200 | ub | (~Thunderbi@p200300ecdf1588e205edf63e67564e92.dip0.t-ipconnect.de) |
| 2022-04-12 13:16:15 +0200 | <geekosaur> | that's up to the system |
| 2022-04-12 13:16:16 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-04-12 13:16:22 +0200 | <mikoto-chan> | sclv: the /go fuwafuwa.#flexcake.moe |
| 2022-04-12 13:16:29 +0200 | <mikoto-chan> | oops |
| 2022-04-12 13:16:38 +0200 | <mikoto-chan> | I wanted to say the hyphen confused me |
| 2022-04-12 13:16:46 +0200 | <geekosaur> | host <- fmap (takeWhile (/= '.') . systemName) getSystemID |
| 2022-04-12 13:16:46 +0200 | <mikoto-chan> | and go to a room ... |
| 2022-04-12 13:19:04 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 13:19:10 +0200 | robosexual | (~spaceoyst@77.223.90.202) (Quit: Konversation terminated!) |
| 2022-04-12 13:19:22 +0200 | <abastro> | I wonder `takeWhile` here would be a safe approach |
| 2022-04-12 13:19:26 +0200 | lispy | (~lispy@82.212.119.74) (Ping timeout: 250 seconds) |
| 2022-04-12 13:19:44 +0200 | <Nahra> | geekosaur: Thanks! |
| 2022-04-12 13:21:32 +0200 | robosexual | (~robosexua@77.223.90.202) |
| 2022-04-12 13:22:33 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-04-12 13:23:54 +0200 | axeman | (~quassel@2a02:8109:a380:78:16ca:21f1:a997:8861) |
| 2022-04-12 13:25:14 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 272 seconds) |
| 2022-04-12 13:26:12 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 2022-04-12 13:27:15 +0200 | abastro | (~abab9579@143.248.229.139) (Ping timeout: 246 seconds) |
| 2022-04-12 13:27:16 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-04-12 13:27:31 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 13:28:32 +0200 | shachaf | (~shachaf@user/shachaf) (Ping timeout: 252 seconds) |
| 2022-04-12 13:29:36 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 13:29:57 +0200 | shachaf | (~shachaf@user/shachaf) |
| 2022-04-12 13:30:55 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 13:31:30 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 13:34:07 +0200 | vysn | (~vysn@user/vysn) (Ping timeout: 240 seconds) |
| 2022-04-12 13:34:16 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 13:36:24 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-04-12 13:36:30 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:36:46 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:36:54 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:37:07 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:37:15 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:37:30 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:37:37 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:37:52 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:37:59 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:38:13 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:38:21 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:38:34 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:38:42 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:38:45 +0200 | z0k | (~z0k@39.40.132.11) (Ping timeout: 256 seconds) |
| 2022-04-12 13:38:46 +0200 | zeenk | (~zeenk@2a02:2f04:a313:d600:8d26:ec9f:3ff6:fc94) (Quit: Konversation terminated!) |
| 2022-04-12 13:38:48 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 13:38:56 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:39:04 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:39:19 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:39:25 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:39:40 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:39:47 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:39:57 +0200 | zeenk | (~zeenk@2a02:2f04:a313:d600:8d26:ec9f:3ff6:fc94) |
| 2022-04-12 13:40:05 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:40:10 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 13:40:13 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:40:26 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:40:34 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:40:48 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:40:56 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:41:04 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-04-12 13:41:05 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) |
| 2022-04-12 13:41:11 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:41:19 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:41:34 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:41:41 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:41:57 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:42:05 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:42:20 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:42:28 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:42:45 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:42:51 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:43:07 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:43:12 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Remote host closed the connection) |
| 2022-04-12 13:43:15 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:43:30 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:43:34 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) |
| 2022-04-12 13:43:36 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:43:50 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:43:58 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:44:12 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:44:20 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:44:33 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:44:41 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:44:42 +0200 | Batzy | (~quassel@user/batzy) (Quit: No Ping reply in 180 seconds.) |
| 2022-04-12 13:44:45 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 13:44:57 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:45:05 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 13:46:08 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-04-12 13:46:47 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-04-12 13:46:54 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) |
| 2022-04-12 13:47:54 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 13:47:57 +0200 | InstX1_ | (~Liam@2601:6c4:4080:3f80:1d4a:af44:f702:f9c0) |
| 2022-04-12 13:48:04 +0200 | coot | (~coot@213.134.190.95) |
| 2022-04-12 13:48:56 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 13:48:57 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 13:49:47 +0200 | z0k | (~z0k@39.40.132.11) |
| 2022-04-12 13:51:33 +0200 | CiaoSen | (~Jura@p200300c9572d40002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-04-12 13:52:30 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-04-12 13:53:29 +0200 | zer0bitz | (~zer0bitz@2001:2003:f444:8f00:d9de:fb6b:4dff:6b4) |
| 2022-04-12 13:55:21 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 13:58:27 +0200 | axeman | (~quassel@2a02:8109:a380:78:16ca:21f1:a997:8861) (Ping timeout: 240 seconds) |
| 2022-04-12 14:00:57 +0200 | jgeerds | (~jgeerds@d5364b87.access.ecotel.net) (Ping timeout: 248 seconds) |
| 2022-04-12 14:01:42 +0200 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) (Quit: leaving) |
| 2022-04-12 14:02:20 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 14:03:25 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 14:03:59 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 14:06:27 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-04-12 14:09:02 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 250 seconds) |
| 2022-04-12 14:09:25 +0200 | chenqisu12 | (~chenqisu1@183.217.200.38) (Quit: Leaving) |
| 2022-04-12 14:10:50 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 272 seconds) |
| 2022-04-12 14:11:53 +0200 | abastro | (~abab9579@192.249.26.12) |
| 2022-04-12 14:12:16 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 14:12:29 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 14:13:38 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 14:17:42 +0200 | robosexual | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 14:22:25 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-04-12 14:23:31 +0200 | Frinasa[m] | (~odirfjohr@2001:470:69fc:105::1:f483) |
| 2022-04-12 14:24:20 +0200 | robosexual1 | (~robosexua@77.223.90.202) |
| 2022-04-12 14:24:40 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-04-12 14:27:28 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-04-12 14:29:09 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) (Client Quit) |
| 2022-04-12 14:29:23 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-04-12 14:29:42 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 14:37:41 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 14:38:49 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 14:39:20 +0200 | Major_Biscuit | (~MajorBisc@c-001-009-035.client.tudelft.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-04-12 14:39:22 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) () |
| 2022-04-12 14:39:28 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 14:41:25 +0200 | Major_Biscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) |
| 2022-04-12 14:41:29 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-04-12 14:43:41 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) |
| 2022-04-12 14:44:15 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 246 seconds) |
| 2022-04-12 14:44:26 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 14:44:34 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 250 seconds) |
| 2022-04-12 14:46:24 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 14:46:47 +0200 | Major_Biscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) (Ping timeout: 240 seconds) |
| 2022-04-12 14:48:40 +0200 | Major_Biscuit | (~MajorBisc@c-001-009-035.client.tudelft.eduvpn.nl) |
| 2022-04-12 14:49:53 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) (Quit: issued !quit command) |
| 2022-04-12 14:50:01 +0200 | CiaoSen | (~Jura@p200300c9572d40002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-04-12 14:54:47 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-04-12 14:55:52 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 15:01:39 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) |
| 2022-04-12 15:02:13 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-04-12 15:03:29 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 15:04:24 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 248 seconds) |
| 2022-04-12 15:04:28 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.5) |
| 2022-04-12 15:07:42 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
| 2022-04-12 15:10:48 +0200 | razetime | (~quassel@117.254.34.230) (Ping timeout: 248 seconds) |
| 2022-04-12 15:11:20 +0200 | razetime | (~quassel@117.254.35.90) |
| 2022-04-12 15:11:40 +0200 | sloorush | (~sloorush@136.233.9.99) (Ping timeout: 250 seconds) |
| 2022-04-12 15:12:17 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-04-12 15:12:44 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 250 seconds) |
| 2022-04-12 15:15:36 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-04-12 15:19:54 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Read error: Connection reset by peer) |
| 2022-04-12 15:21:54 +0200 | dschrempf | (~dominik@92-249-159-213.pool.digikabel.hu) (Quit: WeeChat 3.4.1) |
| 2022-04-12 15:21:59 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 15:25:57 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-04-12 15:26:12 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) (Ping timeout: 240 seconds) |
| 2022-04-12 15:26:37 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 15:27:06 +0200 | <juri_> | is there a way to easily use property tests for benchmarking? |
| 2022-04-12 15:27:48 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Quit: Leaving...) |
| 2022-04-12 15:28:00 +0200 | <merijn> | Depends, do you care about your benchmarks being meaningful? ;) |
| 2022-04-12 15:31:23 +0200 | <juri_> | That good, eh? |
| 2022-04-12 15:33:11 +0200 | <merijn> | I'm just increasingly convinced that *good* benchmarks are crazy hard and you almost certainly won't get that from property tests. You could probably throw some timers into a test framework and get some ballpark numbers, but you'd have to take those with a considerable grain of salt |
| 2022-04-12 15:34:56 +0200 | <abastro> | hm gtk declarative is a bit hard to apply into existing ui application.. |
| 2022-04-12 15:35:07 +0200 | <abastro> | I guess I might not use it? hmm |
| 2022-04-12 15:35:19 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-04-12 15:35:19 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-04-12 15:35:19 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-04-12 15:37:24 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-04-12 15:37:42 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-04-12 15:37:54 +0200 | <juri_> | merijn: I was hoping to have a test returning (something, expectation), so quickcheck could check the expectation, and I could get another function run over [something], to analyse. |
| 2022-04-12 15:39:54 +0200 | <tdammers> | what's the problem with using actual benchmarking frameworks? |
| 2022-04-12 15:40:02 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 250 seconds) |
| 2022-04-12 15:40:24 +0200 | <juri_> | I'd actually have to write another test? |
| 2022-04-12 15:41:38 +0200 | <geekosaur> | if you want a meaningful benchmark, you'll really need to do that and you'll have to be careful aboutit, as merijn said |
| 2022-04-12 15:41:48 +0200 | <geekosaur> | but in general, the more tests the better anyway :) |
| 2022-04-12 15:41:53 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2022-04-12 15:44:01 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-04-12 15:44:48 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-04-12 15:45:24 +0200 | abastro | (~abab9579@192.249.26.12) (Remote host closed the connection) |
| 2022-04-12 15:45:29 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-04-12 15:46:02 +0200 | <juri_> | tell that to my CPU. :) |
| 2022-04-12 15:48:39 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-04-12 15:51:26 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 15:56:05 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 15:57:01 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 15:59:06 +0200 | alp__ | (~alp@user/alp) (Ping timeout: 250 seconds) |
| 2022-04-12 15:59:28 +0200 | ub | (~Thunderbi@p200300ecdf1588e205edf63e67564e92.dip0.t-ipconnect.de) (Quit: ub) |
| 2022-04-12 15:59:36 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 16:00:29 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) |
| 2022-04-12 16:00:53 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-04-12 16:01:52 +0200 | robosexual1 | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 16:02:01 +0200 | robosexual1 | (~robosexua@77.223.90.202) |
| 2022-04-12 16:02:53 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 16:04:16 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 16:04:47 +0200 | deadmarshal_ | (~deadmarsh@95.38.112.20) (Ping timeout: 240 seconds) |
| 2022-04-12 16:05:15 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 240 seconds) |
| 2022-04-12 16:05:31 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-04-12 16:06:19 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-04-12 16:07:01 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-04-12 16:08:24 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2022-04-12 16:13:42 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 272 seconds) |
| 2022-04-12 16:14:04 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Read error: Connection reset by peer) |
| 2022-04-12 16:14:06 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 16:14:29 +0200 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2022-04-12 16:16:36 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 16:19:24 +0200 | slack1256 | (~slack1256@186.11.42.180) |
| 2022-04-12 16:20:32 +0200 | fockerized | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-04-12 16:21:45 +0200 | odnes_ | (~odnes@5-203-221-3.pat.nym.cosmote.net) |
| 2022-04-12 16:22:20 +0200 | odnes | (~odnes@5-203-221-3.pat.nym.cosmote.net) (Read error: Connection reset by peer) |
| 2022-04-12 16:23:22 +0200 | redb | (~nmh@136.49.49.211) (Ping timeout: 250 seconds) |
| 2022-04-12 16:23:47 +0200 | Major_Biscuit | (~MajorBisc@c-001-009-035.client.tudelft.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-04-12 16:23:58 +0200 | redb | (~nmh@136.49.49.211) |
| 2022-04-12 16:29:52 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 250 seconds) |
| 2022-04-12 16:37:04 +0200 | slac92731 | (~slack1256@191.126.99.201) |
| 2022-04-12 16:39:31 +0200 | slack1256 | (~slack1256@186.11.42.180) (Ping timeout: 256 seconds) |
| 2022-04-12 16:40:08 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2022-04-12 16:45:29 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-04-12 16:48:43 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 16:48:59 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 16:49:06 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 16:49:22 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 16:49:27 +0200 | Major_Biscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) |
| 2022-04-12 16:49:30 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 16:49:44 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 16:49:51 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 16:50:06 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 16:50:13 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2022-04-12 16:53:05 +0200 | Akiva | (~Akiva@user/Akiva) |
| 2022-04-12 16:54:07 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::1) (Ping timeout: 260 seconds) |
| 2022-04-12 16:57:13 +0200 | fendor | (~fendor@91.141.72.148.wireless.dyn.drei.com) |
| 2022-04-12 16:59:03 +0200 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-04-12 17:01:00 +0200 | odnes | (~odnes@5-203-221-3.pat.nym.cosmote.net) |
| 2022-04-12 17:01:47 +0200 | odnes_ | (~odnes@5-203-221-3.pat.nym.cosmote.net) (Read error: Connection reset by peer) |
| 2022-04-12 17:04:53 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 17:04:58 +0200 | Major_Biscuit | (~MajorBisc@83.22.32.182.ipv4.supernova.orange.pl) (Ping timeout: 250 seconds) |
| 2022-04-12 17:05:06 +0200 | alp__ | (~alp@user/alp) |
| 2022-04-12 17:05:39 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-04-12 17:09:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2022-04-12 17:10:04 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6aaf:d90d:7db8:1a48) (Quit: WeeChat 2.8) |
| 2022-04-12 17:16:52 +0200 | jonathanx_ | (~jonathan@dyn-5-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2022-04-12 17:17:47 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-04-12 17:20:08 +0200 | razetime | (~quassel@117.254.35.90) (Ping timeout: 250 seconds) |
| 2022-04-12 17:20:32 +0200 | razetime | (~quassel@117.254.34.157) |
| 2022-04-12 17:21:02 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-04-12 17:23:50 +0200 | <tomsmeding> | generally, property tests are also random, so not particularly suited to a reproducible benchmark |
| 2022-04-12 17:24:44 +0200 | <tomsmeding> | (this effect is particularly strong if the generator of your input type can generate values of different sizes and the function to test is super-linear in the input size) |
| 2022-04-12 17:28:00 +0200 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-04-12 17:28:45 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 17:28:55 +0200 | rembo10 | (~rembo10@main.remulis.com) |
| 2022-04-12 17:33:17 +0200 | lispy | (~lispy@82.212.116.142) |
| 2022-04-12 17:34:08 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 17:37:07 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 17:37:18 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 272 seconds) |
| 2022-04-12 17:40:15 +0200 | cdman | (~dcm@user/dmc/x-4369397) (Quit: Leaving) |
| 2022-04-12 17:40:19 +0200 | <abastro[m]> | What is this claim of monad in JS: |
| 2022-04-12 17:40:19 +0200 | <abastro[m]> | https://www.freecodecamp.org/news/when-to-use-react-suspense-vs-react-hooks-f66ef94cb54f/ |
| 2022-04-12 17:40:19 +0200 | <abastro[m]> | Seems abuse of concepts |
| 2022-04-12 17:45:31 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 17:47:24 +0200 | <abastro[m]> | I wonder why ppl are exporting concept of monad which works poorly outside of haskell-like type system |
| 2022-04-12 17:48:34 +0200 | <geekosaur> | the concept of monad exists everywhere. writing a generalized one is difficult outside of haskell, but specializations of the concept are still useful |
| 2022-04-12 17:49:21 +0200 | <geekosaur> | for example it provides a way to do callbacks while writing relatively straightforward "procedural" code (see pretty much any use of IO in Haskell) |
| 2022-04-12 17:49:39 +0200 | <abastro[m]> | I doubt its usefulness, even in haskell it sucks to use them |
| 2022-04-12 17:50:14 +0200 | <geekosaur> | how much work have you done with callback-based programming? |
| 2022-04-12 17:50:21 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2022-04-12 17:50:49 +0200 | <geekosaur> | tl;dr: it sucks even more |
| 2022-04-12 17:52:10 +0200 | goepsilongo | (~chacho@2603-7000-ab00-62ed-0000-0000-0000-0bd0.res6.spectrum.com) |
| 2022-04-12 17:52:32 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) |
| 2022-04-12 17:53:54 +0200 | razetime | (~quassel@117.254.34.157) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-04-12 17:54:01 +0200 | razetime | (~quassel@117.254.34.157) |
| 2022-04-12 17:54:24 +0200 | <monochrom> | Monads arise everywhere in nature, such as Haskell tutorials and Javascript tutorials >:) |
| 2022-04-12 17:54:45 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 17:55:02 +0200 | <monochrom> | @quote monochrom fibonacci.*nature |
| 2022-04-12 17:55:02 +0200 | <lambdabot> | monochrom says: the fibonacci sequence is everywhere in nature, for example haskell tutorials and python tutorials |
| 2022-04-12 17:55:09 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-04-12 17:56:30 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-04-12 18:00:29 +0200 | mason0 | (~bc8147f2@cerf.good1.com) (Quit: CGI:IRC (Session timeout)) |
| 2022-04-12 18:01:15 +0200 | odnes | (~odnes@5-203-221-3.pat.nym.cosmote.net) (Quit: Leaving) |
| 2022-04-12 18:02:35 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-04-12 18:03:52 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) |
| 2022-04-12 18:04:29 +0200 | kenran | (~kenran@200116b82b941e00eb843d1befbc82ec.dip.versatel-1u1.de) (Client Quit) |
| 2022-04-12 18:06:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2022-04-12 18:06:44 +0200 | lbseale | (~ep1ctetus@user/ep1ctetus) |
| 2022-04-12 18:08:27 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 240 seconds) |
| 2022-04-12 18:08:32 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-04-12 18:09:00 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 18:13:33 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 2022-04-12 18:14:32 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 18:17:07 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2022-04-12 18:18:09 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-04-12 18:19:04 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 250 seconds) |
| 2022-04-12 18:22:46 +0200 | slack1256 | (~slack1256@186.11.44.52) |
| 2022-04-12 18:23:16 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Remote host closed the connection) |
| 2022-04-12 18:24:36 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 240 seconds) |
| 2022-04-12 18:24:51 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2022-04-12 18:25:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2022-04-12 18:25:26 +0200 | slac92731 | (~slack1256@191.126.99.201) (Ping timeout: 272 seconds) |
| 2022-04-12 18:25:53 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-04-12 18:26:24 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-04-12 18:26:37 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-04-12 18:28:32 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-04-12 18:28:42 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) |
| 2022-04-12 18:28:43 +0200 | wmacmil | (~wmacmil@2600:1700:cd90:8f10:f523:1d17:345c:e650) (Client Quit) |
| 2022-04-12 18:33:02 +0200 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-04-12 18:33:25 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 256 seconds) |
| 2022-04-12 18:34:49 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 18:35:27 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-04-12 18:35:46 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 18:37:10 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Remote host closed the connection) |
| 2022-04-12 18:38:03 +0200 | joo-_ | (~joo-_@80-62-116-147-mobile.dk.customer.tdc.net) |
| 2022-04-12 18:38:03 +0200 | joo-_ | (~joo-_@80-62-116-147-mobile.dk.customer.tdc.net) (Changing host) |
| 2022-04-12 18:38:03 +0200 | joo-_ | (~joo-_@fsf/member/joo--) |
| 2022-04-12 18:44:48 +0200 | axeman | (~quassel@2a02:8109:a380:78:a77:f1:10ab:6048) |
| 2022-04-12 18:45:24 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-04-12 18:45:45 +0200 | z0k | (~z0k@39.40.132.11) (Ping timeout: 246 seconds) |
| 2022-04-12 18:46:47 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-04-12 18:47:23 +0200 | <dmj`> | Tree is a monad, therefore Monads grow on trees |
| 2022-04-12 18:48:56 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 18:53:06 +0200 | sammelweis_ | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-04-12 18:53:14 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-04-12 18:54:58 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-04-12 18:56:27 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-04-12 18:57:14 +0200 | averell | (~averell@user/averell) |
| 2022-04-12 18:58:18 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-04-12 18:58:51 +0200 | coot | (~coot@213.134.190.95) |
| 2022-04-12 19:00:34 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 19:00:48 +0200 | <monochrom> | Every monad can be expressed as a free monad (so, tree) and then quotiented out by an interpreter (so, cut down). So, every monad is a harvested tree. >:) |
| 2022-04-12 19:03:14 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 19:04:00 +0200 | mbuf | (~Shakthi@122.174.160.5) (Quit: Leaving) |
| 2022-04-12 19:04:12 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 240 seconds) |
| 2022-04-12 19:04:56 +0200 | ishaan | (~ishaan@122.161.52.79) (Ping timeout: 248 seconds) |
| 2022-04-12 19:05:35 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 19:07:23 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-04-12 19:08:04 +0200 | ElVinzFR | (~Guest46@2a01cb0c09c6d5001c67be9a6b15034f.ipv6.abo.wanadoo.fr) |
| 2022-04-12 19:08:07 +0200 | z0k | (~z0k@39.40.122.185) |
| 2022-04-12 19:10:32 +0200 | <ElVinzFR> | In the definition of whileJust_, there is a recursive call. I read that there is no recursive tail optimization on monadic functions. Does this mean that the stack will grow ? |
| 2022-04-12 19:10:52 +0200 | xkuru | (~xkuru@user/xkuru) |
| 2022-04-12 19:11:11 +0200 | <geekosaur> | I guess that discussion the other day about TCO went completely over your head |
| 2022-04-12 19:11:12 +0200 | <monochrom> | Depends on the actual monad. |
| 2022-04-12 19:11:31 +0200 | <monochrom> | Which actual monad do you have in mind? |
| 2022-04-12 19:11:51 +0200 | <dolio> | I don't think every monad is the quotient of a free monad. |
| 2022-04-12 19:12:04 +0200 | <monochrom> | In IO, State, Maybe, Either, Except, or Reader, everything will be OK. |
| 2022-04-12 19:12:31 +0200 | coot | (~coot@213.134.190.95) (Ping timeout: 256 seconds) |
| 2022-04-12 19:12:34 +0200 | <monochrom> | But why trust me? Do your own benchmark to see. Don't just speculate. |
| 2022-04-12 19:12:55 +0200 | <ElVinzFR> | I want to use IO monad to react to user input |
| 2022-04-12 19:13:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 19:13:47 +0200 | <monochrom> | Hell, why trust anything you read on the Internet at all? |
| 2022-04-12 19:14:03 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 2022-04-12 19:14:05 +0200 | <ElVinzFR> | Have to start with something. |
| 2022-04-12 19:14:14 +0200 | <monochrom> | How can you trust them, when one video says the earth is flat, and another says the earth is round. |
| 2022-04-12 19:14:42 +0200 | <monochrom> | Sure, start with benchmarking. |
| 2022-04-12 19:17:52 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2022-04-12 19:20:26 +0200 | axeman | (~quassel@2a02:8109:a380:78:a77:f1:10ab:6048) (Quit: No Ping reply in 180 seconds.) |
| 2022-04-12 19:21:41 +0200 | axeman | (~quassel@2a02:8109:a380:78:2ba7:cbb3:509b:bd1d) |
| 2022-04-12 19:23:37 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 19:26:18 +0200 | stevenxl | (~stevenxl@c-73-72-2-81.hsd1.il.comcast.net) |
| 2022-04-12 19:27:02 +0200 | ElVinzFR | (~Guest46@2a01cb0c09c6d5001c67be9a6b15034f.ipv6.abo.wanadoo.fr) (Quit: Client closed) |
| 2022-04-12 19:29:10 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 19:31:04 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 248 seconds) |
| 2022-04-12 19:31:28 +0200 | slac53263 | (~slack1256@191.126.99.201) |
| 2022-04-12 19:32:32 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 19:33:42 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 19:33:50 +0200 | slack1256 | (~slack1256@186.11.44.52) (Ping timeout: 272 seconds) |
| 2022-04-12 19:34:56 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Client Quit) |
| 2022-04-12 19:36:55 +0200 | razetime | (~quassel@117.254.34.157) (Remote host closed the connection) |
| 2022-04-12 19:37:28 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-04-12 19:37:44 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2022-04-12 19:40:18 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-04-12 19:40:36 +0200 | lispy | (~lispy@82.212.116.142) (Quit: Client closed) |
| 2022-04-12 19:43:58 +0200 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Client Quit) |
| 2022-04-12 19:44:23 +0200 | notzmv | (~zmv@user/notzmv) (Read error: Connection reset by peer) |
| 2022-04-12 19:45:27 +0200 | axeman | (~quassel@2a02:8109:a380:78:2ba7:cbb3:509b:bd1d) (Ping timeout: 240 seconds) |
| 2022-04-12 19:46:40 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-04-12 19:46:54 +0200 | cosimone | (~user@93-47-228-79.ip115.fastwebnet.it) |
| 2022-04-12 19:48:59 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 19:49:34 +0200 | <dolio> | You don't really even need to test. |
| 2022-04-12 19:49:55 +0200 | <dolio> | If your question is, "am I the first person to realize this obvious, massive flaw?" The answer is probably, "no." |
| 2022-04-12 19:50:04 +0200 | <monochrom> | Heh |
| 2022-04-12 19:50:27 +0200 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-04-12 19:51:03 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 256 seconds) |
| 2022-04-12 19:51:20 +0200 | <monochrom> | No no no, the real question is "but did anyone fix it?" Looking at most interpreters/compilers for python and javascript and maybe even java, the answer is also probably "no". >:) |
| 2022-04-12 19:51:28 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2022-04-12 19:51:58 +0200 | <geekosaur> | java didn't even support tco until recently |
| 2022-04-12 19:52:30 +0200 | <geekosaur> | and I continue to maintain that tco doesn't work the same way in a graph reduction language, and everything you think you know about it is wrong |
| 2022-04-12 19:52:45 +0200 | <monochrom> | The "real" world "industry" has all kinds of funny priorities. It is actually safe to be pessimistic. |
| 2022-04-12 19:52:47 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 240 seconds) |
| 2022-04-12 19:52:48 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-04-12 19:53:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 19:53:53 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 256 seconds) |
| 2022-04-12 19:54:17 +0200 | <dolio> | Those all have alternate ways of looping that don't rely on TCO. The flaw would be that Haskell only has function calls that can't be used to loop indefinitely. |
| 2022-04-12 19:54:24 +0200 | fendor_ | (~fendor@91.141.45.157.wireless.dyn.drei.com) |
| 2022-04-12 19:55:25 +0200 | <monochrom> | OK yes. |
| 2022-04-12 19:56:21 +0200 | <Las[m]> | Would making GHC choose a random instance if there are duplicate instances break GHC in some way I'm not aware of? |
| 2022-04-12 19:56:53 +0200 | <geekosaur> | IncoherentInstances more or less does that |
| 2022-04-12 19:57:00 +0200 | fendor | (~fendor@91.141.72.148.wireless.dyn.drei.com) (Ping timeout: 250 seconds) |
| 2022-04-12 19:57:04 +0200 | <geekosaur> | well,it'll still reject exact matches I think |
| 2022-04-12 19:57:14 +0200 | <dolio> | Actually, even incoherent instances doesn't do that. :) |
| 2022-04-12 19:57:26 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 250 seconds) |
| 2022-04-12 19:57:55 +0200 | <monochrom> | I think it doesn't break GHC, it just makes your code act funny. But I haven't tried. |
| 2022-04-12 19:57:55 +0200 | <dolio> | It does something kind of like that, though. |
| 2022-04-12 19:58:50 +0200 | <geekosaur> | looks like the asker re TCO went away |
| 2022-04-12 19:59:14 +0200 | <monochrom> | Well yeah millenial twitter attention span. |
| 2022-04-12 19:59:17 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 19:59:25 +0200 | <geekosaur> | they still want a nice simple solution that fits their "it can only work this way that I think I know" mindset |
| 2022-04-12 19:59:41 +0200 | jonathanx_ | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-04-12 19:59:49 +0200 | <Las[m]> | thanks, I'll try patching GHC and find out |
| 2022-04-12 20:00:12 +0200 | <monochrom> | Yikes haha |
| 2022-04-12 20:02:03 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 246 seconds) |
| 2022-04-12 20:02:20 +0200 | <tomsmeding> | O.o |
| 2022-04-12 20:02:39 +0200 | <tomsmeding> | I mean, it's just haskell, but eh |
| 2022-04-12 20:03:53 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2022-04-12 20:03:59 +0200 | ix | (~ix@2a02:8010:674f:0:d65d:64ff:fe52:5efe) (Ping timeout: 252 seconds) |
| 2022-04-12 20:04:39 +0200 | z0k | (~z0k@39.40.122.185) (Ping timeout: 256 seconds) |
| 2022-04-12 20:05:17 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 20:05:21 +0200 | z0k | (~z0k@39.40.122.185) |
| 2022-04-12 20:05:34 +0200 | akegalj | (~akegalj@23-132.dsl.iskon.hr) |
| 2022-04-12 20:07:01 +0200 | ix | (~ix@2a02:8010:674f:0:d65d:64ff:fe52:5efe) |
| 2022-04-12 20:08:36 +0200 | axeman | (~quassel@2a02:8109:a380:78:95ee:a2c4:4c41:7559) |
| 2022-04-12 20:08:48 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 20:11:43 +0200 | jgeerds | (~jgeerds@d5364b87.access.ecotel.net) |
| 2022-04-12 20:13:28 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 250 seconds) |
| 2022-04-12 20:15:10 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-04-12 20:15:44 +0200 | dextaa | (~dextaa@user/dextaa) (Read error: Connection reset by peer) |
| 2022-04-12 20:17:51 +0200 | dextaa | (~dextaa@user/dextaa) |
| 2022-04-12 20:17:57 +0200 | econo | (uid147250@user/econo) |
| 2022-04-12 20:18:08 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) |
| 2022-04-12 20:19:29 +0200 | coot | (~coot@213.134.190.95) |
| 2022-04-12 20:20:32 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-04-12 20:20:59 +0200 | <Hecate> | heyo |
| 2022-04-12 20:22:24 +0200 | <tomsmeding> | \o |
| 2022-04-12 20:29:42 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) (Ping timeout: 246 seconds) |
| 2022-04-12 20:29:55 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-04-12 20:38:56 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 20:40:31 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 20:44:17 +0200 | bahamas | (~lucian@84.232.140.158) |
| 2022-04-12 20:44:27 +0200 | axeman | (~quassel@2a02:8109:a380:78:95ee:a2c4:4c41:7559) (Ping timeout: 240 seconds) |
| 2022-04-12 20:44:40 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 248 seconds) |
| 2022-04-12 20:44:40 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 250 seconds) |
| 2022-04-12 20:45:27 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-04-12 20:46:33 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 20:46:35 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2022-04-12 20:46:37 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 20:48:24 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 20:50:17 +0200 | axeman | (~quassel@2a02:8109:a380:78:c8da:9dc6:9792:51c3) |
| 2022-04-12 20:50:42 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 20:51:51 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) |
| 2022-04-12 20:53:38 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 20:56:01 +0200 | ub | (~Thunderbi@p200300ecdf1588e205edf63e67564e92.dip0.t-ipconnect.de) |
| 2022-04-12 20:57:22 +0200 | ub | (~Thunderbi@p200300ecdf1588e205edf63e67564e92.dip0.t-ipconnect.de) (Client Quit) |
| 2022-04-12 20:59:14 +0200 | kaph | (~kaph@dynamic-adsl-78-12-162-98.clienti.tiscali.it) |
| 2022-04-12 21:01:24 +0200 | robosexual1 | (~robosexua@77.223.90.202) (Quit: WeeChat 3.4) |
| 2022-04-12 21:03:41 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 21:05:35 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-04-12 21:09:45 +0200 | xaotuk | (~sasha@cable-178-148-235-107.dynamic.sbb.rs) |
| 2022-04-12 21:12:58 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-04-12 21:13:24 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-04-12 21:17:59 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-04-12 21:21:51 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 246 seconds) |
| 2022-04-12 21:24:08 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-04-12 21:26:49 +0200 | ridcully | (~ridcully@pd951f433.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-04-12 21:27:48 +0200 | ridcully | (~ridcully@pd951f433.dip0.t-ipconnect.de) |
| 2022-04-12 21:28:31 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 21:28:51 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:af05:7994:32e5:1bd2) |
| 2022-04-12 21:30:26 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-04-12 21:33:04 +0200 | akegalj | (~akegalj@23-132.dsl.iskon.hr) (Quit: leaving) |
| 2022-04-12 21:34:21 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2022-04-12 21:34:45 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-04-12 21:36:24 +0200 | bahamas | (~lucian@84.232.140.158) (Ping timeout: 248 seconds) |
| 2022-04-12 21:37:23 +0200 | axeman | (~quassel@2a02:8109:a380:78:c8da:9dc6:9792:51c3) (Quit: No Ping reply in 180 seconds.) |
| 2022-04-12 21:38:38 +0200 | axeman | (~quassel@2a02:8109:a380:78:b7c1:3e0f:fd2d:484) |
| 2022-04-12 21:38:52 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-04-12 21:39:24 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) |
| 2022-04-12 21:42:42 +0200 | alp__ | (~alp@user/alp) (Ping timeout: 260 seconds) |
| 2022-04-12 21:43:33 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 21:43:53 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 21:44:47 +0200 | yauhsien | (~yauhsien@61-231-57-22.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-04-12 21:51:50 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-04-12 21:52:07 +0200 | axeman | (~quassel@2a02:8109:a380:78:b7c1:3e0f:fd2d:484) (Ping timeout: 240 seconds) |
| 2022-04-12 21:54:03 +0200 | raym | (~raym@user/raym) (Ping timeout: 246 seconds) |
| 2022-04-12 21:54:57 +0200 | raym | (~raym@user/raym) |
| 2022-04-12 21:55:38 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:af05:7994:32e5:1bd2) (Quit: WeeChat 2.8) |
| 2022-04-12 21:58:10 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-04-12 22:00:02 +0200 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) |
| 2022-04-12 22:03:06 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-04-12 22:04:45 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 22:05:04 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 22:05:55 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 256 seconds) |
| 2022-04-12 22:07:25 +0200 | dextaa | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-04-12 22:07:58 +0200 | <HensonAway> | /quit |
| 2022-04-12 22:08:01 +0200 | HensonAway | (~kvirc@107-179-133-201.cpe.teksavvy.com) (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) |
| 2022-04-12 22:08:24 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-04-12 22:11:32 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2022-04-12 22:12:01 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-04-12 22:15:42 +0200 | <shapr> | yay blog post on calling SMT solvers in Haskell https://shapr.github.io/posts/2022-04-11-smt-solvers-part-three.html |
| 2022-04-12 22:15:55 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Client Quit) |
| 2022-04-12 22:16:07 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-04-12 22:17:53 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-04-12 22:23:08 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-04-12 22:24:20 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds) |
| 2022-04-12 22:24:45 +0200 | ccntrq | (~Thunderbi@2a01:e34:eccb:b060:63fb:4f44:a784:526) (Remote host closed the connection) |
| 2022-04-12 22:25:54 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-04-12 22:27:33 +0200 | <dmj`> | nice, sbv is cool. The z3 backend is nice too |
| 2022-04-12 22:27:39 +0200 | redb | (~nmh@136.49.49.211) (Ping timeout: 246 seconds) |
| 2022-04-12 22:27:54 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-04-12 22:29:12 +0200 | slack1256 | (~slack1256@186.11.41.244) |
| 2022-04-12 22:31:25 +0200 | slac53263 | (~slack1256@191.126.99.201) (Ping timeout: 256 seconds) |
| 2022-04-12 22:34:44 +0200 | alp__ | (~alp@user/alp) |
| 2022-04-12 22:36:33 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-04-12 22:42:47 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 240 seconds) |
| 2022-04-12 22:42:52 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Read error: Connection reset by peer) |
| 2022-04-12 22:45:25 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-04-12 22:48:55 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 22:48:56 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-04-12 22:48:59 +0200 | redb | (~nmh@136.49.49.211) |
| 2022-04-12 22:49:24 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-04-12 22:51:04 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-04-12 22:51:09 +0200 | ubert | (~Thunderbi@p200300ecdf1588e22aca51cd048e2ffe.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-04-12 22:52:25 +0200 | sloorush | (~sloorush@2401:4900:4dd6:a45b:a43f:2865:3883:396a) |
| 2022-04-12 22:53:33 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 246 seconds) |
| 2022-04-12 22:54:14 +0200 | z0k | (~z0k@39.40.122.185) (Ping timeout: 250 seconds) |
| 2022-04-12 22:54:34 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-04-12 22:59:31 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 23:00:12 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-04-12 23:02:44 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-04-12 23:04:12 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-04-12 23:04:17 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-04-12 23:05:11 +0200 | fendor_ | (~fendor@91.141.45.157.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-04-12 23:09:15 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 23:09:18 +0200 | anomal | (~anomal@87.227.196.109) (Remote host closed the connection) |
| 2022-04-12 23:09:37 +0200 | anomal | (~anomal@87.227.196.109) |
| 2022-04-12 23:14:00 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 23:14:44 +0200 | acidjnk_new | (~acidjnk@p200300d0c722df6551746e639bede6b3.dip0.t-ipconnect.de) |
| 2022-04-12 23:17:47 +0200 | acidjnk | (~acidjnk@p200300d0c7049f336039e1baac7dfab4.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-04-12 23:18:36 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) |
| 2022-04-12 23:19:25 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 23:24:21 +0200 | kenran | (~kenran@200116b82b941e00e4d4a50fd3a17d60.dip.versatel-1u1.de) |
| 2022-04-12 23:24:22 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 272 seconds) |
| 2022-04-12 23:27:29 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-04-12 23:28:12 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 246 seconds) |
| 2022-04-12 23:29:57 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 23:31:49 +0200 | acidjnk_new | (~acidjnk@p200300d0c722df6551746e639bede6b3.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-04-12 23:33:26 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-04-12 23:33:49 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Quit: ZNC 1.8.2+cygwin2 - https://znc.in) |
| 2022-04-12 23:34:37 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-04-12 23:34:48 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-04-12 23:35:06 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-04-12 23:35:16 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-04-12 23:42:53 +0200 | kenran | (~kenran@200116b82b941e00e4d4a50fd3a17d60.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-04-12 23:44:18 +0200 | sloorush | (~sloorush@2401:4900:4dd6:a45b:a43f:2865:3883:396a) (Ping timeout: 250 seconds) |
| 2022-04-12 23:46:31 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 23:46:51 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 23:49:36 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.4) |
| 2022-04-12 23:49:50 +0200 | Unicorn_Princess | (~Unicorn_P@93-103-228-248.dynamic.t-2.net) |
| 2022-04-12 23:50:31 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 23:50:51 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 23:52:26 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-04-12 23:52:37 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-04-12 23:53:22 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-04-12 23:57:00 +0200 | yauhsien | (~yauhsien@61-231-36-20.dynamic-ip.hinet.net) |
| 2022-04-12 23:57:50 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.5) |
| 2022-04-12 23:58:34 +0200 | lavaman | (~lavaman@c-174-63-118-52.hsd1.ma.comcast.net) (Ping timeout: 272 seconds) |