Robustifying pretty-printers

Robustifying pretty-printers

[Vladimir Prus]

While playing with pretty-printers and KDevelop, I've got GDB
to "hang", with the below backtrace:

	(gdb) where
	#0  0xb7d0ed2a in strcmp () from /lib/tls/i686/cmov/libc.so.6
	#1  0x081be1a7 in install_variable (var=0x191b0620) at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1731
	#2  0x081beef7 in create_child_with_value (parent=0x8a6e158, index=514255, name=0xb7bf8e14 "[514255]", value=0x191b03d0)
    at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1859

The '514255' above is sufficient to understand what happened. Our beloved GCC fails to emit
proper debug info, therefore a vector is considered in scope before constructor is executed,
and the vector is full of random bits.

Now, what are the best strategies for fix this (assuming GCC won't be
fixed for 10 years to come)? One approach is to make IDE check at what
line the variable is declared, and don't try to pretty-print it unless
the current line is above that. Alternatively, we might need to revive
the code to limit the number of children to fetch, and use some reasonable
limit, like 10. Comments?

- Volodya

Re: Robustifying pretty-printers

[Vladimir Prus]

On Saturday 13 June 2009 you wrote:

> 
> While playing with pretty-printers and KDevelop, I've got GDB
> to "hang", with the below backtrace:
> 
> 	(gdb) where
> 	#0  0xb7d0ed2a in strcmp () from /lib/tls/i686/cmov/libc.so.6
> 	#1  0x081be1a7 in install_variable (var=0x191b0620) at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1731
> 	#2  0x081beef7 in create_child_with_value (parent=0x8a6e158, index=514255, name=0xb7bf8e14 "[514255]", value=0x191b03d0)
>     at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1859
> 
> The '514255' above is sufficient to understand what happened. Our beloved GCC fails to emit
> proper debug info, therefore a vector is considered in scope before constructor is executed,
> and the vector is full of random bits.
> 
> Now, what are the best strategies for fix this (assuming GCC won't be
> fixed for 10 years to come)? One approach is to make IDE check at what
> line the variable is declared, and don't try to pretty-print it unless
> the current line is above that. Alternatively, we might need to revive
> the code to limit the number of children to fetch, and use some reasonable
> limit, like 10. Comments?

In fact, there's yet another case:

	class StdStringPrinter:
    "Print a std::basic_string of some kind"

    def __init__(self, encoding, val):
        self.encoding = encoding
        self.val = val

    def to_string(self):
        # Look up the target encoding as late as possible.
        encoding = self.encoding
        if encoding == 0:
            encoding = gdb.parameter('target-charset')
        elif encoding == 1:
            encoding = gdb.parameter('target-wide-charset')
        elif isinstance(encoding, WideEncoding):
            encoding = encoding.value
        return self.val['_M_dataplus']['_M_p'].string(encoding)

I am not quite sure where the 'string' method is defined, so the
question is -- assuming I know the expected size of the string.
How do I make the 'string' method not to fetch more than that?

- Volodya

	

Re: Robustifying pretty-printers

[Phil Muldoon]

> In fact, there's yet another case:
>
> 	class StdStringPrinter:
>      "Print a std::basic_string of some kind"
>
>      def __init__(self, encoding, val):
>          self.encoding = encoding
>          self.val = val
>
>      def to_string(self):
>          # Look up the target encoding as late as possible.
>          encoding = self.encoding
>          if encoding == 0:
>              encoding = gdb.parameter('target-charset')
>          elif encoding == 1:
>              encoding = gdb.parameter('target-wide-charset')
>          elif isinstance(encoding, WideEncoding):
>              encoding = encoding.value
>          return self.val['_M_dataplus']['_M_p'].string(encoding)
>
> I am not quite sure where the 'string' method is defined, so the
> question is -- assuming I know the expected size of the string.
> How do I make the 'string' method not to fetch more than that?
>    

I'll answer a particular question in your email: counted string support 
should hopefully arrive soon. This comprises of two patches currently 
working through the review process over on the archer mailing list.

The approved first part is here:

http://sourceware.org/ml/archer/2009-q2/msg00017.html

The second part is more to do with null character preservation and 
emission, but has some counted string dependencies. It is currently 
going through review here:

http://sourceware.org/ml/archer/2009-q2/msg00111.html

When these have been accepted there, I'll submit them to the gdb-patches 
for additional review, and then hopefully into GDB head pretty soon.

In the std:string example, it would be modified to use counted strings 
like so:


diff --git a/gdb/python/lib/gdb/libstdcxx/v6/printers.py 
b/gdb/python/lib/gdb/libstdcxx/v6/printers.py
index 2bd2593..6bf4f3b 100644
--- a/gdb/python/lib/gdb/libstdcxx/v6/printers.py
+++ b/gdb/python/lib/gdb/libstdcxx/v6/printers.py
@@ -468,7 +468,17 @@ class StdStringPrinter:
encoding = gdb.parameter('target-charset')
elif isinstance(encoding, WideEncoding):
encoding = encoding.value
- return self.val['_M_dataplus']['_M_p'].string(encoding)
+ type = self.val.type
+ if type.code == gdb.TYPE_CODE_REF:
+ type = type.target ()
+
+ ptr = self.val ['_M_dataplus']['_M_p']
+ realtype = type.unqualified ().strip_typedefs ()
+ reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
+ header = ptr.cast(reptype) - 1
+ len = header.dereference ()['_M_length']
+
+ return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)

But the optional string length parameter could be used in other 
examples, too.

Regards

Phil

Re: Robustifying pretty-printers

[Vladimir Prus]

On Monday 15 June 2009 Phil Muldoon wrote:


> --- a/gdb/python/lib/gdb/libstdcxx/v6/printers.py
> +++ b/gdb/python/lib/gdb/libstdcxx/v6/printers.py
> @@ -468,7 +468,17 @@ class StdStringPrinter:
> encoding = gdb.parameter('target-charset')
> elif isinstance(encoding, WideEncoding):
> encoding = encoding.value
> - return self.val['_M_dataplus']['_M_p'].string(encoding)
> + type = self.val.type
> + if type.code == gdb.TYPE_CODE_REF:
> + type = type.target ()
> +
> + ptr = self.val ['_M_dataplus']['_M_p']
> + realtype = type.unqualified ().strip_typedefs ()
> + reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
> + header = ptr.cast(reptype) - 1
> + len = header.dereference ()['_M_length']
> +
> + return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)

Great, this is exactly what I was looking for.

Thanks,
Volodya

Re: Robustifying pretty-printers

[Daniel Jacobowitz]

On Mon, Jun 15, 2009 at 04:38:57PM +0400, Vladimir Prus wrote:
> On Monday 15 June 2009 Phil Muldoon wrote:
> > + return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
> 
> Great, this is exactly what I was looking for.

Is it?  This uses the length from the (possibly uninitialized)
std::string as a maximum.  I think we want something higher level,
similar to today's "set print elements", to apply.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Robustifying pretty-printers

[Vladimir Prus]

On Monday 15 June 2009 Daniel Jacobowitz wrote:

> On Mon, Jun 15, 2009 at 04:38:57PM +0400, Vladimir Prus wrote:
> > On Monday 15 June 2009 Phil Muldoon wrote:
> > > + return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
> > 
> > Great, this is exactly what I was looking for.
> 
> Is it?  This uses the length from the (possibly uninitialized)
> std::string as a maximum.  I think we want something higher level,
> similar to today's "set print elements", to apply.

That's a separate matter, which I raise in the topic starter. Yes, we want
some safety net. As it stands, any IDE that automatically displays local
variables is totally broken if pretty-printing is enabled.

But at the same time, even if we assume that the variable is already
initialized, we need to terminate the string at the length, as opposed
to assuming it has some null terminator. The higher level safety net
might cut the string at 100 characters, preventing a hang. But it would
be nicer to cut it at actual string length, so avoid showing garbage.

- Volodya

Re: Robustifying pretty-printers

[André Pönitz]

On Monday 15 June 2009 15:25:31 Vladimir Prus wrote:
> On Monday 15 June 2009 Daniel Jacobowitz wrote:
> 
> > On Mon, Jun 15, 2009 at 04:38:57PM +0400, Vladimir Prus wrote:
> > > On Monday 15 June 2009 Phil Muldoon wrote:
> > > > + return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
> > > 
> > > Great, this is exactly what I was looking for.
> > 
> > Is it?  This uses the length from the (possibly uninitialized)
> > std::string as a maximum.  I think we want something higher level,
> > similar to today's "set print elements", to apply.
> 
> That's a separate matter, which I raise in the topic starter. Yes, we want
> some safety net. As it stands, any IDE that automatically displays local
> variables is totally broken if pretty-printing is enabled.

The decision whether a std::string display should be limited to 100 or 
10000 characters or maybe whether it should be risked to show "all" is 
nothing that should be done on the gdb side, as all are valid choices
under certain circumstances.

So, please, don't make that kind of "high level" decision on the gdb side,
and also, please, generally take into account that other IDEs might
have other preferences than your IDE. 

At least from my point of view having a minimal(-ish) set of MI commands
providing fast and robust access to the data gdb can provide on the CLI is a 
lot more desirable than having a bigger part of _one_ IDE's logic hardwired
into gdb MI.

Andre'

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> While playing with pretty-printers and KDevelop, I've got GDB
Vladimir> to "hang", with the below backtrace:

Yeah :(

Vladimir> Now, what are the best strategies for fix this (assuming GCC
Vladimir> won't be fixed for 10 years to come)?

It will be fixed, but that won't matter, because users will still
smash the stack.

Vladimir> Alternatively, we might need to revive the code to limit the
Vladimir> number of children to fetch, and use some reasonable limit,
Vladimir> like 10. Comments?

With the current libstdc++ printers I am sure you will be able to come
up with any number of weird problems here.

A few thoughts:

* In the case of iterating over a container, the CLI code here already
  does the right thing -- it iterates over the children and respects
  "set print elements".  If the python code returns an iterable object
  (i.e., it doesn't immediately fetch all the children), then I think
  the result should be fairly sensible.  (Most libstdc++ printers do
  this, but I haven't checked them all recently.)

  So, one idea is to do as you suggest: resurrect the child-limiting
  code for MI.  This is necessary but not sufficient, because the
  previous patches did not make varobj fetch lazily.  This should not
  be very hard, though.

* We can add a new Value method to detect whether a pointer-valued
  Value is valid.  Then we could weed out some bad cases early in the
  printers.

* I'm not sure what to do about std::string.  Here, lazy iteration
  cannot fix the problem.  We could bake "print elements" awareness
  into the printer itself, but this is unsatisfactory since it can
  yield the "wrong" display to the user in some cases (string printing
  is very weird IMNSHO).  Maybe 3 times this limit or something like
  that would work well enough in most situations.  Or maybe we can
  just ignore the weird corner cases.

It would be nice if there were a way to make this magically work for
all printers without the printer authors needing to do anything
special.  I don't see how that could be done, though.

Let me know what you think.  I'm planning to fix all the known printer
problems shortly.

Tom

Re: Robustifying pretty-printers

[Vladimir Prus]

On Tuesday 16 June 2009 Tom Tromey wrote:

> >>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Vladimir> While playing with pretty-printers and KDevelop, I've got GDB
> Vladimir> to "hang", with the below backtrace:
> 
> Yeah :(
> 
> Vladimir> Now, what are the best strategies for fix this (assuming GCC
> Vladimir> won't be fixed for 10 years to come)?
> 
> It will be fixed, but that won't matter, because users will still
> smash the stack.

Yeah.

> Vladimir> Alternatively, we might need to revive the code to limit the
> Vladimir> number of children to fetch, and use some reasonable limit,
> Vladimir> like 10. Comments?
> 
> With the current libstdc++ printers I am sure you will be able to come
> up with any number of weird problems here.
> 
> A few thoughts:
> 
> * In the case of iterating over a container, the CLI code here already
>   does the right thing -- it iterates over the children and respects
>   "set print elements".  If the python code returns an iterable object
>   (i.e., it doesn't immediately fetch all the children), then I think
>   the result should be fairly sensible.  (Most libstdc++ printers do
>   this, but I haven't checked them all recently.)
> 
>   So, one idea is to do as you suggest: resurrect the child-limiting
>   code for MI.  This is necessary but not sufficient, because the
>   previous patches did not make varobj fetch lazily.  

Exactly, they only limited the number of children sent to frontend. If we
go this route, I think it is better to make -var-list-children take a
couple of parameters to specify the desired range, with [0, whatever] as
default -- as opposed to the previous approach where this limit should
be set on varobj, not on individual -var-list-children call. 

It's also obvious to you, but for everybody's benefit I'd point out that

	-var-list-children some_var 10 20

will fetch the [0, 10] range if not already fetched, which is probably
just fine, given how frontend is likely to use this functionality.

>   This should not
>   be very hard, though.
> 
> * We can add a new Value method to detect whether a pointer-valued
>   Value is valid.  Then we could weed out some bad cases early in the
>   printers.

Is this substantially better than letting pretty printer throw? What
will happen in that case -- I assume the value will end up ""?

> * I'm not sure what to do about std::string.  Here, lazy iteration
>   cannot fix the problem.  We could bake "print elements" awareness
>   into the printer itself, but this is unsatisfactory since it can
>   yield the "wrong" display 

How "wrong" exactly?

>   to the user in some cases (string printing
>   is very weird IMNSHO).  Maybe 3 times this limit or something like
>   that would work well enough in most situations.  Or maybe we can
>   just ignore the weird corner cases.
> 
> It would be nice if there were a way to make this magically work for
> all printers without the printer authors needing to do anything
> special.  I don't see how that could be done, though.

Can the .string method automatically trim at 'print elements' value,
or thice it? But, it's not clear what to do if user wants to fetch
more of the value.

- Volodya

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> Exactly, they only limited the number of children sent to
Vladimir> frontend. If we go this route, I think it is better to make
Vladimir> -var-list-children take a couple of parameters to specify
Vladimir> the desired range, with [0, whatever] as default -- as
Vladimir> opposed to the previous approach where this limit should be
Vladimir> set on varobj, not on individual -var-list-children call.

Just to be clear, do you also want these options on -var-update?
Or should it remember the previous values passed via -var-list-children?

Tom

Re: Robustifying pretty-printers

[Vladimir Prus]

On Wednesday 08 July 2009 Tom Tromey wrote:

> >>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Vladimir> Exactly, they only limited the number of children sent to
> Vladimir> frontend. If we go this route, I think it is better to make
> Vladimir> -var-list-children take a couple of parameters to specify
> Vladimir> the desired range, with [0, whatever] as default -- as
> Vladimir> opposed to the previous approach where this limit should be
> Vladimir> set on varobj, not on individual -var-list-children call.
> 
> Just to be clear, do you also want these options on -var-update?
> Or should it remember the previous values passed via -var-list-children?

I think the most reasonable behavour is to remember the number of fetched
children. So, if frontend decided to fetch 20 children once, -var-update should
not silently check only 10 of them on. I also think it's best for varobj to
remember the number of children requested by frontend, not actually reported.
So, if you had 15 children, and fronend first did:

	-var-list-children v 0 10

and then, maybe in response to user action, did:

    -var-list-children 10 20

and go 5 new children, and then more children are added, then -var-update
will report all existing children between 0 and 20, as opposed to showing
just 15.

There's also a question how frontend will know that there are more children --
so that it can show "..." in the tree view, or something. The best approach would
be for GDB to fetch one children more, and then use emit 'has-more' field in 
-var-list-children output. The other alternative is for frontend to fetch one more
item than it wishes to display -- but such a logic has to be repeated for each
frontend. Anyway, this aspect seems independent from others, so I can do it
myself after you are done with the code changes.

We probably need a way to explicitly reset the 'remembemered' limit on elements,
so that frontend is not forced to display 20 elements forever. 

- Volodya

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> There's also a question how frontend will know that there
Vladimir> are more children -- so that it can show "..." in the tree
Vladimir> view, or something. The best approach would be for GDB to
Vladimir> fetch one children more, and then use emit 'has-more' field
Vladimir> in -var-list-children output. The other alternative is for
Vladimir> frontend to fetch one more item than it wishes to display --
Vladimir> but such a logic has to be repeated for each
Vladimir> frontend. Anyway, this aspect seems independent from others,
Vladimir> so I can do it myself after you are done with the code
Vladimir> changes.

I don't mind doing it.

I was thinking of a 'dynamic' attribute, to let the FE know that the
numchild attribute cannot be believed.  But, I think I like your
approach better.

Vladimir> We probably need a way to explicitly reset the
Vladimir> 'remembemered' limit on elements, so that frontend is not
Vladimir> forced to display 20 elements forever.

I couldn't find a reason why you wanted the range on
-var-list-children and not as a separate command.  Could you explain
why?  The reason I ask is that this issue was already solved in the
old patch: you could use -var-set-child-range to set and also unset
the range.

Tom

Re: Robustifying pretty-printers

[Vladimir Prus]

On Thursday 09 July 2009 Tom Tromey wrote:

> Vladimir> We probably need a way to explicitly reset the
> Vladimir> 'remembemered' limit on elements, so that frontend is not
> Vladimir> forced to display 20 elements forever.
> 
> I couldn't find a reason why you wanted the range on
> -var-list-children and not as a separate command.  Could you explain
> why?  The reason I ask is that this issue was already solved in the
> old patch: you could use -var-set-child-range to set and also unset
> the range.

The primary reason is that if frontend wants to fetch more data, it's
natural to issue:

	-var-list-children 10 20

than

	-var-set-child-range 0 20
	-var-list-children

and then filter out the first 10 elements FE already has.

- Volodya

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> The primary reason is that if frontend wants to fetch more data, it's
Vladimir> natural to issue:
Vladimir> 	-var-list-children 10 20
Vladimir> than
Vladimir> 	-var-set-child-range 0 20
Vladimir> 	-var-list-children
Vladimir> and then filter out the first 10 elements FE already has.

I don't understand.  The FE would do this:

    -var-set-child-range 10 20
    -var-list-children

I suppose with the list-children approach we can have resetting be
done like:

    -var-list-children foo -1 -1

Another question is whether changing the visualizer ought to reset the
selected child range.  I'm not sure it matters; I assume a FE will do
this itself.

Tom

Re: Robustifying pretty-printers

[Vladimir Prus]

On Friday 10 July 2009 Tom Tromey wrote:

> >>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Vladimir> The primary reason is that if frontend wants to fetch more data, it's
> Vladimir> natural to issue:
> Vladimir> 	-var-list-children 10 20
> Vladimir> than
> Vladimir> 	-var-set-child-range 0 20
> Vladimir> 	-var-list-children
> Vladimir> and then filter out the first 10 elements FE already has.
> 
> I don't understand.  The FE would do this:
> 
>     -var-set-child-range 10 20
>     -var-list-children

And what children with -var-update reevaluate? From 10 to 20? Or
from 0 to 20? If the former, it's not very useful. If the latter,
then it appears that low boundary is only used for -var-list-children.
Maybe, it's most useful to decouple setting the range for -var-update
and getting specific children. So, if frontend wants more children
now, it will do:

	-var-list-children 10 20

and if it wishes for 20 children to be fetched from now on, it will
explicitly do:

	-var-set-child-limit 20

Note that there's only upper limit here, since it looks like no other command
but -var-list-children even need lower limit.

> I suppose with the list-children approach we can have resetting be
> done like:
> 
>     -var-list-children foo -1 -1
> 
> Another question is whether changing the visualizer ought to reset the
> selected child range.  I'm not sure it matters; I assume a FE will do
> this itself.

Probably so.

- Volodya

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Tom> -var-set-child-range 10 20
Tom> -var-list-children

Vladimir> And what children with -var-update reevaluate? From 10 to
Vladimir> 20? Or from 0 to 20? If the former, it's not very useful. If
Vladimir> the latter, then it appears that low boundary is only used
Vladimir> for -var-list-children.

Right.  There is a separation between what the varobj code does
internally, and what MI reports to the FE.

-var-set-child-range affects what is reported to the FE.  Only
children in that range are reported.  I was assuming the same would be
true even if this were done via arguments to -var-list-children.

What happens in varobj is another matter.  Currently we always fetch
children starting at 0, because the pretty-printers have a simple,
iterator-based design.

Vladimir> Maybe, it's most useful to decouple setting the range for -var-update
Vladimir> and getting specific children. So, if frontend wants more children
Vladimir> now, it will do:

Vladimir> 	-var-list-children 10 20

Vladimir> and if it wishes for 20 children to be fetched from now on, it will
Vladimir> explicitly do:

Vladimir> 	-var-set-child-limit 20

What is the difference between this and "-var-list-children 0 20"?

Tom

Re: Robustifying pretty-printers

[Vladimir Prus]

On Friday 10 July 2009 Tom Tromey wrote:

> >>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Tom> -var-set-child-range 10 20
> Tom> -var-list-children
> 
> Vladimir> And what children with -var-update reevaluate? From 10 to
> Vladimir> 20? Or from 0 to 20? If the former, it's not very useful. If
> Vladimir> the latter, then it appears that low boundary is only used
> Vladimir> for -var-list-children.
> 
> Right.  There is a separation between what the varobj code does
> internally, and what MI reports to the FE.
> 
> -var-set-child-range affects what is reported to the FE.  Only
> children in that range are reported.  I was assuming the same would be
> true even if this were done via arguments to -var-list-children.
> 
> What happens in varobj is another matter.  Currently we always fetch
> children starting at 0, because the pretty-printers have a simple,
> iterator-based design.
> 
> Vladimir> Maybe, it's most useful to decouple setting the range for -var-update
> Vladimir> and getting specific children. So, if frontend wants more children
> Vladimir> now, it will do:
> 
> Vladimir> 	-var-list-children 10 20
> 
> Vladimir> and if it wishes for 20 children to be fetched from now on, it will
> Vladimir> explicitly do:
> 
> Vladimir> 	-var-set-child-limit 20
> 
> What is the difference between this and "-var-list-children 0 20"?

That frontend needs one command, not two. Let me try to explain this
in a different way. Suppose we don't have -var-update at all. Then,
we don't need any reason for varobj to remember a limit. FE will use
-var-list-children to get whatever children it wants to display.

With -var-update, we have two choices:
1. Either plugin emits -var-update for individual varobjs, with the
desired range, or
2. Varobj remembers the number of children to fetch.

1 is cumbersome. 2 requires that varobj remember the upper limit only.
That's why I am suggesting -var-set-child-limit with a single parameter.
If I'm not making myself clear yet, maybe we should talk on IRC, say on
Monday?

- Volodya

Re: Robustifying pretty-printers

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> 2. Varobj remembers the number of children to fetch.

Vladimir> 1 is cumbersome. 2 requires that varobj remember the upper
Vladimir> limit only.  That's why I am suggesting -var-set-child-limit
Vladimir> with a single parameter.  If I'm not making myself clear
Vladimir> yet, maybe we should talk on IRC, say on Monday?

Yes, let's do that.  I still don't understand.

Tom