fadr

fadr

[Chong Yidong]

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.

Re: fadr

[Thien-Thi Nguyen]

() 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

Re: fadr

[Dmitry Dzhus]

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
む

Re: fadr

[Thien-Thi Nguyen]

() 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

Re: fadr

[Dmitry Dzhus]

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
む

Re: fadr

[Chong Yidong]

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.

Re: fadr

[Glenn Morris]

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.

Re: fadr

[Dmitry Dzhus]

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
む

Re: fadr

[Stefan Monnier]

> (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

Re: fadr

[Nick Roberts]

 > 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

Re: fadr

[Dmitry Dzhus]

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
む

fadr

[Nick Roberts]

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