New library system now in CVS

After the SEUL server move was successfully completed, Ales released a new snapshot of gaf. With that out of the way I was given the all clear to merge my component library work.

I've therefore nuked the "libraries" branch from my public git repository, as it was no longer relevant.

There are a number of things I want to get sorted out before the next release (which is likely to be soon after the next code sprint on 9th June):

1. Rationalise the Scheme files in libgeda and geda-symbols. At the moment, the core rc file for gEDA is installed by the symbol package, and has loads of configure substitions in it. My plan is to:
   • Move all configure substitutions into a single file, config.scm, which would be installed with libgeda;
   • Provide some utility functions for common tasks like building paths from components;
   • Move system-gafrc from geda-symbols to libgeda, and split out the default component library & font setup code into geda-symbols.scm and geda-fonts.scm, which would be installed with geda-symbols.
   Other improvements to the Scheme files could be carried out later, but this would lay the ground-work.
2. While on the subject of Scheme, gEDA currently uses a lot of Guile functions & macros which are marked as deprecated in the current stable branch of Guile, 1.8.x. Since Ales has given the all-clear to move gaf to Guile 1.8, there are number of housekeeping tasks to do:
   • Update gaf configure scripts to check for presence of Guile 1.8 or later. Although currently the scripts check for the presence of certain functions, this is really difficult for developers, because it's something of a moving target, and it's hard to keep the configure scripts up-to-date with all of the functions people have used. It seems a lot more sensible to deal with it the same way as the GTK+ dependency has been dealt with: specify a particular version of Guile to support, and then make sure people do not use functions which require a newer version. Since Guile is very stable, this doesn't seem unreasonable.
   • Flush out all uses of deprecated interfaces, and generally make sure that we are using Guile the Right Way.
   A longer-term aim would be to use "guile-snarf" to generate code for registering Guile procedures made available by libgeda & gschem's C code. This would reduce the number of places where code would have to be changed when adding, removing or modifying a Guile procedure, and would hopefully make life easier for people new to the way libgeda & gschem work with libguile.
3. Replace the C code which currently implements the directory and command component library backends with equivalent Scheme code. This would make the component library code much simpler, and would have the added advantage of providing examples of how to implement new component library backends. This would very much require both a full upgrade to Guile 1.8.x, as well as the aforementioned reorganization of Scheme files.
4. Optimisation of look-ups. A simple optimisation would be to cache the results of s_clib_glob(), probably in a hashtable.

I'm intending to leave the next big killer feature, component categorization, until the release after next.

There are two big things which I'd like to be fixed before the next release that I don't think I'll have time to do:

1. Fix the preview widget to work properly with the new component back-ends. Currently, it needs to have a pathname in order to load the symbol for display, but it should be able to use the o_read_buffer() function I recently added to libgeda.
2. Make gschem be able to open schematic or symbol files not associated with a file (probably read-only). This would be much harder, but is more-or-less required for using gschem as the graphical front-end of a design database system (a future idea).

These are a couple of jobs which follow on from each other quite intuitively, and would make a big difference to my work. If no-one steps forward to do them, I'll probably leave them for the release after next.

Anyway, none of the aforementioned will happen before my exams, which finish on the 8th June, so I guess I'll have an awful lot of coding to get done between the code sprint and the next release!

Chocolate Birthday Cake

We made a rather delicious birthday cake for one of our friends, and it worked so well I thought I'd post it here (because I'm bound to lose the piece of scrap paper it's scribbled on).

For the cake

• 6 oz butter
• 6 oz caster sugar
• 3 eggs
• 8 oz plain white flour
• 3.5 tsp baking powder
• 3 tbsp cocoa powder

Preheat oven 180° C. Whisk eggs. Cream butter and sugar together. Sift in flour and baking powder. Mix cocoa powder and 3 tbsp hot water together to form a paste, and stir in. Add 1 tbsp milk if still stiff. Put in greased 8 in sprung cake tin and bake for 35-40 minutes.

For the icing

• 4 oz butter
• 2 oz sifted cocoa powder
• 8 oz icing sugar

Place cocoa and butter in bowl and microwave on 800 W for 20 seconds. Cream together, and gradually sift in sugar. Add a small amount of milk if too thick. Spread on cake once cool.

Website updates and component library work

In order to put (much) more information about my gEDA work on my website, there's been a slight reorganization; I've made a new section for "software" in which I've put a whole page on gEDA development. It contains more information on my git repositories and the tools I use.

I've also put a list of things I've been working on recently, and a list of things I've got planned.

I've now been able to implement support for using Guile functions as the backend for a component library. Amusingly, I worked out that both directory and command backends could be easily (trivially?) implemented using this feature, assuming the appropriate Scheme functions for reading files & directories and executing programs were available. And I suspect that this would be a lot easier than the large amount of C code I currently have to do this. However, I cannot guarantee that the necessary libraries will be present on a user's system, so I think that it's going to stay the way it is for the time being.

I'm getting quite concerned by the huge stack of changes I need to commit to CVS, and I'm hoping that not too many things will change on the CVS trunk before I get the chance to get my stuff in. Fortunately I think I should be able to use stgit to make sure my trees don't diverge too far from CVS.

Better blogging with Emacs

Having got Emacs 22 set up with g-client I rapidly got annoyed with the necessity of continually copying and pasting URLs from a web browser window in order to post to my blog and to page through the posts available, so I quickly hacked together some ELisp to make it easier:

;;; Blogger support
(add-to-list 'load-path "~/.emacs.d/site-lisp/g-client")
(load-library "g")
(setq blog-feed-url "http://www.blogger.com/feeds/<blognum>/posts/default")
(setq blog-feed-page-size 25)
(defun blog-post nil "Post to weblog" (interactive)
  (gblogger-new-entry blog-feed-url))
(defun blog-feed (&optional page) 
  "View recent weblog posts" (interactive "p")
  (let ((n (+ 1 (* (- page 1) blog-feed-page-size))))
    (gblogger-atom-display 
     (concat blog-feed-url
	     "?start-index=" (number-to-string n)
	     "&max-results=" (number-to-string blog-feed-page-size)))
    (message "Viewing blog posts from %d to %d" n (+ n blog-feed-page-size))))

Once you've set blog-feed-url to the correct URL for your blog, you can use blog-post to start a new page, and blog-feed to view your posts. A prefix parameter passed to blog-feed will view that page of entries: for instance, C-u 8 M-x blog-feed will view page 8 of your blog entries (entries 175 to 200, given the default setting of blog-feed-page-size).

Unfortunately, this still isn't ideal; what would be best is for gblogger-atom-display to display a list of blog entries in a buffer, with clickable view and edit text. Having to use an external program feels like something of a hack.

Also, I turned out to be right about the reason for not being able to post new entries; it was that I'd published too many in a short period of time, and had activated Blogger's anti-spam mechanism. Everything works fine again now. However, it would be nice if posting via the Blogger API gave you a meaningful error message rather than just throwing your post away.

Tab-completion in Emacs' c-mode

For a long time, I've wanted tab-completion in Emacs when programming in C, and haven't had the time to delve into ELisp enough to work out how to do it. However, thanks to the Emacs Wiki I now have it working!

I added the following to my .emacs file:

; Better tab completion
(defun indent-or-complete ()
  "Complete if point is at end of a word, otherwise indent line."
  (interactive)
  (if (looking-at "\\>")
      (dabbrev-expand nil)
    (indent-for-tab-command)))
(add-hook 'c-mode-common-hook
          (function (lambda ()
                      (local-set-key (kbd "<tab>") 'indent-or-complete))))

And now it works very nicely indeed!

Blogger annoyances and Emacs 22

When I set up my weblog on Blogger I made the error of enabling an option which caused all newline characters in my postings to be converted to literal HTML newlines (<br>). This was fine for a long time, until I wanted to write my blog postings in a text editor with HTML support (such as Emacs) and then copy them into my weblog. Emacs has really good support for general text editing and word-wrapping in particular, so once I started using it for editing blog postings using the automatic newline conversion mode didn't really make sense.

Unfortunately, I couldn't just turn off the conversion, because then I'd lose formatting in all of my older posts. Today I finally bit the bullet and switched it off, going through many (but not all) of my older posts adding explicit paragraph tags. I couldn't be bothered to convert every posting, however, so there are probably several posts dotted around with decidedly dodgy formatting. I did take the opportunity to delete some rather useless posts (like "Friday Five" and "Unconscious Mutterings" posts -- anyone remember those from Back In The Day?)

While on the subject of Emacs, I today discovered the joy of Emacs 22, built from CVS. This is going to be the next major version of Emacs, and has loads of awesome features, like the ability to use GTK widgets, and proper UTF8 support. In particular, it supports the g-client library, part of the Emacspeak project, which allows me to post to Blogger directly from Emacs. It would much more convenient than having to fire up Firefox (Blogger doesn't support Firefox) and mess about with the Blogger website, if it worked. Unfortunately, although I can edit blog entries, I can't seem to post new ones, which is most bizarre. I feel an e-mail to the maintainer coming on.

There are many other good things about Emacs 22: left clicking on links in dired and help buffers spring to mind in particular. I really recommend that regular Emacs users check it out from CVS and try it out.

Update: I think the problem with g-client was that due to (re)posting so many old entries, I'd triggered an anti-spam setting that requires me to complete a captcha -- and thus use the Blogger website -- for the next 24 hours. So hopefully it'll start Just Working tomorrow.

New component library for gEDA

Rather than revising for my exams, I've been rewriting the gEDA component library system. The motivation was to provide a way to use the output of arbitrary commands as symbols in your schematic, and to have a way for code in gEDA applications to find and use schematic symbols without caring about where they're coming from.

My new all-singing all-dancing code is now in a runnable state, and I've put it on my public git repository in the "libraries" tree (breaking my "master" tree in the process, but hey). You can get it using the command:

cg-clone git://repo.or.cz/geda-gaf/peter-b.git

(Update: If you don't use git, you can get a magic patch between CVS and my libraries tree.)

I'm hoping to get the changes into CVS before the next code sprint (which has yet to be scheduled). For people wishing to try them out before then, it is important to note:

1. These patches touch a large amount of libgeda, and I have not tested whether or not they break anything other than gschem. gEDA with these patches applied should be considered dangerous; do not use it on production data. If it steals your car and runs over your dog, don't say I didn't warn you.
2. From a users point of view, gschem should operate exactly the same as without these patches applied. Please let me know of any changes/regressions.
3. These patches change the embedding mechanism. Embedding is now indicated by a single boolean flag (OBJECT.complex_embedded). However, the existing functions for (un)embedding and checking status have been retained.
4. There are extensive DOxgyen comments explaining the operation of the system in libgeda/src/s_clib.c. If they are insufficiently illuminating, please tell me what needs expanding on.

There are a number of bugs and things that still need to be done:

1. The lists of sources/symbols should be sorted by name.
2. A source type based on Guile callbacks would be good, so that users could define their own symbol-generating functions without needing to write extra external programs. It also wouldn't be too difficult to do.
3. Although I tried hard to protect the data structures containing the component source and symbol data from damage by making pointers to them "const" wherever possible, it is still possible for non-const pointers to the structures to be obtained using the functions which return GLists.
4. It would be great to be able to categorize symbols in a more fine-grained manner than just by which source they came from.
5. Searching for symbols is still quite a brute-force process, and needs to be optimised (lots of hashtables).
6. At the moment, component library commands are required to implement certain arguments ("get" and "list"). It would be nice for command sources to have custom arguments used to retrieve symbol data or lists of symbols.
7. It would be nice not to have to load a list of every single symbol available at startup. If symbols were being obtained from e.g. a database server, it would slow down gschem start significantly. This would fundamental changes to the way the component selector dialog works (a custom GtkTreeModel would be required) but other than that there are no major API obstacles.
8. Reviewing and descending hierarchy doesn't work for symbols without a filename (i.e. not from a directory-based library).

Send me any comments, complaints, suggestions, bug/crash reports, patches etc. I don't guarantee to do anything with them anytime soon, because if I don't do some studying now I'll be in big big trouble.