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
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,
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
Sylvain Wallez wrote:
big-snip/
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
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 closet
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 out
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
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
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 to
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
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo
Ok, let's add the cocoon stack trace only (no map:log or similar) for
now and see what happens? deal?
+1 deal :)
--
Torsten
I think map:log 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
On 15 Jan 2004, at 03:37, Geoff Howard wrote:
Christopher Oliver wrote:
I think map:log 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
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?
snip
Without getting into all the details, I think a proper API for a
global debugger would require quite a bit more
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
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 2004,
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: map:act type=log src=blah blah/?
+1
IMHO, I find adding a println() type construct to the sitemap a bit of
a
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 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 that
snipped a great deal
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
Jorg Heymans wrote:
snipped a great deal
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
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
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
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
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
Stefano Mazzocchi wrote:
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
snip
I'm still +1 to map:log 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...
Joerg Heinicke wrote:
On 14.01.2004 21:28, Torsten Curdt wrote:
I'm still +1 to map:log 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
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
snip
I'm still +1 to map:log 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
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: map:act type=log src=blah blah/?
+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
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
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
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
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 map:log write to a specific logging
category (cocoon.processing), where calls
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
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
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.
snip
WDYT?
/me thinks it's great!
Some low-level remarks,
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
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
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
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
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.
snip
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,
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.
hi,
snip/
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
On 12.01.2004 23:40, Sylvain Wallez wrote:
How about adding a message attribute to ProcessingNode, e.g:
map:match pattern=page/*
map:generate type=jx src=screens/{1}.xml message=match
is page/{1}/
which would output something like
sitemap:
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
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 that this stack
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,
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
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):
map:debug message= {1} ./
It's easier to add/remove (comment/uncomment) a tag than an attribute.
Or, arguing syntax even more: ;)
map:log
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):
map:debug message= {1} ./
It's easier to add/remove (comment/uncomment) a
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
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
53 matches
Mail list logo
