Whitebox (profiler) ... again

[nblumhardt]

Hello all-

I've just updated Whitebox (http://whitebox.googlecode.com) to work with Autofac 3.1. I'll publish nupkgs when I get a chance.

Enough time's passed now that I think it is unlikely we'll get enough momentum up to realise the original Whitebox vision as a full-fledged profiling tool (happy to be proven wrong ;)).

The issues for me seem to be:

• Apps take a lot of work - there are many usability issues, presentation issues, installation, configuration and so-on that take dedicated grunt work to cover
  
• WPF skills are a bit thin on the ground
• The connectivity model is going to need a lot more work to suit debugging scenarios - local named-pipes connectivity is fine but isn't enough for the long haul

So, I have a new proposal - tailored to match the time I have available to invest in it...

• Leave the Whitebox project where it is
• Grab the internal analysis engine - lifetime scope reconstruction, warnings, etc., and bring these over to create a new Autofac.Analysis assembly
• Build a simple client assembly Autofac.Analysis.Writer (?) that dumps analyses to a file or STDOUT
• Allow others to use the analysis assembly to write better tools/visualizers (like Whitebox) if they want to :)
• I'd consider writing an adapter to push events to Serilog, which could then shuttle them elsewhere for viewing

The total burden on the Autofac project would be a lot smaller than taking Whitebox as a whole - just a couple of library assemblies and some tests - but then hopefully we'd have a simple drop-in solution for those like my client last week who need to get quick answers about why memory is being consumed or components not created in the way they expect.

What do you think? Is runtime "transparency" still an important enough problem for us to want to spend some time solving it?

Cheers,
Nick

[Kaleb Pederson]

I can't speak for others, but that'd probably be fine for my needs.

The only problem I've had to track down a few times is why a component marked as InstancePerLifetimeScope() (or anything but SingleInstance)is being treated as a single instance -- which has always boiled down to me being surprised by a SingleInstance() component indirectly requiring it.

I haven't tried whitebox, but it's quite possible that I'll eventually need something that does much more than the above; we're soon to be delivering a product that allows our customers to write plugins and override some of our components and I'm sure someone will eventually do something entirely unexpected with the limited subset of Autofac that we've exposed.

It would also be nice to be able to generate a graph of the dependency chain for developer documentation.

Thank you for Autofac -- I'm frequently amazed at how powerful a healthy dose of composition is in its hands :).

--Kaleb

--
You received this message because you are subscribed to the Google Groups "Autofac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autofac+u...@googlegroups.com.
To post to this group, send email to aut...@googlegroups.com.
Visit this group at http://groups.google.com/group/autofac.
For more options, visit https://groups.google.com/groups/opt_out.

[alex.mey...@gmail.com]

Hi Nick,

I agree about the effort required to maintain a proper application in addition to a framework and the numerous associated integrations.

With a simple output mechanism such as STDOUT (reminds me of the Storm Multi-Language Protocol) it would be easy to integrate the logging into existing tools. I could imagine creating a sink in SignalR to push the events to a web application in real-time. Having a simple interface for data collection would open up such possibilities and “free the data” from the tyranny of a WPF application. The existing Whitebox project could become the first example client demonstrating consumption of the new interface.

I don’t think you can ever have too much instrumentation in your application. The more insight you have into what is happening the better.

Cheers,

Alex.

---

From: nblum...@nblumhardt.com<nblum...@nblumhardt.com>
To: <aut...@googlegroups.com>
Sent: Saturday, October 5, 2013
Subject: Whitebox (profiler) ... again

--

[Travis Illig]

I like the idea of a simple output mechanism.

Would it be worth using the System.Diagnostics.Trace or ETW stuff so people could add listeners for whatever endpoints they wanted? It might be a little more flexible than straight-up STDOUT.

-T

[Nicholas Blumhardt]

Great, thanks for the feedback guys.

Kaleb, generating a dependency graph isn't something I'd considered but seems like it should fall out nicely.

Alex - hitting more than one nail on the head there; driving a web client (or Glimpse?) would fit better with a wide range of apps being built with Autofac.

Travis, good point. Supporting S.D.Trace out of the box seems like a reasonable place to start.

I should also offer a disclaimer at this point that this could still take me some time...... ;)

Cheers,

Nick

--
You received this message because you are subscribed to a topic in the Google Groups "Autofac" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/autofac/GbX3nzqwXyM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to autofac+u...@googlegroups.com.

[Nicholas Blumhardt]

Going to chip away at it here: https://github.com/autofac/autofac-analysis

Crikey, was the last email in this thread really three months ago? :)

Cheers!

Nick

[Alex Meyer-Gleaves]

Awesome. Adding some sweet Serilog goodness no doubt!

It would seem you have a preference for GitHub now. ;)

You received this message because you are subscribed to the Google Groups "Autofac" group.

To unsubscribe from this group and stop receiving emails from it, send an email to autofac+u...@googlegroups.com.

[Nicholas Blumhardt]

:) -- regarding Serilog, just using it as a convenient output for now while I work out what the presentation mechanism should be like. The code as committed presents warnings/issues nicely, but I realised after running it that the dump of components and annotated object graphs is half the value (or more) - so outputting that structured info well will be a core goal.

On Git - I think Eric Raymond sums it all up here: http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html .... I've loved and encouraged adoption of Hg for a long time, but the writing seems to be on the wall. We should reconsider making a move to GitHub. Just my $0.02 of course.

Cheers!

[Dru Sellers]

+1 for github

[Kendall Bennett]

I would prefer Git. Not that I particularly like git much at all, since we use Perforce as our internal version control system. But GitHub tools such as their simple GUI makes it much easier for the casual users to work with Git. I think that is the primary reason why usage has exploded, and GitHub is a large part of that reason. Most of the projects I am involved with have made the switch to Git and GitHub and it makes it a lot easier to work with them.

Regards,

Sent from my iPad Air!

Kendall Bennett, CEO

A Main Hobbies

424 Otterson Drive

Chico, CA 95928

[Alex Meyer-Gleaves]

A good read, though I hope we haven't reached the "crusty, insular, and backward-looking" phase yet! ;P

I have been thinking about this for a while and certainly agree that the battle is over. I'll start looking into the migration process to see what is involved. From what I have read in the past it isn't exactly a seamless process, especially with the migration of issues.

What do you think Travis? Do we bite the bullet and follow the heard for the greater good of the project. :)

[Travis Illig]

I don't mind moving as long as it's not just for the sake of moving. It'll give me a good excuse to learn more about Git than just what GitHub for Windows offers. :)

I don't think moving the code will be bad since you can just check it out and check it into GitHub. We'll lose history, but I'm not sure that's horrible.

I think the pain will be in moving all the issues, wiki, etc. over. I really don't want to maintain things in two places.

-T

[Nicholas Blumhardt]

Hi folks - update on the original topic of this thread, since someone mentioned it a few days ago.

I made some progress getting Whitebox across as a library, but I am not optimistic about how it is coming out. So much of the "visibility" aspect of Whitebox is in fact visual that without a UI it is pretty unappealing to me.

Giving some other options consideration, will report back.... :)

--

[James Nail]

Reading Mark Seemann's recent post about "Captive Dependencies" got me thinking about Whitebox (or Autofac analytics in general) again.  I'd love to just have a utility that I can run as part of an integration test to assert that none of my registrations are improperly scoped.  A GUI is nice, but detecting those scoping errors are the bigger plus for me.

[James Nail]

Hi Nicholas,

I just got a chance to peek at your autofac-analysis repo, and I realized it's been a while since you've gotten after it.

I'm really interested in getting those analytical capabilities, so I'd love to help move the ball forward in any way possible.  Is there anything I can do to help out?  

Thanks,

James

On Sunday, March 23, 2014 5:37:54 PM UTC-4, nblumhardt wrote:

[Travis Illig]

We're in the process of working on ASP.NET 5 compatibility and switching things to version 4 for everything. (Just in case you were thinking of setting up a pull request or something, things are changing.)

To really make progress on Whitebox we sort of need a plan/design - an endpoint to work toward. The current stuff in the repo is a great start, but as is labeled in there, it's sort of prototype stages... and as you noticed, it hasn't been touched in a while.

If you want to help push it forward, some of the meta-coding stuff would be the biggest help.

• What should be recorded?
• What can currently be recorded? (Where are the gaps?)
• What should the ouptut format be?
• How would a UI or monitor (or log listener, or whatever) attach to it so the output can be visualized or analyzed?
• Are there changes required in the core Autofac to enable better profiling?

It's sort of hard to get traction on it or get more than one person pushing forward on it without some sort of plan. :)

Google Docs or something similar is a reasonable place to put that stuff; if you do end up getting momentum and want to start really cranking on it, we can give you access to that repo and you can post the plan (and start committing code) there.

In the meantime, if you have something specific you want in there, you can fork it to play around or you can submit a pull request. We'd love to have the help!

-T

[nblumhardt]

I'd love to see some progress on this - if you need a hand with anything let me know. I'm hanging out in https://jabbr.net/#/rooms/autofac (who owns the room?) if anyone would like to chat about where things are at.

Cheers!

Nick

[James Nail]

Thanks Travis,

I'll dig in when I get a spare moment this week.

-James