[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fadr
From: |
Dmitry Dzhus |
Subject: |
Re: fadr |
Date: |
Mon, 22 Jun 2009 23:56:27 +0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (gnu/linux) |
Thank you for your feedback, now I really want to discuss what I wrote
and what I should have used instead.
Thien-Thi Nguyen wrote:
> I would also suggest looking at bindat.el, which is adept at wire
> to tree to wire (unpacking/packing) operations for (possibly
> nested) fixed-width data types.
I don't need unpacking, but the lisp structure bindat maps packed data
to is the same as one I use in my code — nested lists and a-lists.
Actually,
> If we already have a tree,
I already have a tree. A lot of different trees with different
structure. Like this, for example:
(setq threads '((threads . (((id . "1")
(target-id . "LWP18334")
(frame . ((level . "0")
(addr . "0x08048b9a")
(func . "mult_matrices_mt")
(args . (((name . "m1")
(value . "0x804ba30"))
((name . "m2")
(value . "0x804ba30"))))
(file . "test.c")
(fullname . "/home/sphinx/projects/gsoc/test.c")
(line . "142")))
(state . "stopped"))))
(current-thread-id . "1")))
I'm pleasantly surprised to see that `bindat-get-field` works with such
tree (and others I have) like charm.
> `bindat-get-field' tweaked or extended is preferable to
> `fadr-member' stunted or recast.
Moreover, it looks like I don't even need to tweak anything, as
`bindat-get-field` is exactly what I was meant to write instead of
`fadr-member`. Its docstring mentions the same C-style dotted notation I
had in mind while writing fadr.
The difference between these two is that `bindat-get-field` is of
variable arity and accepts symbols and integers; for `fadr-member` field
selectors need to be concatenated into a string.
(defun bindat-get-field (struct &rest field)
(let ((path))
(dolist (f field)
(setq path
(concat path
(cond ((integerp f) (format "[%d]" f))
((symbolp f) (format ".%s" f))))))
(fadr-member struct path)))
(inverse is longer)
So `fadr-member` is just a reinvented wheel at all.
I'm going to drop it.
> Insert Perlis quote re strings, here....
So what really makes «stark» strings non-lispy (apart from having a
font-lock color which differs from that of symbols and parenthesis)?
Sometimes I need to access several different leaves of my tree in the
same line, so I wrote `fadr-expand` which works as follows:
(fadr-expand "Thread ~.threads[0].id has name ~.threads[0].target-id"
threads)
=>
"Thread 1 has name LWP18334"
A more realistic example from my code:
(fadr-format "~.id (~.target-id) ~.state in ~.frame.func " thread)
=>
"1 (LWP18334) stopped in mult_matrices_mt "
I coded this function to save some typing. Now I'm in doubts about
whether it follows the spirit of Lisp.
--
Happy Hacking.
http://sphinx.net.ru
む
- fadr, Chong Yidong, 2009/06/22
- Re: fadr, Thien-Thi Nguyen, 2009/06/22
- Re: fadr,
Dmitry Dzhus <=
- Re: fadr, Dmitry Dzhus, 2009/06/22
- Re: fadr, Dmitry Dzhus, 2009/06/22
- fadr, Nick Roberts, 2009/06/23