|
04:42
[Coke] left
|
|||
| patrickb | timo: This is very interesting. I guess the back ofy brain will mule over this the next few weeks on how best to put this to use. Thanks! | 05:13 | |
| Different topic: I want to build an index mapping all variables in a project and dependent projects to their type. The presumably best idea so far is to somehow log types while running the executable under debugging. | 05:15 | ||
| This is pretty fuzzy though. There are many unanswered questions. | |||
| Is there any chance this can run sufficiently fast when doing the logging in the debug client? (i.e. Break on every scope change and look at stuff.) | 05:17 | ||
| Or should I rather stop the world every now and then (e.g. the GC) and do a full heap inspection? | 05:18 | ||
| When running a typical program, will the rate of yield be good enough to inform an auto-complete functionality and not be annoying? | 05:27 | ||
| I'm very fuzzy on this idea. I think the idea might be good, but I have no plan whatsoever. | 05:28 | ||
| Any opinions welcome! | 05:29 | ||
|
05:47
Pixi joined
|
|||
| japhb | Certainly Rakudo already has a way to inspect the variables visible to a given scope (otherwise typo error messages wouldn't work). I would guess the harder part of what you want is enumerating all the scopes in a project and its dependencies. | 06:05 | |
| patrickb | Hm. I would have guessed this to be pretty easy. I suspect this means I know too little. :-P | 06:08 | |
| japhb | Comma may have done this already, but my thinking is that most of our introspection capabilities are based on either following lexical and dynamic scopes *up* from a given location, or package scopes *down*. The latter would be easy peasy. The former is less obvious from an enumeration point of view, though I wouldn't put it past lizmat++ to already have a module for this ... ;-) | 06:14 | |
|
06:34
[Coke] joined
08:08
finanalyst joined
09:41
finanalyst left
|
|||
| timo | the information necessary for typo suggestions is used at compile time. some lexical variables are lowered to local variables by the optimizer, so we may be losing information there | 16:53 | |
| using the information from compile time is tricky for the same reason why Grammar::Debugger can't easily be used to debug regexes inside the core setting or something, because you can't just re-do the compilation for the core setting after the fact or something like that | 17:14 | ||
|
18:15
finanalyst joined
|
|||