|
03:26
apogee_ntv left
03:27
apogee_ntv joined
|
|||
| patrickb | timo: In the current debugger impl, I'm essentially processing incoming events as a single stream of events. I rely on events not jumping the queue. This is made difficult by MVM-Remote splitting up incoming events into multiple streams. What's your opinion on adding a all-events supply that could be used alternatively? | 05:46 | |
|
06:39
kjp left
06:41
kjp joined
06:42
kjp left
06:43
kjp joined
12:04
[Coke]_ joined
12:07
[Coke] left
12:43
[Coke]_ is now known as [Coke][,
[Coke][ is now known as [Coke]
|
|||
| timo | feel free to put something like that in if it would help you | 15:06 | |
|
19:33
lizmat left
19:34
lizmat joined
20:44
lizmat left
20:46
lizmat joined
|
|||
| timo | 1st time I'm seeing spesh complain that the reverse postorder calculation failed :) | 21:46 | |
| I'm now fuzzing JSON::Fast and JSON::Tiny, which as you may notice are both written in raku, not nqp :) | 22:59 | ||
| with defered forkserver and persistent mode, the stability is garbage but the speed goes up and down between 1k and 3k execs per second | 23:00 | ||
| that's decent enough to actually fuzz something! | |||
| [Coke] | are you fuzzing the raku modules to catch stuff in moar? | 23:01 | |
| timo | right now i'm really just developing the ability of fuzzing code in general | 23:26 | |
| i think i saw two lyrids! | |||
| I currently don't have a commandline to build a nqp-m or rakudo-m that has ASan turned on, so it's not going to be very good at finding real hard crashes at all | 23:29 | ||
| do you have any idea in particular for what I should point the fuzzer at to maybe find something interesting in the fuzzing implementation itself, or the fuzzed thing? | 23:33 | ||