Hi Tom,
On Sat, 2006-05-13 at 17:41 -0600, Tom Tromey wrote:
> I think this merge could be done fairly simply. In fact I think it
> just requires adding a 'Class' argument to
> VMStackWalker.getCallingClass and VMStackWalker.getCallingClassLoader.
> This argument would name the immediate caller,
Hi,
I still don't get it. Why can you walk up one frame from the context
class, but not two frames from the VMStackWalker class?
Regards,
Jeroen
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Tom Tromey
> Sent: Sunday, May 14, 2006 01:42
> To: G
Andrew Haley wrote:
Tom Tromey writes:
> This week I spent some time looking at the libgcj/Classpath merge
> situation. After removing all the simple merges that hadn't yet been
> handled for some reason, I looked at VMStackWalker a little.
>
> I think this merge could be done fairly simpl
Bryce McKinlay wrote:
> GetCallingClass(Class) is intended for situations where you
> really want the caller of an external API into the class,
> but due to overloaded methods or inlining may have an
> indeterminate number of frames between the external method
> and the site at which GetCallingCla
Hi there,
Am Dienstag, den 16.05.2006, 09:29 +0200 schrieb Jeroen Frijters:
> Bryce McKinlay wrote:
> > GetCallingClass(Class) is intended for situations where you
> > really want the caller of an external API into the class,
> > but due to overloaded methods or inlining may have an
> > indetermi
Hi again,
> If gcj cannot reliably walk the stack at the moment,
I just want to add one comment here. The problem (at least as we found
it @aicas) is not to reliably walk the stack, the problem is that the
VMStackWalker interface is not well suited for 'walking' the stack. You
can pull the whole
Roman Kennke wrote:
> > If gcj cannot reliably walk the stack at the moment,
>
> I just want to add one comment here. The problem (at least as we found
> it @aicas) is not to reliably walk the stack, the problem is that the
> VMStackWalker interface is not well suited for 'walking' the
> stack.
Roman Kennke wrote:
> I also don't think I misunderstood the purpose of the VMStackWalker VM
> interface. As far as I understand it, this interface is there in order
> to provide more efficient access to stack information than
> Thread.getStackTrace().
Tom's proposal was about VMStackWalker.getCal
Hi Jeroen,
Am Dienstag, den 16.05.2006, 14:25 +0200 schrieb Jeroen Frijters:
> Roman Kennke wrote:
> > Here (@Aicas) we faced a similar problem as described by Tom.
> > We came up with another possible (but similar) solution, which
> > doesn't 'muddle up' the VM interface (ok, depends on your mea
Roman Kennke wrote:
> Here (@Aicas) we faced a similar problem as described by Tom.
> We came up with another possible (but similar) solution, which
> doesn't 'muddle up' the VM interface (ok, depends on your meaning
> of 'muddle up', it adds a new method with -IMO - also clearly
> defined semanti
Roman Kennke wrote:
> We could then merge some patches for java.util.logging, which
> would make use of this for more efficient logging. I think this
> would be useful for GNU Classpath. As it is now, we faced severe
> bottlenecks in applications that make use of the logging API.
Well then, by al
Hello again,
Am Dienstag, den 16.05.2006, 14:25 +0200 schrieb Jeroen Frijters:
> Roman Kennke wrote:
> > Here (@Aicas) we faced a similar problem as described by Tom.
> > We came up with another possible (but similar) solution, which
> > doesn't 'muddle up' the VM interface (ok, depends on your m
12 matches
Mail list logo
