@tomstaijen That was not a very good explanation and I apologize. I am working on a Patch as I previously said for DI and within that I am adding some examples. So hopefully by tomorrow evening EST I should have something for you to look at.
@jcwrequests Thanks, it helped, found the resolver in de context's props. Eagerly waiting to see your patch. W.r.t. to lifetime, for now i'm working with singleton services and forced per-message lifetimescope (using Autofac's Func<Owned<T>>)
@rogeralsing that's super cool! How'd you make that?
here is a better one
played around with a "Walk" system message, that notifies a callback of its existence, and then do the same for its own children.. then I rendered the result in GraphViz
but it could be solve with proper monitor support instead, that would be better. if we have a
IMonitorLifecycle interface that gets called from the cell whenever a lifecycle event occurs, the one could plug that in there and get a realtime view :)
We should totally provide a debugger like this, like a vs debug extension. hover a system or actorref instance and get a full view of the system :)
yeah, I think that's a really cool idea
I took a look at @jcwrequests post on monitoring via AOP the other day
that's an idea I think we should explore more closely after 1.0 ships
considering #722 - I've created a test case for app.config HOCON string loading... but it passes anyway, config is loaded correctly
@/all for anyone interested in @jcwrequests's post about AOP for instrumenting monitoring in Akka.NET: http://www.message-flow.com/2015/01/monitoring-akkanet-based-systems.html
@Horusiath hmmm... can @jorgef replicate the issue?
because App.config loading is only automatic in
/dev right now
Akka.NET v0.8 on NuGet doesn't do it
I'm testing explicit loading with F#
Configuration.load() which is basically an alias for ConfigurationFactory.Load()
also, when @HCanber schedulers can be merged to dev branch?
@Horusiath as soon as we figure out why @HCanber's pull request makes the system load performance counter throw an
InvalidOperationException then I think we can move on
and merge it in
which is really weird, because his code doesn't even touch the performance counter definitions
at least in a way that's obvious
fu*k, I have to include JSON.NET converter for F#
Expr but the problem is... Akka.FSharp has no direct dependency to JSON.NET :D
@Horusiath why do you need that? do you need to do some special handling with the F# expressions?
expression-based deciders i.e.
but isnt the akka serializer mechanics enough to deal with that? do you need to do actual json parsing/writing/annotations?
but this is so minor feature, I think I'll drop this idea untill there will be something more justifying reason to include Expr support for JSON.NET
NetwonSoftJsonSerializer will not know how to serialize F# quotation expressions
only FsPickler does
oh, and we removed fspickler?
no, but it used on top-level only, as attached akka serializer
expressions being properties of serialized objects won't work with it
ah, that should probably be possible to solve using the surrogate mechanism now. eg. FSExpressionDecider (containing expressions) -> FSExpressionDeciderSurrogate containing expressions pre serialized by fs pickler and stored as a string base64 or whatever in the surrogate., then the other way around, turn the base64 string into expressions and recreate the FSExpressionDecider
yes, but still it will work only for special case (Deciders), while leaving potential hole for other types of messages using expressions