I make a lot of use of “start” in the windows world, so here’s the Ubuntu/Debian equivalent
Amazing: instructions to get apt-get working on cygwin.
Thinking the “MEF” way, where dependencies are reflected and the configuration is nil. Bare bones, the relationships needed to be known are a simple tuple: ( Interface (or Abstract) Type, Concrete Type, Factory Type ).
Query this structure by the interface and and get the concrete type. Reflect the dependencies. Query the factory for each dependency and build it, then with the factory for the requested type, inject them. Do this recursively.
I also wonder whether there are any IoC frameworks, built using themselves as the DI mechanism.
I released a somewhat raw cut of my first android app a few weeks ago. I love the platform, and OpenGL ES is pretty cool.
Planetoid: Solar Planet Orrery is an interactive simulation of the positions of the solar planets by date. You can change the angle of view or direction through time as you observe the planets orbit around the sun.
The idea man behind this is Ben, eminent LA astronomy and computer geek.
I am considering building a custom DI container, as it occurred to me our own custom providers or even the out-of-the box providers do most of the work. I had been describing the ‘provider’ to other coders as a powerful factory for a long time. Looking into Ninject, I found they describe how their DI bindings are resolved by a provider:
Okay, so remember when we said type bindings were from a service type to an implementation type? Well, we lied. You caught us. Type binding is really a little bit more complicated than we let on. Rather than being from one type to another, bindings are actually from a service type to a provider. Simply put, a provider is an object that can create instances of another type. It’s like a factory, but specifically designed to work with Ninject.
Ninject is referring to their own concept of provider, but replace that with an ASP.NET provider or any one that pulls in XML config and you have the beginnings of a tiny DI framework.
A repository of well known FOSS is located at dotnetit.org. This includes Apache Xerces (an XML parser including DOM and SAX implementations), Apache Xalan (an XSLT and XPATH parser and processor), regexp libraries, cryptography libraries, etc.
An open source alternative .NET IDE is #develop. This project is coming along fast, and includes a library NRefactory that parses C# and VB.NET and IMO has a superior abstract syntax tree model than the CodeDom.
If broken it is, fix it you should is a great MSDN blog heavy in content that walks through debugging techniques for memory leaks, crashes and the like, using windbg and perfmon. Great place to learn how to poke around your heap from the command line.
The standard corlib doesn’t provide a good library to creating zip files (while it does do zip compression). If you’d like to do this but don’t want to use a third party check out Jon Galoway’s blog. In short, use the J# library and java.util.zip.
I got an email from someone who couldn’t compile GibberMonkey 0.1, after referencing spidermonkey-dotnet 0.2.0. GM code has undergone some changes since the 0.1 binary release. It and SM.NET 0.2 are in the process of being refactored to present a good API to the library user.
Enough catchup. The latest code from TFS on both projects will compile together. To be specific, the GM changeset 9678 will compile against the development branch ($/spidermonkeydotnet/development/spidermonkey-dotnet) SM.NET changeset 21914.
Also, if your a codeplex.com member you can simplify all this by joining the project and hitting the TFS and mapping these projects to your workspace.
I’ve branched the code, and pulled out the stuff I’ve been thinking about to set free (as in speech). This is basically just the raw bridge, no “generic object embedding”. Check out the project on the codeplex project page or on freshmeat. Future enhancements for this piece will include the debugger API, and not much else I can think of right now. More updates to come as I settle down (I’ve just relocated from NYC to LA).
I should apologize for all the bugs in CodePraxis.com lately. I upgraded to the “New Blogger,” which gained me nothing but a broken site. The XML feed of the new Blogger has different schema which has been the root cause of all the issues.
Part of the purpose of GibberMonkey is to be the usability testbed for the new generic object embedding in spidermonkey-dotnet (see previous posts).
The alpha version of spidermonkey-dotnet now runs under Mono. Makefiles for Mono compilation and the above features are both in source control.