Logs: liberachat/#haskell
| 2025-10-20 07:59:22 | → | acidjnk joins (~acidjnk@p200300d6e7171945c42b348415052731.dip0.t-ipconnect.de) |
| 2025-10-20 08:05:00 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 08:05:53 | × | jreicher quits (~user@user/jreicher) (Ping timeout: 256 seconds) |
| 2025-10-20 08:06:12 | × | gustrb quits (~gustrb@191.243.134.87) (Ping timeout: 244 seconds) |
| 2025-10-20 08:07:18 | × | img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-10-20 08:08:25 | <monochrom> | The best thing about meaningful names is that there are so many meanings to choose from! |
| 2025-10-20 08:08:35 | → | img joins (~img@user/img) |
| 2025-10-20 08:10:37 | → | Googulator64 joins (~Googulato@2a01-036d-0106-03fa-0485-6a66-0733-0e38.pool6.digikabel.hu) |
| 2025-10-20 08:10:38 | × | Googulator96 quits (~Googulato@2a01-036d-0106-03fa-0485-6a66-0733-0e38.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-20 08:17:46 | → | FirefoxDeHuk joins (~FirefoxDe@109.108.69.106) |
| 2025-10-20 08:18:43 | × | FirefoxDeHuk quits (~FirefoxDe@109.108.69.106) (Client Quit) |
| 2025-10-20 08:19:49 | → | FirefoxDeHuk joins (~FirefoxDe@109.108.69.106) |
| 2025-10-20 08:19:53 | → | fp joins (~Thunderbi@2001:708:20:1406::10c5) |
| 2025-10-20 08:20:41 | → | gustrb joins (~gustrb@191.243.134.87) |
| 2025-10-20 08:22:19 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-10-20 08:29:26 | → | kubrat joins (~kubrat@149.62.205.212) |
| 2025-10-20 08:30:16 | × | mzg_ quits (mzg@abusers.hu) (Remote host closed the connection) |
| 2025-10-20 08:30:40 | × | synchromesh quits (~john@2406:5a00:2412:2c00:75ff:6dec:5332:48f7) (Read error: Connection reset by peer) |
| 2025-10-20 08:31:59 | → | synchromesh joins (~john@2406:5a00:2412:2c00:75ff:6dec:5332:48f7) |
| 2025-10-20 08:32:26 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 248 seconds) |
| 2025-10-20 08:34:08 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 08:34:55 | × | FirefoxDeHuk quits (~FirefoxDe@109.108.69.106) (Quit: Client closed) |
| 2025-10-20 08:37:37 | × | wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 265 seconds) |
| 2025-10-20 08:39:09 | → | wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de) |
| 2025-10-20 08:39:44 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-10-20 08:40:58 | <dminuoso> | davean: I guess if we just think of monad transformers or just constructions that eventually embed as some kinds of pyramid, it seems rather arbitrary whether we imagine the pyramid to have its tip pointed downwards or upwards. |
| 2025-10-20 08:43:05 | → | FirefoxDeHuk joins (~FirefoxDe@109.108.69.106) |
| 2025-10-20 08:45:37 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 08:45:38 | × | Googulator64 quits (~Googulato@2a01-036d-0106-03fa-0485-6a66-0733-0e38.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-20 08:45:49 | → | Googulator64 joins (~Googulato@2a01-036d-0106-03fa-0485-6a66-0733-0e38.pool6.digikabel.hu) |
| 2025-10-20 08:46:56 | × | wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 240 seconds) |
| 2025-10-20 08:47:07 | → | wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de) |
| 2025-10-20 08:48:20 | <davean> | dminuoso: don't think of it as a peramid, think of its a sphere with subspheres nested inside it |
| 2025-10-20 08:48:27 | <davean> | expanding out from zero |
| 2025-10-20 08:48:46 | <dminuoso> | davean: Sure, and in that model wouldnt we think of IO as the inner core? |
| 2025-10-20 08:49:07 | <davean> | It *is* the inner core, its not that we choose to think about it, it is litterly enclosed by |
| 2025-10-20 08:49:18 | <dminuoso> | If we take a given IO action, say `putStrLn "Hello world"`, then its the action of putting that core inside layers and layers until we have a matching sphere. |
| 2025-10-20 08:49:26 | <dminuoso> | Rather than pulling it out. |
| 2025-10-20 08:50:05 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-10-20 08:51:23 | <dminuoso> | This may just be the difference between operational and semantic thinking. |
| 2025-10-20 08:51:41 | <davean> | No, putStrLn is already an object in IO, it has no other existance |
| 2025-10-20 08:52:01 | <dminuoso> | Well I meant `liftIO (putStrLn "foo")` of course. |
| 2025-10-20 08:52:48 | <davean> | Write, that projects from the IO space to the IO subspace of SomeT IO |
| 2025-10-20 08:52:51 | <tomsmeding> | dminuoso: I think of liftIO as lifting "into SomeT", not "out of IO" |
| 2025-10-20 08:53:00 | <davean> | Yah, it NEVER LEAVES IO |
| 2025-10-20 08:53:04 | <davean> | It can't leave IO |
| 2025-10-20 08:53:07 | <tomsmeding> | the sky above is larger than you, so lifting moves it into the larger thing |
| 2025-10-20 08:53:44 | <davean> | it maps the IO subspace into the SomeT space, and specicily the IO subspace of said |
| 2025-10-20 08:54:04 | <tomsmeding> | indeed, SomeT IO may well have more logic than IO itself, so also in that sense, it's "lifting" into a more exalted space of SomeT IO computations |
| 2025-10-20 08:54:17 | <tomsmeding> | it's exactly what monochrom said |
| 2025-10-20 08:55:22 | <davean> | what did monochrom say? |
| 2025-10-20 08:55:33 | <tomsmeding> | 47 minutes ago |
| 2025-10-20 08:55:40 | <dminuoso> | Dont all monad transformers put the base monad on the outside, in the sense that if we have some tranformer stack over IO, ultimately we have something like `IO ((M1 :.: M2 :.: ...) a)` (and possibly a lambda outside for Reader)? |
| 2025-10-20 08:55:43 | <tomsmeding> | <monochrom> The best thing about meaningful names is that there are so many meanings to choose from! |
| 2025-10-20 08:56:16 | <davean> | dminuoso: no, no, that is very much NOT what they do |
| 2025-10-20 08:56:23 | <tomsmeding> | https://hackage.haskell.org/package/transformers-0.6.1.0/docs/Control-Monad-Trans-State-Strict.html#t:StateT |
| 2025-10-20 08:56:33 | <tomsmeding> | StateT s m a ~= s -> m (a, s) |
| 2025-10-20 08:56:34 | <dminuoso> | Ah I guess not. |
| 2025-10-20 08:56:46 | <davean> | dminuoso: which I think is where your confusion is |
| 2025-10-20 08:56:47 | <tomsmeding> | when you run them, you get a computation inside m, yes |
| 2025-10-20 08:56:59 | <dminuoso> | davean: No, this is actually just a tangent I was starting to explore. |
| 2025-10-20 08:57:19 | <tomsmeding> | and contrary to what davean is saying, I do not think your perspective is wrong, it's just a perspective that mismatches with what I think is the intended intuition behind "lift" |
| 2025-10-20 08:57:26 | <dminuoso> | davean: Until now I was just focused more on thinking of transformers as a syntactical construct where IO resided in since thats how I think of how the effects compose. |
| 2025-10-20 08:58:11 | <davean> | It isn't how the effects compose though, which gets really improtant with state and such |
| 2025-10-20 08:58:19 | <dminuoso> | tomsmeding: Perhaps. liftIO is just one of the few things that never really clicked on the naming to me. |
| 2025-10-20 08:58:58 | <dminuoso> | davean: Apart from ReaderT, I've never really used transformers much for a bunch of reasons. |
| 2025-10-20 08:59:21 | <dminuoso> | Except for some local computation tricks. |
| 2025-10-20 08:59:44 | <dminuoso> | Say something like runMaybeT $ do ... |
| 2025-10-20 09:00:11 | → | __monty__ joins (~toonn@user/toonn) |
| 2025-10-20 09:00:54 | <dminuoso> | Despite transformers being labeled with terms like "composition of effects", they are the antithesis of compositionality of library code. |
| 2025-10-20 09:02:19 | <davean> | How so? |
| 2025-10-20 09:04:01 | <srazkvt> | ig because instead of being able to call both functions for the wrapped monad, you need to lift the computations ? |
| 2025-10-20 09:04:26 | <dminuoso> | If you use hard-wired transformers its really hard to compose different transformer code together. If you use mtl code you lack effect order specification. As a result you have a large variety of effect libraries that try to address these issues. |
| 2025-10-20 09:04:47 | <dminuoso> | As a consequence hackage now is filled with code that ends up using any combination. |
| 2025-10-20 09:05:37 | <dminuoso> | The only effect that is universally compatible with most libraries is pure IO. |
| 2025-10-20 09:06:56 | <davean> | mtl you have a specific monad and then properties about it that you can use |
| 2025-10-20 09:07:13 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 09:08:30 | × | fp quits (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 256 seconds) |
| 2025-10-20 09:12:26 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-10-20 09:21:26 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-10-20 09:23:16 | × | FirefoxDeHuk quits (~FirefoxDe@109.108.69.106) (Quit: Client closed) |
| 2025-10-20 09:23:35 | <endokqr> | I am profiling (+RTS -p) a Haskell program that runs for quite some time and I am interested in data from the full run. Unfortunately, this makes the time huge! I thought I'd be able to adjust the resolution of the time profile with -i and/or -V, but this seems to have no effect. What am I misunderstanding? |
| 2025-10-20 09:23:40 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 09:24:43 | → | FirefoxDeHuk joins (~FirefoxDe@109.108.69.106) |
| 2025-10-20 09:32:27 | → | fp joins (~Thunderbi@130.233.70.140) |
| 2025-10-20 09:33:01 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-10-20 09:40:15 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-20 09:43:39 | × | trickard_ quits (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-20 09:43:52 | → | trickard_ joins (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-10-20 09:47:59 | × | FirefoxDeHuk quits (~FirefoxDe@109.108.69.106) (Quit: Client closed) |
| 2025-10-20 09:50:27 | <dminuoso> | endokqr: -i is just the sampling rate, think of it how accurate/finely grained the data is. |
| 2025-10-20 09:50:45 | <dminuoso> | In practice this controls the data size of the profiling data |
| 2025-10-20 09:51:02 | <endokqr> | dminuoso, Yeah, and I would imagine by setting -i to e.g. "10 Hz" would give me fewer stack frames in the time profile. But whatever number I pass there I get the same 9.1 GB .prof file. |
| 2025-10-20 09:51:35 | <dminuoso> | endokqr: No, the cost centers are collected regardless. The interval is just how often the RTS stops and writes a record. |
| 2025-10-20 09:51:47 | → | mreh joins (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2025-10-20 09:52:21 | <dminuoso> | The "stack frames" what you describe is just the cost centers. |
| 2025-10-20 09:52:31 | <endokqr> | Ooooh, okay. So the only solution for me is to either post-process the .prof file and try to recognise "unimportant" branches of the tree and prune them, or go in and try to assign cost centres more intelligently? |
| 2025-10-20 09:52:38 | <dminuoso> | Yes. |
| 2025-10-20 09:53:10 | → | FirefoxDeHuk joins (~FirefoxDe@109.108.69.106) |
| 2025-10-20 09:53:34 | × | FirefoxDeHuk quits (~FirefoxDe@109.108.69.106) (Write error: Connection reset by peer) |
All times are in UTC.