Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Doug Evans <dje@google.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: RFC: block of commands
Date: Sun, 24 Jan 2016 22:23:00 -0000	[thread overview]
Message-ID: <1453674323.2097.91.camel@skynet.be> (raw)
In-Reply-To: <CADPb22S7u6YinHKSh-keg8SvP8d4847BLVW1Gqqf-RyJbVM=Ww@mail.gmail.com>

On Sun, 2016-01-24 at 12:03 -0800, Doug Evans wrote:
> On Fri, Jan 22, 2016 at 1:49 PM, Philippe Waroquiers
> <philippe.waroquiers@skynet.be> wrote:
> >
> >
> > I think that effectively, the principles you suggest below
> > should allow to make a reasonable syntax, and no backward
> > incompatibility.
> > So basically:
> >   * trailing } is mandatory
> >   * inside a block of commands, { } and ;  must be escaped
> >   * a command block is limited to be on a single line
> >     I guess multiple lines will be ok if each line is terminated
> >     by a \.
> >
> > The above principles should also allow to extend if/while/...
> > to have 'one line' if/while/...
> >
> > I also think that 'one line if' will allow to do things such as:
> >
> >    thread apply all if $ebp -$esp > 1000000 { echo big frame in this thread }
> >
> > (today, trying to use an 'if' in thread apply gives a quite strange
> >  behaviour : the rest of the 'if' command is read during each execution
> > for each thread, which is not very user friendly :).
> >
> > I will work based on the above idea, and resubmit a draft patch
> > but that will for sure have to wait after FOSDEM, which
> > will already consume the night and week-end free time :).
> >
> > Thanks for the comments/help/nice suggestions
> >
> 
> 
> Hi.
> Sounds like a plan, but in an effort to make your time
> as productive as I can I would suggest first trying to come
> up with syntax that the community can accept.
Good idea, the plan is easier to write than the code.
> 
> Among the questions we need to answer:
> - when/how to escape { } ;
>   (what I gave was a strawman, I didn't dig deep
>   into whether there are any gotchas)
> - what to do with { } in expressions,
>   e.g., "if ({1,2,3})[2] == 3 { echo foo }"
> - ???
Here are some more details/answers:

Basic syntax
------------
Block of commands are single line, trailing } are mandatory.
These conditions are needed to allow to extend existing commands
(thread apply, if, while) in a (reasonably) backward compatible way.
The parsing of command blocks will be deferred to the commands
that accepts block of commands (or commands) as parameters.

Commands in a block are separated by ;.
; is optional in front of a { or a }, e.g.

   {  echo 1\n  { echo 2\n;  echo 3\n ; }  echo 4\n }


Escaping:
---------
{ } ; must be escaped inside a block of commands in order
to lose their 'block of command special character semantic'.

A single \ is good enough to escape, no need to have a \ for each
nesting level, e.g.
     thread apply all { echo \{ at nesting 1 { echo \; at nesting 2 } }

No need to escape in expressions which are 'at nesting 0', e.g.
    if ({1,2,3})[2] == 3 { echo foo }

The 'if' command parser will search for a trailing }
and will parse backward to search the matching opening {, counting
nesting levels. So, thanks to backward parsing, {}; do not need to
be escaped in expressions.
Only problem I see with this are expressions that are
terminated with a }.
Then the parser might confuse such an expression in an 
'end terminated if' with a block of command of
a 'single line' if.
So, probably we will have to handle escaping the final } of such an
expression.
However, that will be a backward incompatibility.
I guess this incompatibility is unlikely, unless there is a language
where } are often terminating an expression ?
I do not see how to avoid this (unlikely?) backward incompatibility.

When 'if' is used inside a command block, then special characters
in the expression must be escaped e.g.
   thread apply all { if (\{1,2,3\})[2] == 3 { echo three } }


Error handling
--------------
   {/s  ...   }
means to continue executing the block if a command fails;
all the output of failing commands are silently ignored.

   {/c .... }  
also means to continue executing the block if a command fails,
but the error is reported.

Extension of existing commands
------------------------------
Commands that have a command as parameter or read other commands
will be extended to accept a block of commands (which must be
at the end of the line).
So:
   thread apply all { .... }
   if expression { ... } [else { ... } }
   while expression { ... }
Is there something else to extend ?

Maybe single line  define such as
  define helloworld { echo hello;  echo world\n }
?

Have a way to silence some commands using optional /s marker
------------------------------------------------------------
E.g.
  thread apply all /s  command
means that a thread is shown only if command has produced some output

Some new commands
-----------------
As discussed, new command 
  frame apply all 
accepting also an optional /s

For completeness, I guess we better have:
  inferior apply all ....
(and optional /s marker) 


The idea is that all the above can be combined e.g.
   inferior apply all /s  { thread apply all /s  { frame apply all /s  if condition { echo look at this inferior/thread/frame }}}
(long single lines like that can be broken in separate lines using \ at the end of the line).
Note: I guess that the parser of inferior/thread/frame apply all
can be a 'forward parser', and so the first two { will be optional for the above.
Otherwise, inferior/thread/frame will also look for a terminating } and do a backward
parsing, then in the above example, all { } are needed to allow backward parsing.

I would have preferred to avoid the (unlikely I hope) incompatibility of }
terminated expressions, but I do not see a reasonable way to do that.

Comments/remarks/plan-killer-bugs/... welcome. 

Philippe


  reply	other threads:[~2016-01-24 22:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21  1:29 Doug Evans
2016-01-22 21:47 ` Philippe Waroquiers
2016-01-24 20:03   ` Doug Evans
2016-01-24 22:23     ` Philippe Waroquiers [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-01-11 21:40 Doug Evans
2016-01-12 20:52 ` Philippe Waroquiers
2015-11-21 18:41 Philippe Waroquiers
2015-12-03 22:28 ` Philippe Waroquiers
2015-12-21 13:35   ` Philippe Waroquiers
2016-01-04 19:28 ` Philippe Waroquiers

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1453674323.2097.91.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox