[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Console requirements?
|
Hi Aaron,
the Launch "Scripts" that I presented as part of the
Component-Based Launch Approach (CBL) at the Toronto
Meeting, were originally not meant to be interactive
or very configurable.
I know that scripting is a very hot topic, and I'm
still not very sure what to do for the Launches.
But knowing that a very generic solution is probably
out of sight with so many players around, it looks
like I'll be shooting for something very very simple,
which would then not be interactive -- basically just
a means of serializing / deserializing a sequence
of configured steps for a Launch.
Given the schedule and involvement in RSE, I'm not sure
if I can provide a first CBL implementation as part of
RSE 1.0 in september (read: it's not on the committed
plan right now).
But, I do want to continue work on it and continue
gathering ideas / prototyping.
HTH,
Martin
--
Martin Oberhuber - WindRiver, Austria
+43(662)457915-85
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Tuesday, April 11, 2006 4:02 PM
> To: Device Debugging developer discussions
> Subject: RE: [dsdp-dd-dev] Console requirements?
>
> Martin/John,
>
> I was pondering this a bit as well after Johns email, and my first
> reaction was pretty much the same. Yes, a debugger console could use
> the same console infrastructure, but the point would be the scripting
> and the syntax. Regarding syntax, that could be a very, very long
> discussion (religious war?).
>
> It sounded to me as we were discussing connections and such
> in the last
> DSDP meeting in Toronto that it was assumed by everyone that a
> connection sequence would have to be a script of some kind since the
> actions required are arbitrary for a given system. What is
> the plan for
> the implementation of these scripts?
>
> It would make sense to me that the common debugger commands
> that John is
> asking about could be a pluggable command interpreter that drives some
> underlying set of common actions in the debugger. This way we could
> have a common command interpreter (and syntax) as a part of DSDP, but
> other vendors could also write command interpreters that
> would be their
> own syntax (we have our own of course that we have a lot of customers
> using...) So the point is that somewhere there is some overlap.
>
> Aaron
>
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> > Oberhuber, Martin
> > Sent: Tuesday, April 11, 2006 1:35 AM
> > To: Device Debugging developer discussions
> > Subject: RE: [dsdp-dd-dev] Console requirements?
> >
> > Hi John,
> >
> > By proposing actions like step etc. for a console view, did
> > you mean a debugger command prompt?
> >
> > My understanding of a console was a window into the target's
> > or debuggee's input/output.
> >
> > It might be that part of the technology for a console view
> > can be re-used for a debugger command prompt. My feeling,
> > however, is that this would be more related to scripting
> > (i.e. scripting debugger actions that are otherwise available
> > in the GUI).
> >
> > The script commands would then be executed from a generic
> > script interpreter / command prompt. So, your suggestion
> > would boil down to creating a scriptable DOM for debugger actions.
> >
> > Does this make sense?
> >
> > Cheers,
> > Martin
> > --
> > Martin Oberhuber - WindRiver, Austria
> > +43(662)457915-85
> >
> >
> > > -----Original Message-----
> > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> > > Sent: Monday, April 10, 2006 8:28 PM
> > > To: Device Debugging developer discussions
> > > Subject: RE: [dsdp-dd-dev] Console requirements?
> > >
> > > Sorry for chiming in so late on this.
> > >
> > > So besides the mechanics of a console window, including
> the desired
> > > ability to connect one to some sort of processing engine of
> > arbitrary
> > > nature, we should consider whether we'd want to create a
> processing
> > > engine that deals with the common debugger actions.
> > >
> > > I.e., while Freescale might want to introduce a console
> to let the
> > > user drive a CodeWarrior debug session in a proprietary
> > way, I would
> > > think it might be desirable to have a console that allows
> a user to
> > > drive a debug session in a common way. There's certainly a
> > good amount
> > > of commonality across debuggers in general: step in, step
> > over, step
> > > out, run, suspend, terminate, stackcrawl, show/modify
> locals, etc,
> > > etc...
> > >
> > > I can't tell if this is already part of what's being
> > considered, or if
> > > anyone sees any value in this. But it seems that as Eclipse based
> > > solutions proliferate in the embedded market, the ability
> to drive
> > > basic debugging operations from a console in a way that's
> > consistent
> > > across solutions/vendors might be useful.
> > >
> > > John
> > >
> > > At 11:59 AM 4/10/2006, Spear, Aaron wrote:
> > > >Ewe,
> > > >
> > > >We just finished talking about it a little bit on the TM
> > > phone call. To
> > > >summarize:
> > > >
> > > > >From the comments on these feature requests/bug reports,
> > > it appears that
> > > >Darin and others would be open to having us submit whatever
> > > changes we
> > > >need to the platform (as stated, they don't have the
> > bandwidth to do
> > > >more at the moment) As such, it sounds like we ought to
> > > figure out our
> > > >requirements, and then after a bit of design and review,
> > > copy-and-paste
> > > >what we need to live somewhere in the DSDP sources for
> > now, and then
> > > >submit whatever makes sense back (at least any framework
> > > changes). It
> > > >sounds like the pluggable terminal emulations should be
> > used by the
> > > >existing RSE "shell" component as well as the process console.
> > > >
> > > >I must disclose that I have not yet studied the current console
> > > >architecture. It sounds as though you have. I am
> > presuming that you
> > > >are the one that wrote Wind's current telnet implementation
> > > which both
> > > >Doug and Martin have talked about being a possible
> > > contribution. How
> > > >do you think we should go about discussing the refactoring
> > > that needs to
> > > >happen in the framework as well as the design we want to
> > > have for this
> > > >stuff moving forward? You mentioned a few items below. I
> > > have no idea
> > > >what the process should be as far as the platform changes
> > > goes. Perhaps
> > > >if the changes to simply enable what we want are not too
> > radical they
> > > >can be done before 3.2 is complete if we do the
> implementation and
> > > >submit it? (no idea if that is a ridiculous expectation or not)
> > > >
> > > >regards,
> > > >Aaron
> > > >
> > > >-----Original Message-----
> > > >From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > >[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Stieber, Uwe
> > > >Sent: Saturday, April 08, 2006 3:11 AM
> > > >To: Device Debugging developer discussions; Target
> > > Management developer
> > > >discussions
> > > >Subject: RE: [dsdp-dd-dev] Console requirements?
> > > >
> > > >Hi Aaron,
> > > >you may want to refer to the bugzilla entries
> > > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=36669 and
> > > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=111186. They
> > both deal
> > > >with Consoles and need to take into account if modifying
> > the platform
> > > >console service.
> > > >
> > > >Basically an improved console should allow easy
> "connectivity" to
> > > >whatever. First hand, we look mainly for getting the
> > > currently existing
> > > >implementation of the ProcessConsole splitted into an public
> > > >ProcessConsole (not tight together with launch
> configurations) and
> > > >possible still internal DebugProcessConsole (tight together
> > > with launch
> > > >configurations as the current implementation is, no change
> > to current
> > > >users/clients). This is basically similar to what you
> > pointed out in
> > > >your second point besides the console infrastructure
> should not be
> > > >limited to debuggee processes only.
> > > >
> > > >Additional, the consoles should have an contributable font
> > and colour
> > > >provider which allows to change fonts/colours for matching
> > > parts of the
> > > >document. The current implementation of the platform console
> > > >infrastructure requires to replace the whole
> > > >IDocument/IDocumentPartitioner implementation of the console
> > > which is an
> > > >overkill for the basic requirement to get all three streams
> > > of a process
> > > >very easely connected to an console and to have influence on the
> > > >presentation by in example simple regex matcher.
> > > >
> > > >Best regards,
> > > >
> > > >--
> > > >Uwe Stieber
> > > >Senior Software Engineer
> > > >Engineering - Wind River Gmbh - Austria
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> > Spear, Aaron
> > > > > Sent: Friday, April 07, 2006 5:54 PM
> > > > > To: Device Debugging developer discussions; Target Management
> > > > > developer discussions
> > > > > Subject: [dsdp-dd-dev] Console requirements?
> > > > >
> > > > > Hello All,
> > > > >
> > > > > I wanted to kick off a thread to solicit some
> > > requirements/thoughts
> > > > > for consoles in the brave new DSDP world. I will throw a
> > > few out that
> > > >
> > > > > I can
> > > > > see:
> > > > >
> > > > > -Pluggable/Selectable terminal emulations (plain
> text, vt-100,
> > > > > vt-220,...). We ought to have stock ones like those
> > > mentioned, but
> > > > > there should be an extension point so others can
> > > contribute something
> > > > > completely specific if they want.
> > > > >
> > > > > -Pluggable connectivity to the other side. The simple
> > > use case is a
> > > > > replacement/augmentation of the existing Eclipse
> > console, one that
> > > > > does stdio with the debugged process. I think that we
> > > will want to
> > > > > reuse the same component elsewhere though, e.g. a
> > > terminal opened on a
> > > >
> > > > > socket from the RSE or something.
> > > > >
> > > > > I don't know what exactly we will do with this little
> > > sub-project. It
> > > >
> > > > > seems to me that it should probably be pushed into the
> > > platform (at
> > > > > least the framework changes for
> > > > > consoles) and then perhaps we have specific terminal
> > > emulations that
> > > > > exist in DSDP?
> > > > >
> > > > > cheers,
> > > > > Aaron
> > > > >
> > > > > --
> > > > > Aaron Spear
> > > > > Debug Tools Architect/Staff Engineer Mentor Graphics
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > dsdp-dd-dev mailing list
> > > > > dsdp-dd-dev@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > > >
> > > >_______________________________________________
> > > >dsdp-dd-dev mailing list
> > > >dsdp-dd-dev@xxxxxxxxxxx
> > > >https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > >_______________________________________________
> > > >dsdp-dd-dev mailing list
> > > >dsdp-dd-dev@xxxxxxxxxxx
> > > >https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > >
> > > _______________________________________________
> > > dsdp-dd-dev mailing list
> > > dsdp-dd-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > >
> > _______________________________________________
> > dsdp-dd-dev mailing list
> > dsdp-dd-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> >
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
