Discussion:
Per project debug helpers and expending QTC variables in "Extra Debugging Helpers" setting
(too old to reply)
jeandet
2018-09-06 06:26:06 UTC
Permalink
Hi all,

I was trying to add per project debugging helpers with QTC by using
gdbinit file which doesn't seems to work. If I add something like this
'python exec(open('/some-path/qtc-helpers.py').read())' gdb loads the
file without error while my classes are not decorated and this file
works if loaded from QTC in "Extra Debugging Helpers".
So is there an error in the doc here?

http://doc.qt.io/qtcreator/creator-debugging-helpers.html#adding-custom-debugging-helpers
And even here it seems to says that it should works:
https://github.com/awulkiew/debugging-helpers

Then my second attempt was to add %{CurrentProject:Path}/qtc-helpers.py
in "Extra Debugging Helpers", here while there is a little variable
chooser widget, it seems that we can't use QTC variable here.
Looking quickly in the QTC code, this widget is a PathChooser which has
a FancyLineEdit which doesn't seems to expend QTC variables maybe only
ENV vars with Environment::expandVariables .


I'm not sure I'm right but this looks like two bugs? If yes I can do a
bug report.

BTW, my main question is, did I miss a way to load per custom Debugging
Helpers project? I don't really understand why the default use case
would be to make them global. When you work on different projects or
when your classes change you have to update your Debugging Helpers. It
would be more convenient to ship them with each project and QTC would
detect them with some mechanism. This way it would ensure that helpers
match current code.
Best regards,
Alexis.
Eike Ziller
2018-09-06 06:46:50 UTC
Permalink
Post by jeandet
Hi all,
I was trying to add per project debugging helpers with QTC by using gdbinit file which doesn't seems to work. If I add something like this 'python exec(open('/some-path/qtc-helpers.py').read())' gdb loads the file without error while my classes are not decorated and this file works if loaded from QTC in "Extra Debugging Helpers".
So is there an error in the doc here?
http://doc.qt.io/qtcreator/creator-debugging-helpers.html#adding-custom-debugging-helpers
https://github.com/awulkiew/debugging-helpers
Then my second attempt was to add %{CurrentProject:Path}/qtc-helpers.py in "Extra Debugging Helpers", here while there is a little variable chooser widget, it seems that we can't use QTC variable here.
Looking quickly in the QTC code, this widget is a PathChooser which has a FancyLineEdit which doesn't seems to expend QTC variables maybe only ENV vars with Environment::expandVariables .
I'm not sure I'm right but this looks like two bugs? If yes I can do a bug report.
No idea about the first one, but at least that the variables don’t work sounds like a bug.
The variable chooser is there, but it looks like the value is not expanded where it is used
(e.g. in GdbEngine::setupEngine(), "const QString path = stringSetting(ExtraDumperFile);” there should be some kind of Utils::globalMacroExpander()->expand(…) be involved).

Br, Eike
Post by jeandet
BTW, my main question is, did I miss a way to load per custom Debugging Helpers project? I don't really understand why the default use case would be to make them global. When you work on different projects or when your classes change you have to update your Debugging Helpers. It would be more convenient to ship them with each project and QTC would detect them with some mechanism. This way it would ensure that helpers match current code.
Best regards,
Alexis.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator
--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
***@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
André Pönitz
2018-09-06 07:35:10 UTC
Permalink
Post by jeandet
I was trying to add per project debugging helpers with QTC by using gdbinit file which
doesn't seems to work. If I add something like this 'python
exec(open('/some-path/qtc-helpers.py').read())' gdb loads the file without error while my
classes are not decorated and this file works if loaded from QTC in "Extra Debugging
Helpers". So is there an error in the doc here?
It "works" in .gdbinit but takes a bit more code, currently sth like

python sys.path.insert(1, '/data/dev/creator/share/qtcreator/debugger/')
python import gdbbridge
python gdbbridge.theDumper.addDumperModule({"path":"/tmp/qtc.py"}

This is likely to change over time, so I'd recommend to use the "Extra Debugging
Helpers" setting which will be adapted when this happens
Post by jeandet
Then my second attempt was to add %{CurrentProject:Path}/qtc-helpers.py in "Extra Debugging
Helpers", here while there is a little variable chooser widget, it seems that we can't use
QTC variable here. Looking quickly in the QTC code, this widget is a PathChooser which has
a FancyLineEdit which doesn't seems to expend QTC variables maybe only ENV vars with
Environment::expandVariables .
Bug.
Post by jeandet
I'm not sure I'm right but this looks like two bugs? If yes I can do a bug report.
Feel free to.
Post by jeandet
BTW, my main question is, did I miss a way to load per custom Debugging Helpers project?
No, there isn't.
Post by jeandet
I don't really understand why the default use case would be to make them global.
When you
work on different projects or when your classes change you have to update your Debugging
Helpers. It would be more convenient to ship them with each project and QTC would detect
them with some mechanism. This way it would ensure that helpers match current code.
That's in theory the Right Method, but in practice it breaks at least as often as
any other approach. A classic in that situation are incompatible Python versions
for dumpers for different libraries.

Having said that, applying a simple scheme like 'if there is a foo.so, check whether
there's a foo.so.pyqtc in reach' would make sense to me.

Andre'
jeandet
2018-09-06 08:16:29 UTC
Permalink
Thank you Eike and André for your help :)
Post by André Pönitz
Post by jeandet
I was trying to add per project debugging helpers with QTC by using gdbinit file which
doesn't seems to work. If I add something like this 'python
exec(open('/some-path/qtc-helpers.py').read())' gdb loads the file
without error while my
classes are not decorated and this file works if loaded from QTC in "Extra Debugging
Helpers". So is there an error in the doc here?
It "works" in .gdbinit but takes a bit more code, currently sth like
python sys.path.insert(1,
'/data/dev/creator/share/qtcreator/debugger/')
python import gdbbridge
python gdbbridge.theDumper.addDumperModule({"path":"/tmp/qtc.py"}
Makes sense, I though it was weird that qtc would find dumper functions
by just loading my script in gdb.
Post by André Pönitz
This is likely to change over time, so I'd recommend to use the "Extra Debugging
Helpers" setting which will be adapted when this happens
Post by jeandet
Then my second attempt was to add %{CurrentProject:Path}/qtc-
helpers.py in "Extra Debugging
Helpers", here while there is a little variable chooser widget, it
seems that we can't use
QTC variable here. Looking quickly in the QTC code, this widget is
a PathChooser which has
a FancyLineEdit which doesn't seems to expend QTC variables maybe only ENV vars with
Environment::expandVariables .
Bug.
Post by jeandet
I'm not sure I'm right but this looks like two bugs? If yes I can do a bug report.
Feel free to.
https://codereview.qt-project.org/#/c/238974/
This a is quite trivial patch and makes me using gerrit...
Post by André Pönitz
Post by jeandet
BTW, my main question is, did I miss a way to load per custom
Debugging Helpers project?
No, there isn't.
Post by jeandet
I don't really understand why the default use case would be to make them global.
When you
work on different projects or when your classes change you have to
update your Debugging
Helpers. It would be more convenient to ship them with each project
and QTC would detect
them with some mechanism. This way it would ensure that helpers match current code.
That's in theory the Right Method, but in practice it breaks at least as often as
any other approach. A classic in that situation are incompatible Python versions
for dumpers for different libraries.
Having said that, applying a simple scheme like 'if there is a
foo.so, check whether
there's a foo.so.pyqtc in reach' would make sense to me.
Yeah or anything that would detect project wide helpers. Maybe
buildsystem generator variables would also be enough.
Post by André Pönitz
Andre'
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator
Loading...