From: Dmitry Dzhus <dima@sphinx.net.ru>
To: emacs-devel@gnu.org
Subject: Re: fadr
Date: Mon, 22 Jun 2009 23:56:27 +0400 [thread overview]
Message-ID: <873a9sghzo.fsf@sphinx.net.ru> (raw)
In-Reply-To: 873a9sz1my.fsf@ambire.localdomain
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
む
next prev parent reply other threads:[~2009-06-22 19:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 15:12 fadr Chong Yidong
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
2009-06-22 19:56 ` Dmitry Dzhus [this message]
2009-06-23 9:14 ` fadr Thien-Thi Nguyen
2009-06-22 16:27 ` fadr Dmitry Dzhus
2009-06-22 16:39 ` fadr Chong Yidong
2009-06-22 18:24 ` fadr Glenn Morris
2009-06-22 21:57 ` fadr Dmitry Dzhus
2009-06-24 21:33 ` fadr Stefan Monnier
2009-06-23 5:54 ` fadr Nick Roberts
2009-06-22 21:38 ` fadr Dmitry Dzhus
2009-06-23 5:47 ` fadr Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873a9sghzo.fsf@sphinx.net.ru \
--to=dima@sphinx.net.ru \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).