[Bug translator/6847] New: $$parms/$$vars should be $$*

[Bug translator/6847] New: $$parms/$$vars should be $$*

[mhiramat at redhat dot com]

Because kernel already uses 'parms' variables;
$ cscope -L -1 parms 
drivers/isdn/hardware/eicon/divacapi.h parms 148 API_PARSE parms[MAX_MSG_PARMS+1];
drivers/scsi/osst.c parms 104 } parms[] __initdata = {
drivers/scsi/st.c parms 116 } parms[] __initdata = {
fs/isofs/rock.h parms 79 char parms[2];
include/net/dn_dev.h parms 89 struct dn_dev_parms parms;
include/net/ip6_tunnel.h parms 24 struct ip6_tnl_parm parms;
include/net/ipip.h parms 26 struct ip_tunnel_parm parms;
include/net/neighbour.h parms 99 struct neigh_parms *parms;
include/net/neighbour.h parms 157 struct neigh_parms parms;
net/atm/clip.c parms 327 .parms = {
net/decnet/dn_neigh.c parms 102 .parms ={
net/ipv4/arp.c parms 181 .parms = {
net/ipv6/ndisc.c parms 141 .parms = {
net/sched/sch_gred.c parms 43 struct red_parms parms;
net/sched/sch_red.c parms 43 struct red_parms parms;
sound/isa/sb/emu8000.c parms 702 unsigned short parms[28];
sound/oss/midibuf.c parms 48 static struct midi_parms parms[MAX_MIDI_DEV];

-- 
           Summary: $$parms/$$vars should be $$*
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mhiramat at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$*

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-08-17 15:25 -------
In reality, there is no namespace collision.
We use "$$" prefixes only for metavariables.

The "$" *suffix* suggested in bug #3672 was done
specifically to avoid namespace collisions of the
kind you are looking for here.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$*

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-08-17 20:06 -------
(In reply to comment #1)
> The "$" *suffix* suggested in bug #3672 was done
> specifically to avoid namespace collisions of the
> kind you are looking for here.

I think this also could simplify the syntax including bug #3672.

- one $ (ex. $var, $return): returns the value of var or return value.
- two $ (ex. $$var, $$return, $$*): returns the values with variable names.
- more than two $ (ex. $$$var, $$$*): returns the values ($ means the depth of
nesting) with variable names.

And the simple syntax also simplifies parser :-) (don't requires 'suffix' parsing)

Thank you,

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$*

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-08-17 20:10 -------
(In reply to comment #2)
> And the simple syntax also simplifies parser :-) (don't requires 'suffix' parsing)

Additionally, it could allow us to implement consistent variable filtering
syntax like $$__* (expanded only to __vars, not _vars nor vars.)

I think this wildcard rule is already familiar to systemtap users.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$*

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-08-18 14:53 -------
> > The "$" *suffix* suggested in bug #3672 was done
> > specifically to avoid namespace collisions of the
> > kind you are looking for here.
> 
> I think this also could simplify the syntax including bug #3672.

Let's just say they are opposing proposals.

> - one $ (ex. $var, $return): returns the value of var or return value.
> - two $ (ex. $$var, $$return, $$*): returns the values with variable names.
> - more than two $ (ex. $$$var, $$$*): returns the values ($ means the depth of
> nesting) with variable names.

One obstacle in this scheme's way is that there are material
differences betewen the various metavariables ($$return,
$$vars, $$parms, $$locals, and perhaps others in the future).
They can't all match "*".  Further, there is interplay with
.return probes' optional saving of invocation-time variables.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$* or $$%parms/$$%vars

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-08-18 15:12 -------
(In reply to comment #4)
> One obstacle in this scheme's way is that there are material
> differences betewen the various metavariables ($$return,
> $$vars, $$parms, $$locals, and perhaps others in the future).
> They can't all match "*".  Further, there is interplay with
> .return probes' optional saving of invocation-time variables.

Indeed. In that case, metavariables might better have another
character which C language doesn't use, like $$%locals, $$%parms, etc.

What would you think?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|$$parms/$$vars should be $$*|$$parms/$$vars should be $$*
                   |                            |or $$%parms/$$%vars


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$* or $$%parms/$$%vars

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-08-18 15:25 -------
(In reply to comment #5)
> (In reply to comment #4)
> > One obstacle in this scheme's way is that there are material
> > differences betewen the various metavariables  [...]

> Indeed. In that case, metavariables might better have another
> character which C language doesn't use, like $$%locals, $$%parms, etc.

I'd rather keep the status quo, and use new $ suffixes for
struct-expanded variants of any particular variable (including
metavariables).


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6847] $$parms/$$vars should be $$* or $$%parms/$$%vars

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-08-28 16:08 -------
(In reply to comment #6)
> I'd rather keep the status quo, and use new $ suffixes for
> struct-expanded variants of any particular variable (including
> metavariables).

Ok, so let's close this bug :)


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=6847

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.