[pgrouting-dev] DBSP first try problems
Razequl Islam
ziboncsedu at gmail.com
Sun Jul 1 02:14:01 PDT 2012
Hi Steve,
Thanks for your comments. Here are my feedbacks:
- I completely agree with you with the commenting issue. I will add more
comments in the code, specially what each of the function does. I think it
will be very helpful to people reading the code.
- Actually I do have a test code that reads input from text file call the
function in the same manner the sql does, get the result and writes it back
to another text file. I did this for my own debugging purpose, never
thought it will be helpful for others. But from your remark, I am thinking
that this can be easily turned into a nice testing tool and can be added
with the main codes. I need to clean up and modify the existing code and I
think then I can add it with my project. Currently I am busy with the A*
implementation. Once it is finished, I will give one or two days on the
testing code.
- Please let me know the results of your test and your experience on it.
- Razegul
On Sun, Jul 1, 2012 at 1:09 AM, Stephen Woodbridge
<woodbri at swoodbridge.com>wrote:
> Hi Razequl,
>
> (Jinfu, I have not had a chance to look over your code yet, but to the
> extent that the comments below might apply to your code, you might want to
> consider this as input to you also.)
>
> I am not going to try and review you actual algorithm, because I'm not
> sure I can add any value or insights to it. The following are observations
> and recommendations as opposed to requirements.
>
> Regarding your project, the code looks very clean and easy to read, but it
> does not have many/any comments describing what it is doing or how it
> works. I am equally negligent in this area with a lot of my code, but have
> found that over time a regret not adding the comments when I write the code
> originally because it requires more work to figure it out later. Also when
> others have to read it and make changes for any reason it is great to have
> the comments to help understand the code. Also since this code will be
> publicly available to a very wide audience this says a lot about you to
> these people.
>
> We have not really figured out how we want to do testing yet. I know Jay
> did some initial test infrastructure, I have taken a couple of stabs at
> trying to work out some method for doing this. There are multiple levels of
> testing and it might mean that we have different infrastructure for each.
> When Roni developed the core TRSP algorithm, he had a local test bed which
> consisted of a C/C++ main commandline tool, that could read in a text file
> that defined a graph, restrictions, test cases and results. Basically these
> very much followed the output of the SQL needed to feed the SQL function to
> invoke the command. So the main would read in the text file, run the
> algorithm and display the results and exit. This worked totally outside the
> postgresql environment. This made it easy to run in the debugger and made
> it easy to verify the correctness of the core algorithm. Unfortunately this
> never got checked into the source tree so we don't have it today. One of
> the advantages of this approach, was that when a bug was reported, we could
> easily run the SQL commands to create the text files for input, then run
> the test program. If the results were the same as the SQL results then we
> knew the problem was in the core algorithm and it could easily be debugged.
> If the test results were good then we knew that the problem was in the
> wrapper code that I wrote and I could then tackle debugging that.
>
> It would be nice to have a directory like extra/bdsp/test/ that contained
> test files, and a target to build extra/bdsp/src/dotest and a a target for
> make test that would run all the tests in the test directory using dotest
> and would report pass/fail for each test.
>
> This might be something that you and jinfu and maybe Jay would get
> involved to collaborate for some extra karma points :). Before you commit
> to something like this make sure you can meet the requirements of your
> projects. If you can work it into your own project then that would be fine
> also and we can review and refactor what you have done for pgRouting as a
> whole later after GSoC.
>
> Next I will install you code and try to run it against some of my graphs.
>
> Great job so far, keep up the good work.
>
> Thanks,
> -Steve
>
>
>
> On 6/29/2012 9:46 PM, Razequl Islam wrote:
>
>> Hi Steve,
>> It is great that you got some time to review the code. I have trsp in my
>> local folder but I found it is not in the git. I will commit that again.
>> And yes, commenting trsp subdirs should work. Also as I have not done
>> any work on that folder, you should be able to review my work. All my
>> codes are in the bdsp folder.
>> Thanks for your time. I am waiting to learn more from you.
>>
>> - Razequl
>>
>> On Fri, Jun 29, 2012 at 11:10 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>>>
>> wrote:
>>
>> OK, my temporary fix was to comment out the subdir:
>>
>> #SUBDIRS(extra/trsp)
>>
>> -Steve
>>
>>
>> On 6/29/2012 12:59 PM, Stephen Woodbridge wrote:
>>
>> Hi Razequl,
>>
>> I finally have some time to look at your code, but have run into
>> a small
>> build problem.
>>
>> woodbri at mappy:~/work/ pgrouting-git/gsoc-bdsp$ git clone
>> git://github.com/zibon/ pgrouting.git
>> <http://github.com/zibon/**pgrouting.git<http://github.com/zibon/pgrouting.git>
>> >
>>
>> Initialized empty Git repository in
>> /u/work/pgrouting-git/gsoc- bdsp/pgrouting/.git/
>> remote: Counting objects: 1930, done.
>> remote: Compressing objects: 100% (743/743), done.
>> remote: Total 1930 (delta 1189), reused 1882 (delta 1151)
>> Receiving objects: 100% (1930/1930), 685.37 KiB | 1112 KiB/s,
>> done.
>> Resolving deltas: 100% (1189/1189), done.
>> woodbri at mappy:~/work/ pgrouting-git/gsoc-bdsp/ pgrouting$ cmake .
>>
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- POSTGRESQL_EXECUTABLE is POSTGRESQL_EXECUTABLE-NOTFOUND
>> -- Found PostgreSQL: /usr/include/postgresql/8.3/ server,
>> /usr/lib/libpq.so
>> -- Boost version: 1.34.1
>> -- Found the following Boost libraries:
>> Boost headers were found here: /usr/include
>> Output directory for libraries is set to
>> /usr/lib/postgresql/8.4/lib
>> -- Found PGROUTING_CORE core:
>> /home/woodbri/work/pgrouting- git/gsoc-bdsp/pgrouting/core/ src
>> Installation directory for libraries is set to
>> /usr/lib/postgresql/8.4/lib and for SQL files is set to
>> /usr/share/pgrouting
>> CMake Error at CMakeLists.txt:117 (SUBDIRS):
>> subdirs Incorrect SUBDIRS command. Directory: extra/trsp
>> does not
>> exists.
>>
>>
>> -- Configuring done
>> woodbri at mappy:~/work/ pgrouting-git/gsoc-bdsp/ pgrouting$ ls
>> extra/
>>
>> bdsp CMakeLists.txt driving_distance tsp
>>
>>
>> So you can see that there is no extra/trsp directory in your
>> repository.
>> Do you need to add, commit and push that to your remote?
>>
>> Also don't forget your report, its Friday again. :)
>>
>> Thanks,
>> -Steve
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>> osgeo.org <pgrouting-dev at lists.osgeo.org>>
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>>
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>>
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>>
>>
>> ______________________________**_________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>
>>
>
> ______________________________**_________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120701/fb430404/attachment-0001.html>
More information about the pgrouting-dev
mailing list