IRC channel logs
2023-01-05.log
back to list of logs
<dthompson>Zarutian_iPad: no this is just for local vats. baby steps. <flatwhatson>would be neat to then be able to do introspection on things like current actors, in-flight messages, traces/logs <Zarutian_iPad>that is, you might be leaking information you did not want to leak <dthompson>yeah, it's something to consider. those sorts of issues are for a later phase of development where we harden the underlying language implementation. I'm not doing it here but we could narrow the view of the stack to restrict what can be seen in the debugger. <flatwhatson>something like (call-with-hidden-stack thunk) might be an option to protect sensitive calls <flatwhatson>also wrapping unmentionable values in a way that can be detected by your stack builder <dthompson>yeah that would be cool. good stuff to think about. <Zarutian_iPad>flatwhatson: that is the way of hiding secrets. Think of it more like not generating metadata for your asversary <Zarutian_iPad>could just stick the stack object into an vat local only sealed box though <flatwhatson>right, i'm thinking from my payments/banking background where leaking customer info to operators is v.bad <flatwhatson>but it's not adversarial exactly. would an adversary get your stack trace anyway? <Zarutian_iPad>and I was thiniking of this from the perspective of trying to minimize data leakage lick those used by locksporters to pick the lock <Zarutian_iPad>via captp op:listen on an eventual promise that gets smashed/rejected/#failed by something <dthompson>for now, we leave the current process environment out of our scope of work. we'll get there eventually. :) <isd>The idea being that when an exception crosses a CapTP boundary, you don't include the stack trace, but you can generate a randomized trace id, log the stack trace somewhere, and return the trace id to the caller. This way the caller doesn't have access to your part of the stack trace, but if the debugger has the necessary authority, it can aggregate log entries to reconstruct the full stack trace across multiple vats <isd>I'm not familiar with Causeway, but it's mentioned several times in that thread so I assume yes. <drakonis>so, when are we getting a spritely powered slime? <jfred>Oh that's so cool! More convenient than even the bootstrap helpers <cwebber>dthompson is starting research into thinking about our version of a distributed debugger (causeway inspired, but we're thinking of some other things too), codename "questie" <cwebber>same name as on the spritelyproject.org page's "monster manual" set of creatures <cwebber>but it'll probably be part of guile-goblins core <cwebber>as will Aurie, which was a separate library in racket-goblins <cwebber>,enter-vat changes the game of understandability so much <drakonis>will it judiciously steal from cl's debugging experience? <cwebber>it would be nice for us to steal from CL's debugging, but that's more making the baseline guile debugger better <dthompson>the distributed debugger is more about capturing events and information such as when those events occurred and providing tools to sift through that data to identify the source of bugs. <cwebber>but dthompson is not being restricted to just those ideas, and we *hope* that the actormap snapshot/restore can make our distributed debugging infrastructure very poserful :) <civodul>re distributed debugging, hop (https://hop.inria.fr) was/is able to display cross-stage backtraces: a backtrace where you see both client code (Scheme compiled to JS running the browser) and server code <dthompson>civodul: thanks for the pointer. another place to look for inspiration.