00:23 arunvickram joined 01:04 arunvickram left, arunvickram joined 01:36 stanrifkin left 02:02 arunvickram left 02:43 hulk joined 02:44 kylese left 03:15 hulk left, kylese joined
jubilatious1_98524 weekly: unix.stackexchange.com/a/804447/227738 03:34
weekly: unix.stackexchange.com/a/804449/227738 05:03
B-licious. 05:04
05:27 arunvickram joined
Geth raku.org/build-dev: 771f3755fb | (Coleman McFarland)++ | 2 files
Build dev automatically

If branch is "dev", build and push a "dev" container.		 06:03
raku.org: dontlaugh++ created pull request #293:
Build dev automatically		 06:05
raku.org/main: 97994937b6 | (Coleman McFarland)++ | 2 files
Build dev automatically

If branch is "dev", build and push a "dev" container.		 06:06
raku.org/dev: 6be170ca30 | (Coleman McFarland)++ | lib/Org/Home.rakumod
test dev deploy
 06:30
raku.org/dev: 78 commits pushed by librasteve++, (Will Coleda)++, (Patrick Böker)++, rcmlz++, (Coleman McFarland)++
review: github.com/Raku/raku.org/compare/6...c2b80b52bd		 06:38
06:50 Aedil joined 07:03 arunvickram left 08:24 Sgeo left
lizmat Voldenet: wonder whether it's some kind of impedance mechanism at work 09:39
Geth Papers: librasteve++ created pull request #59:
fix broken links		 10:34
Papers: librasteve++ created pull request #60:
update list of IRC channels		 10:44
Papers/main: 2a148dd636 | librasteve++ (committed using GitHub Web editor) | README.md
fix broken links (#59)
 10:54
raku.org/dev: 50 commits pushed by (Will Coleda)++, librasteve++, (Patrick Böker)++, rcmlz++
review: github.com/Raku/raku.org/compare/4...f7643a48fb		 11:34
12:29 stanrifkin joined 12:45 stanrifkin left 13:21 librasteve_ left 13:39 MoC joined 13:47 arunvickram joined 14:42 ShimmerFairy joined 14:53 stanrifkin joined 15:00 jgaz joined 15:15 arunvickram left 15:23 arunvickram joined 15:30 arunvickram left 15:31 arunvickram joined 15:44 arunvickram left 15:59 guestll joined 16:05 Sgeo joined 16:27 MoC left 17:13 librasteve_ joined 17:43 guestll left 17:54 [Coke] joined, [Coke] left 20:11 sergot left 20:13 arunvickram joined 20:38 Pixi left 20:40 arunvickram left 20:42 arunvickram joined 20:43 Pixi joined
Voldenet So, I've rethought it and it turns out that I used Lock::Async for wrong things 20:48
m: my $n = Lock.new; $n.lock; await start { $n.unlock; } # this will not work 20:49
camelia An operation first awaited:
in block <unit> at <tmp> line 1

Died with the exception:
Attempt to unlock mutex by thread not holding it
in block at <tmp> line 1
Voldenet m: my $n = Lock::Async.new; $n.lock; await start { $n.unlock; } # this works
camelia ( no output )
Voldenet It might seem like a minor case but actually it's not really that difficult to use locks wrong 20:52
m: sub foo { await Promise.in(1); }; await do for ^100 { start { my $n = Lock::Async.new; $n.lock; foo; $n.unlock; } }; say now - BEGIN now; 20:53
camelia 1.095393154
timo you have to await $n.lock, too, don't you?
Voldenet ah, right
m: sub foo { await Promise.in(1); }; await do for ^100 { start { my $n = Lock::Async.new; await $n.lock; foo; $n.unlock; } }; say now - BEGIN now;
camelia 1.112947583
Voldenet either way, "foo" may seem safe to use, because it's not async or anything but it will quietly change the thread 20:54
so I'm starting to think that Lock::Async is suddenly better in a lot of scenarios
timo ah, you're talking about it being unsafe to "await" while holding a regular Lock? 20:55
nemokosch how does foo work that it's "not async"?
timo the docs of Lock::Async point this out explicitly: "There is no requirement that a Lock::Async is locked and unlocked by the same physical thread, meaning it is possible to do a non-blocking await while holding the lock. The flip side of this is Lock::Async is not re-entrant." 20:57
and the docs of Lock say: Any await performed while a Lock is held will behave in a blocking manner; the standard non-blocking behavior of await relies on the code following the `await` resuming on a different Thread from the pool, which is incompatible with the requirement that a Lock be unlocked by the same thread that locked it. 20:58
Voldenet Yes – either way, I've been comparing Lock and Lock::Async using only performance characteristics while forgetting that they are for different use cases, just straightening this out 20:59
timo this might only work when using Lock's protect method though
perhaps it's using something inside the runtime that checks if locks are being held, i do remember seeing a counter for something like that somewhere 21:01
Voldenet hm, is it even possible to say "this await has to go back to the thread where it has started"?
nemokosch > Because protect will block any threads that are waiting to execute the critical section the code should be as quick as possible. it's hard to break this sentence down 21:04
21:13 Aedil left
timo you would install a different $*AWAITER, or put a CurrentThreadScheduler into your $*SCHEDULER in that dynamic scope I think 21:14
Voldenet that works 21:16
m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; await do for ^100 { start { Lock.new.protect({ foo; }); } }; say now - BEGIN now
camelia MoarVM panic: Memory allocation failed; could not allocate 393216 bytes
Voldenet m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; await do for ^50 { start { Lock.new.protect({ foo; }); } }; say now - BEGIN now
camelia MoarVM panic: Memory allocation failed; could not allocate 393216 bytes
Voldenet or maybe not :(
(it does work locally though, even if it's a bit memory hungry) 21:17
timo well, you are trying to get it to create a hundred threads 21:19
i'm not sure what the memory limit is on camelia
but i think even though we start with a smaller nursery the first time we start a thread, it's still a good chunk of memory 21:20
Voldenet on my system it takes `191372maxresident)k` 21:22
around as much as
m: my @x; @x[2 ** 23] = 1 21:23
camelia ( no output )
Voldenet …hmmm?
m: my @x; @x[2 ** 25] = 1
camelia ( no output )
nemokosch is it sparse? lol
Voldenet I think it isn't
m: my @x; @x[2 ** 32] = 1
camelia MoarVM panic: Memory allocation failed; could not allocate 34359738376 bytes
Voldenet so you can actually use around 400MB in camelia 21:24
m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; await do for ^20 { start { Lock.new.protect({ foo; }); } }; say now - BEGIN now 21:25
camelia 1.28416232
Voldenet m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; await do for ^50 { start { Lock.new.protect({ foo; }); } }; say now - BEGIN now
camelia MoarVM panic: Memory allocation failed; could not allocate 393216 bytes
timo I didn't actually look how CurrentThreadScheduler would behave in this situation, maybe I was wrong 21:26
Geth raku.org/use-new-container-path: ec067bbe88 | (Coleman McFarland)++ | scripts/cibuild.sh
Refactor cibuild.sh script

Remove reference to proto-25 container repository. This will let us remove that repository completely and move to a more unambiguous name.		 21:27
timo also, try if Lock.new.protect without the $*SCHEDULER and without anything else makes it do the blocking correctly
Geth raku.org: dontlaugh++ created pull request #294:
use new container path
raku.org/use-new-container-path: fb637c3ffa | (Coleman McFarland)++ | 2 files
Refactor cibuild.sh script

Remove reference to proto-25 container repository. This will let us remove that repository completely and move to a more unambiguous name.		 21:28
raku.org/use-new-container-path: 2a2d66bf84 | (Coleman McFarland)++ | 2 files
Refactor cibuild.sh script

Remove reference to proto-25 container repository. This will let us remove that repository completely and move to a more unambiguous name.		 21:33
Voldenet timo: I've checked and on my machine I get 68 threads (64 default and 4 base ones) - this approach does work 21:35
m: use nqp; say nqp::getattr_i($*SCHEDULER<>, ThreadPoolScheduler, <$!max_threads>)
camelia 64
Voldenet and camelia also can use 64 threads, why 300kB then, hm
erm 300MB*
m: await do for ^100 { start { sleep 1; } }; say now - BEGIN now 21:36
camelia MoarVM panic: Memory allocation failed; could not allocate 393216 bytes
Voldenet yes, it's just some memory limit, not a bug
m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; my $*SCHEDULER = ThreadPoolScheduler.new(:16max_threads); await do for ^50 { start { Lock.new.protect({ foo; say $*THREAD; }); } }; say now - BEGIN now 21:38
camelia Thread #4 (GeneralWorker)
Thread #6 (GeneralWorker)
Thread #7 (GeneralWorker)
Thread #8 (GeneralWorker)
Thread #9 (GeneralWorker)
Thread #10 (GeneralWorker)
Thread #11 (GeneralWorker)
Thread #12 (GeneralWorker)
Thread #13 (GeneralWorke…
Voldenet m: sub foo { my $*SCHEDULER = CurrentThreadScheduler; await Promise.in(1); }; my $*SCHEDULER = ThreadPoolScheduler.new(:16max_threads); await do for ^50 { start { Lock.new.protect({ foo }); } }; say now - BEGIN now
camelia 4.056335106
Geth raku.org/main: bec99be217 | (Coleman McFarland)++ (committed using GitHub Web editor) | scripts/cibuild.sh
use new container path (#294)

Refactor cibuild.sh script
Remove reference to proto-25 container repository. This will let us remove that repository completely and move to a more unambiguous name.
Voldenet so yes, CurrentThreadScheduler is the way, this is useful to know 21:39
21:43 arunvickram left
Geth raku.org/dev: 628659896b | (Coleman McFarland)++ | scripts/cibuild.sh
use new container path (#294)

Refactor cibuild.sh script
Remove reference to proto-25 container repository. This will let us remove that repository completely and move to a more unambiguous name.		 21:45
22:03 arunvickram joined
Geth raku.org/dev: 5bb4a517a5 | (Coleman McFarland)++ | lib/Org/Home.rakumod
Another test of dev autodeployment
 22:04
bscan Hey all, I just added a code formatter to the Raku LSP if anyone is interested in kicking the tires on it. It's a fully custom formatter since I'm not aware of any maintained code formatters for Raku. Does anyone here use a formatter I'm not aware of? 22:57
marketplace.visualstudio.com/items...-navigator
nemokosch great news! 23:05
Voldenet it works well 23:08
hm, if you use multiple statements in one line, e.g. `my $x; $x++` they are still in one line after formatting 23:10
I'm not sure if it's intended
arunvickram that's awesome! thanks for your work bscan! 23:28
23:28 arunvickram left
ugexe Does it use RakuAST? 23:29
bscan I can look at the multiple statements in one line. Generally, I have it not do anything if it's unsure of what to do. Unfortunately, it does not use RakuAST yet. Is that ready? 23:43

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!