| Geth | MoarVM: ugexe++ created pull request #1875: Do not persist tokens in CI artifacts |
01:40 | |
| MoarVM: MasterDuke17++ created pull request #1876: Fix format specifiers clang on OSX complains about |
01:52 | ||
| MoarVM/main: afc8354b0f | (Nick Logan)++ (committed using GitHub Web editor) | .github/workflows/build_release.yml Do not persist tokens in CI artifacts |
08:34 | ||
| MoarVM/main: 4ca3abdaad | (Patrick Böker)++ (committed using GitHub Web editor) | .github/workflows/build_release.yml Merge pull request #1875 from ugexe/patch-23 Do not persist credentials in CI artifacts |
|||
|
10:18
sena_kun joined
11:50
timo1 is now known as timo
|
|||
| timo | have we ever considered if we should try treating exception handling like an optimizable dispatch? | 12:07 | |
| if we have a code path where the exception handler happens to be the same every time, and we invoke it very often for some reason? like i guess a loop where you "next" often would be such a case, or using "warn" when you never have a custom CONTROL block in use you'd hit the default one every time ... a bare "try" without an explicit handler so it just returns Nil could hit his case too? | 12:09 | ||
| we would still have to look upwards in the stack to find the actually relevant exception handler that is responsible, but we'd "just" guard on that i guess | 12:10 | ||
| and it would very much have to be good at not duplicating that work in the case we miss, and however we do it must not be slow for the general case | 12:12 | ||
| lizmat | I think that's a great idea (if it isn't already implemented :-)) | 12:18 | |
| timo | i'm not deeply familiar with exception handling right now | 12:38 | |
| can i just say i o | 12:43 | ||
| love the concept of "trampoline" in code | |||
| jnthn | It's not optimized like that, but there is some handling that can rewrite control exceptions into gotos | 13:42 | |
| timo | oh, nice to see you jnthn! :) | 13:45 | |
| right, i know about the goto rewrite. that currently only happens when the handler action is goto and the goto target is in the same piece of code, AIUI | |||
| and i'm hoping that if the actually invoked handler tends to be monomorphic, it could get inlined and also "become" a goto with a little bit of necessary extra setup and teardown perhaps | 13:46 | ||
| perhaps setting up spesh logging for invoked exception handler and seeing what spread of targets we tend to see is a good first step just for investigation purposes | 13:47 | ||
| re-reading some 6guts posts made me realize I definitely miss your puns. "That goes in the resumption hole" ehehe | 13:52 | ||
| Geth | MoarVM: patrickbkr++ created pull request #1877: GH Actions: Remove the deprecated macos-12 runner |
||
| MoarVM/main: 1f5bf40904 | (Patrick Böker)++ | .github/workflows/build_release.yml GH Actions: Remove the deprecated macos-12 runner Add macos-14. Also for good measurereplace ubuntu-20.04 with ubuntu 24.04. |
14:22 | ||
| MoarVM/main: 9ed81b24a6 | (Patrick Böker)++ (committed using GitHub Web editor) | .github/workflows/build_release.yml Merge pull request #1877 from patrickbkr/no-macos-12-in-ci GH Actions: Remove the deprecated macos-12 runner |
|||
|
16:38
unicodable6 left,
unicodable6 joined
|
|||
| timo | i have only looked further at it now, but running handlers goes via MVM_frame_dispatch with spesh_cand == -1, which does put an invocation log entry already | 20:19 | |
| (that is, if it's an MVM_EX_ACTION_INVOKE handler) | 20:20 | ||
| oh, that is a log that the frame got entered, not what it got entered from? | 20:21 | ||
| for that i would want a separate MVM_spesh_log_bytecode_target i believe | 20:22 | ||
| (and of course it's only useful for cases where the exception-causing op is actually in the frame, not one or more levels down) | 20:53 | ||
|
22:54
sena_kun left
|
|||