Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Question about MIVariableManager

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Petr Suchomel
> Sent: Thursday, May 16, 2013 2:44 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Question about MIVariableManager
> 
> Marc,
> 
> Thanks for hint. 
> 
> MIVariableObject.setChildren(ExpressionInfo[]) sets the 
> expression info, but does not create physical children which 
> means, they still need to be created. Can you give me a 
> little more insights?

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.

> 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. 
> 

Back to the top