Hi all
As a reminder these will be added as experimental functions with the following text on the documentation:
Step 1: The GSoC participants removed from the GSoC team have no longer access to the repositories.
meaning
repo = Branch was created on the pgRouting repo instead of the student repo if not merged in a week the branch will be deleted, and the student would need to create a new PR from a fork.
No seg fault = Segmentation fault found before merge, should be fixed before merge. note: Although we have a message on all experimental functions about the possibility of segmentation fault.
No known issues = Issues were found. Need documentation about issue.
progress and new (issue) links will be posted in this thread
pgr_coreNumbers PR has been merged into develop.
The tests were so complete that was easy to fix the issue found by the rabbit.
@sakirr05 thanks for your contribution
pgr_planarFaces PR has been merged into develop.
The tests were so complete that was easy to fix the issue found by the rabbit.
I did modify a lot the excesive documentation.
@sakirr05 thanks for your contribution
pgr_makeBiconnectedPlanar PR has been merged into develop.
The tests were so complete that was easy to fix the issue found.
@Mohit242-bit thanks for your contribution
About pgr_makeMaximalPlanar:
Unfortunatelly I need to close the PR and delete branch: It was created on the pgrouting repo instead of a fork, pgRouting repo is for releases work, not for new features work.
- we do not want users to be mislead about new functionality on other branches.
@Mohit242-bit you will need to create a PR from your fork (actions running), fix the segmentation fault for it to be merged, otherwise the PR (that comes from a fork) can remain as draft until the segmentation fault is fixed.
Hii @cvvergara ,
I’ve created a PR from my fork to the pgrouting repository to fix the segmentation issue. Please let me know if any further changes are needed.
Hi @Mohit242-bit
Thanks for the new PR.
I was wondering what happened to the commits?:
- [makeMaximalPlanar/sql] Adding SQL code for pgr_makeMaximalPlanar
- [makeMaximalPlanar/C/C++] Adding C/C++ code for pgr_makeMaximalPlanar
- [makeMaximalPlanar/pgtap] Adding test files for pgr_makeMaximalPlanar
- [makeMaximalPlanar/docqueries] Adding test documentation examples cod…
- [makeMaximalPlanar/doc] Adding documentation for pgr_makeMaximalPlanar
- Updating release notes and NEWS about the new function pgr_makeMaxima…
Maybe you don’t know how to do a git rebase or a git cherry-pick?
Anyway I am waiting for Iosefa to have a look into it.
pgr_maxWeightedMatch PR has been merged into develop
It follows the same structure of maxCardinalityMatch (rabbit comments made me realize that)
so it now returns column edge instead of start_vid, end_vid, agg_cost
Both functions were added into ordering_driver
I had a branch were I was working on the maxCardinalityMatch using an existing driver so I just used what I had worked in my fork before 
I also separated implementation from the header.
@Mayur I think you don’t understand what is a header and when to put code on the header.
(besides that templates go in header files)
So simple example
a header file.hpp
int bar();
inline int foo() {return 1;}; // very little code
the implementation file.cpp
int bar() {
<zillions of lines of code>
;};
You had an inline function with <zillions of lines of code>
@sakirr05 thanks for your contribution
