Logs: liberachat/#haskell
| 2021-06-10 20:59:23 | jolly29 | is now known as jolly |
| 2021-06-10 20:59:37 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) |
| 2021-06-10 20:59:43 | <kenran> | ohh, I tried that one, but I think I had one too many `runST` calls still in there. Now I'm getting a different error, let me see |
| 2021-06-10 21:00:06 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-06-10 21:00:41 | <nshepperd> | you won't need to use runST at all |
| 2021-06-10 21:00:52 | <kenran> | yeah, I think that does the trick, thanks! |
| 2021-06-10 21:01:27 | <kenran> | I'm still very unsure if all that is even going to solve any problem, and whether I even look for the problem in the right place |
| 2021-06-10 21:02:26 | <kenran> | I don't understand ByteString.Lazy well, and stuff with Handle even less, so that makes for a potent situation :D |
| 2021-06-10 21:05:05 | × | tremon quits (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2021-06-10 21:07:04 | × | jippiedoe quits (~david@2a02-a44c-e14e-1-6bdc-c755-d41c-84af.fixed6.kpn.net) (Ping timeout: 272 seconds) |
| 2021-06-10 21:12:29 | <kenran> | In https://wiki.haskell.org/Dealing_with_binary_data there's written "B.getContents .. will read the whole of stdin into memory". What is "the whole" here? |
| 2021-06-10 21:12:56 | <kenran> | Its documentation says that the handle is closed after the operation, so what does that mean for stdin? |
| 2021-06-10 21:13:40 | <kenran> | Can I think of it as a file which is consumed by getContents/reading? |
| 2021-06-10 21:14:18 | × | chexum quits (~chexum@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-06-10 21:14:28 | → | chexum joins (~chexum@gateway/tor-sasl/chexum) |
| 2021-06-10 21:14:32 | <monochrom> | reading and storing into memory until EOF |
| 2021-06-10 21:15:01 | × | Erutuon quits (~Erutuon@user/erutuon) (Quit: WeeChat 2.8) |
| 2021-06-10 21:15:09 | <monochrom> | If I feed a whole blu-ray disc to your stdin, you will OOM. |
| 2021-06-10 21:15:41 | <nshepperd> | in the case of stdin that means it will block until whoever is writing to stdin closes the pipe |
| 2021-06-10 21:16:27 | <kenran> | Flushing should suffice, shouldn't it? (That's what I think I learned by playing around with reading/writing operations on a pipe) |
| 2021-06-10 21:16:31 | <nshepperd> | such as by pressing ^D in the terminal |
| 2021-06-10 21:16:58 | <monochrom> | suffice for what? |
| 2021-06-10 21:17:06 | × | amahl quits (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-06-10 21:17:48 | <monochrom> | and who is flushing? |
| 2021-06-10 21:18:42 | <kenran> | Ah nvm, I used LBS.getContents on one end ("left"), hPut some value on the other, flushed, then the left side could read it and responded. Without flushing, it was still blocking on hGetContents |
| 2021-06-10 21:19:22 | <monochrom> | But B is not LBS. |
| 2021-06-10 21:19:28 | <kenran> | Without the L in LBS there it wouldn't have worked at all IIUC? |
| 2021-06-10 21:19:47 | <monochrom> | Not sure what's your definition of "work". |
| 2021-06-10 21:19:49 | × | dunkeln quits (~dunkeln@94.129.65.28) (Ping timeout: 268 seconds) |
| 2021-06-10 21:20:19 | <kenran> | It would have blocked indefinitely I think, but I'll just try it. |
| 2021-06-10 21:21:29 | <kenran> | I need to attack this from the bottom, for instance by understanding what EOF really means |
| 2021-06-10 21:21:34 | <kenran> | Thanks for the pointers! |
| 2021-06-10 21:21:45 | <nshepperd> | B.getContents promises to return all data that will ever be written to stdin at once as a single bytestring. it blocks until whoever is writing closes the pipe so that no more can be written |
| 2021-06-10 21:21:58 | <monochrom> | Yeah, you need a Unix course. |
| 2021-06-10 21:22:16 | × | dhil quits (~dhil@195.213.192.47) (Ping timeout: 272 seconds) |
| 2021-06-10 21:22:46 | × | thyriaen quits (~thyriaen@45.178.73.238) (Read error: Connection reset by peer) |
| 2021-06-10 21:22:47 | → | thyriaen_ joins (~thyriaen@45.178.73.238) |
| 2021-06-10 21:23:47 | × | teaSlurper quits (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-06-10 21:24:10 | <kenran> | monochrom: exactly! It might even be worth learning some of that stuff without using Haskell. |
| 2021-06-10 21:24:14 | × | BosonCollider quits (~olofs@90-227-86-119-no542.tbcn.telia.com) (Ping timeout: 245 seconds) |
| 2021-06-10 21:25:06 | × | Guest97 quits (~Guest9@43.241.144.108) (Quit: Connection closed) |
| 2021-06-10 21:27:28 | <maerwald> | unix: we didn't know how to create an API, so we made everything a file |
| 2021-06-10 21:28:39 | → | teaSlurper joins (~chris@81.96.113.213) |
| 2021-06-10 21:28:54 | <hpc> | man 2 open, man 2 read, man 2 close are a good place to start |
| 2021-06-10 21:29:06 | <dminuoso> | kenran: By the way, if you are curious about ST, think of it as a restricted way to use IO in a localized manner. mergesort is from an outside perspective a completely pure operation, right? |
| 2021-06-10 21:29:55 | <monochrom> | I think that's false. fork, exec, pipe, sbrk could have been defined through special files too, but not done, and thank God. |
| 2021-06-10 21:30:21 | <maerwald> | lol |
| 2021-06-10 21:30:45 | <hpc> | i can see it now |
| 2021-06-10 21:30:56 | <monochrom> | If you're looking at "echo 1 > /sys/foo/bar/go-to-sleep-now" then sure, but that's a linux invention. |
| 2021-06-10 21:31:27 | <hpc> | fork() {pid=$1; cp --recursive /proc/$pid /proc/$(cat /proc/new-pid);} |
| 2021-06-10 21:31:46 | × | chomwitt quits (~Pitsikoko@athedsl-20549.home.otenet.gr) (Ping timeout: 272 seconds) |
| 2021-06-10 21:32:26 | motherfs1 | is now known as motherfsck |
| 2021-06-10 21:32:27 | <kenran> | dminuoso: yes |
| 2021-06-10 21:33:01 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Remote host closed the connection) |
| 2021-06-10 21:33:20 | × | teaSlurper quits (~chris@81.96.113.213) (Ping timeout: 264 seconds) |
| 2021-06-10 21:33:29 | <kenran> | I think I saw something like that mentioned on the haskell wiki page for ST |
| 2021-06-10 21:33:50 | <dminuoso> | kenran: But would you agree, that an efficient mergesort implementation requires memory manipulations? Or perhaps quicksort is a more motivating example, there the need for in-place partitioning is obvious. |
| 2021-06-10 21:34:01 | → | thyriaen__ joins (~thyriaen@45.178.73.238) |
| 2021-06-10 21:34:03 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-06-10 21:34:44 | <monochrom> | I can also be talked into "we didn't know how to create an ABI, so we created software interrupts instead". |
| 2021-06-10 21:34:51 | → | dhil joins (~dhil@80.208.56.181) |
| 2021-06-10 21:35:03 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-10 21:35:19 | <kenran> | dminuoso: sounds right to me, from the looks of the algorithms, yes |
| 2021-06-10 21:36:33 | → | waleee joins (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-06-10 21:36:56 | × | thyriaen_ quits (~thyriaen@45.178.73.238) (Ping timeout: 264 seconds) |
| 2021-06-10 21:37:08 | <dminuoso> | kenran: So ST gives us mutable references like IORef that we can write to, read from or mutate. Just like mutable stores from other languages (often called variables there). But in a way that you can use this in the middle of pure code. |
| 2021-06-10 21:38:09 | <janus> | isn't it better to mention STRef when talking about ST |
| 2021-06-10 21:38:21 | × | neceve quits (~quassel@2a02:c7f:607e:d600:a95a:ecd2:e57a:3130) (Ping timeout: 272 seconds) |
| 2021-06-10 21:39:08 | <kenran> | dminuoso: that's very interesting. I might even have a piece of code that could use this immediately. It's one part of an algorithm where memory blows up to 1.5 GB (though it's not a space leak, it just requires a lot) and where I though having mutability would help. |
| 2021-06-10 21:39:42 | <kenran> | Thanks everyone, time to sleep and tackle this again tomorrow! |
| 2021-06-10 21:40:34 | → | pretty_dumm_guy joins (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2021-06-10 21:41:44 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 245 seconds) |
| 2021-06-10 21:42:19 | <dminuoso> | monochrom: Mmm, procfs/sysfs is an odd one. On the one hand, files are a really comfortable API for plumbing things together. But recall that time where `rm -rf /` could irrepably brick your mainboard? |
| 2021-06-10 21:42:30 | × | Xe quits (~cadey@tailscale/xe) (Quit: WeeChat 3.1) |
| 2021-06-10 21:42:36 | × | kenran quits (~kenran@200116b82b390f00b0c803a76fadf7bb.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2021-06-10 21:42:37 | × | tcard quits (~tcard@p2307053-ipngn17101hodogaya.kanagawa.ocn.ne.jp) (Quit: Leaving) |
| 2021-06-10 21:42:44 | → | Xe joins (~cadey@tailscale/xe) |
| 2021-06-10 21:42:45 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 2021-06-10 21:44:55 | <janus> | the term file is so overloaded by now, it is not just one API |
| 2021-06-10 21:45:41 | <monochrom> | I think that the motivation for sysfs was shelll scripts. "echo 1 > /sys/foo/bar/power-saving-mode" is very shell-friendly. It would suck to have to write C code for that, even if it's just an ioctl call. |
| 2021-06-10 21:46:19 | <maerwald> | monochrom: powershell kinda solved that... where you just call their C# crap and it works |
| 2021-06-10 21:46:36 | <janus> | if poettering had had traction earlier, sysfs would never have been necessary ;) |
| 2021-06-10 21:46:47 | × | immae quits (~immae@2a01:4f8:141:53e7::) (Ping timeout: 252 seconds) |
| 2021-06-10 21:47:02 | <hpc> | or if someone wrote a shell wrapper for ioctl |
| 2021-06-10 21:47:20 | <janus> | they did, it is called systemctl :P |
| 2021-06-10 21:47:27 | <monochrom> | Yeah. My next thought was "What if Ritchie and Thompson invented Python instead of C?" |
| 2021-06-10 21:47:39 | → | immae joins (~immae@2a01:4f8:141:53e7::) |
| 2021-06-10 21:49:11 | <hpc> | or if it was like lisp machines, where the shell and the system language are the same |
| 2021-06-10 21:49:26 | <janus> | Python without C is not Python, the whole point of Python is that it finds that comfy spot where they have interoperability because they write all the low-level parts in C |
| 2021-06-10 21:50:11 | <hpc> | and let's be honest, some of the high-level parts too |
| 2021-06-10 21:50:48 | <monochrom> | I am OK with that argument, but if you do that, you may as well say "R&T who invent Python is not R&T" in the first place. |
| 2021-06-10 21:51:42 | → | tcard joins (~tcard@p2307053-ipngn17101hodogaya.kanagawa.ocn.ne.jp) |
| 2021-06-10 21:51:43 | <janus> | maybe I am missing the point, but the Unix greybeards were trying the best they could to make scripting languages, they called them shells? |
| 2021-06-10 21:52:13 | → | mikoto-chan joins (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
| 2021-06-10 21:52:44 | <janus> | you're suggesting they could have put some typing in their shells instead of leaving it to compiled languages? but performance was so critical, they didn't consider the fact that people would still be using these shells 50 years later |
| 2021-06-10 21:53:16 | <boxscape> | it's like the ancient chinese script that was written on turtle shells |
| 2021-06-10 21:55:43 | × | yushyin quits (nrX1Axr00h@karif.server-speed.net) (Quit: WeeChat 3.1) |
| 2021-06-10 21:56:01 | → | yushyin joins (DqPAekUnN9@karif.server-speed.net) |
| 2021-06-10 21:56:43 | × | pretty_dumm_guy quits (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.2-rc1) |
| 2021-06-10 21:56:51 | × | Ariakenom quits (~Ariakenom@2001:9b1:efb:fc00:1900:b2bf:db54:db6b) (Quit: Leaving) |
All times are in UTC.