| lizmat | afk& | 00:01 | |
|
00:03
finanalyst left
|
|||
| timo | a good chunk of time during startup is spent deserializing objects. you would assume / hope that some portion of those are not actually necessary and there may be ways to prevent some of that work from being necessary | 00:13 | |
| ok, we actually first check if getcurhllsym("module_loader") is null before we attempt to loadbytecode ModuleLoader, i wonder if we register the module loader a bit too late in the right hlls so we don't get it from its hll symbol every time? | 00:21 | ||
| huh, v6d.bootstrap.moarvm seems rather tiny | 00:22 | ||
| okay what on earth is going on here haha | 00:29 | ||
| in bootstrap.c/BOOTSTRAP.nqp there's the "my class BOOTSTRAPATTR" at the top | |||
| it has a bunch of methods that are basically accessors, so like `method box_target() { $!B | |||
| `method box_target() { $!box_target }` | 00:30 | ||
| the bytecode we generate for it is basically: | |||
| checkarity 1,1; param_rp_o loc_2_obj, 0; paramnamesused | |||
| and then 8 times in a row: loadlib "libperl6_ops_moar.so", "libperl6_ops_moar.so"; loadext "libperl6_ops_moar.so", "Rakudo_ops_init"; | 00:31 | ||
| 27 times in a row in the case of `method name() { $!name }` | 00:32 | ||
| no, that is actually `method type() { $!type }` that has 27 | 00:33 | ||
| it actually looks like we've also compiled these methods a whole bunch of times? | |||
| there are 34 frames in the moar bytecode file named "dimensions" | 00:34 | ||
| each one has one more instance of loadlib + loadext than the previous one | 00:35 | ||
| that's pretty funny | |||
| did the latest nqp revision bump go wrong? i have the very latest nqp but here it shows up as 2024.12-4-g31d5cc698 instead of the 2024.12-5-g9a843dc6e we ask for in the nqp revision file | 02:03 | ||
| ... i was on a branch | 02:04 | ||
| guifa | timo: happens to the best of us | 02:11 | |
| timo | well, complaining on IRC is by far the most effective way to immediately find the source of the problem yourself :) :) | 02:13 | |
|
02:13
djinni` left
|
|||
| guifa | 99% of problems are solved by complaining about them | 02:13 | |
| and then immediately finding the solution | |||
| if you hadn't've said anything, it would never have been solved | |||
| timo | i'm sure that's true | 02:15 | |
|
02:34
djinni` joined
07:59
finanalyst joined
10:26
sena_kun joined
10:29
sena_kun left
10:31
sena_kun joined
|
|||
| SmokeMachine | Hi! Would someone say this is a bug? www.irccloud.com/pastebin/LupEUlFX/ | 12:06 | |
| this is related to this: github.com/FCO/Cromponent/pull/9 Does any one have any idea on what's happening here? I am manipulating the EXPORT, so it is probably my fault... But I'm not sure if this kind of error should be thrown (`lang-call cannot invoke object of type 'VMNull' belonging to no language at line` (with no line number)) | 12:09 | ||
| lizmat | that is typically a problem with something not being initialized properly | 12:11 | |
| m: use nqp; BEGIN nqp::null()() # like this | 12:12 | ||
| camelia | ===SORRY!=== Error while compiling <tmp> An exception X::Comp::AdHoc occurred while evaluating a BEGIN: lang-call cannot invoke object of type 'VMNull' belonging to no language at <tmp>:1 Exception details: ===SORRY!=== Error while compili… |
||
| SmokeMachine | oh! when trying to run that as a function() | 12:13 | |
| s/"()"/?/ | |||
| should a raku only code (messing with EXPORT) be able to do that? | 12:15 | ||
| lizmat: ^^ | 12:16 | ||
| lizmat | if it exports an nqp::null as a Callable somehow, yes | ||
| although it probably should complain :) | 12:17 | ||
| SmokeMachine | it's not using nqp directly... but it's using Cro template's compilation and exporting it... | 12:22 | |
| ok... I think the problem is being thrown by the template compilation... | 12:25 | ||
| lizmat | yeah, that may do some NQP stuff under the hood | ||
| Geth | rakudo/main: 3265ff3bb6 | (Elizabeth Mattijsen)++ | docs/dispatchers.md Update documentation of recently added syscalls |
12:38 | |
|
13:41
guifa left
13:57
finanalyst left
13:58
finanalyst joined
|
|||
| SmokeMachine | lizmat: it seems my problem is not related to nqp... | 14:11 | |
| but to when this code is EVAL()ed... I have no idea why... www.irccloud.com/pastebin/cf3unkeS/ | |||
| any suggestion? | 14:16 | ||
| ab5tract | SmokeMachine: I wonder if breaking down some of the embedded logic into subs would help isolate the issue? | 14:47 | |
| SmokeMachine | ab5tract: I'm trying to do that... but it's not so eazy... | 14:53 | |
| ab5tract | :( | ||
| Does it need to be BEGIN? | 14:54 | ||
|
14:55
librasteve_ joined
|
|||
| SmokeMachine | ab5tract: not sure... that's generated by Cro template's compilation... | 14:55 | |
| ab5tract | Ah! Okay, that helps explain why it looks like generated code ;) | 14:56 | |
| So… one approach you might explore would be to compare the QAST of this code vs a smaller, working generated template | 14:57 | ||
| Ee, “compiled” template | |||
| SmokeMachine | and it works if I use the module Todo (that exports that code), but it doesn't if I use a module that uses Todo... | ||
| ab5tract: may this help on context? github.com/FCO/Cromponent/pull/9 | 15:00 | ||
| I'm extremaly lost... and I don't know where to go from here... | 15:04 | ||
| The only difference from the code that works | 15:15 | ||
| The only difference from the code that works to the code that does not work is the order on the prelude (that comes from a hash, so it may always be different)... usercontent.irccloud-cdn.com/file/.../image.png | 15:17 | ||
| Any suggestion? I'm really lost... :( | 15:23 | ||
| ab5tract | Checking but simultaneously engaging with rambunctious nephews | 15:26 | |
| Smoke | |||
| SmokeMachine: it’s a long shot but does switching to -I. change anything? | 15:28 | ||
| SmokeMachine | Thanks! | ||
| let me try... | |||
| ab5tract: no luck... :( | 15:30 | ||
| ab5tract | Boo :( | ||
| SmokeMachine | ab5tract: but, please, don't let me to be between you and your nephews | 15:31 | |
| If I run `todo-routes.rakumod` as if it was a script (`raku -I. -Ibin/lib bin/lib/todo-routes.rakumod`) it works as expected... | 15:44 | ||
| I recuded `Todo` to a minimal, and now it id just creating an empty `__TEMPLATE_SUB__Todo`... it still breaks if using `todo-routes` | 15:46 | ||
| This is the generated code now: www.irccloud.com/pastebin/o2IPxffA/ | 15:47 | ||
| it seems that if I remove the prelude it works... | 15:52 | ||
| But the code becomes only this: www.irccloud.com/pastebin/GCMjGOqq/code.raku | 15:53 | ||
| No... I was wrong... that doesn't wor... but the error changes... | 15:56 | ||
| www.irccloud.com/pastebin/ugSKj3o0/ | 15:57 | ||
| ab5tract | Oh, that’s kind of interesting! | 15:58 | |
| SmokeMachine | www.irccloud.com/pastebin/DEm4ECEq/ | 16:00 | |
| any idea of what could cause this missing or wrong version of dependency? | 16:01 | ||
| but it's after compiling... | 16:02 | ||
| ab5tract | SmokeMachine: no idea :( | 16:15 | |
| Have you tried any of these variations with RakuAST enabled? | |||
| SmokeMachine | no, I didn't... let me try now... | 16:16 | |
| jdv | what is the state of the ast effort? is it the gnarly bits left? | ||
| SmokeMachine | ab5tract: no luck... even if I --target=ast, it dies on begin time... :( | 16:19 | |
| ab5tract | That’s a good question actually. I think nine++ was actually tackling things in sort order of spectests. This was intended to reduce the chances of “big” things being left to the end / the dark side of pareto | 16:20 | |
| SmokeMachine | and remofint the prelude did't work either... | ||
| ab5tract | I’m considering picking things back up in the new year. I figure if I do anything sub optimally, it may act as a summoning spell :) | 16:21 | |
| SmokeMachine: I’ll try to clone and poke at it at some point today | |||
| It’s the code from the PR you linked earlier? | 16:22 | ||
| SmokeMachine | ab5tract: thank you very much! I'll commit som comments pointing to the prelude removal... | ||
| yes | 16:23 | ||
| ab5tract | Cool :) | ||
| SmokeMachine | ab5tract: the PR: github.com/FCO/Cromponent/pull/9 | 16:32 | |
| ab5tract: the comment: the comment: github.com/FCO/Cromponent/pull/9/f...1R140-R165 | 16:33 | ||
| lizmat | Question: should | 16:56 | |
| raku -e '' | |||
| be *writing* out any bytecode ? | 16:57 | ||
| timo ^^ ?? | 16:59 | ||
| according to the MVM_COVERAGE_LOG of raku -e '' | |||
| it spends a log of time in NQP::src/vm/moar/QAST/QASTCompilerMAST.nqp | 17:00 | ||
| writing headers and frames | |||
| timo | yeah we can't run code without writing a compunit and loading it into moar | 17:07 | |
| it should only go into a buffer, not a file, though | |||
| please be aware that the overhead of the coverage log is probably significant, and not every line takes the same amount of time, so using it to estimate how much time is spent in one place is not reliable | 17:11 | ||
| SmokeMachine: with MVM_COVERAGE_LOG=blabla.txt and MVM_COVERAGE_CONTROL=2 you'll get a file with every line everywhere that is run, so you'll also get lines before the mysterious error happens | 17:15 | ||
| it might become very big, however | |||
| without the COVERAGE_CONTROL, the same line should only appear a few times, rather than every time it's run | 17:17 | ||
| SmokeMachine | timo: thanks! I'm trying to understand the generated file... | 17:39 | |
| that's huge | 17:40 | ||
| 11790681 lines | 17:41 | ||
| timo | yeah | 17:44 | |
| just look at the last few hundred | 17:45 | ||
| ignore the first few million | |||
| SmokeMachine | from back to front, 17 hits on SETTING::src/core.c/Exception.rakumod (on different lines); 19 hits on SETTING::src/core.c/Rakudo/Internals.rakumod (lines 1823, 1825, 1828, 1806, 1805 and 1804); 5 hits on src/vm/moar/dispatchers.nqp on lines (1825 and 1835); 5 hits on SETTING::src/core.c/Int.rakumod (line 78); 6 hits on src/vm/moar/dispatchers.nqp (lines 1817, 1821, 1825); 16 hits on SETTING::src/core.c/List.rakumod (lines 492 | 17:57 | |
| and 493); 2 hits on SETTING::src/core.c/Rakudo/Internals.rakumod (lines 1819 and 1823); thousands of hits on SETTING::src/core.c/IO/Handle.rakumod (line 37); | |||
| timo | that's probably in big parts the printing of the exception | 17:58 | |
