I make a lot of use of “start” in the windows world, so here’s the Ubuntu/Debian equivalent
http://www.tech-juice.org/2011/03/13/ubuntu-opening-files-with-default-program-on-command-line/
Amazing: instructions to get apt-get working on cygwin.
http://www.fir3net.com/Cygwin/cygwin-package-installation.html
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:
snip
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.
/snip
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.
Yesterday I cut the initial release of my first project leveraging spidermonkey-dotnet. It is called GibberMonkey, and it is a JavaScript scriptable IRC bot, programmable even from the chatroom. Source code, .Net & Mono binaries are available on CodePlex. It is the result of a marriage between the SpiderMonkey engine & the SmartIrc4Net library. SmartIrc4Net is a C# library providing an API for communicating with an IRC server, documentation for this API is here.
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 SmartIrc4Net API is completely exposed to JavaScript, all done generically without specific embedding code. GibberMonkey itself is quite small because of this. The key feature that was missing in the alpha generic embedder was full support of delegates. What is now possible is for a JavaScript function (JSTYPE_FUNCTION) to be created at runtime and be mapped and stored automatically as any needed delegate type. Later on, managed code can make the callback to the JS engine seamlessly.
This solution was implemented by System.Reflection.Emitting a dynamic method of the necessary delegate type. Inside this method the parameters are moved into an array so we can eventually invoke the user JavaScript function via JS_CallFunction. Hardcore. GibberMonkey wraps dozens of SmartIrc4Net delegate types, and this is the primary method of customizing the bot’s behavior.
The alpha version of spidermonkey-dotnet now runs under Mono. Makefiles for Mono compilation and the above features are both in source control.
