To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
> Some thoughts re: data format debugger
> I suggest we enumerate
Mike, are you saying there is some ground work to lay for this in Daffodil
itself, or are these things which the debugger needs to
ree in memory. As parse-events are produced, no-longer necessary parts of
> the infoset are pruned away. Similarly, when unparsing, once a part of the
> infoset has been unparsed, that part of the infoset tree is pruned away if
> no longer needed.
>
>
> _
ing, once a part of the
> infoset has been unparsed, that part of the infoset tree is pruned away if
> no longer needed.
>
>
>
> From: Steve Lawrence
> Sent: Thursday, April 22, 2021 9:32 AM
> To: dev@daffodil.apache.org
> Subject: Re: The future o
nce
Sent: Thursday, April 22, 2021 9:32 AM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
Some thoughts related to showing the infoset as if it were a variable as
this is prototyped
1) How do DAP/IDE's represent very large hierarchical data? Info
> It looks like some of the code from java-debug can be reused without
involving JDI. The java-debug project could be viewed as an implementation
of the DAP communication protocol, coupled with JDI to provide
request/response values to DAP. For example, the `ProtocolServer` [3]
hard-codes the JDI,
I'm currently seeing what it takes to get a minimal VS Code extension
talking DAP over stdin/stdout to an external Scala process.
On Fri, Apr 23, 2021 at 11:01 AM Adam Rosien wrote:
> I've looked at scala-debug-adapter a bit now, and it doesn't do very much:
> there's some socket stuff and state
I've looked at scala-debug-adapter a bit now, and it doesn't do very much:
there's some socket stuff and state management, but otherwise it delegates
to the underflying java-debug library which manages the DAP protocol [1].
*That* library does assume use of JDI and supplies JVM-level stuff to DAP
(
> dig a bit to see if the DAP-only hooks can be reused without JDI coming
along for the ride
Cool, that would be good to dig at. Big win if we can reuse it.
, and to add/remove
>> >>>>> breakpoints. And an information view for things like variables,
>> >> in-scope
>> >>>>> delimiters, PoU's, etc.
>> >>>>>
>> >>>>> The only reason I mention a debug pr
; >>> parse/unparse that need to be points where users can pause, and
> data
> > > >>> structures available to display.
> > > >>> >
> > > >>> > E.g., it is 100% a display issue that the infoset (shown as XML)
> is
> > &g
k.
> >>>>>
> >>>>>
> >>>>> On 1/6/21 12:44 PM, Beckerle, Mike wrote:
> >>>>>> I don't think of it as a daffodil debug protocol, but just a
> >>>>> separation of concerns between display of information and the
> >> behaviors of
> >>&
, how to display the infoset with sensible limits
>>>>> on sizing, is fairly easy to come up with some design for, that will at
>>>>> least be (1) always fairly small (2) much more useful in more cases. It
>>>>> won't be perfect but can be much better than what we do n
> >>> >
> > >>> > One sensible display "mode" should be that displaying the context
> > >>> surrounding the current element (when parsing or unparsing) displays
> at
> > >>> most N-lines. (N/2 before, N/2 after) with a maxim
> value might be some big thing which needs to be
> elided
> >>> ...
> >>> > ...
> >>> >???
> >>> >
> >>> > ???
> >>> >
> >>> > The is just an idea to reduce XML matching end-ta
apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
Hi everybody, I've recently started working on Daffodil with some other
folks and will be helping where I can with the debugger.
I've been writing Scala since ~2011 and recently wrote a book about Cats
Effect, which
> ...
>>>> >
>>>> >...
>>>> >89ab782 ...
>>>> >some text is here and some more text
>>>> > value might be some big thing which needs to be
>>>> elided ...
>>>> > ...
>>>> >???
>>>> >
ot starting from the
>>> absolute root.
>>> >
>>> > The ... within simple content means that content is elided to fit on
>>> one line. Always follows some text characters to differentiate from the
>>> child-element context.
>>> >
>>> > The ??? means zer
__
> From: John Wass
> Sent: Monday, April 12, 2021 9:58 AM
> To: dev@daffodil.apache.org
> Subject: Re: The future of the daffodil DFDL schema debugger?
>
> > the code is here https://github.com/jw3/example-daffodil-debug
>
> There is now a complete console
This is actually very cool using ZIO for this. I have to learn more about ZIO.
From: John Wass
Sent: Monday, April 12, 2021 9:58 AM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
> the code is here https://github.
arly for a trace output being dumped to a text
>> file.
>> >
>> > I made the above example an unparser kind of example by showing a
>> following sibling that exists that is after the current node.
>> >
>> > I think the key concept is that any sibli
modes would be useful. E.g., a text marker like ">>>" as in:
>> >
>> >>>> value
>> >
>> > might be better, particularly for a trace output being dumped to a text
>> file.
>> >
>> > I made the above example a
layed in a way
> that fits on one line.
> > E.g., even if the element name was really long, I'd suggest:
> >
> > abcd ...
> >
> > Where the element name itself gets elided because it is too long.
> >
> > A thought. Note that the above presentation is shown as quasi-XML, but
&g
c model (akin to the DSOM
>> object model) of the schema.
>> This is here just to point out that it's really out of scope. There are
>> many questions about the schema (e.g., "can I add this property to this
>> element?") that are not? required for the debugger
er unspecified aspects of the situation.
From: John Wass
Sent: Friday, January 8, 2021 4:45 PM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
What other features could find a nice home in an IDE integration? Having
sin
great, but that's really entirely different than our goals for debugging
> that we're trying to discuss here.
>
>
> ____________
> From: Sloane, Brandon
> Sent: Thursday, January 7, 2021 1:25 PM
> To: dev@daffodil.apache.org
> Subject: Re: The future of the daffodi
y entirely different than our goals for debugging that we're trying
to discuss here.
From: Sloane, Brandon
Sent: Thursday, January 7, 2021 1:25 PM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
We could also crea
-site analysis in cases
where it is not practical to attach a debugger while Daffodil is running.
From: Sloane, Brandon
Sent: Thursday, January 7, 2021 1:21 PM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
I've bee
racking)
* The memory requirements when used on large infosets
From: Larry Barber
Sent: Thursday, January 7, 2021 1:08 PM
To: dev@daffodil.apache.org
Subject: RE: The future of the daffodil DFDL schema debugger?
When I was doing strange and unusual things with DFD
Subject: Re: The future of the daffodil DFDL schema debugger?
Yep, something like that seems very reasonable for dealing with large infosets.
But it still feels like we still run into usability issues.
For example, what if a user wants to see more? We need some configuration
options to increase what
ach other.
From: Steve Lawrence
Sent: Wednesday, January 6, 2021 1:42 PM
To: dev@daffodil.apache.org
Subject: Re: The future of the daffodil DFDL schema debugger?
Yep, something like that seems very reasonable for dealing with large
infosets. But it still feels like we
and some more text"
>currentNode = "value might be some big thing which needs to be elided ..."
>followingSibling1 = { ... }
>???
> }
>
> That's enough for 1 email thread on this debug topic.
>
>
>
>
elided ..."
followingSibling1 = { ... }
???
}
That's enough for 1 email thread on this debug topic.
____
From: Steve Lawrence
Sent: Tuesday, January 5, 2021 2:26 PM
To: dev@daffodil.apache.org
Subject: The future of the daffodil DFDL schema debugger?
N
32 matches
Mail list logo
