Hello all:
PSC: Please send your vote on this motion
General developers: If you see fit, please let us know what you think.
I am opening this motion, because of the following:
During the last 10 years an effort has been made to standardize the code base of pgRouting.
With this standardization, adding new functionality has been getting “easier”.
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:
Before: https://docs.pgrouting.org/3.3/en/pgr_trsp.html
That starting from 3.4 has become:
https://docs.pgrouting.org/3.4/en/pgr_trsp.html
https://docs.pgrouting.org/3.4/en/pgr_trsp_withPoints.html
https://docs.pgrouting.org/3.4/en/pgr_trspVia.html
https://docs.pgrouting.org/3.4/en/pgr_trspVia_withPoints.html
(the old functionality is still available)
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
https://github.com/pgRouting/pgrouting/pull/2504
The twitch channel:
https://www.twitch.tv/cvvergara
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)
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).
By doing the changes proposed on the PR, it will be avoided problems generated from the copy/paste and “forgot to adjust something”,
for example:
https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L243
Clearly the file was copied from the orders_input file, but "forgot to change the word “Orders” to “vehicles”.
Also, those PGR_DBG are for developing purposes, and “forgot to delete those PGR_DBG” statements. This is a “Development problem”.
We also might have “Maintenance problems”, for example, because of the interaction with postgres like the data type Portal:
https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L196
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.
By using C++ and having a template:
https://github.com/pgRouting/pgrouting/pull/2504/commits/38ebae23a5d65e98590f4d3a817ebea419a6f6c5
- the type that postgres has its captured automatically, for example:
auto SPIportal = pgr_SPI_cursor_open(SPIplan);
- 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.
So a lot of problems for developing and maintenance are solved by using C++ instead of C and using templates on similar code.
This is a first step, and a crucial one as there is a function static void process within the C files, that connect with postgres, where they make the calls to get the data from postgres.
and they are all similar, therefore they are candidates to become templates
This experiment:
https://github.com/pgRouting/pgrouting/pull/2473
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.
So the getters,/fetchers/check code on the
https://github.com/pgRouting/pgrouting/pull/2504
that interact with postgres, it’s a “must” to be in C++, this “must” does not work well on MSVC.
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)
Regards
Vicky