Newest at the top
| 2024-10-24 15:34:25 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3217-270c-61bf-78b5-c91b-cacd.rev.sfr.net) (Remote host closed the connection) |
| 2024-10-24 15:33:55 +0200 | leah2 | (~leah@vuxu.org) leah2 |
| 2024-10-24 15:31:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-24 15:30:52 +0200 | euleritian | (~euleritia@dynamic-176-006-137-198.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-10-24 15:24:00 +0200 | leah2 | (~leah@vuxu.org) (Ping timeout: 244 seconds) |
| 2024-10-24 15:15:17 +0200 | euleritian | (~euleritia@dynamic-176-006-137-198.176.6.pool.telefonica.de) |
| 2024-10-24 15:15:06 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-10-24 15:08:18 +0200 | CiaoSen | (~Jura@2a05:5800:46d:2500:ca4b:d6ff:fec1:99da) (Ping timeout: 245 seconds) |
| 2024-10-24 15:06:15 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-24 15:05:09 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-10-24 15:02:41 +0200 | hgolden__ | (~hgolden@23.162.40.28) (Ping timeout: 248 seconds) |
| 2024-10-24 15:00:22 +0200 | hgolden_ | (~hgolden@23.162.40.69) hgolden |
| 2024-10-24 14:59:20 +0200 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-10-24 14:59:05 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Read error: Connection reset by peer) |
| 2024-10-24 14:58:05 +0200 | gentauro | (~gentauro@user/gentauro) gentauro |
| 2024-10-24 14:56:28 +0200 | rubin55 | (sid666177@id-666177.lymington.irccloud.com) rubin55 |
| 2024-10-24 14:56:24 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-10-24 14:56:04 +0200 | meinside | (uid24933@id-24933.helmsley.irccloud.com) meinside |
| 2024-10-24 14:55:19 +0200 | meinside | (uid24933@id-24933.helmsley.irccloud.com) (Ping timeout: 264 seconds) |
| 2024-10-24 14:55:15 +0200 | rubin55 | (sid666177@id-666177.lymington.irccloud.com) (Ping timeout: 246 seconds) |
| 2024-10-24 14:51:26 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 255 seconds) |
| 2024-10-24 14:49:15 +0200 | CiaoSen | (~Jura@2a05:5800:46d:2500:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-10-24 14:40:53 +0200 | zero | zzz |
| 2024-10-24 14:39:49 +0200 | ubert | (~Thunderbi@178.115.35.86.wireless.dyn.drei.com) (Ping timeout: 248 seconds) |
| 2024-10-24 14:32:51 +0200 | CiaoSen | (~Jura@2a05:5800:46d:2500:ca4b:d6ff:fec1:99da) (Ping timeout: 252 seconds) |
| 2024-10-24 14:25:29 +0200 | symdrome | (~user@2804:1e78:2202:2220::416) symdrome |
| 2024-10-24 14:24:56 +0200 | <vektor> | As in, I've had test cases terminate gracefully (and then run into the timout) after >10 seconds, which I had thought to be practically impossible. |
| 2024-10-24 14:23:46 +0200 | hgolden_ | (~hgolden@169.150.203.36) (Ping timeout: 252 seconds) |
| 2024-10-24 14:23:26 +0200 | <vektor> | Looking into it, it might've just been that QuickCheck generates obscenely large test cases and my UUT is simply slower than expected. Seems I should check my assumptions about "sized" and such. |
| 2024-10-24 14:22:02 +0200 | <geekosaur> | compiling the unit with -fno-omit-yields may help |
| 2024-10-24 14:21:24 +0200 | hgolden__ | (~hgolden@23.162.40.28) hgolden |
| 2024-10-24 14:20:12 +0200 | dilaver_ | (~dilaver_@user/dilaver-:32218) dilaver_ |
| 2024-10-24 14:19:38 +0200 | <vektor> | I see. If the presumed loop in my unit under test is also non-allocating I'm a little hosed. I mean, I suppose I could do a substantially more manual approach to troubleshoot. |
| 2024-10-24 14:19:29 +0200 | dilaver_ | (~dilaver_@user/dilaver-:32218) (Quit: Ping timeout (120 seconds)) |
| 2024-10-24 14:19:27 +0200 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2024-10-24 14:18:44 +0200 | alp | (~alp@2001:861:e3d6:8f80:4c11:7ead:439d:9e81) (Remote host closed the connection) |
| 2024-10-24 14:16:44 +0200 | <Leary> | vektor: Non-allocating loop maybe. There's no escape if the GC doesn't have a chance to act. |
| 2024-10-24 14:16:30 +0200 | mceresa | (~mceresa@user/mceresa) (Remote host closed the connection) |
| 2024-10-24 14:14:01 +0200 | <vektor> | https://paste.tomsmeding.com/VrrXMpLr - am I missing something about the way QuickCheck's "within" (aka timeout) is supposed to be used? This thing loops forever. |
| 2024-10-24 14:12:58 +0200 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2024-10-24 14:11:27 +0200 | vektor | (~vektor@IP-149249145213.pools.medianet-world.de) |
| 2024-10-24 14:09:58 +0200 | mceresa | (~mceresa@user/mceresa) (Remote host closed the connection) |
| 2024-10-24 14:08:34 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 244 seconds) |
| 2024-10-24 14:08:17 +0200 | CiaoSen | (~Jura@2a05:5800:46d:2500:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-10-24 14:04:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-10-24 13:53:17 +0200 | identity | (~identity@user/ZharMeny) identity |
| 2024-10-24 13:52:56 +0200 | hgolden__ | (~hgolden@169.150.203.10) (Ping timeout: 255 seconds) |
| 2024-10-24 13:50:22 +0200 | hgolden_ | (~hgolden@169.150.203.36) hgolden |
| 2024-10-24 13:29:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-24 13:29:10 +0200 | mari-7733 | (~mari-este@user/mari-estel) (Quit: on the move) |