Newest at the top
| 2026-03-10 15:12:57 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 15:11:43 +0100 | st_aldini | (~Betterbir@136.48.46.187) st_aldini |
| 2026-03-10 15:11:37 +0100 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 15:06:08 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 252 seconds) |
| 2026-03-10 15:03:57 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 246 seconds) |
| 2026-03-10 14:57:25 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2026-03-10 14:56:38 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2026-03-10 14:55:36 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-10 14:44:10 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-10 14:36:22 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-10 14:30:10 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 245 seconds) |
| 2026-03-10 14:27:44 +0100 | Fijxu_ | (~Fijxu@user/fijxu) fijxu |
| 2026-03-10 14:26:29 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 14:26:23 +0100 | adamCS | (~adamCS@70.19.85.77) adamCS |
| 2026-03-10 14:26:17 +0100 | Fijxu | (~Fijxu@user/fijxu) (Read error: Connection reset by peer) |
| 2026-03-10 14:25:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-10 14:20:54 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2026-03-10 14:18:33 +0100 | gabiruh | (~gabiruh@191.252.222.55) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2026-03-10 14:17:19 +0100 | adamCS | (~adamCS@70.19.85.77) (Remote host closed the connection) |
| 2026-03-10 14:07:55 +0100 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) nschoe |
| 2026-03-10 14:07:38 +0100 | nschoe- | (~nschoe@2a01:e0a:8e:a190:bcc4:c62f:8a83:eae8) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2026-03-10 14:07:24 +0100 | jreicher | (~joelr@user/jreicher) (Ping timeout: 256 seconds) |
| 2026-03-10 14:02:37 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 13:50:08 +0100 | <Freakie> | I hope it doesn't sound like I'm being difficult, I'm just working with a lot of constraints (albeit intentioanlly) |
| 2026-03-10 13:49:17 +0100 | <Freakie> | at which point in-memory sharing is also problematic |
| 2026-03-10 13:48:56 +0100 | <Freakie> | the same problem can be moved to cache level |
| 2026-03-10 13:48:36 +0100 | <Freakie> | the point is more that the whole model of computation i'm working with only counts I/O operations as costful, hence *in theory* pointer sharing is problematic |
| 2026-03-10 13:47:54 +0100 | <Freakie> | it would problem be something like that if I get that far |
| 2026-03-10 13:46:55 +0100 | <comerijn> | Why not give your data a Storable instance and just allocate blocks of memory explicitly |
| 2026-03-10 13:46:39 +0100 | <Freakie> | well technically it would only matter once data needs to be pushed to the disk |
| 2026-03-10 13:46:30 +0100 | <comerijn> | *that |
| 2026-03-10 13:46:27 +0100 | <comerijn> | At the point why not take an entirely different approach |
| 2026-03-10 13:46:12 +0100 | m1dnight_ | (~m1dnight@141.134.26.23) (Ping timeout: 244 seconds) |
| 2026-03-10 13:46:05 +0100 | <Freakie> | it's nothing to do with referential transparency and everything to do with data locality |
| 2026-03-10 13:45:53 +0100 | <Freakie> | I'm trying to work with I/O efficient algorithms and sharing can imply page faults |
| 2026-03-10 13:45:48 +0100 | <comerijn> | Freakie: In an immutable setting, how do you think you could possibly observe whether something is shared? |
| 2026-03-10 13:45:16 +0100 | <comerijn> | sharing or not sharing is not obsevable |
| 2026-03-10 13:45:12 +0100 | <Freakie> | it seems counterintuitive but it's a pretty essential part (at least if the algorithms actually manage to scale to the problem sizes they want toa ddress) |
| 2026-03-10 13:44:45 +0100 | <Freakie> | yes but sharing is a problem in theory for what the algorithms need to do |
| 2026-03-10 13:44:31 +0100 | <comerijn> | A compact region is not mutable |
| 2026-03-10 13:44:13 +0100 | <comerijn> | Data is immutable |
| 2026-03-10 13:44:09 +0100 | <comerijn> | Freakie: deep copying question makes no sense |
| 2026-03-10 13:43:25 +0100 | <Freakie> | (it's desired in what I'm trying to do) |
| 2026-03-10 13:43:16 +0100 | <Freakie> | do you know if the compact regions are deep copied? |
| 2026-03-10 13:42:51 +0100 | <Freakie> | and then sorting them lazily (i.e. when you actually need to traverse said level) |
| 2026-03-10 13:42:24 +0100 | <Freakie> | otherwise I was planning on using the levelwise layout of the BDD to separate the closest data (for example what needs to be processed on the current and next level) from the priority queue itself |
| 2026-03-10 13:41:02 +0100 | <Freakie> | maybe a compact PQ could help but then I suppose the region will just keep growing till the algorithm is done? |