Rant and a UML class diagram for deconf.

I haven’t mentioned confuse or deconf nor the deconf specification lately.

That’s mainly because at this moment I’m focusing myself on other things. In a few weeks I’ll have a long holiday, chances are high I’ll work on a few of my items in my growing to do list.

Amongst them are further improving codegen and deconf-desk, an implementation of this desktop configuration standard which I wrote a few weeks ago.

However. Since it’s a good practise and since it might help interested people in joining the efforts of implementing it, I created a UML Class diagram of what is current and of what the idea is. If you don’t know how to interpret a class diagram, you can of course use codegen to generate code from it.

You can find it here. It obviously uses the observer/observable pattern a lot. That’s because successful current configuration systems also use it (like gconf, you can view the desktop applications as the observers and the daemon as the observable). I’m also using the (remote) proxy pattern. You’ll notice that this “design pattern bla bla” is indeed just naming for something that is most likely trivial and something you most likely call different and already know. Yet it’s interesting to discover how they are being reused by programmers time after time and for totally different projects and scopes.

Anyway, as usual. This ain’t a promise that something usable will ever exist. I never make such promises for free software projects. And this one highly depends on the cooperation of an awful lot other people. In fact it’s nearly undoable to ever make this succeed. That’s mainly because the community of people that are attempting to build a free software desktop are very bad at actually agreeing on desktop standards and shared desktop components.

To the Microsofts of this world: If you want to make sure we will never succeed in selling our desktop, make sure we will for ever keep disagreeing like we are doing now. The strength of Microsoft as a desktop software builder is that they do have decision making leadership. Our failure is that we don’t. And that we can’t agree on the most simple and basic things. I’ll keep repeating this until I die or until we solve the problem. We aren’t solving the real problems at this moment.

Note that the kernel folks do have decision making leadership. And surprise surprise: they are successful at selling it. This is indeed why I asked these additional questions to the GNOME Foundation board candidates of this year. Perhaps now they’ll address this problem? I fear not. Sure it’s not the purpose of that board. Whatever, it’s all we have a.t.m..

No, I’m by far not satisfied by the achievements of the freedesktop.org movement. It’s, by far, not enough. Agreed it’s a small step in the right direction. And no, it’s not a big step for mankind. We need so much more. It’s unbelievable.

Note that if I was intelligent enough to have the solution, I’d propose it. I’m not. So yes, indeed, this is rant. I know.

Observer/Observable in codegen, Improved Java class builder XSLT Template

Today I dramatically refactored codegen again. I removed the Hashtables from the Package and Project classes and replaced it with IList’s. I also
replaced all ArrayList references with IList’s and added a Add and a Clear method for every many-relation in the classes. So make sure you update your checkout.

I did this because I wanted to implement Observer/Observable. If you don’t know what Observer/Observable is, read about it at wikipedia. You can’t easily observe the Add method of the ArrayList (unless you
extend that class, of course). However, now it’s possible to be Observer of the Package, Project, Interface, Class, Operation,
Attribute and Parameter instances. This means that if they change, you can get notified about it (and, for example, regenerate your code).

This doesn’t yet have a use-case because the sample application uses the ISourceParser for parsing the UML class diagram source file and the IGenerator
for generating the entire project in two steps. The idea is to some day create an IGenerator that plays the role of an observer of
those instances. This would allow for regeneration of code on-the-fly when deep integrating codegen with a integration development
environment or code editing application. For example regenerating code when your diagram changes.

Perhaps someday regeneration or redrawing on-the-fly of the diagram if the code changes (this ain’t current, it’s a futuristic idea). I’m
still experimenting with my own ideas here. I got inspired about all this after reading this blog.

I’d like to point out that this is indeed in the scope of this project. I’m indeed attempting to build a code generation framework, not just a simple code generator. Of course is the only end-user use of codegen at this moment “a simple code generator that is a little bit fancy because it can already handle multiple input formats and generate multiple programming languages. I’m, however, (in future) planning to do much cooler things with the concept of code generation. Mainly integration with integrated development environments and really making Model Driven Development much more easy and pleasant. But for all those cool idea’s, you first need to get the basics right. Right?

The first contribution from somebody other than me comes from my colleague Marien Johan who greatly improved the
Java class builder XSLT Template. He basically rewrote the stylesheet and added a huge amount of comments and documentation. Check it out if you’re planning to add support for other languages.

Short term plans for codegen: Create some NUnit tests, create PHP 5 and Python XSLT Templates. Also redoing the current Observable/Observer infrastructure. A.t.m. it’s junk. But I need to get some sleep now. Feel free to contact me if you’d like to help with these or any other subjects related to codegen.

Codegen and PHP5

I just committed a very simple set of XSLT Templates that will let codegen generate PHP5 classes and interfaces. I haven’t yet done it the way Marien Johan did it for Java. I know this is a better way of creating xsl’s. I will improve this soon.

First signs of Java support in codegen

These XSLT Templates for simple Java interfaces and classes are the first clear signs that I’m really planning to some day support non .NET languages including Java, Perl, Python, C (GObject), C++ on codegen.

I’m working on it. You can help me (search for pvanhoof on the popular community IRC networks). Especially if you think that at this moment it sucks: I’m working on it. And you can help me. Okay?!

Oh, update. And I finally updated the UML class diagram.

Feature list and more OO support for codegen

I wrote a short feature and planned list about codegen.

Our Subversion repository is back up, so you can start updating your checkout. I’d like to iterate that my company isn’t the copyright owner. I might have scared people away by putting the code on that specific repository. I’m the copyright owner and yes, the project is fully LGPL licensed (and I’m not requiring copyright ownership reassignment).

I also added support for discovering which packages a class depends on. It can be used to create the “using”, “#include or “imports” many programming languages utilise (the generator always uses the package name as default namespace). If you’re target is .NET, the NETSupport.Fixer will also search for .NET standard packages and namespaces to depend your class/interface code on (so that you can
generate the project files and using clausules correctly. The default XSLT Template has some support for this as a sample).

On top of that I added support for abstract classes and abstract attributes and operations. They’ll remain abstract if the class is abstract. But a class that ain’t abstract cannot have abstract attributes nor operations upon generation (of course). Codegen now checks for that. I also added support for discovery for the need of the overrides code attribute.

If you check the default XSLT Template for generating a class, you’ll see that now there’s support for inheritance, implementing interfaces, abstract classes, abstract operations and typed attributes, private, public and protected (for the class, operations and typed attributes), typed operation parameters, namespaces and package dependencies. I’ve tested these XSLT Templates and so far haven’t succeeded in letting it generate a class or interface that didn’t compile. Unless I start using wierd and/or unexisting type names for the attributes, operations or parameters. If I’m still missing something: let me know. Also check the feature list for more information.

I’m going to start creating a XSLT Template set for PHP 5, Python classes and Java soon. If people want to help me with that, get in touch.

Technical documentation for codegen available

It looks like our company Subversion service is unavailable at this moment (update: My colleagues told me it’s most likely hanging at the RAID bios after a power failure in the building. It could be hanging there since there was one defect disk being replaced, but since it’s Sunday and the disk will arrive this Monday anyway, chances are high nobody is going to press [enter] until Monday morning: damned). But no worries, I’ve put online a new snapshot. Note that this one isn’t yet
committed in the Subversion repository (as the service is also unavailable for me). So if you
update your sources before I commit this new stuff, you’ll get less. If this unavailability happens often,
I’ll put it on a more known repository (like the ones that you can get at Novell Forge).
Feel free to make suggestions about this.

Note that I removed all the Subversion meta information to make sure nobody will
use this snapshot as a starting point (to make sure nobody will update
the snapshot code using Subversion). View this one as a sneak preview.

Again quite a lot has changed. I refactored a lot stuff. Added support for protected class members and the visibility attribute for interfaces and classes. And I fixed
stuff so that the Default XSLT Templates now successfully transform into a
complete VS.NET 2003 solution. Including correctly build classes that are filled with,
correctly build interfaces with abstract operations and attributes, correctly build project files and a correctly
build solution file. Somebody should really repeat this XSL Template work
for Eclipse Java, Python, Perl, PHP, GObject, C++ etcetera. Now that we
have a Free Software code generator framework, lets make it greater than
any existing one.

Therefore I created this technical documentation. It explains how to build your own code generator
using codegen (which ain’t hard and very few code is needed, don’t worry)
and how to prepare your XSLT Templates so that’ll generate
code in your favourite programming language and environment. This lets
you define the generated code exactly how you want it. And this lets you
choose how much of house-style code gets generated.

Note to the people that hate code generators: Codegen does not try
to define nor generate your implementations. It merely attempts to convert your UML
Class diagram into skeleton code. This basically means that it’ll generate
your classes and interfaces in the syntax of your favourite programming
language. Codegen will not read your database or whatever. At this moment it’s only using your UML Class diagram. Support for generating code using a database schema as input isn’t planned.

You have the very nice NHibernate for that.
Yet technically spoken isn’t NHibernate a code generator. It’s rather
a very useful framework for making it more easy to implement your data access
layer. Integration with NHibernate is a possible feature for a codegen user to
create. I can imagine one could mark certain UML objects as an implementation
of a IPersistable interface, and tell codegen to generate code for each
class that implements that interface to try generate calls to the NHibernate
framework. There’s not yet such a generator for codegen implemented. The main focus
of codegen isn’t to generate this type of implementation code. Often it’s
the task of the programmer to do this. But it could be a nice add-on, yes.

Documentation about codegen and support for XSLT Templates

I wrote a document that describes codegen in detail (yet it’s not a technical description, for a technical description there’s this simplified DIA UML Class diagram). And I created a snapshot of what is current for people that dislike using Subversion. There’s also a binary available of the sample console tool.

Note to readers: I hate managing projects with tools like sourceforge or Novell Forge. I hate creating versions, I just want to code. Stuff like that. If you’d like to help me with this: contact me. For now, don’t expect me to start throwing versions at you guys. I’m not a manager, just a simple programmer. Versions will sooner or later happen. Sure. Whatever.

Codegen now also supports XSLT Templates as secondary input. Using the default XSLT Template set it now successfully builds to a VS.NET solution with all classes and interfaces in separate files (and correctly converted by the templates to usable stub code). I’d be happy to create a repository with contributed Template sets. For example one that in stead generates MonoDevelop project files. Or nant build files. Or XSLT Templates for generating other languages like Java, GObject, Python or Perl. Just contribute them.

It also supports writing the (by the XSL Transformer) internally used intermediate XML documents to the filesystem. This makes it possible to apply your own XSL Transformations on the resulting XML files.

Other ideas like support for reverse engineering code written using programming languages like Java, C# and VB.NET is on the to do list of the project. I’ll (or you’d) need to create a parser for the language first. I’m most likely going to take a look at the ones shipped with Mono for this. After that I’m (or you’d) need to create a XSLT Template that converts the intermediate internal XML document to, for example, XMI. Which is a format readable by Rational Rose. Or create one that converts it to DIA. The creation of such XSLT Templates would already add support for convertion of XMI to DIA and/or DIA to XML (depending on which XSLT Template you made). You could also create a concrete IGenerator that does this (if XSLT isn’t suitable for this, but I as far as I can tell … it’s suitable).

I’m not an XSL geek, so I’m silently hoping for the worlds greatest XSLT dudes offering me help with this. You can find sample XSLT Templates and the XML format to convert here. Information about both the XMI and the DIA format is available online.

More on the codegen project

Today I added support for XSLT Templates to codegen.

The generator will during the generation phase create an internal XML document before it’ll apply your XSLT Template on it. In that template you can iterate the operations, parameters, attributes and interfaces of each generated interface and class. It will also pass some arguments to the XsltTransform instance. Arguments like the name of the inherited class, the package name, the class name or the interface name to generate.

How the internal XML document is formatted and which parameters to expect is documented in the sample templates. All this is, of course, experimental. I’m going to tweak and bugfix it this evening. Don’t just sit there reading this blog entry with a donkey-face. Help me :-)! It’s C# but it’s LGPL (yes, that is possible).

Lets make a new supported-list: Dia class diagrams in, XMI models (class diagram) (Rational Rose) in, C# out, VB.NET out, any format and/or language using XSLT out

I also added a Nant build file and tested the project with Mono, an opensource .NET framework that works on platforms like Linux. Everything builds and works with Mono. This effectively makes the framework platform independent. I also added MonoDevelop combine and project files. This eases debugging and developing on Linux. The Visual Studio .NET solution files are also stored in the repository. I suggest using AnkhSVN if you’d like source control with Subversion to be intergrated in VS.NET. It works great. So it doesn’t matter much on what platform you’d like to develop if you want to contribute.

XMI/Rational Rose support for that code generator thing

Yesterday I wrote about a code generator that generates skeleton code from your UML Class diagrams. Today the support for XMI files (Rational Rose supports this) is done. It’s still, of course, experimental.

This brings the “supports”-list to: Dia in, XMI in, C# out and VB.NET out. And since all this is implemented as a LGPL library, it’s easy to integrate your existing softwares (like integrated development environments) with it. You can, indeed, generate class per class and interface per interface. And the generation doesn’t have to go to a file. The output is a TextWriter and defaults to the Console.Out instance. There’s also implementations (for C# and VB.NET) that will write to files and directories. The input is also abstracted to StreamReader. So you could implement one that reads it’s data from any source (including remote locations, databases or any other input source).

Next on my to do list for this project is implementing a IGenerator that uses XSLT Templates. If you’re interested in helping me with this, search me on the typical opensource IRC networks as “pvanhoof” and talk. Do type my nickname in a channel, it’ll make my IRC client flash. I might be busy coding :-p.

The nice guys at Novell approved putting the project at Novell Force. You can find the webpage for it here. I’ll add information and releases to that page later. You can put bugs here.

ps. If you need commit access on this repository, ask.

Free software (LGPL) code generator framework

I’m working on something that I’ll call “A Code Generator framework” written in C# (but not only meant for .NET).

As every good code generator it doesn’t try to generate your great implementations. It will try to convert your UML class diagram into skeleton code (which is IMHO a boring and automatable task). A good thing about this UML to skeleton code generator is that it forces the developer to design first, code later (reverse engineering to a UML class diagram is cool for refactoring, but this code generator isn’t meant for refactory tasks).

I’ve added support for Dia as input and C# and VB.NET as output. Continue reading if that triggers your interest. If not, I’m also planning to support Rational Rose (sooner or later) as input and XSLT als output (which would make it even more easy to add other languages).

In fact it’s already somewhat finished (so for me it ain’t vaporware any more). I released this as LGPL. You can find the sources in a Subversion repository here. You can contact me if you’d like to make changes and/or if you’d like commit access.

Little bit UML of codegenIt heavily uses the Strategy Design Pattern. The framework abstracts the source and target. The Strategy Design Pattern’s delegate is a concrete IGenerator implementation. A concrete ISourceParser implementation is an object that can parse a specific source into a list of interfaces, classes and packages. The interfaces and classes itself have, of course, properties and methods. At this moment I’m not yet supporting aggregation nor composition. This is on my to do list.

You can find a UML class diagram here.

I’ve added support for Dia, C# and VB.NET. Dia input support is implemented in DiaSupport.Parser.CSharpSupport.CSharpCodeGenerator implements support for the C# language and VBNETSupport.VBNETCodeGenerator implements support for the VB.NET language.

I also created implementations for both C# and VB.NET that will write files in directories (one directory per package). It will not yet generate Visual Studio .NET solution and project nor nANT build files. This is on my to do list. I’d first like to create a generator that will transform XSLT files.

I’ve added a sample console tool that demonstrates how to use the framework. You can also use the framework as a library. For example if you’d like to integrate with an Integrated Development Environment.

Quick ‘n dirty DIA to C# code generator

This is a quick ‘n dirty Dia UML class diagram to C# code generator. It doesn’t yet support aggregation nor composition. It does support inheritance (dia:connections), classes (dia:object), interfaces (dia:object) and properties (attributes). It also doesn’t yet supports methods (I’d have to generate the methods that are to be implemented because your class implements interfaces that define them. Same for Properties that are defined in the interfaces (they aren’t yet generated in classes that implement the interface). All this is perfectly possible but I’m lazy right now (and I have to go to my girlfriend in a few minutes).

Of course it also doesn’t generate implementations. And it doesn’t work with xslt (it simply uses Console.WriteLine).

Since the opensource community reads this on planet.gnome.org, I expect a fully supported and fully functional DIA to C# code generator in a few minutes! I added a line that this thing is LGPL (I don’t really care). So .. start! :-P

Optimizing g_utf8_offset_to_pointer

Hey Federico,

I’m most likely missing something extremely important here but simply doing,

gchar *
g_utf8_offset_to_pointer (const gchar *str,
                          glong        offset)
{
  const gchar *s = str;
  while (offset--)
    if (*s < 191) s++;
    else s = g_utf8_next_char (s);

  return (gchar *)s;
}

Makes it a little bit faster (on my system). Oh and that way can the utf8_skip_data bitmap also be 191 bytes smaller, of course (adjust the macro to subtract 191 from (*s)). The idea here is that arithmetic operations are less expensive (on my CPU/architecture/system) than looking up memory. Just compile test.c using gcc -S test.c with and without -DOPT and check the differences in the resulting test.s file.