Output of --debug in different places
When doing --debug with the GUI the logged lines appear either in the
standard output (or standard error??) or the GUI Console, or both.
The Console is a fixed size and wraps so output there is lost.
Is this a bug to be reported?
A recent example, with a recent Nightly on Debian, ~1700 lines of mainly
preferences messages is in the Terminal, then the GUI appears.
Load a file from the splash screen, F5.
Console shows:
---====================start
QSettingsCached: QSettings::setValue(): recentFileList = ''
QSettingsCached: QSettings::setValue(): recentFileList = ''
Loaded design '/usr/share/openscad/examples/Basics/logo.scad'.
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
ECHO: version = [2019, 6, 10]
Compiling design (CSG Products generation)...
Geometries in cache: 2
Geometry cache size in bytes: 725104
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Compiling highlights (1 CSG Trees)...
Normalized CSG tree has 4 elements
renderer: Renderer() start
renderer: setColorScheme
renderer: Renderer() end
renderer: Renderer() start
renderer: setColorScheme
renderer: Renderer() end
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds
renderer: setColorScheme
---====================end
This is in Terminal
---====================start
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
polyset-gl: Polyset render
renderer: setColor b
renderer: setColor a
polyset-gl: Polyset render
renderer: setColor b
renderer: setColor a
polyset-gl: Polyset render
renderer: setColor b
renderer: setColor a
polyset-gl: Polyset render
renderer: setColor b
renderer: setColor a
polyset-gl: Polyset render
renderer: setColor b
renderer: setColor a
polyset-gl: Polyset render
polyset-gl: Polyset render
---====================end
Then F6. A lot of interesting messages to Console, but by the time it
finishes they are lost.
Tail of console:
---====================start
<full of these next few lines>
OGL_helper: draw(Halffacet_iterator)
CGAL_OGL_Polyhedron: getFacetColor
OGL_helper: draw(Halffacet_iterator)
CGAL_OGL_Polyhedron: getFacetColor
OGL_helper: construct_axes
OGL_helper: init() end
CGALRenderer: buildPolyhedron() end
CGALRenderer: draw() polyhedron
CGAL_OGL_Polyhedron: draw()
CGAL_OGL_Polyhedron: draw() end
CGALRenderer: draw() end
---====================end
This added to Terminal
---====================start
CGALRenderer: draw()
CGALRenderer: draw() polyhedron
CGAL_OGL_Polyhedron: draw()
CGAL_OGL_Polyhedron: draw() end
CGALRenderer: draw() end
---====================end
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
On 21.07.19 09:20, MichaelAtOz wrote:
Is this a bug to be reported?
Not really, it's debug output. It might make sense to
clean up some stuff there, but it's not enabled normally
so there should be no harm even if there are some extra
messages that are not too useful.
In general I'm all for nice and useful debug messages
as those can help debugging issues on systems that can't
have development environments.
The Settings output going crazy does not fall in that
of cause. There's probably some GUI events triggering
that. Common and very annoying problem with lots of
GUI code I've seen.
ciao
Torsten.
This was not about the amount, but that some only go to the Console not to
Std:??, and the Console wraps, losing messages. Whether it was always that
way.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
On 22.07.19 00:58, MichaelAtOz wrote:
This was not about the amount, but that some only
go to the Console not to Std:??, and the Console> wraps, losing messages. Whether it was always that
way.
Probably, the GUI code has lots of places where it
switches the output in slightly obscure manner. One
of those places that would need some love, but
putting it on a prioritized list likely needs a very
long roll of paper ;-).
ciao,
Torsten.
Messages go to the stderr when they are not printed from a GUI event. When
printed from a GUI event they should go the console of the window the
event belongs to, but if they come from libraries that are not part of
OpenSCAD via random printfs they wont go the console.
The console wraps at 5000 lines, if you want to see more it can easily be
made bigger as it seems pretty light on resources. Perhaps a user
preference?
On Mon, 22 Jul 2019 at 00:05, Torsten Paul Torsten.Paul@gmx.de wrote:
On 22.07.19 00:58, MichaelAtOz wrote:
This was not about the amount, but that some only
go to the Console not to Std:??, and the Console> wraps, losing
messages. Whether it was always that
way.
Probably, the GUI code has lots of places where it
switches the output in slightly obscure manner. One
of those places that would need some love, but
putting it on a prioritized list likely needs a very
long roll of paper ;-).
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org