| 02:16:33 | * | Trix[a]r_za is now known as Trixar_za |
| 02:44:37 | * | fowl quit (Ping timeout: 245 seconds) |
| 02:46:17 | * | q66 quit (Remote host closed the connection) |
| 03:00:33 | * | Trixar_za is now known as Trix[a]r_za |
| 03:07:33 | * | Trix[a]r_za is now known as Trixar_za |
| 03:26:45 | * | Trixar_za is now known as Trix[a]r_za |
| 04:29:40 | * | OrionPK quit (Quit: Leaving) |
| 05:23:37 | * | xcombelle joined #nimrod |
| 06:43:35 | * | xcombelle quit (Read error: Connection reset by peer) |
| 06:52:34 | * | zahary joined #nimrod |
| 07:26:35 | * | zahary quit (Quit: Leaving.) |
| 07:29:25 | * | zahary joined #nimrod |
| 08:10:47 | * | zahary quit (Quit: Leaving.) |
| 08:17:01 | * | zahary joined #nimrod |
| 09:17:09 | * | zahary quit (Quit: Leaving.) |
| 09:29:11 | * | zahary joined #nimrod |
| 10:13:05 | * | q66 joined #nimrod |
| 10:35:24 | * | Trix[a]r_za is now known as Trixar_za |
| 10:50:11 | * | fowl joined #nimrod |
| 10:56:41 | * | xcombelle joined #nimrod |
| 10:57:16 | zahary | Araq, have you seen this already? https://trace.gl/docs.html |
| 10:57:36 | zahary | ah, skip the docs part: https://trace.gl/ |
| 10:59:59 | zahary | if you remembered, I argued about adding support for "debugging backwards in time". this is somewhat similar to what I had in mind in terms of implementation. |
| 11:02:32 | zahary | there are only a few additional features in the original "debugging backwards in time" video. I described them here: |
| 11:02:33 | zahary | https://github.com/codegl/tracegl/issues/42 |
| 11:02:33 | zahary | https://github.com/codegl/tracegl/issues/43 |
| 11:08:00 | Araq | zahary: haven't seen it before, looks interesting |
| 11:08:46 | Araq | though I'm skeptical ... the compiler's 'debug' already provides too much information |
| 11:09:23 | zahary | what do you mean by "too much" ? |
| 11:09:39 | zahary | too slow instrumentations? too much memory? too useful :) |
| 11:10:16 | Araq | well it prints the AST but that contains too much information, often I do debug(subtree) or in fact renderTree() |
| 11:11:18 | Araq | backwards watchpoints would be awesome though |
| 11:11:42 | Araq | (your issue 42) |
| 11:12:20 | zahary | well, this is how I debug too. but I have to recompile if I want to print something new and I have to be careful to print AST only for one file for example to not get too much spam (you probably have seen my if nimdbg: … templates) |
| 11:13:07 | Araq | yeah well I use: if n.info ?? "temp": debug(n) |
| 11:13:13 | zahary | with tracing, it should be easier to just run things once and then explore, slice and dice the trace output to find out everything about the code |
| 11:15:26 | Araq | true ... |
| 11:16:59 | Araq | unfortunately we still have no "write hook" in C backend |
| 11:17:53 | Araq | on the other hand there are lots of bugs because the lack of an effect |
| 11:18:10 | Araq | and tracing doesn't help with that much |
| 11:18:31 | Araq | "why hasn't this been transformed already?" |
| 11:19:07 | zahary | you can still get to the point where (before) it should have been transformed and start stepping through the code |
| 11:20:22 | zahary | in the original video, this is just like stepping though a normal debugger. in the trace.gl interface, "step over" takes you on the next line with the same indentation, "step out" in the next unnested line, etc |
| 11:30:46 | Araq | the red/green marking for conditionals is pretty cool too |
| 11:31:22 | zahary | yeah |
| 11:38:49 | * | Trixar_za is now known as Trix[a]r_za |
| 11:38:59 | zahary | to sum things up, debugging is about building a number of hypotheses about what the problem is and then testing them one by one. Possibly this involves recompiling the program to add additional output statements and re-running it carefully to pick the right places to set up breakpoints. Tracing allows you to have a strict superset of the capabilities of the regular debugger and you are able to test hypotheses without recompiling and re-running just by navigati |
| 11:40:12 | zahary | only the memory issue exists, but worst-case is that you record the trace in a ring-buffer and you don't have a complete history, but some smaller window |
| 11:42:43 | Araq | actually the real issue for Nimrod's C backend is runtime performance, not memory usage |
| 11:43:44 | Araq | a factor of 10-20 when running in ENDB is hardly acceptable :-/ |
| 11:44:26 | zahary | The beauty if nimrod is that it will be just a compilation option |
| 11:45:30 | zahary | I guess, I'll still you some mix of C debuggers for more realistic speeds, proper profiling, etc, but I can have a number of other debug modes |
| 11:46:07 | Araq | endb already supports 'push debugger: off/on' |
| 11:46:25 | zahary | in the code? |
| 11:46:38 | Araq | yeah |
| 11:47:02 | Araq | many modules in stdlib do that |
| 11:47:13 | Araq | as users rarely want to debug the stdlib ;-) |
| 11:47:56 | Araq | also things are now done via hooks, so you can write your own debugger in user code |
| 11:48:15 | Araq | and make it communicate via sockets |
| 11:52:14 | * | Trix[a]r_za is now known as Trixar_za |
| 11:53:07 | zahary | btw, If I have to speculate I think the run-time penalty will be something like x2 or x3. |
| 11:54:32 | Araq | well ... I never finished these refactorings but the plan is system/debugger provides an API that can be used for nimrod debuggers like endb |
| 11:57:28 | Araq | what do you mean "speculate"? "koch boot" takes 20s (1 run) "koch boot -d:release" 3s ... |
| 11:57:49 | zahary | yeah, for classic debuggers that's desirable. DBGp is a debugging protocol that's getting popular (there are plugins for ruby, python, perl, PHP, lua, etc) and it's supported in Komodo, vim, Notepadd++, Eclipse, etc. |
| 11:58:36 | zahary | the komodo guys are the most active supporters of it |
| 12:12:52 | Araq | the protocol looks sane but then aporia needs to parse xml responses ;-) |
| 12:14:22 | dom96 | I am willing to make that sacrifice for the sake of consistency :P |
| 12:23:13 | * | Trixar_za is now known as Trix[a]r_za |
| 12:29:38 | fowl | i wanted to do ludum dare but i forgot about it until a couple hours ago:/ |
| 12:33:48 | dom96 | aww. Do the extended one. |
| 15:13:48 | * | OrionPK joined #nimrod |
| 15:30:38 | zahary | hmm, how come fflush from C is not exported? |
| 15:40:42 | dom96 | zahary: http://build.nimrod-code.org/docs/system.html#558 ? |
| 15:41:36 | zahary | ah, thanks |
| 19:12:50 | * | xcombelle quit (Remote host closed the connection) |
| 20:35:52 | * | fowl quit (Read error: Connection reset by peer) |
| 21:41:37 | NimBot | Araq/Nimrod eb7a17a Araq [+1 ±1 -0]: new JS code generator |
| 21:50:36 | reactormonk | Araq, you extracted the type generation? |
| 22:31:01 | Araq | reactormonk: it's the type info generation |
| 23:08:49 | * | q66 quit (Remote host closed the connection) |