The simple title of this blog entry indicates that nothing much has happened in the last few months. Well, at least not much I thought was worth telling you.
I finished an alpha version of my build system as a proof of the feasibility to inject script like C# code in the .NET framework (see my blog entry C# Script).
After that I started a new properties core framework (the basic ideas are discussed in my previous blog entry MVC at the property granularity).
After two rewrites, I got the basic updating mechanisms working and the C# integration was not looking bad. It made sense to create some more test cases and I ended up designing a complete Tao and OpenGL based application framework in .NET.
Well, progress is slower as projects get bigger. After porting my math library from the previous 3D engine, I managed to implement half of a scene graph and a simple rendering engine. All in all it is working perfectly. The updating mechanism is completely hidden and the computations are incremental and only invoked when required. I even managed to implement incremental sets and maps. Well, incremental ordered lists seem to be much more difficult because iterator logic is required … and sorting will surely burn my brain, but I will try as soon the requirements are popping up.
And for fun I tried to create a generic LR top down parser, of which my first attempt sadly failed, nevertheless I created a nice syntax for specifying BNF grammars. My intention was to implement a Lexer for JavaScript.
Over the last year I created an object model for incremental computation of XSL traits.
After two implementations the problem more and more grew over my head and by stepping back a week or so, I realized that the problem itsself of computing dependable traits (XSL values, or more commonly properties), may be solved by a different, graph based approach.
The nodes of this graph are the values, connections between them relate to the functions. Changes are propagated in an invalidation phase.
When accessing an invalid value, an evaluation may be started at any time. The function responsible computing the value is called and may access other values. If a value is invalid, the evaluation for that value starts, and so on.
This basic model results in a Model/View implementation at property granularity. Multiple observers are possible and performance – when combined with memoization – seems to be efficient.
The graph itsself can be maintained by tracking all input values which are used in a function evaluation.
By using a static evaluation stack, this process can even be totally hidden, so that no additional (meta) information about the dependencies is required.
The application containing the XSL core I talked about goes in production in a few weeks, and recently I started the build a complete framework to prove the assumption that this model is useful for creating several kinds of applications.
Right now I am trying to solve the problem of effectively representing, sorting or filtering lists while maintaining the lazy nature of the evaluator core.
I think that dependable properties like the ones used in the Microsoft Presentation Foundation or at the core of the F3 language (soon to be released by Sun, here called attributes) will create a new platform for software development of interactive applications.
This concept may even be capable to solve the concurrency problem we face over the next few years.
yours armin
Joel uncovered the iceberg secret in 2002, that is so great you must read:
yours armin
It’s that simple, and I use it since the 80s:
The following rules should silence all criticism of the two parties:
I don’t want to go into discussion about legacy display terminals or what should be stored in the revision control.
I consider the source the model and so it shall not be changed by personal preference or by any tool.
Following the above rules, ragged tables are avoided and indentation always represents the semantic structure of the source, independent of the tab-size the editor is configured with.
So, follow these rules and create great code.
yours armin
Well, I now found an explanation why my felt productivity dropped since I work in teams:
read
and then
moblog: The Windows Shutdown crapfest
It may happen, even in the company you are working right now!
yours armin
Even if a human task switch would cost no time at all, there are obvious drawbacks, nicely explained in one of my favorite blogs:
So, this logically explains why being patient always has an advantage over hurrying.
yours armin
ah, and always don’t forget to “prepare 4 space!”
The last weekend I decided to upgrade my computer and got out in a rush to get the required components. I bought a new MB, CPU, cooler, 2GB RAM, Graphic Card and a silence power supply unit.
After getting the hardware running, I sadly recognized that installing all the software I need for working in my different projects actually took much more time. So much time, that the complete weekend was wasted getting the software installation prepared for the next week.
Absorbed in getting all the software running, I downloaded a new cygwin and sadly, again, the automake and autoconf tools did not work. Well, I require to build some libraries which depend heavily on them. And by now I was not able to use GNUmake, SCons or jam for many reasons.
Recognizing that most of these make tools simply don’t suite my needs and that I have spent so many times configuring other tools to build libraries, I remembered that I always wanted to create a makefile tool.
Insanebits.com is now online and while collecting some more insanity I am evaluating blogging software.
Because I prefer Textile and don’t like Perl, I ended up with the three
and
TextPattern seems to have a limit of 2 categories per post, but right now seems to be the best choice.
Wordpress needs a Textile plugin and supports only one Weblog. According to some articles it seems to be slow.
ExpressionEngine is commercal but free for personal use.
I will install TextPattern to see how it feels, see you soon at insanebits.com
As my development blog somehow ceased over the last few months, I though about what could be interesting for geeks to read here.
For me, some things have been changed:
Like before, I am active in the creation of new technologies, but I don’t think they need to be published before they have been theoretically nailed down and implemented in production code. Yes, I got more pragmatic at least!! Some of my nerdy friends may or may not agree ;-)
Actually, I work now ;-) Well, I thought it before, but compared with working simultaneously in two teams which are distributed around the world and the isolated code hacking I have done before, I need to admit that I was a slacker ….
Curiously, the felt productivity is not as high as before, but that is one of the things I need to work out first.
But what has really be increased, is the daily insanity I get confronted with while working with the ever changing computer software. And I think these “insane bits”, I want to call them, got so frequent that it might be worth starting a blog.
This is about the things I call “broken windows” or stuff that happens once or every time you use a particular software. Some of them are simple bugs, but some of them are decade old problems which would be simple to fix if users would not get used to ignoring them.
The latter problems are sometimes so obvious that every new user stumbles across them and experienced users explain these defects as inevitable. THAT HAS TO BE CHANGED!!!
The vision of “insane bits” is to make the insanity obvious and so help and force the authors to fix it!
This is the first entry of this blog and will moved to http://insanebits.com as soon the website is online.
At this time I would like to invite all my known friends and their friends to build a trust network of geeks, nerds and power users to support this blog. The scope should be computer centered, but may extend to technology or even environment related topics.
So prepare for a lot of insanity @ http://insanebits.com (.org,.net,.eu will work, too)
yours Armin
It worked again, I created an engine which can be used to make all kinds of value computations persistent, meaning that when input value used parameterized a complex system are changed, this engine is capable to solve all computations required to incrementally rebuild the final output by lazy evaluation.
Ok, you tell me thats nothing spectacular, one writes down the dependencies and the computation required to create the output values, then feed this information into a small interpreter and run it.
But now I tell you, that all computational dependencies are directly derived from your code and so are tracked automatically and even the graph is rebuilt if the dependency structure is changed and that automatic intermediate caches and type safety are self-evident. And more importantly, you don’t have to write one additional line of code or even think about it while creating your algorithms!