[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rewriting x11-color.scm

From: Neil Puttock
Subject: Re: Rewriting x11-color.scm
Date: Thu, 23 Jul 2009 01:15:03 +0100

2009/7/21 Mark Polesky <address@hidden>:
> I rewrote x11-color.scm so that now the color-list is generated
> semi-automatically. It's more organized, easier to read, and less
> than a quarter of its original size. But does my approach slow
> things down at all? Measurably? I figure the current version is
> probably faster because no calculations need to be made during the
> definition of the color-list. But I don't have a good sense of the
> impact of this. I'm not posting a patch here because I'm pretty
> sure it would be way too big for the list-server.
> Anyway, please comment if you can.

Very nice. :)

A good (but tedious) test of whether it's impacting on compile times
would be to compare doc builds with and without the changes, since
there are so many LilyPond invocations for the snippets.

I've just done an unscientific test comparing `make test-baseline'
compile times, and it actually seems to be a bit quicker (3'35'' vs

(define (append-all arg)
  (let ((arg-list (string-split (string-capitalize arg) #\ )))

I'd replace the space char with #\sp (or #\space) to get rid of the
nasty space before the parentheses (same in make-x11-color-handler).

(define (make-x11-color-handler)
  (let ((x11-color-table (make-hash-table 31)))
    (lambda (arg)
      (let* ((x11-color-table (make-hash-table 31))

This resets the hash table each time x11-color is invoked, so it'll
never cache any colour lookups.

        (if temp
                  (let* ((temp-1 (assq-ref x11-color-list arg-sym))

Indentation's a bit awry here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]