| 16:38:25 | * | NimBot joined #nimrod |
| 16:38:30 | Araq | it's nice for the "embedded debugger" too |
| 16:38:44 | Zor | what's that? |
| 16:39:20 | Araq | the language supports pragmas like {.breakpoint.} and {.watchpoint: myVariable.} |
| 16:39:56 | Araq | which cause the codegen to insert certain runtime calls for the debugger |
| 16:40:13 | Zor | does it integrate with gdb or do you have your own debugger? |
| 16:40:27 | Araq | my own debugger ;-) |
| 16:40:58 | Araq | we have "integration" with gdb by emitting #line directives |
| 16:41:37 | Araq | so yeah; there are 2 somewhat incompatible debuggers |
| 16:41:58 | Zor | I guess your debugger lives mostly in the runtime? and you have a separate program that attaches to it? |
| 16:42:01 | Zor | or something like that? |
| 16:42:12 | Araq | it's worse than that ;-) |
| 16:42:45 | Araq | the debugger is completely in the runtime and thus in the same address space |
| 16:43:05 | Araq | so if your corruption is bad enough the debugger can't help you ... |
| 16:43:09 | Zor | ah... |
| 16:43:20 | Zor | well, cooperative debuggers will always have that weakness |
| 16:43:34 | Zor | no matter if they allow remote attaching or not |
| 16:43:56 | Araq | true but remote attaching would be very cool |
| 16:44:24 | Araq | I guess I should export some API so somebody can do that without hacking the stdlib |
| 16:45:30 | Zor | could just use a simple tcp-based thing |
| 16:45:45 | Zor | and have something like a NIMROD_DEBUG_LISTEN=address:port env var |
| 16:46:12 | Araq | the embedded debugger is also quite slow; factor 4 or something iirc |
| 16:46:42 | Araq | though it's hard to tell as most of the slowdown is caused by the line tracing |
| 16:47:08 | Araq | however I played with GDB software emulated watchpoints once |
| 16:47:10 | Zor | how does the debugger grab locals? |
| 16:47:29 | Araq | and they are far worse :-) |
| 16:47:41 | Zor | do you instrument the program with a (slow) complete shadow stack in debug builds? |
| 16:48:35 | Araq | yes but it's not that slow as the shadow stack lives on C's stack |
| 16:48:54 | Araq | you lose any registerization etc. |
| 16:49:24 | Araq | you get 'frame->var' instead of 'var' in the C code |
| 16:49:57 | Zor | how do you store it on the C stack btw? |
| 16:50:13 | * | FreeArtMan joined #nimrod |
| 16:51:38 | Araq | void f() { struct { void* parent; locals_here; } frame; frame->parent = tos; tos = &frame; ... } |
| 16:51:52 | Araq | where 'tos' is a thread local variable |
| 16:52:53 | Zor | how does the debugger know where to look in the locals_here for a particular var? |
| 16:53:25 | Araq | good question :-) |
| 16:53:53 | Araq | the frame also contains RTTI describing the layout |
| 16:53:58 | reactormonk | have fun with optimized away variables |
| 16:57:56 | Zor | by the way, does nimrod have a debug { ... } statement-ish thing |
| 16:57:58 | Zor | +? |
| 17:00:36 | Araq | reactormonk: the C compiler can't optimize away the variable :P as it would change the semantics |
| 17:00:58 | reactormonk | Araq, hm. |
| 17:01:12 | reactormonk | Araq, never had an 'optimized away' with the gdb? |
| 17:01:41 | Araq | Zor: yeah there is debugEcho or the more general 'when not defined(release)' |
| 17:02:24 | Araq | reactormonk: the shadow stack inhibits such optimizations |
| 17:03:27 | reactormonk | Araq, ok |
| 17:06:49 | Araq | Zor: there is no real debug mode in nimrod; instead it's much more finely grained |
| 17:07:16 | Araq | you can query if a certain runtime check is enabled/disabled or a user defined symbol exists etc. |
| 17:08:16 | Araq | 'debugEcho' is not restricted to debugging, it pretends it has no side effects so that it can be used in pure functions; somewhat like UnsafeIO in Haskell |
| 17:09:31 | Araq | and the shadow stack can be en-/disabled on a per function basis |
| 19:02:57 | * | Trixar_za is now known as Trix[a]r_za |
| 19:05:22 | * | FreeArtMan quit (Quit: rm -rf /) |
| 19:05:38 | * | FreeArtMan joined #nimrod |
| 19:20:51 | * | FreeArtMan quit (Quit: rm -rf /) |
| 20:32:15 | * | xcombelle quit (Read error: Connection reset by peer) |
| 21:00:33 | * | gradha joined #nimrod |
| 21:16:56 | gradha | didn't even know we have a mascot www.facebook.com/nimnimrod |
| 21:17:16 | gradha | still no sunset |
| 21:21:59 | dom96 | I wonder what language that is |
| 21:25:09 | gradha | looks hebrew |
| 21:38:29 | * | gour quit (Quit: WeeChat 0.4.0) |
| 21:44:10 | dom96 | " gradha started following dom96 a minute ago " |
| 21:44:14 | dom96 | How nice of you :P |
| 21:44:33 | gradha | yeah, just realizer I wasn't stalking enough people, no wonder my facebook is empty |
| 21:45:51 | gradha | are you going to theme Aporia to its new logo? |
| 21:46:18 | dom96 | as soon as filwit creates one I like, sure. |
| 21:46:58 | gradha | you need splash screens |
| 21:47:27 | dom96 | yes, and 10 minutes loading times! |
| 21:48:14 | gradha | I worked at a place where a common internal tool would launch and loudly play some Tom Jones clip |
| 22:01:51 | Araq | gradha: XD |
| 22:01:59 | Araq | highly professional ... |
| 22:05:18 | gradha | the tool was named tomcat, IIRC the logo was the face of a cat fading to an F14 |
| 22:06:26 | Araq | the tomcat server? |
| 22:06:59 | gradha | no, it was a videogame toolchain, one of the few public references can be found at http://www.shawnhargreaves.com/cv.html, page of the lead programmer |
| 22:09:22 | Araq | wow the guy who developed Allegro |
| 22:10:01 | gradha | most people confuse that with common listp |
| 22:10:19 | Araq | Abuse? |
| 22:10:50 | gradha | http://www.franz.com/products/allegrocl/ |
| 22:11:07 | gradha | at least I was told CL stands for common listp, IIRC |
| 22:11:35 | gradha | once I gave a talk on programming with Allegro and people from lisp showed up, were confused as hell |
| 22:12:02 | gradha | there isn't much functional programming in blitting sprites |
| 22:12:19 | Araq | oh yeah I heard about that allegro Lisp environment |
| 22:12:24 | Araq | never used it though |
| 22:12:36 | Araq | well I didn't use much Lisp anyway |
| 23:00:22 | gradha | looks like strutils could grow a toOctal proc accepting integers rather than chars |
| 23:02:14 | gradha | oh, maybe toOct does that |
| 23:06:30 | * | gradha quit (Quit: bbl, have youtube videos to watch) |