[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Question about MIVariableManager
|
Hi Petr,
I don't think I'll be able to help much more without diving deeply into the
details of your situation, which I won't be able to do.
If it makes you feel better, it takes everyone quite some time
before being comfortable with the way we nest callbacks. But once
you get used to it, it becomes much simpler to understand, and actually
quite enjoyable to work with (or maybe that's just me ;)). Give it time.
Also, MIVariableManager is one of the most complex part of DSF-GDB.
I try to stay away from it as much as I can, because each time I have
to deal with it, I have to really take a lot of time to figure it out again.
Don't despair, I'm sure you'll figure it out.
Marc
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Petr Suchomel
> Sent: Thursday, May 16, 2013 9:00 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Question about MIVariableManager
>
> Marc,
>
> When you say physical children, you mean in GDB?
> I guess you could keep track of objects that are created in GDB
> or not, then if they are not, you can create them only when
> you need them.
>
> Children are not created in GDB (they are in reality pretty
> printed, nothing like -var-create is called, but the behavior
> is mimicked).
> Yet, I moved only a little bit to realize I am completely lost again:
> queueCommand(MICommand, DataRequestMonitor); (this what I
> understood, but the complexity of nesting is something I have
> not seen in 15+ years of my java life)
> The whole thing gets called when you try expand root node and
> get children from UI... so far so good.
> What I am really trying to determine, how children and
> MIVariableObjects should be created and how/when they should
> be placed into cache. I thought I knew, but it looked like
> only an illusion.
> --Petr
>
>
> > To your question: I am somehow concerned by level of
> > anonymous class nesting ... code get somehow hard to read
> at some point.
>
> At first read this does look intimidating. I suggest not looking
> at the definition :) When you actually use it, it becomes simpler.
>
> public <V extends ICommandResult> ICommandToken queueCommand(
> final ICommand<V> command, DataRequestMonitor<V> rm)
>
> translates to something like
>
> queueCommand(MICommand, DataRequestMonitor);
>
> Marc
>
>
> >
> > --Petr
> >
> >
> >
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> > Sent: Thursday, May 16, 2013 11:35 AM
> > To: 'CDT General developers list.'
> > Subject: Re: [cdt-dev] Question about MIVariableManager
> >
> >
> >
> > Hi,
> >
> >
> >
> > if you have information about the children when creating a
> > variable object, what you could do is pre-fill that
> >
> > information directly in MIVariableManager. For instance, you
> > can use MIVariableObject.setChildren(..)
> >
> > directly. Once the children are filled, MIVariableManager
> > will not try to fetch those children again,
> >
> > so you should avoid those inefficiencies.
> >
> >
> >
> > > I am very concerned by complexity of public <V extends
> > ICommandResult> ICommandToken queueCommand(
> >
> > > final ICommand<V> command,
> > DataRequestMonitor<V> rm) where a different commands queue
> > each other and so on.
> >
> >
> >
> > I'm not sure which part is causing concern? :)
> >
> >
> >
> > I hope this helps.
> >
> >
> >
> > Marc
> >
> >
> >
> > ________________________________
> >
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Petr Suchomel
> > Sent: Wednesday, May 15, 2013 10:02 PM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] Question about MIVariableManager
> >
> > Folks,
> >
> > Excuse me if I am asking dumb questions.
> >
> > What I am trying to do:
> >
> > I am trying to clone and modify MIVariableManager (and
> > necessary classes around) to have one which can handle data
> > from QtCreator pretty printers for Momentics. If I am looking
> > at Qt types through Momentics, you simply get information
> > which is very hard (or impossible) to read, simple pretty
> > printers such as we are using today simply sucks facing
> > complexity of Qt objects.
> >
> > QtCreator has very nice and powerful pretty printers,
> > which are mimicking GDB/MI object behavior - we did some
> > further changes which allow easy to put in CDT
> infrastructure for us.
> >
> >
> >
> > Yet there are significant differences. CDT/GDB is using
> > multistep evaluation of variable to e.g. access its children,
> > there are also necessary workarounds to find if children are
> > pretty printed etc. This is all resolved on Python level in
> > QtCreator PP.
> >
> > While everything is driven by expressions there are
> > some noticeable differences:
> >
> > - Qt PP are using something called iname -
> > similar to GDB -var-create generated name
> >
> > - Values are generally encoded to avoid
> > problem with platform dependent encoding
> >
> > - By getting particular variable, you are
> > getting also its children + for it children, immediate
> > children includes information about count of their descendants.
> >
> >
> >
> > It would be very inefficient to copy every single step
> > and do evaluations again and again, good example could be e.g
> > MIRootVariableObject - if I have this object, I can also
> > immediately construct it descendants as long as I have all
> > info to do so:
> >
> > Two examples, creating "argv" and "mainApp"
> >
> >
> >
> >
> > ^done,data=[{iname="local.argv",name="argv",numchild="4",child
> > ren=[{addr="0x7a9f2d4",numch\
> >
> > ild="0",type="char
> > *",valueencoded="6",value="636f6d2e6578616d706c652e50756c6c4d7
> > 942656172642e746573\
> >
> >
> > 744465765f50756c6c4d7942656172643433313133303465",},{addr="0x7
> > a9f2d8",numchild="0",type="char *",val\
> >
> >
> > ueencoded="6",value="48656c6c6f",},{addr="0x7a9f2dc",numchild=
> > "0",type="char *",valueencoded="6",val\
> >
> >
> > ue="46726f6d",},{addr="0x7a9f2e0",numchild="0",type="char
> > *",valueencoded="6",value="4242544c61756e6\
> >
> > 3685061727469636970616e74",},],type="char **",value="<4
> > items>",},],typeinfo=[{name="Y2hhciAq",size=\
> >
> > "4"}{name="dW5zaWduZWQgY2hhcg==",size="1"}]
> >
> >
> >
> >
> > ^done,data=[{iname="local.mainApp",name="mainApp",addr="0x7a9f
> > 2b0",addr="0x7a9f2b0",numchi\
> >
> >
> > ld="4",children=[{iname="local.mainApp.@1",name="[QObject]",ad
> > dr="0x7a9f2b0",numchild="1",addr="0x7a\
> >
> > 9f2b0",type="QObject",value="
> > ",},{name="mSoundManager",addr="0x804a114",addr="0x804a114",nu
> > mchild="\
> >
> >
> > 2",origaddr="0x7a9f2b8",type="SoundManager",value="{...}",},],
> > type="PullMyBeardApp",value="{...}",},\
> >
> >
> > ],typeinfo=[{name="dW5zaWduZWQgbG9uZw==",size="4"}{name="U291b
> > mRNYW5hZ2Vy",size="132"}{name="U291bmR\
> >
> > NYW5hZ2VyICo=",size="4"}]
> >
> >
> >
> > One problem I facing and I am not sure if I can crack
> > through, is that MIRootVariableObject.create(....) after
> > sending request to evaluate root variable and
> > handleCompleted is finished, I have all data to create
> > children ... but I have very weak idea what should be the
> > approach to do so. Creating only expressions from iname
> > property and asking all over again for all data would be
> > inefficient -> I am very concerned by complexity of public <V
> > extends ICommandResult> ICommandToken queueCommand(final
> > ICommand<V> command, DataRequestMonitor<V> rm) where a
> > different commands queue each other and so on.
> >
> >
> >
> > Does anybody know what would be the best approach?
> >
> > Thank you,
> >
> > --Petr
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > This transmission (including any attachments) may
> > contain confidential information, privileged material
> > (including material protected by the solicitor-client or
> > other applicable privileges), or constitute non-public
> > information. Any use of this information by anyone other than
> > the intended recipient is prohibited. If you have received
> > this transmission in error, please immediately reply to the
> > sender and delete this information from your system. Use,
> > dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and
> > may be unlawful.
> >
> >
> ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain
> > confidential information, privileged material (including
> > material protected by the solicitor-client or other
> > applicable privileges), or constitute non-public information.
> > Any use of this information by anyone other than the intended
> > recipient is prohibited. If you have received this
> > transmission in error, please immediately reply to the sender
> > and delete this information from your system. Use,
> > dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and
> > may be unlawful.
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
