* fadr
@ 2009-06-22 15:12 Chong Yidong
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Chong Yidong @ 2009-06-22 15:12 UTC (permalink / raw
To: Nick Roberts; +Cc: Dmitry Dzhus, emacs-devel
Hi Nick,
I noticed that you checked in fadr.el into lisp/. After looking through
the file, I have significant reservations:
* A Lisp utility library like this should go into lisp/emacs-lisp/
instead of the main lisp/ directory.
* It's completely unclear what "fadr" stands for. If we keep this
file, we must rename it to something less cryptic.
* More fundamentally, I think the way this library works is misguided.
The example given in the commentary says:
(setq basket '((apples . (((color . green) (taste . delicious))
((color . red) (taste . disgusting))))))
Its contents may be accessed using `fadr-member':
(fadr-member basket ".apples[1].color")
red
If I understand correctly, this smacks of trying to shoehorn C
structure-addressing habits into Emacs Lisp. Passing a "black-box"
string argument like ".apples[1].color" is ugly and un-Lispy.
Unless there is some overriding reason, I think the GDB-MI project
should drop the fadr dependency. If you need a way to interface easily
with nested structures, I suggest using Common Lisp structures, i.e. the
`defstruct' macro which has been in cl-macs.el for a long time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 15:12 fadr Chong Yidong
@ 2009-06-22 16:14 ` Thien-Thi Nguyen
2009-06-22 19:56 ` fadr Dmitry Dzhus
2009-06-22 16:27 ` fadr Dmitry Dzhus
` (2 subsequent siblings)
3 siblings, 1 reply; 12+ messages in thread
From: Thien-Thi Nguyen @ 2009-06-22 16:14 UTC (permalink / raw
To: emacs-devel
() Chong Yidong <cyd@stupidchicken.com>
() Mon, 22 Jun 2009 11:12:58 -0400
Unless there is some overriding reason, I think the GDB-MI
project should drop the fadr dependency. If you need a way to
interface easily with nested structures, I suggest using Common
Lisp structures, i.e. the `defstruct' macro which has been in
cl-macs.el for a long time.
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. If we already have a tree,
`bindat-get-field' tweaked or extended is preferable to
`fadr-member' stunted or recast.
Put another way, i'd rather see:
(bindat-get-field/searching basket 'apples 1 'color)
than:
(fadr-member basket ".apples[1].color")
Insert Perlis quote re strings, here....
thi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 15:12 fadr Chong Yidong
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
@ 2009-06-22 16:27 ` Dmitry Dzhus
2009-06-22 16:39 ` fadr Chong Yidong
2009-06-22 18:24 ` fadr Glenn Morris
2009-06-22 21:38 ` fadr Dmitry Dzhus
2009-06-23 5:47 ` fadr Nick Roberts
3 siblings, 2 replies; 12+ messages in thread
From: Dmitry Dzhus @ 2009-06-22 16:27 UTC (permalink / raw
To: Chong Yidong; +Cc: Nick Roberts, dima, emacs-devel
Thanks for seeing my code.
Chong Yidong wrote:
> * It's completely unclear what "fadr" stands for. If we keep this
> file, we must rename it to something less cryptic.
Fast adressing.
> * More fundamentally, I think the way this library works is misguided.
> The example given in the commentary says:
>
> (setq basket '((apples . (((color . green) (taste . delicious))
> ((color . red) (taste . disgusting))))))
>
> Its contents may be accessed using `fadr-member':
> (fadr-member basket ".apples[1].color")
> red
>
> If I understand correctly, this smacks of trying to shoehorn C
> structure-addressing habits into Emacs Lisp. Passing a "black-box"
> string argument like ".apples[1].color" is ugly and un-Lispy.
It seemed to me to be not lispy enough from the very beginning, but I
couldn't think of a better replacement, with «better» meaning «allowing
to write compact yet expressive code». The problem with fadr is that
it's deliberately untyped.
> Unless there is some overriding reason, I think the GDB-MI project
> should drop the fadr dependency. If you need a way to interface easily
> with nested structures, I suggest using Common Lisp structures, i.e. the
> `defstruct' macro which has been in cl-macs.el for a long time.
I didn't know about this, thanks for pointing out at this facility. I'm
familiar with similar kind of structures from some experience I had with
Scheme. I'll see how I can fit this in my code to work with GDB/MI
responses.
I should use `(eval-when-compile (require 'cl))`, right?
--
Happy Hacking.
http://sphinx.net.ru
む
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 16:27 ` fadr Dmitry Dzhus
@ 2009-06-22 16:39 ` Chong Yidong
2009-06-22 18:24 ` fadr Glenn Morris
1 sibling, 0 replies; 12+ messages in thread
From: Chong Yidong @ 2009-06-22 16:39 UTC (permalink / raw
To: Dmitry Dzhus; +Cc: Nick Roberts, emacs-devel
Dmitry Dzhus <dima@sphinx.net.ru> writes:
> I didn't know about this, thanks for pointing out at this facility. I'm
> familiar with similar kind of structures from some experience I had with
> Scheme. I'll see how I can fit this in my code to work with GDB/MI
> responses.
Thien-Thi Nguyen has also suggested using bindat.el. His email did not
include you in the CC, and I don't know if you are subscribed to
emacs-devel. This is a good suggestion if you're working with binary
data rather than Lisp objects (I am not sure about your usage case.)
The bindat.el file can be found in the lisp/emacs-lisp directory.
> I should use `(eval-when-compile (require 'cl))`, right?
If you choose to use the cl package, then yes.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 16:27 ` fadr Dmitry Dzhus
2009-06-22 16:39 ` fadr Chong Yidong
@ 2009-06-22 18:24 ` Glenn Morris
2009-06-22 21:57 ` fadr Dmitry Dzhus
2009-06-23 5:54 ` fadr Nick Roberts
1 sibling, 2 replies; 12+ messages in thread
From: Glenn Morris @ 2009-06-22 18:24 UTC (permalink / raw
To: Dmitry Dzhus; +Cc: Chong Yidong, Nick Roberts, emacs-devel
Also, could you write proper ChangeLog entries that actually describe
the changes, please? See the existing ones for the format.
Something like this is kind of useless:
2009-06-22 Dmitry Dzhus <dima@sphinx.net.ru>
Nick Roberts <nickrob@snap.net.nz>
* progmodes/gdb-mi.el: Pull further modified changes from
Dmitry's repository (http://sphinx.net.ru/hg/gdb-mi/).
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
@ 2009-06-22 19:56 ` Dmitry Dzhus
2009-06-23 9:14 ` fadr Thien-Thi Nguyen
0 siblings, 1 reply; 12+ messages in thread
From: Dmitry Dzhus @ 2009-06-22 19:56 UTC (permalink / raw
To: emacs-devel
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
む
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 15:12 fadr Chong Yidong
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
2009-06-22 16:27 ` fadr Dmitry Dzhus
@ 2009-06-22 21:38 ` Dmitry Dzhus
2009-06-23 5:47 ` fadr Nick Roberts
3 siblings, 0 replies; 12+ messages in thread
From: Dmitry Dzhus @ 2009-06-22 21:38 UTC (permalink / raw
To: emacs-devel
Chong Yidong wrote:
> If you need a way to interface easily with nested structures, I
> suggest using Common Lisp structures, i.e. the `defstruct' macro which
> has been in cl-macs.el for a long time.
As long as I understand, with `defstruct` and friends I'll need to
declare structure types for each level of my tree-like structure so that
I can nest structure slot accessor calls, e.g.:
(defstruct threads-response threads current-thread-id)
(defstruct thread id target-id state frame)
(defstruct frame level addr func args file fullname line)
(defstruct arg name value)
(setq threads
(make-threads-response
:threads
(list
(make-thread :id "1"
:target-id "LWP18334"
:frame (make-frame :level "0"
:addr "0x08048b9a"
:func "mult_matrices_mt"
:args (list (make-arg :name "m1"
:value "0x08048b9a")
(make-arg :name "m2"
:value "0x0804ba30"))
:file "test.c"
:fullname "/home/sphinx/projects/gsoc/test.c"
:line "142")
:state "stopped"))
:current-thread-id "1"))
(frame-func (thread-frame (first (threads-response-threads threads))))
I'll also need to convert my list-alist trees (I've provided a real
example of trees I deal with in my previous mail in this thread) to such
structures, though it doesn't seem complex to me. What's good in
`defstruct` is that it provides simple type and schema checking, so if
my structures get spoiled (which is unlikely, but may happen if GDB's MI
changes output format), it will be easier to debug related bugs. I don't
think if this is worth investing effort right now, though, probably
`binopt.el` code will be sufficient.
I believe `defstruct` doesn't impose any performance overhead? Given
that I need to handle much less then a hundred trees per one short
timeframe.
I've grepped through Emacs sources, looking for examples of using
`defstruct`, but I haven't found anything resembling my case.
I've also found the following notice (mh-loaddefs.el:70):
> The `defstruct' in the "cl" library produces compiler warnings, and
> generates code that uses functions present in "cl" at run-time.
— is this true?
The following sentence from cl package info manual is a bit unclear to me:
> Also, the `:type' slot option is ignored.
Does this mean that `defstruct` procedures are unable to check if slot
values provided to structure constructor are of some certain types?
So :type slot options used around erc-backend.el:109 are merely harmless
annotations for developer?
--
Happy Hacking.
http://sphinx.net.ru
む
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 18:24 ` fadr Glenn Morris
@ 2009-06-22 21:57 ` Dmitry Dzhus
2009-06-24 21:33 ` fadr Stefan Monnier
2009-06-23 5:54 ` fadr Nick Roberts
1 sibling, 1 reply; 12+ messages in thread
From: Dmitry Dzhus @ 2009-06-22 21:57 UTC (permalink / raw
To: emacs-devel
Glenn Morris wrote:
> Also, could you write proper ChangeLog entries that actually describe
> the changes, please? See the existing ones for the format.
Nick did these two big commits for me. When I commit to Emacs CVS myself
I'll make sure to write ChangeLogs. (Sometimes the concept of ChangeLog
file entry seems a duplication of SCM commit message to me, although I
admit that well written ChangeLogs are more pleasant to read than SCM
commit logs). Any more tips on commit policy?
--
Happy Hacking.
http://sphinx.net.ru
む
^ permalink raw reply [flat|nested] 12+ messages in thread
* fadr
2009-06-22 15:12 fadr Chong Yidong
` (2 preceding siblings ...)
2009-06-22 21:38 ` fadr Dmitry Dzhus
@ 2009-06-23 5:47 ` Nick Roberts
3 siblings, 0 replies; 12+ messages in thread
From: Nick Roberts @ 2009-06-23 5:47 UTC (permalink / raw
To: Chong Yidong; +Cc: Dmitry Dzhus, emacs-devel
Chong Yidong writes:
> Hi Nick,
>
> I noticed that you checked in fadr.el into lisp/. After looking through
> the file, I have significant reservations:
I had reservations too but I thought that Dmitry would get better advice about
what to do about it from this mailing list than from me. That indeed seems to
be the case so you can consider the presence of fadr.el to be temporary until
an alternative is worked out.
Is that an acceptable arrangement?
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 18:24 ` fadr Glenn Morris
2009-06-22 21:57 ` fadr Dmitry Dzhus
@ 2009-06-23 5:54 ` Nick Roberts
1 sibling, 0 replies; 12+ messages in thread
From: Nick Roberts @ 2009-06-23 5:54 UTC (permalink / raw
To: Glenn Morris; +Cc: Chong Yidong, emacs-devel, Dmitry Dzhus
> Something like this is kind of useless:
I added this log. I anticipated that this file will change considerably
over the next month or two, so that these early changes will become
largely irrelevant.
Unfortunately there's a limit to how much time I'm able to commit to this work
and I'm trying to focus on the bigger picture, i.e. migrating GDB in Emacs to
use GDB/MI, rather than recording changes in excruciating detail that no-one
will be interested in. Rest assured that later changes will be recorded
more accurately.
> 2009-06-22 Dmitry Dzhus <dima@sphinx.net.ru>
> Nick Roberts <nickrob@snap.net.nz>
>
> * progmodes/gdb-mi.el: Pull further modified changes from
> Dmitry's repository (http://sphinx.net.ru/hg/gdb-mi/).
>
> Thanks.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 19:56 ` fadr Dmitry Dzhus
@ 2009-06-23 9:14 ` Thien-Thi Nguyen
0 siblings, 0 replies; 12+ messages in thread
From: Thien-Thi Nguyen @ 2009-06-23 9:14 UTC (permalink / raw
To: Dmitry Dzhus; +Cc: emacs-devel
() Dmitry Dzhus <dima@sphinx.net.ru>
() Mon, 22 Jun 2009 23:56:27 +0400
[...] I'm pleasantly surprised to see that `bindat-get-field` works
with such tree (and others I have) like charm.
Cool.
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.
As we walk from root to leaf, ...
The difference between these two is [...]
So `fadr-member` is just a reinvented wheel at all.
I'm going to drop it.
... may our steps synch regardless of shoe size.
> 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)?
I believe Perlis was saying all strings are stark. In some cases i would
disagree, but maybe because i'm weird.
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.
When you want to collect several leaves, collect first their common branch,
then proceed from there. This is a missing feature from bindat.el:
(bindat-get-fields STRUCT BRANCH-SPEC LEAF-SPECS)
=> multiple values (or what have you);
either: all leaves
or: branch, plus all leaves
Would you like to add it?
thi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fadr
2009-06-22 21:57 ` fadr Dmitry Dzhus
@ 2009-06-24 21:33 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2009-06-24 21:33 UTC (permalink / raw
To: Dmitry Dzhus; +Cc: emacs-devel
> (Sometimes the concept of ChangeLog file entry seems a duplication of
> SCM commit message to me, although I admit that well written
> ChangeLogs are more pleasant to read than SCM commit logs).
No need to write it twice: just write the ChangeLog entry and then pull
it into the commit message via C-c C-a (in *VC-Log* or *cvs-commit*).
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-06-24 21:33 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-22 15:12 fadr Chong Yidong
2009-06-22 16:14 ` fadr Thien-Thi Nguyen
2009-06-22 19:56 ` fadr Dmitry Dzhus
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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.