Bertrand Delacretaz wrote:
Le 1 août 05, à 15:10, Sylvain Wallez a écrit :
...Tell me what you think!
/me thinks that this is just great, thanks Sylvain!
Thanks! I just committed a few changes in the flow engine so that we
have JS stacktraces in the Cocoon stacktrace!
-Bertrand, thin
Le 1 août 05, à 15:10, Sylvain Wallez a écrit :
...Tell me what you think!
/me thinks that this is just great, thanks Sylvain!
-Bertrand, thinking about launching polishyourheroplates.com
smime.p7s
Description: S/MIME cryptographic signature
Sylvain Wallez wrote:
Conclusion
--
The Cocoon stacktrace gives some very valuable information about what
problem happened, and more importantly where it happened. We now need to
progressively add location information to important places in the code
to make these Cocoon stacktraces mo
Ugo Cei wrote:
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto:
I have refactored the error handling stuff to have Cocoon stack
traces, i.e. a trace of the involved components and the corresponding
locations in the call stack.
I think it's time to take that hero plate o
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto:
I have refactored the error handling stuff to have Cocoon stack
traces, i.e. a trace of the involved components and the corresponding
locations in the call stack.
I think it's time to take that hero plate out of the close
Sylvain Wallez wrote:
Conclusion
--
The Cocoon stacktrace gives some very valuable information about what
problem happened, and more importantly where it happened. We now need to
progressively add location information to important places in the code
to make these Cocoon stacktraces
Hi all,
I have refactored the error handling stuff to have Cocoon stack traces,
i.e. a trace of the involved components and the corresponding locations
in the call stack.
For example, we can track nested JXTG macro calls, flowscript function
calls, pipeline locations, mounted sitemaps, etc
Vadim Gritsenko wrote:
Christopher Oliver wrote:
So I would propose something like the following:
1) Have the TreeProcessor pass the sitemap source location in
setGenerator(), addTransformer(), and setSerializer() to the
ProcessingPipeline.
2) In "Debug" mode instrument the PipelineProcessor t
Christopher Oliver wrote:
So I would propose something like the following:
1) Have the TreeProcessor pass the sitemap source location in
setGenerator(), addTransformer(), and setSerializer() to the
ProcessingPipeline.
2) In "Debug" mode instrument the PipelineProcessor to write the
output of e
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough
to build a debugger?
Without getting into all the details, I think a proper API for a
global debugger would require quite a bit more infrastructure tha
There are several issues with getting a meaningful stack trace from the
execution of the pipeline:
1) The pipeline itself is not executed by the TreeProcessor but instead
by a Pipeline processor. The sitemap source locations of the pipeline
elements are not currently available to the Processing
On 15 Jan 2004, at 03:37, Geoff Howard wrote:
Christopher Oliver wrote:
I think is still needed if you want to see the values of
sitemap variables while debugging.
hmmm, don't you get this already with the stacktraces? I mean, the
sitemap variables are normally used as:
1) tokens for URLs
2
I think is still needed if you want to see the values of
sitemap variables while debugging.
Would it be possible to modify the output from
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154
Ok, let's add the cocoon stack trace only (no map:log or similar) for
now and see what happens? deal?
+1 deal :)
--
Torsten
On Jan 15, 2004, at 2:44 AM, Stefano Mazzocchi wrote:
Ok, let's add the cocoon stack trace only (no map:log or similar) for
now and see what happens? deal?
+1
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Rea
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
I'm still +1 to and see no real reason why not to do it.
All I am asking is ...do we really need it?
h,
[feeling hacky is not a real reason if there is no alternative
proposed and the need i
Joerg Heinicke wrote:
On 14.01.2004 21:28, Torsten Curdt wrote:
I'm still +1 to and see no real reason why not to do it.
All I am asking is ...do we really need it?
IMO no. We should review the logging of the sitemap components and
change it in that way that you get a clear meaning of the
Stefano Mazzocchi wrote:
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
I'm still +1 to and see no real reason why not to do it.
All I am asking is ...do we really need it?
h,
[feeling hacky is not a real reason if there is no alternative
proposed and the need is felt...
I am just
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
I don't like this and find it hacky. Using println in the
flowscript is a useful technique and as I said I use it. But
introducing official println equivalents all over the place will
lead to floods of messages
I'd like to second that.
Besides I
On 14.01.2004 21:28, Torsten Curdt wrote:
[ Besides I still think *println* is bad in flowscript although it
might be (well.. *is*) super for development. But having e.g. an
optional flowscript console would be much better IMO. Otherwise:
if we start using println... which components may use Syste
On Jan 14, 2004, at 1:10 PM, Jorg Heymans wrote:
How is setting a breakpoint different from inserting a logging
statement? Breakpoint locations need to be carefully chosen as well
with strategy. Ofcourse if you get it wrong you don't loose much
time, just reset and rerun, no recompiling needed.
I don't like this and find it hacky. Using println in the flowscript
is a useful technique and as I said I use it. But introducing
official println equivalents all over the place will lead to floods
of messages
I'd like to second that.
Besides I think we are mixing debugging with error report
Jorg Heymans wrote:
I'm dead serious when I think that debuggers brain-damange their
users: debugging a program with a debugger instead of with a ton of
println is *much* slower for me. not only because of the many layers
of tool that have to run around my program, but also because logging
fo
I'm dead serious when I think that debuggers brain-damange their users:
debugging a program with a debugger instead of with a ton of println is
*much* slower for me. not only because of the many layers of tool that
have to run around my program, but also because logging forces you to
think abo
On 13 Jan 2004, at 11:46, Torsten Curdt wrote:
It seems to me like this thread mixes concerns between error
reporting (strack traces) and debugging or "processing monitoring"
(knowing what's going on at a high level).
:) exactly
What I want is a way to know what my cocoon is doing at a level tha
On 13 Jan 2004, at 11:39, Torsten Curdt wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround cycle is long (e.g. J2EE apps). For example, although
On 13 Jan 2004, at 09:47, Steven Noels wrote:
On Jan 13, 2004, at 7:56 AM, Sylvain Wallez wrote:
However, do we really need a new sitemap statement? What about a
simple log action: ?
+1
IMHO, I find adding a println() type construct to the sitemap a bit of
a hack (but admittedly less work than
Hi,
I'm a cocoon users, and I agree: a general debugger would be cool; but we can
live without it. Anyway, it'll make work more efficient
Le Mercredi 14 Janvier 2004 18:44, Stefano Mazzocchi a écrit :
> On 12 Jan 2004, at 23:40, Sylvain Wallez wrote:
> > Stefano Mazzocchi wrote:
> >> On 12 Jan 20
On 12 Jan 2004, at 23:40, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A
source-level debugger is mainly required when t
Sylvain Wallez wrote:
Christopher Oliver wrote:
I don't think anyone is suggesting that there shouldn't be support for
a source level debugger. But that is a large project, IMO. And having
the ability to do "println" debugging doesn't preclude it.
You're right.
I agree with Vadim that an explic
It seems to me like this thread mixes concerns between error reporting
(strack traces) and debugging or "processing monitoring" (knowing what's
going on at a high level).
:) exactly
So it might be a good idea to have write to a specific logging
category ("cocoon.processing"), where calls to ad
On Jan 13, 2004, at 10:34 AM, Bertrand Delacretaz wrote:
Le Mardi, 13 jan 2004, à 09:47 Europe/Zurich, Steven Noels a écrit :
... saw Marc once hooking the Eclipse debugger into an Apple, and
that seriously kicked ass - you don't need println() anymore of you
have a full-blown debugger at your s
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround cycle is long (e.g. J2EE apps). For example, although
Rhino has a JavaScript debugger, I rarely use
Le Mardi, 13 jan 2004, à 09:47 Europe/Zurich, Steven Noels a écrit :
... saw Marc once hooking the Eclipse debugger into an Apple, and that
seriously kicked ass - you don't need println() anymore of you have a
full-blown debugger at your service.
Yes, if you're debugging java code it's fairly eas
On Jan 13, 2004, at 7:56 AM, Sylvain Wallez wrote:
However, do we really need a new sitemap statement? What about a
simple log action: ?
+1
IMHO, I find adding a println() type construct to the sitemap a bit of
a hack (but admittedly less work than coming up with a full-blown
debugging API + t
Christopher Oliver wrote:
I don't think anyone is suggesting that there shouldn't be support for
a source level debugger. But that is a large project, IMO. And having
the ability to do "println" debugging doesn't preclude it.
You're right.
I agree with Vadim that an explicit sitemap instructi
Le Mardi, 13 jan 2004, à 03:41 Europe/Zurich, Tony Collen a écrit :
Vadim Gritsenko wrote:
[snip]
I don't like that message has been added to the core sitemap tags.
How about adding separate tag (ant-like):
It's easier to add/remove (comment/uncomment) a tag than an attribute.
Or, arguing s
Vadim Gritsenko wrote:
[snip]
I don't like that message has been added to the core sitemap tags. How
about adding separate tag (ant-like):
It's easier to add/remove (comment/uncomment) a tag than an attribute.
Or, arguing syntax even more: ;)
this is a message, substitution:
{1}
or eve
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround
I don't think anyone is suggesting that there shouldn't be support for a
source level debugger. But that is a large project, IMO. And having the
ability to do "println" debugging doesn't preclude it.
My $0.02,
Chris
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Chr
Vadim Gritsenko dijo:
> Christopher Oliver wrote:
>> Sylvain Wallez wrote:
>>
>>> - we need a "popStackFrame()" method, since once a component has been
>>> executed successfully and execution continues in its following
>>> siblings, it should no longer appear in the stack trace
>>
>>
>> The idea is
Christopher Oliver wrote:
Sylvain Wallez wrote:
- we need a "popStackFrame()" method, since once a component has been
executed successfully and execution continues in its following
siblings, it should no longer appear in the stack trace
The idea is that this stack trace is created during exce
On 12.01.2004 23:40, Sylvain Wallez wrote:
How about adding a "message" attribute to ProcessingNode, e.g:
which would output something like
sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
page/getNumberA.html
I like this very much!
+1
I don't like this and f
hi,
Great idea, i was thinking about doing some sort of sitemap debugging,
please keep in mind that output is not solely system.out but some sort
of UI,
perhaps to give some idea, the servlet, or command line might be replaced by
ui
see
http://meineseite.one.at/bh22351/cocoonbean-3.png,
or http:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround cycle is long (e.g. J2
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
"println()" style debugging seems to work quite well. A source-level
debugger is mainly required when the development turnaround cycle is
long (e.g. J2EE apps). For example, alt
On 12 Jan 2004, at 16:35, Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace
(with location information) spanning (possibly nested) invocations
of the sitemap, flowscript, and JXTemplateGenerator.
WDYT?
On 12 Jan 2004, at 07:38, Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor resu
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough
to build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
en
Christopher Oliver wrote:
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough
to build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
encountered (detected usi
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough to
build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
encountered (detected using the stack element's loca
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace
(with location information) spanning (possibly nested) invocations
of the sitemap, flowscript, and JXTemplateGenerator.
WDYT?
/me thinks it's great!
Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator.
WDYT?
/me thinks it's great!
Some low-level remarks, howev
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor result. Although location informa
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor result. Although location information is
available it isn't
55 matches
Mail list logo
