<div dir="ltr">+0 <div><br></div><div>Looks good to me but I need some time to understand everything mentioned here (which shouldn't be a blocker for development).<br><br></div><div>Thanks for your efforts.</div><div>Best, </div><div>Rajat</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 11, 2023 at 1:04 PM Ashish Kumar <<a href="mailto:ashishkr23438@gmail.com">ashishkr23438@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1, looks good.<div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div>Regards,</div>Ashish.</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 11 Apr 2023 at 21:56, Vicky Vergara <<a href="mailto:vicky@erosion.dev" target="_blank">vicky@erosion.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Hello all:<br>PSC: Please send your vote on this motion<br></div><div>General developers: If you see fit, please let us know what you think.<br></div><div><br></div><div>I am opening this motion, because of the following:<br></div><div>During the last 10 years an effort has been made to standardize the code base of pgRouting.</div><div>With this standardization, adding new functionality has been getting "easier".<br><div>TRSP was a stopper, on simplifying the code base as it did not follow the standard we have been using these last years, but finally on 3.4, we managed to rewrite the code and fix a lot of bugs that pgr_trsp had:</div><div>Before: <a href="https://docs.pgrouting.org/3.3/en/pgr_trsp.html" target="_blank">https://docs.pgrouting.org/3.3/en/pgr_trsp.html</a><br></div><div>That starting from 3.4 has become: <br><a href="https://docs.pgrouting.org/3.4/en/pgr_trsp.html" target="_blank">https://docs.pgrouting.org/3.4/en/pgr_trsp.html</a><br><a href="https://docs.pgrouting.org/3.4/en/pgr_trsp_withPoints.html" target="_blank">https://docs.pgrouting.org/3.4/en/pgr_trsp_withPoints.html</a></div><div><a href="https://docs.pgrouting.org/3.4/en/pgr_trspVia.html" target="_blank">https://docs.pgrouting.org/3.4/en/pgr_trspVia.html</a><br><a href="https://docs.pgrouting.org/3.4/en/pgr_trspVia_withPoints.html" target="_blank">https://docs.pgrouting.org/3.4/en/pgr_trspVia_withPoints.html</a></div><div>(the old functionality is still available)<br></div></div><br>As standardized code, I mean files/and functions (visually) look very similar and they work in a similar way. On Monday April 10, I made a twitch about the following PR<br><a href="https://github.com/pgRouting/pgrouting/pull/2504" target="_blank">https://github.com/pgRouting/pgrouting/pull/2504</a><br>The twitch channel:<br><a href="https://www.twitch.tv/cvvergara" target="_blank">https://www.twitch.tv/cvvergara</a><br></div>Where I explain the commonality of the "*_input" files, and how the work was done to simplify the base code of pgRouting. (2 hours aprox)<br></div><div>There is one problem that is out of our control with MSVC and postgres, where we are not alone, as plv8 also has the same problem. (detail on the issue).<br></div><div><br></div><div>By doing the changes proposed on the PR, it will be avoided problems generated from the copy/paste and "forgot to adjust something",<br></div><div>for example:<br><a href="https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L243" target="_blank">https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L243</a><br></div><div>Clearly the file was copied from the orders_input file, but "forgot to change the word "Orders" to "vehicles".<br></div><div>Also, those PGR_DBG are for developing purposes, and "forgot to delete those PGR_DBG" statements. This is a "Development problem".<br></div><div>We also might have "Maintenance problems", for example, because of the interaction with postgres like the data type <font size="4"><span style="font-family:monospace">Portal</span></font>:<br><a href="https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L196" target="_blank">https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L196</a></div><div>if for some reason whatsoever, the PostgreSQL team decides to change the name of the data type, we have zillions of places where we need to do a change.<br></div><div><br>By using C++ and having a template:<br><a href="https://github.com/pgRouting/pgrouting/pull/2504/commits/38ebae23a5d65e98590f4d3a817ebea419a6f6c5" target="_blank">https://github.com/pgRouting/pgrouting/pull/2504/commits/38ebae23a5d65e98590f4d3a817ebea419a6f6c5</a><br></div><div><br></div><div>* the type that postgres has its captured automatically, for example:<br></div><div><span style="font-family:monospace"><font size="4">auto SPIportal = pgr_SPI_cursor_open(SPIplan);</font></span><br></div><div>* The code is clean, we don't need to use PGR_DBG like before, with manual copy/paste and adjustment, something might be missing, and we need to debug, but then, when things work, we forget that we don't need to debug anymore.<br><br></div><div>So a lot of problems for developing and maintenance are solved by using C++ instead of C and using templates on similar code.<br><br></div><div>This is a first step, and a crucial one as there is a function <span style="font-family:monospace"><font size="4">static void process </font></span>within the C files, that connect with postgres, where they make the calls to get the data from postgres.<br></div><div>and they are all similar, therefore they are candidates to become templates<br><br></div><div>This experiment:<br><a href="https://github.com/pgRouting/pgrouting/pull/2473" target="_blank">https://github.com/pgRouting/pgrouting/pull/2473</a><br></div><div>Although not using a template, but using a single file to process 2 pgrouting functions, demonstrates that templating can be achieved, and the getters will be called from within C++ code.<br><br></div><div>So the getters,/fetchers/check code on the<br><a href="https://github.com/pgRouting/pgrouting/pull/2504" target="_blank">https://github.com/pgRouting/pgrouting/pull/2504</a><br></div><div>that interact with postgres, it's a "must" to be in C++, this "must" does not work well on MSVC.<br></div><div>Which by the way, been the main developer of pgRouting, I haven't touched a windows machine, let alone MSVC since 1997, So from my point of view, developing pgRouting with MSVC is not a priority, what is the priority is that it still be compiled with msys2/mingw64 (whatever that is) and that can be package for windows. (Which Regina has confirmed can be done)<br><br></div><div></div><div>Regards<br></div><div>Vicky<br></div><div></div><div><div><br></div></div></div>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pgrouting-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
</blockquote></div>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pgrouting-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
</blockquote></div>