Stuff Michael Meeks is doing

"Policy is a poor man's substitute for common sense."
-- David Woodhouse

• To me, the most interesting thing about OO.o that needs fixing - is the developer community. That is still predicated on the Sun guys perceiving that it might be nice to work together with others to build one, and considering careful compromises to help make that a reality.
• To recap - the problem is that Sun (and some other corporates) simply refuse to include code under the LGPLv3 (which would be our preferred solution) unless they can avoid it's terms by owning the code: nasty.
• My favorite awful compromise of the month (that retains the well known barrier to entry, distrust breeding ground etc. that is assignment) - but might at least make some progress would be to: (wait for it) - assign everything to Oracle ! so they can own it and do what they like with it - but - only on condition that majority non-Sun written code modules are continued to be made available to others under LGPLv3 plus a more lax license: perhaps MPL/CDDL, Apache, BSD (in order of increasing laxness). That would effectively remove the value of the exclusive ownership of code written by others (for unseemly back-room arm twisting), while at least for the forseeable future, not impacting the proprietary value of the bulk of the code-base.
• Clearly, by far the best approach is to pick a license you can accept, with a suitable license steward, and go eclectic ownership - letting creativity flourish: the Mozilla approach. This is also -clearly- in the spirit of the (pure) Marketing around the 'Shared' nature of the 'Shared' Copyright Assignment (SCA) : if it is truly shared (it is not), then why not allow it to be available under another license ? And again, it is regrettable that they will not accept code simply under the terms of the LGPLv3; our problem is not with the license - but the assymetry between it and outright ownership of our code.
• I still hate (C) assignment with a fear and loathing; and continuing it for OO.o drives away the developer help we need; but perhaps this compromise might help re-unite the wider OO.o community, and at least having the bigger corporate contributors working together can't hurt to start with.

• It seems the single file, containing GUI and code, that can be compiled into .cxx & .h files by a head-less binary is quite a nice model; why ? because you still have a self-contained binary that doesn't drag XML files with it (across platforms), and it is easy: fluid -c UI.fl is pretty simple to add to a Makefile. We should have done this years ago with glade 1: it would be have been pretty trivial.
• C++ is not a panacea; it's still easy to mess up memory allocation, cut and paste code, and produce a foul mess that is hard to unwind. A great example would be fltk's sexy void Fl_Widget::label (const char *a); - used to set the label on a widget. As a thing of beauty it stores the raw const pointer value. But - as a bonus there is extra code and lifting for a Fl_Widget::copy_label (const char *a); that does the sane thing. Don't assume other toolkits share good taste in copying conventions.
• sprintf the C++ way is unutterably lame; at least - as I understand it (perhaps that is the problem). Full of enthusiasm for the C++ way, I wrote this sort of thing using std::stringstream oss;:
  oss << "You are " << setw(2) << years << " years " << months << " months old\n";
  which is all pretty and everything (and notably only a single line). Sadly it turns into five function calls plus frame setup, plus exception unwind tables. Contrast with the standard 'va_args' approach in fprintf - a single function call, and some frame setup. I can only imagine what this does to your code size when you have hundreds of debugging statements around the place doing cunning stuff of the form:
  dbg << "data is: " << a << ", " << b << ", " << c << "\n";
  etc. I guess you have to compile them out. A more discerning va_arg version (in C++) could still do nice, powerful object printing (perhaps) but with less of a footprint. Then again, I guess C++'s hidden pointer adjustment makes var arg functions something of a pain static_cast<> wise.
• Mary Rogers over for dinner in the evening - lovely to spend some time with her again.

• I have to say that a great, great loathing is growing in me for python (and all loosely typed languages - JavaScript, you know what you are !). I feel like adding comments before each method of the form:

  #  CairoContext, Process, ProcessTree, float, float, Tuple(x,y,w,h), Tuple(x,y,w,h)
  def draw_processes_recursively(ctx, proc, proc_tree, y, proc_h, rect, clip) :
  

  And of course just that simple example took me sixty seconds to unwind: dig back to each constructor to be sure.
• Feeling good about yourself ? time to start using VBA, or it's moral equivalent: python, for a while. You could argue that the way to fix this is to impose 'self discipline' (similar to the just-a-sub-set-of-C++ argument) - and either mangled the type into all your variable names (but I am not Hungarian), -or- to try to use the same variable name everywhere for a given type (until you have two in the same method).
• Python: it scales to two whole screen-full of code without loosing readability! Python: why write code to be read, when it's so easy to write it new ? Python: great if you can hold the whole program in your head. Now if only Google could target their Java to JavaScript compiler to be a C# to Python compiler ... we might have a readable language, with an incrdibly heavy-to-start run-time (hmm).
• My next bug-bear was return values. Isn't it magic to have a function call that may not return a value, yet gives no warning (somehow I lost the ultimate 'return' statement in a sub-method - perhaps it still lurks, nicely indented, somewhere else in my code):

  def test:
  	def doit():
  		# some code, conditions, forget to return ...
  	a = doit()
  	if a: # is not None
  		# do something.
  

  Nice; I spent half an hour finding the missing return. As a helpful reminder, here is what a real language would say:
  doit.c:8: warning: control reaches end of non-void function
  
• Eventually (by crawling) arrived at the goal of beautiful rendering, despite loosing both feet in the process.
• Dinner, and put the babes to bed, while J. went out to counsel a new client. Prodded at the reprap. After re-working and tightening the X axis yesterday; I turned up the Y axis power (being right on the edge is not so good), for the Z axis tweaked the gear teeth, tightened the belts, applied mini (DRAM) heat sinks to various chips, and ... got my first real, complete print-out, of a coat-hook; generated by repsnapper (nice); fast too.
• Printed out a beer bottle opener, and had an Alsterwasser to celebrate (after mangling it a little by omitting to insert a suitable one cent coin). Apparently rep-straps are sufficiently easy to build that any old idiot can do it. Drawings of ply-wood, and openSUSE packages to follow.
• It seems that repsnapper's optimistic approach of dead reckoning without ever resetting to the end-stops works rather well, and faster too. Surely it is somewhat amazing that the machine can get tens of 0.4mm layers on top of each other reasonably precisely with those means.