Older blog entries for dto (starting at number 69)

I got invited back to NYC for a May gig. Should be pretty cool, Ariane will come along and do vocals.

Richard Stallman is speaking at Holy Cross on Wednesday. I think I'll bring michal or voltron along to see.

I have an extra day off tomorrow because Aparna cancelled class. So I will use it as a "death march" to finish all the stuff I need to finish if I'm going to see RMS speak on Wednesday, tutor comp. theory on Thursday, visit New York City in 2 weeks, and graduate in a month :-).

9 Apr 2001 (updated 9 Apr 2001 at 01:57 UTC) »
Recent thoughts and a suggestion; to be taken with a grain of salt.

The new GObject standard implements a dynamic object system and runtime library on top of ANSI C. From what I can gather, this is an extension of and "factoring out" of the original GTK+ object/type system.

I've done a fair amount of GTK+ coding in C, and my current (+1 year) project has involved heavy use of object-like conventions applied to the C language. (I am developing a free music system as part of the GNU Project.) I like this stuff. I make no pretensions to caring whether or not a language is "purely" object-oriented, or even whether it is object-oriented at all.

What I do care about is convenience and clarity in programming. There are several big "costs" associated with using GTK+ and similar styles of implementing objects in C:

  • Constantly having to dereference yourself in your own objects: self->foo, self->bar. This alone can make a 10-15 line member function look extremely dense.
  • Long method names. There is just one big namespace, so the name of the class is prefixed to every single method name, every time it is called. Even worse, you have to explicitly call gtk_superclass_operation(foo) even if foo is more specialized. That is, you have to remember which classes the methods are originally declared in when calling, instead of just invoking them on the object.
  • Constant need for casting macros like GTK_ADJUSTMENT(foo), GTK_CONTAINER(foo) and the like. This is made worse by the fact that typically you only use them inside argument lists of calls (i.e. nesting gets ugly.) Unless you declare extra pointers with the right type and cast them earlier on, you have to do this or get compiler problems and risk type errors. Even that is extra lines of code using cast macros; there's no way for clarity to win on this one.

GTK+ and its object system are still easy to use and relatively straightforward. I think it is an excellent user-interface library. But if there is one real criticism to be made of GTK use, it is this: at times the sheer verbosity of the object system makes GTK client code compete head-on with some of the densest Java. In my own programs, at times I feel the benefits I get from using abstract data types and "interfaces" are almost completely canceled out by the amount of time I have to spend typing these macros and class names over and over again and making sure everything matches up.

(For several reasons, I cannot use Glade to speed this up for me.)

Languages are a touchy issue---I hope nobody will take this the wrong way. I make no criticisms of the design of anyone's library or object system. My concerns here are limited strictly to usability at the syntactic level, and are based entirely on my own experiences.

Here is my suggestion for improving the situation. Provide a runtime dynamic object library just as is planned with GObject, but also provide a minimal set of syntax extensions on top of C, so that all three problems mentioned above just disappear.

No time to design and build something new, you say? But someone has already built a small syntax extension to C that fits the above requirements exactly. What's more, the neccessary tools for using this set of extensions are already included with every copy of the GNU C Compiler. This extension is called Objective-C, and it is the native language of both GNU's GNUstep project and Apple Computer's new Cocoa framework for developing OSX applications. The language is currently moving toward standardization using C99 as a base.

The main changes are few and are quickly learned: interface and implementation keywords, as well as a somewhat odd (but very readable) syntax for message passing: [reciever message:arg]. There are other wrinkles, but overall it adds up to a set of extensions that complement C's abilities and provide conveniences, rather than (like C++ does) obsoleting large chunks of the language and providing numerous pitfalls.

I would like to propose that app developers for GNOME and GTK start investigating this. Everything that I have learned so far tells me that Objective-C is exactly the "small step" that I, and possibly others in the world of UNIX applications development, would like to take. I don't want to give up even one bit of C's power, but I'm not afraid of convenience and new tools. I like to use abstract data types and some interfaces, but I don't want a completely new language that throws out what I know. Only the parts you want to write in objc need be written that way---the language is completely compatible with C. There are already objc bindings for GTK+ and GNOME, but they do not appear to be actively maintained. Generating interest in the language and volunteering help (as I am doing) could change the situation and find a real answer to the agonized "C or C++" question for people interested in trying something new.

With reference to GObject, in the immediate future, I believe that we could explore two possibilities:

  • Improve the existing Objective-C bindings for GTK+ and GNOME and keep them up-to-date, so that people can begin developing more applications, and so that the barrier to experimentation for other developers is lower. I am willing to help with the bindings, so I have contacted the people involved.
  • Either that, or somehow make GNU Objective-C compatible with GObject (such that it would use GObject transparently as its runtime library.) I have no idea whether or not this is possible, but it would be great because Obj-C would then simply be "extra syntax support for GObject", and we'd have the happy side-effect of not having to make a new dialect ourselves.

Someone with better knowledge of GObject's design would have to comment on these ideas. Thank you, if you have read this far into my rant :-).

-dave

[link to more info on objective c]
[Apple's recent book on Objective-C]

Dave's Monthly "I Love UNIX" article!

I typed a large entry yesterday, but Mozilla crashed before I could post it. Believe it or not, I can get it to reliably segfault upon loading one of the webpages at the W3C. I would have better apprieciated the irony if I had not lost my work at the same time.

At first, and this is scary, it occurred to me that I should use Netscape 4.7 because it would be less likely to crash. Instead I'm using gedit.

We've made some improvements to the Octal API that make it a bit easier to write plugins, and we're very close to defining the wavetable extension and generator event formats.

After long months of investigation and experimentation, I think I've finally figured out a grand unified theory of including illustrations in TeX/LaTeX documents. Here is what I've learned:

  1. Blithely ignore any and all macro packages claiming to do illustrations/diagrams/pictures for LaTeX. There are too many of them, with too much overlapping functionality. My experience has been that these packages are limited, fragile, verbose in the extreme, and produce only mediocre-looking diagrams (if they don't overload TeX by typesetting 28272 dots to fake a smooth curve.)

  2. Use tools that can be made to produce EPS output. For example, some of the stuff that comes with almost any Linux distribution:

    • Illustration: Metapost is a dialect of Knuth's Metafont language, that is designed for mathematical and technical illustration. It outputs directly to EPS format. Use Metapost if you're in need of algorithmically generated, highly precise illustrations, color and shading, or heavy use of TeX typesetting within diagrams.

      This is not without its downsides. Like Metafont and TeX, Metapost is a bizarre but powerful language. It combines a heavily declarative style (it will actually solve systems of equations to determine where things go) with imperative features and loops, and syntax elements taken from both C and Pascal.

    • Diagramming: GNU Pic is a free implementation of Brian Kernighan's original PIC language. There's a fun CACM article from the 80's with examples, which is how I first found out about it. The central idea is that Pic is a language to build abstract diagrams involving simple shapes, points, lines, and curves with prebuilt commands for labeling and arranging all the above. Pic has a much simpler syntax than Metapost, and its intuitive object-placement commands and relative positioning mean that you almost never have to use absolute coordinates or lay things out on graph paper first. If you declare your splines and lines correctly, the output can look really fabulous.

      PIC is well-suited to discrete-math kinds of diagrams with only minimal need for text labels: graph theory, data structures/algorithms, pipes and filters, basic software architecture diagrams (not too complex, PIC is not UML!) simple scatter/line plots, state transition diagrams, automata theory diagrams, and that sort of thing. PIC's economy and loose syntax are especially nice if you will automatically generate diagrams from code or other data, as some C.S. texts do.

      Integrating PIC into your documents is a slightly weird issue; you can use groff to get postscript straight off, but this prevents you from using TeX math or fonts in the diagram. The alternative is to embed the diagram source in your TeX, and run the entire thing through GNU Pic in its TeX mode to change the diagram into TeX specials. XDVI and DVIPS will correctly render these, but DVIPDF does not.

    • Wysiwyg. The venerable Xfig is always available, it usually comes with your X distribution. Its large library of premade symbols is a plus; I used it to design great-looking circuit diagrams for a digital logic class last year. However, xfig's interface is rather weird and harsh-looking, so it's nice to have Dia as an alternative. Through EPS, both tools are easy to integrate with LaTeX. And of course, you can always use GIMP's EPS output if you need to integrate bitmaps.

  3. At the {La}TeX level, use nothing but \epsfbox{} and related commands to include your EPS figures. This is a simple and consistent way of including all your graphics and illustrations regardless of how they were made. If they come from source files in pic, fig, or metapost, you can use make to manage the project and update the EPS when needed.

It's pretty neat that even after 25+ years, UNIX still excels at one of its earliest uses: advanced document preparation and typesetting applications. Because it is used so heavily for this, it is also a great environment for learning computer science: even after more than a year using Linux, I am amazed at the immense resources for education available to the Linux user, both in the enormous volume of useful programs installed with the typical distro, and in easily being able to read the various postscript papers, technical reports, articles, and books found online, or download and examine the source to so many UNIX applications.

Neat stuff.

I have been doing a lot of work on Octal's graphical interface. I want very much for the program to reach usable beta as soon as is possible, and since I have this entire week off I'm going to try the best I can to bring it there.

The new widget builder is in place... the most common three widgets are implemented and functioning. I also incorporated a little bug-fix that solves a glitch in the connection drawing code; thanks to Richard Todd from the mailing list.

Check out the screenshots page to see pics. The weekly tarball should be online Sunday evening.

In other news, I am very pleased to hear that Gnu.org is modernizing its administration tools. I was recently told that updating of www.gnu.org has been moved entirely to CVS (which means I finally have to learn it :-). Overall this is a good thing---as has been their use of SSH tools on some machines in the gnu network. I just never could get Kerberos working correctly for very long... it always seemed to break. Kudos to GNU for upgrading.

Testing.

25 Feb 2001 (updated 1 Mar 2001 at 04:21 UTC) »

Last week before vacation... oooohhohohhhooooohhhhh!

Octal. Very pleased. We're about to renovate the old Octalmachines sourceforge site and turn it into a repository for machine developers and gearlib folks. Basically, a community site with real potential. I've got some folks to help out with that side of things while I continue to focus on the main application and its development.

School. Today I had a doctor's appointment in the morning, then visited the town hall to pick up Zero's new dog license and also to get a notarized proof of my Massachusetts residency (for the grad school application.) I also ordered a transcript from the community college I went to in 1996-1997 (whoa, long time ago!).

Octal stuff

Got the "default parameters" thing working. Also fixed a nasty "variable not getting initialized" kind of bug while I was at it. That DDD program is saving me lots of time---thanks again GNU/FSF.

I'm putting the tarball online tomorrow or so. No matter how difficult I think something is going to be, just working for a little while makes it better :-).

Other

Ari and I went to see Crouching Tiger, Hidden Dragon today. What a wonderful movie!

Good mood today... last night I typed up a quick proof for a problem the students hadn't been able to figure out, and sent them a PDF. Tutored some more between 10-12 (mostly we went over how to construct an NFA from a right-linear grammar, which is a neat procedure) and then came home. I'm going to try to get my art project done today, and I want to do some Octal work as well.

Last night's show went very well. Twenty minutes before I went on, Ariane showed up. Ten minutes before I went on, Ari pulled out her microphone and suggested we do another spontaneous abstract-girl-vocals accompaniment, like we had done in NYC last june. Steve hooked us up and we were ready to go. I'd say it went pretty well, the audience seemed to have a good time, and Ari's vocal improvisations were fabulous.

I even made thirty bucks,but my parking ticket will cost half of that :-(. Anyway I'm tutoring later on, will work on Octal after that.

What an incredibly long day. I awoke at 7:15 to leave for school, and then had that calculus exam. Between 10:20 and 12:30 I tutored, then after Physics class we had our robotics project meeting. I decided to build a base much like the tank-style one in the Mindstorms Constructopedia (but with a better processor and sensor system.) I'm most likely going to be doing a subsumption-style architecture... nerves, signals, responses etc.

From 5PM to 7:30 I tutored in theory of computation... we went over the correspondence between NFA and regular expressions, conversion of NFA to DFA, lambda transitions, etc etc etc. What a long process. Many of the students had inadequate discrete maths background, so if we are talking about how the transition function of a DFA is going to map {states}x{alphabet} --> {states} and they don't know what the cartesian product of sets is... eeh. I hear some of them are on their third try with this course! I can't blame them, really. I have been to several state schools here, and Discrete Maths is not taught very well. Plus, this is a 7AM course that combines day and night students, and some of the night people haven't had discrete math in years!

I'm not really sure what to do. From what they tell me, their understanding is helped by the explanations and examples, so maybe it will be enough. To get them through. Otherwise they don't graduate :-( the course is required.

I have a 3-day weekend coming up. I can't wait to attack Octal and get some more coding done. There will be a developer's release this weekend, including plugin-testing interactive bits and the revised/finished API.

60 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!