I would rather in favour of merging the trunk back to the sandbox first, and do some testings in place (either by adding some stuff to the msautotest as well). <br>Then if we get rid of the potential issues (build problems, memory corruptions, segfaults) we can safely add the stuff in the trunk permanently.<br>
<br>Currently I find several issues either with the simplest mapfiles that should somehow be fixed first. The opengl support didn't work for me at all, it seems the implementation didn't follow the recent changes of the vtable names caused compiler errors. It may also be required to install some additional things that I'm currently not aware of.<br>
I've fixed up the most alloying issues and the sandbox now compiles on windows. I also advertised ready to use windows binary packages for the users to be able to test with on the mapserver-users list.<br><br>Best regards,<br>
<br>Tamas<br><br><br><br><br><br><div class="gmail_quote">2009/4/19 Steve Lime <span dir="ltr"><<a href="mailto:Steve.Lime@dnr.state.mn.us">Steve.Lime@dnr.state.mn.us</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My feeling is we should go with the merge now and work out any details where<br>
there are divergent paths (such as caching) later. We need this addition. Some<br>
of my comments were related to detail such as:<br>
<br>
- how should renderer options be encoded in an output format (presumably not<br>
as a format option, perhaps a new renderer option (hash?))<br>
- what will the make-up of the more specific rendering objects such as line styles<br>
look like?<br>
- reference maps are still necessary but I think we could attack them by turning a<br>
request for one into an internal mapfile and handing it off to the renderer.<br>
<br>
So, I'm +1 for the merge ASAP.<br>
<br>
Steve<br>
<br>
>>> thomas bonfort <<a href="mailto:thomas.bonfort@camptocamp.com">thomas.bonfort@camptocamp.com</a>> 04/17/09 10:49 AM >>><br>
Hi devs,<br>
<br>
RFC 54 has just been committed to the docs site:<br>
<br>
<a href="http://mapserver.org/development/rfc/ms-rfc-54.html" target="_blank">http://mapserver.org/development/rfc/ms-rfc-54.html</a><br>
<br>
I've tried to be as complete as possible, but I'm quite sure I may<br>
have missed a couple (I hope minor) points.<br>
<br>
Most of the RFC is implemented in the graphics sandbox. It would be<br>
great if some of you could try it on your local mapfiles to squeeze<br>
out as many bugs as possible (currently not activated/implemented are<br>
symbology on lines and polygons, and all the raster layer related code).<br>
To enable the plugin code, you need to configure with --with-cairo.<br>
The outputformat drivers are cairo/png , cairo/jpeg, cairo/svg and<br>
cairo/pdf.<br>
<br>
Ideally I'd like to merge the graphics branch into the trunk around<br>
the end of the month so we have more eyes on it before our september<br>
release target.<br>
<br>
Best regards,<br>
<br>
thomas<br>
_______________________________________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
<br>
_______________________________________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</blockquote></div><br>