2025/06/23

Newest at the top

2025-06-23 14:38:59 +0200merijn(~merijn@77.242.116.146) merijn
2025-06-23 14:37:34 +0200soverysour(~soverysou@user/soverysour) (Ping timeout: 260 seconds)
2025-06-23 14:37:08 +0200trickard_trickard
2025-06-23 14:35:05 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au)
2025-06-23 14:34:50 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au) (Ping timeout: 260 seconds)
2025-06-23 14:33:00 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds)
2025-06-23 14:31:57 +0200soverysour(~soverysou@user/soverysour) soverysour
2025-06-23 14:31:57 +0200soverysour(~soverysou@84.232.150.229) (Changing host)
2025-06-23 14:31:57 +0200soverysour(~soverysou@84.232.150.229)
2025-06-23 14:31:03 +0200soverysour(~soverysou@user/soverysour) (Ping timeout: 276 seconds)
2025-06-23 14:30:07 +0200emfrom(~emfrom@2a0d:e487:411f:c6e:cf22:a6ad:c205:90d1)
2025-06-23 14:27:48 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 276 seconds)
2025-06-23 14:25:32 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-06-23 14:20:37 +0200merijn(~merijn@77.242.116.146) merijn
2025-06-23 14:17:41 +0200soverysour(~soverysou@user/soverysour) soverysour
2025-06-23 14:17:41 +0200soverysour(~soverysou@84.232.150.229) (Changing host)
2025-06-23 14:17:41 +0200soverysour(~soverysou@84.232.150.229)
2025-06-23 14:16:22 +0200acidjnk(~acidjnk@p200300d6e70b661750c15e2a18f5d35c.dip0.t-ipconnect.de) acidjnk
2025-06-23 14:15:58 +0200califax(~califax@user/califx) califx
2025-06-23 14:15:35 +0200soverysour(~soverysou@user/soverysour) (Ping timeout: 260 seconds)
2025-06-23 14:14:16 +0200califax(~califax@user/califx) (Remote host closed the connection)
2025-06-23 14:10:50 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au)
2025-06-23 14:10:37 +0200trickard(~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-06-23 14:08:49 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-06-23 14:07:59 +0200soverysour(~soverysou@user/soverysour) soverysour
2025-06-23 14:07:59 +0200soverysour(~soverysou@84.232.150.229) (Changing host)
2025-06-23 14:07:59 +0200soverysour(~soverysou@84.232.150.229)
2025-06-23 14:05:03 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds)
2025-06-23 14:04:19 +0200soverysour(~soverysou@user/soverysour) (Ping timeout: 276 seconds)
2025-06-23 14:03:41 +0200ystael(~ystael@user/ystael) ystael
2025-06-23 14:01:59 +0200talisc(~talisc@user/talisc) (Excess Flood)
2025-06-23 14:00:23 +0200trickard_trickard
2025-06-23 13:52:54 +0200soverysour(~soverysou@user/soverysour) soverysour
2025-06-23 13:52:54 +0200soverysour(~soverysou@84.232.150.229) (Changing host)
2025-06-23 13:52:53 +0200soverysour(~soverysou@84.232.150.229) soverysour
2025-06-23 13:44:39 +0200merijn(~merijn@77.242.116.146) merijn
2025-06-23 13:41:16 +0200soverysour(~soverysou@user/soverysour) (Ping timeout: 265 seconds)
2025-06-23 13:38:22 +0200fp1(~Thunderbi@2001:708:20:1406::10c5) fp
2025-06-23 13:37:46 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au)
2025-06-23 13:37:27 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-06-23 13:36:05 +0200acidjnk(~acidjnk@p200300d6e70b661750c15e2a18f5d35c.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-06-23 13:31:31 +0200Lycurgus(~juan@user/Lycurgus) (Quit: irc.renjuan.org (juan@acm.org))
2025-06-23 13:31:01 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-06-23 13:29:32 +0200 <[exa]> (pls check out the lucene segmentation)
2025-06-23 13:28:45 +0200prdak(~Thunderbi@user/prdak) prdak
2025-06-23 13:28:30 +0200 <[exa]> yes but that's a completely impossible behavior here, writes must not cause locks
2025-06-23 13:28:30 +0200xff0x(~xff0x@2405:6580:b080:900:55ec:c9f:e8b1:7eb5)
2025-06-23 13:28:25 +0200 <Maxdamantus> [exa]: so the one you describe as easier just seems like a variation of a read-write lock that assumes that while the lock is held in write mode, noone else will try to acquire it again in write mode.
2025-06-23 13:27:07 +0200 <Maxdamantus> [exa]: that sounds like the distinction I was describing. Normally a read-write lock will "allow concurrent writes" by ensuring that only one actor can hold the lock when they access it in write mode.
2025-06-23 13:25:24 +0200trickard_(~trickard@cpe-61-98-47-163.wireline.com.au)