things to make mapnik a better developer experience

23 views

Skip to first unread message

kRAkEn/gORe

unread,

Mar 28, 2012, 10:52:50 AM3/28/12

to map...@googlegroups.com

Hi list,
i would like to apply some cleanups and cosmetics changes in the
postgis plugin code, and would like to know where to apply those
changes, if apply them in the master branch or eventually directly in
2.0.x branch.
also, i would like to implemement:

* better debug log handling (especially in plugins)
- ability to compile in std::clog output not only in DEBUG but also
when DEBUG_LOG is defined (to allow logging string in release too)
- if DEBUG is True then DEBUG_LOG will be defined too automatically,
but when DEBUG is False then you need to explicitly define DEBUG_LOG
to enable release logging
- when DEBUG_LOG is defined, add the configuration option (globally
in map or in each plugin initially) to enable or disable logging by
using a variable (obviously this has to do nothing when DEBUG_LOG
support is not compiled in)

<Layer name="mylayer" status="on">
<StyleName>mystyle</StyleName>
<Datasource>
<Parameter name="type">shape</Parameter>
<Parameter name="file">world_boundaries/world</Parameter>
<Parameter name="debug">true</Parameter>
</Datasource>
</Layer>

* some sort of performance benchmark of plugins (binding, querying,
fetching data, binary conversion, etc..)
- compile in benchmark class when PROFILE is True
- allow setting profile off for each datasource

- have an output to something like:

...
[postgis] (SELECT * FROM my_table LIMIT 0): 0.0001s
[postgis] (SELECT ST_XMin(ext),ST_YMin(ext),ST_XMax(ext),ST_YMax(ext)
FROM (SELECT ST_Extent(geom) AS ext FROM my_table): 2.86475s
...

this way you can find easily where the stuff is failing... ouch !

let me know what you think, i *REALLY* starting to need such tools
when developing and improving plugins, but this can be extended to
work also to debug
and profile the rendering code.

cheers,

Lucio

Dane Springmeyer

unread,

Mar 28, 2012, 11:10:40 PM3/28/12

to map...@googlegroups.com, map...@googlegroups.com

Lucio,

Great thoughts.

2.0.x branch is just for stable bug fixes/backports, so new code should go into master (2.1.x series).

Ideally plugin framework/methods for debug printing and profiling could developed in a branch of master, be tested there and rebased into a single commit before merging.