| 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
|
|||
