🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
SmokeMachine it seems I found it 00:03
00:06 lichtkind left
SmokeMachine I was able to add the code... but now it seems the CONTROL is not working when I add it manipulating the AST, but it does work without manipulation... I ran the origibnal code, printing the DEPARSE of $*CU after the manipulation, CONTROL did not work. I copied the code printed and tried with that, that worked... 00:41
usercontent.irccloud-cdn.com/file/...3%402x.png
the code with no AST manipulation works: glot.io/snippets/hag5kjollc 00:45
.tell lizmat can it be some bug on RakuAST? irclogs.raku.org/raku/2025-08-24.html#00:41 00:47
tellable6 SmokeMachine, I'll pass your message to lizmat
SmokeMachine E can it be related to this? github.com/rakudo/rakudo/issues/4227 00:58
01:10 phogg left 01:12 ecocode___ left 01:41 phogg joined 02:15 jgaz left 02:37 gugod left 02:40 gugod joined 02:45 topnep left 02:46 topnep joined 03:22 gugod left 03:40 gugod joined 03:59 stanrifkin joined 04:00 stanrifkin_ left 04:36 Aedil joined, El_Che left 04:37 El_Che joined 06:15 kylese joined 06:25 kylese left 06:29 kylese joined 06:51 _________ joined 06:56 topnep left 06:58 topnep joined 07:14 Guest85 joined, wayland joined 07:15 Guest85 left, wayland76 left 07:27 kylese left 07:30 kylese joined 08:02 Sgeo left 08:47 Sgeo joined
lizmat SmokeMachine: could well be 08:48
tellable6 2025-08-24T00:47:11Z #raku <SmokeMachine> lizmat can it be some bug on RakuAST? irclogs.raku.org/raku/2025-08-24.html#00:41
08:49 greppable6 left, greppable6 joined 08:52 coverable6 left, coverable6 joined 08:54 notable6 left, notable6 joined 09:00 nativecallable6 left, nativecallable6 joined 09:16 kylese left 09:18 kylese joined 09:30 lichtkind joined 10:12 apac joined 10:17 Aedil left 10:22 apac left 10:36 Sgeo left 10:49 librasteve_ joined 11:07 topnep left 11:09 topnep joined 11:19 bartolin left 12:00 Guest2599 left 12:01 Guest1983 joined 12:08 guifa joined
guifa o/ 12:08
I'm suddenly getting a SIGTRAP when working with some nativecall stuff. It seems to be caused by using anything that delays execution (sleep, react whenever, etc). Long shot I know, but has anyone seen that or have any ideas what it might be? 12:10
lizmat no, but if you can make a repeatable case, then please make that a MoarVM issue 12:13
12:26 thatonelutenist left, thatonelutenist joined 12:28 tinita joined
guifa lizmat: I'll try to isolate it down. It seems to have suddenly cropped up. My best guess is it has something to do with the ObjC run loop I kick off in a start { init-obj } block, but it was working last week so I dunno. GOing to keep playing around with it 12:34
lizmat ++guifa
guifa hmmmm.... seems like it might not be the runloop itself. Golfing it down it's not the run loop in and of itself, but something else. Ugh this is gonna take a while to isolate 13:01
13:04 kylese left 13:07 kylese joined 13:49 librasteve_ left
Voldenet hm maybe ui code is sometimes running on a different thread in thread pool? 13:59
since react whenever may change threads 14:00
m: my $x = Channel.new; my $r = start { say $*THREAD; react whenever $x { [$_, $*THREAD].say; await Promise.in(.2); }}; for ^5 { start { loop { await Promise.in(.1) }}}; for ^10 { $x.send($_); }; $x.close; await $r # example 14:01
camelia Thread #4 (GeneralWorker)
[0 Thread #4 (GeneralWorker)]
[1 Thread #9 (GeneralWorker)]
[2 Thread #6 (GeneralWorker)]
[3 Thread #6 (GeneralWorker)]
[4 Thread #4 (GeneralWorker)]
[5 Thread #9 (GeneralWorker)]
[6 Thread #4 (GeneralWorker)]…
Voldenet and as I'm testing, it's difficult to reliably prevent that 14:20
guifa Voldenet: that would have been my first thought, except that I know it was working before
Voldenet `my $*SCHEDULER = CurrentThreadScheduler.new;` is simply not enough
guifa I had recently done some readjusting to how I distributed code across the various controllers/delegates 14:21
it seems *somewhere* there was something I was doing in my old NSApplicationDelegate that was causing issues
But I'm not really using that anymore at all, so I just zeroed out all the old code and now it's literally just an plain NSObject that declares itself to implement NSApplicationDelegate 14:22
and voila everything works
Voldenet hmmmmmmmmmmm 14:23
m: use v6.c; my $x = Channel.new; my $r = start { say $*THREAD; react whenever $x { [$_, $*THREAD].say; await Promise.in(.2); }}; for ^5 { start { loop { await Promise.in(.1) }}}; for ^10 { $x.send($_); }; $x.close; await $r # example
camelia Thread #4 (GeneralWorker)
[0 Thread #4 (GeneralWorker)]
[1 Thread #4 (GeneralWorker)]
[2 Thread #4 (GeneralWorker)]
[3 Thread #4 (GeneralWorker)]
[4 Thread #4 (GeneralWorker)]
[5 Thread #4 (GeneralWorker)]
[6 Thread #4 (GeneralWorker)]…
guifa anyways, it's all fixed now for me (I think) so back to slowly uncommenting stuff and checking it all works 14:25
Voldenet so apparently since v6.d sleep is able to change the thread 14:26
what's scary is that it doesn't seem to respect $*SCHEDULER 14:28
I'm not sure if it's buggy, but it doesn't feel right 14:29
m: my $x = Channel.new; my $r = start { my $*SCHEDULER = CurrentThreadScheduler.new; sub a { ["r", $*THREAD.id].say }; a; react whenever $x { a }}; for ^20 { start { loop { await Promise.in(.01) }}}; start { my $*SCHEDULER = CurrentThreadScheduler.new; sub a { ["s", $*THREAD.id].say }; a; for ^10 { a; $x.send($_); await Promise.in(.1); }; $x.close; }; await $r 14:38
camelia [r 4]
[s 6]
[s 6]
[r 4]
[s 6]
[r 11]
[s 6]
[r 11]
[s 6]
[r 4]
[s 6]
[r 9]
[s 6]
[r 9]
[s 6]
[r 9]
[s 6]
[r 4]
[s 6]
[r 4]
[s 6]
[r 9]
Voldenet my question is: since both blocks use $*SCHEDULER = CurrentThreadScheduler, shouldn't both sender and receiver stay the same? 14:39
or is Channel wrong concurrency primitive to use here 14:42
14:54 Aedil joined 16:19 ntv left 17:25 topnep left 17:27 topnep joined 17:31 Sgeo joined 18:38 summerisle joined 19:12 itaipu left 19:29 itaipu joined 19:35 ecocode___ joined 19:49 itaipu left 19:52 itaipu joined 20:09 apac joined
tbrowder y'all should consider the new issue i just filed with App::Mi6. might be good for Raku marketing. 20:28
lizmat link? 20:29
tbrowder i've created a doc only repo and used hidden Makefiles and rakumodoc files 20:30
i'll do that in a sec. i always grab the wrong thing to paste... 20:31
github.com/tbrowder/Mi6-Helper/issues/20 20:34
^^^
arg not that one 20:35
github.com/skaji/mi6/issues/186 20:37
^^^ that one 20:38
20:40 apac left
tbrowder rakumodoc =>Rakudoc 20:42
my family is calling the old folks home... 20:43
20:43 DarthGandalf left, DarthGandalf joined
SmokeMachine tbrowder: sorry, I’m curious. Why is dist.ini making that usage not possible? 21:47
tbrowder well, i'm not sure it truly is, but the issue is moot now because .X files are not hidden on github's public repos 22:17
22:22 guifa left
tbrowder but i will reframe the issue because i want to put all files to be "hidden" in a single directory with a suitable name. that would include a dist.ini file in some subdirectory. 22:22
i would like to call "mi6 build" at the top level where the dist.ini file is in that directory. 22:24
correction: the "dist.ini" file would be in a subdirectory 22:25
ok, old issue closed, new issue filed. 22:42
22:45 guifa joined 22:49 stanrifkin left 22:51 stanrifkin joined, stanrifkin left 22:52 wayland left 22:58 Aedil left 23:24 guifa left 23:32 lichtkind left 23:56 itaipu left

Powered by Cro and the Raku® Programming Language.

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

Thank you!