[pgrouting-dev] Bidirectional Integration bug

Stephen_Woodbridge1 · May 6, 2013, 5:32pm

Hi Razequl,

I have been trying to integrate your bidirectional shortest path code. I have merged the code into my pgrouting branch "sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something when I merged it, or for that matter that I even merged the correct code because you sent email indicating that you fixed stuff. I merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code library, that the trsp broke, then take you code out and it works again. I assume that there is some kind of function name or global initialization issue. This does not seem to be an issue for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug environment setup and to familiarize yourself with the new source code layout.

Let me know if you have time and I'll help point the way. If you are tied up with class work, etc that clearly takes priority.

Thanks,
-Steve

robe · May 6, 2013, 9:17pm

For PostgreSQL 9.1+ and PostGIS 2.0+ it is possible to denote the version of
PostGIS to test with.

I'm wondering if it would be too much work to have that as a variable that
can be set in the test script.

The reason I ask is right now I have multiple versions of PostGIS installed
on each pg version of the buildbot.

So to pick which one to use. If I do

CREATE EXTENSION postgis;

It ends up using the last version installed.

However I can be more explicit and say

CREATE EXTENSION postgis VERSION "2.0.3";

Or

CREATE EXTENSION postgis VERSION "2.1.0SVN";

So if we could pass that in as a variable, would make it much easier to test
against different versions of PostGIS.

On a slightly related note, I noticed the sew_2.0 is installing the
extension as 1.0.7. Shouldn't this be bumped to 2.0.0?

Thanks,
Regina

Stephen_Woodbridge1 · May 6, 2013, 10:59pm

On 5/6/2013 5:17 PM, Paragon Corporation wrote:

For PostgreSQL 9.1+ and PostGIS 2.0+ it is possible to denote the version of
PostGIS to test with.

I'm wondering if it would be too much work to have that as a variable that
can be set in the test script.

The reason I ask is right now I have multiple versions of PostGIS installed
on each pg version of the buildbot.

So to pick which one to use. If I do

CREATE EXTENSION postgis;

It ends up using the last version installed.

However I can be more explicit and say

CREATE EXTENSION postgis VERSION "2.0.3";

Or

CREATE EXTENSION postgis VERSION "2.1.0SVN";

So if we could pass that in as a variable, would make it much easier to test
against different versions of PostGIS.

Ok, just checked in changes:

Usage: test-runner.pl -pgver vpg -pgisver vpgis -psql /path/to/psql
        -pgver vpg - postgresql version
        -pgisver vpgis - postgis version
        -psql /path/to/psql - optional path to psql
        -h - help

On a slightly related note, I noticed the sew_2.0 is installing the
extension as 1.0.7. Shouldn't this be bumped to 2.0.0?

Yes it will eventually change just have not gotten to it. The current release is 1.05. I also have not done anything to support versioning in pgrouting releases yet. I'm about ready to start making changes to all the function signatures when I do that I'm update the version to '2.0.0DEV'.

-Steve

dkastl · May 7, 2013, 2:49am

On a slightly related note, I noticed the sew_2.0 is installing the

extension as 1.0.7. Shouldn't this be bumped to 2.0.0?

Yes it will eventually change just have not gotten to it. The current
release is 1.05. I also have not done anything to support versioning in
pgrouting releases yet. I'm about ready to start making changes to all the
function signatures when I do that I'm update the version to '2.0.0DEV'.

For the documentation I have added a CMake module to read the Git revision
name/hash
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/CMakeLists.txt#L64

Maybe this would help to automate setting the version number. But I haven't
tried yet if this works with Git tags as well.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

robe · May 7, 2013, 4:28am

to test against different versions of PostGIS.

Ok, just checked in changes:

Usage: test-runner.pl -pgver vpg -pgisver vpgis -psql /path/to/psql

> -pgver vpg - postgresql version
> -pgisver vpgis - postgis version
> -psql /path/to/psql - optional path to psql
> -h - help

Steve,

Can you quote the vpgis version. Version is alwaways supposted to be quoted
otherwise get the below error and everything fails regress.

LINE 1: create extension postgis VERSION 2.1.0SVN
^

ERROR: required extension "postgis" is not installed

Thanks,
Regina

Razequl_Islam · May 7, 2013, 5:35am

Hi Steve,
I also want to have a look at the possible problem. I am trying to set up the environment on my machine. I have the previous version. What do I need to do to get 2.0 working? Should I set up the environment from the scratch or should an update will do. Please let me know how I should proceed. I can also do the debugging once I have the environment in place.

Thanks.

Razequl

···

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi Razequl,

I have been trying to integrate your bidirectional shortest path code. I have merged the code into my pgrouting branch “sew-devel-2_0”, but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as I would like to get this code working in 2.0.

I’m not sure if I found a bug in your code or I broke something when I merged it, or for that matter that I even merged the correct code because you sent email indicating that you fixed stuff. I merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code library, that the trsp broke, then take you code out and it works again. I assume that there is some kind of function name or global initialization issue. This does not seem to be an issue for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug environment setup and to familiarize yourself with the new source code layout.

Let me know if you have time and I’ll help point the way. If you are tied up with class work, etc that clearly takes priority.

Thanks,
-Steve

dkastl · May 7, 2013, 5:40am

Hi Razequl,

The currently used branch is named “sew-devel-2_0” (we’re planning to rename it to “develop” some time).
You find all the necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0

If you want to compile with support for “Driving Distance”, then you need to have CGAL libraries as dependency. GAUL dependency is gone.

Daniel

···

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam <ziboncsedu@gmail.com> wrote:

Hi Steve,
I also want to have a look at the possible problem. I am trying to set up the environment on my machine. I have the previous version. What do I need to do to get 2.0 working? Should I set up the environment from the scratch or should an update will do. Please let me know how I should proceed. I can also do the debugging once I have the environment in place.

Thanks.

Razequl

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi Razequl,

I have been trying to integrate your bidirectional shortest path code. I have merged the code into my pgrouting branch “sew-devel-2_0”, but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as I would like to get this code working in 2.0.

I’m not sure if I found a bug in your code or I broke something when I merged it, or for that matter that I even merged the correct code because you sent email indicating that you fixed stuff. I merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code library, that the trsp broke, then take you code out and it works again. I assume that there is some kind of function name or global initialization issue. This does not seem to be an issue for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug environment setup and to familiarize yourself with the new source code layout.

Let me know if you have time and I’ll help point the way. If you are tied up with class work, etc that clearly takes priority.

Thanks,
-Steve

Razequl_Islam · May 7, 2013, 5:52am

Hi Daniel,
Thanks for the information. I am going through the given link and trying to set it up. I will let you know if I am finished or I encounter any problem. Thanks for your help.

Razequl

···

On Tue, May 7, 2013 at 11:40 AM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Razequl,

The currently used branch is named “sew-devel-2_0” (we’re planning to rename it to “develop” some time).
You find all the necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0

If you want to compile with support for “Driving Distance”, then you need to have CGAL libraries as dependency. GAUL dependency is gone.

Daniel

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam <ziboncsedu@gmail.com> wrote:

Hi Steve,
I also want to have a look at the possible problem. I am trying to set up the environment on my machine. I have the previous version. What do I need to do to get 2.0 working? Should I set up the environment from the scratch or should an update will do. Please let me know how I should proceed. I can also do the debugging once I have the environment in place.

Thanks.

Razequl

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi Razequl,

I have been trying to integrate your bidirectional shortest path code. I have merged the code into my pgrouting branch “sew-devel-2_0”, but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as I would like to get this code working in 2.0.

I’m not sure if I found a bug in your code or I broke something when I merged it, or for that matter that I even merged the correct code because you sent email indicating that you fixed stuff. I merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code library, that the trsp broke, then take you code out and it works again. I assume that there is some kind of function name or global initialization issue. This does not seem to be an issue for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug environment setup and to familiarize yourself with the new source code layout.

Let me know if you have time and I’ll help point the way. If you are tied up with class work, etc that clearly takes priority.

Thanks,
-Steve

Alec_Gosse · May 7, 2013, 2:27pm

Hello all,

I am working on a bicycle routing project and converting from Open Trip Planner to pgRouting on both OSX and 64bit Ubuntu with PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under ubuntu 12.10, but not on OSX 10.8 using dependencies installed through Homebrew.

Homebrew is certainly the best way I've found to install open-source tools on a mac, so I would like to help get pgRouting 2.0 installable that way. Homebrew tends to use quite current packages such as boost 1.53, however, but I see in tool/NOTES.txt that pgRouting requires boost 1.46.1? Since things build on Ubuntu using boost 1.49, I'm wondering if this still applies?

In either case, what's the best way for me to help get things running under OSX? Should I post errors I can't resolve to the list, and or is someone already working on this?

Best,
Conrad (Alec) Gosse, MUEP
Doctoral Candidate: Civil &
Environmental Engineering
University of Virginia
Charlottesville, VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Razequl,

The currently used branch is named "sew-devel-2_0" (we're planning to rename it to "develop" some time).
You find all the necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0

If you want to compile with support for "Driving Distance", then you need to have CGAL libraries as dependency. GAUL dependency is gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam <ziboncsedu@gmail.com> wrote:
Hi Steve,
I also want to have a look at the possible problem. I am trying to set up the environment on my machine. I have the previous version. What do I need to do to get 2.0 working? Should I set up the environment from the scratch or should an update will do. Please let me know how I should proceed. I can also do the debugging once I have the environment in place.

Thanks.
- Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:
Hi Razequl,

I have been trying to integrate your bidirectional shortest path code. I have merged the code into my pgrouting branch "sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something when I merged it, or for that matter that I even merged the correct code because you sent email indicating that you fixed stuff. I merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code library, that the trsp broke, then take you code out and it works again. I assume that there is some kind of function name or global initialization issue. This does not seem to be an issue for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug environment setup and to familiarize yourself with the new source code layout.

Let me know if you have time and I'll help point the way. If you are tied up with class work, etc that clearly takes priority.

Thanks,
-Steve

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Stephen_Woodbridge1 · May 7, 2013, 4:34pm

On 5/7/2013 1:35 AM, Razequl Islam wrote:

Hi Steve,
I also want to have a look at the possible problem. I am trying to set
up the environment on my machine. I have the previous version. What do I
need to do to get 2.0 working? Should I set up the environment from the
scratch or should an update will do. Please let me know how I should
proceed. I can also do the debugging once I have the environment in place.

If you have the old environment already there, then it should be as simple as:

mkdir work
cd work

# if you already have a fork it might be better to work with that
git clone git://github.com/pgRouting/pgrouting.git

cd pgrouting
git checkout sew-devel-2_0
tools/doit
(cd build && sudo make install)

tools/test-runner.pl

tools/doit - a simple shell script to configure and compile. It creates a directory "build" and all the build atrifacts go into it.

tools/test-runner.pl - is a perl script the runs the automated tests in the database. If you have pg 9.1+ it assumes you can use "create extension " for both postgis and pgrouting. If you have pg <9.1 then it assumes you have already create a template_pgrouting database that has postgis installed in it.

Currently, I have db_* test disabled as they crash. you can run them manually with:

create a database with postgis and pgrouting installed in it say "test1"

# load the test data for dijkstra
psql -U postgres -h localhost -f src/bd_dijkstra/test/bd_dijkstra-any-00.data test1

# run a test(s) for dijkstra (test are 01-06)
psql -U postgres -h localhost -f src/bd_dijkstra/test/bd_dijkstra-any-01.test test1

# load the test data for astar
psql -U postgres -h localhost -f src/bd_astar/test/bd_astar-any-00.data test1

# run a test(s) for astar(test are 01-06)
psql -U postgres -h localhost -f src/bd_astar/test/bd_astar-any-01.test test1

I have run both your unit test files in "tester" directory and they run ok, So it has something to do with the integration.

Thanks,
-Steve

Thanks.
- Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Hi Razequl,

    I have been trying to integrate your bidirectional shortest path
    code. I have merged the code into my pgrouting branch
    "sew-devel-2_0", but it is crashing the back-end with a segv.

    If you have time and want to look into this that would be great as I
    would like to get this code working in 2.0.

    I'm not sure if I found a bug in your code or I broke something when
    I merged it, or for that matter that I even merged the correct code
    :) because you sent email indicating that you fixed stuff. I merged
    the code from master at https://github.com/zibon/__pgrouting
    <https://github.com/zibon/pgrouting>

    I also ran into an issue that when I merged you code into the code
    library, that the trsp broke, then take you code out and it works
    again. I assume that there is some kind of function name or global
    initialization issue. This does not seem to be an issue for trsp now
    that the bi-dir code is in a separate library.

    This might give you a chance to get your development/test/debug
    environment setup and to familiarize yourself with the new source
    code layout.

    Let me know if you have time and I'll help point the way. If you are
    tied up with class work, etc that clearly takes priority.

    Thanks,
       -Steve

Stephen_Woodbridge1 · May 7, 2013, 8:11pm

On 5/7/2013 10:27 AM, Alec Gosse wrote:

Hello all,

I am working on a bicycle routing project and converting from Open
Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under
ubuntu 12.10, but not on OSX 10.8 using dependencies installed
through Homebrew.

Homebrew is certainly the best way I've found to install open-source
tools on a mac, so I would like to help get pgRouting 2.0 installable
that way. Homebrew tends to use quite current packages such as boost
1.53, however, but I see in tool/NOTES.txt that pgRouting requires
boost 1.46.1? Since things build on Ubuntu using boost 1.49, I'm
wondering if this still applies?

Well the required version is whatever you can get to work. I know there are some problems with 1.47, but those might be specific to that version.

In either case, what's the best way for me to help get things running
under OSX? Should I post errors I can't resolve to the list, and or
is someone already working on this?

Yes, We can try to help if we know what errors you are seeing. I'm not sure anyone here has OSX so you might need to take some initiative to figure things out. If you look at the CMakeLists.txt files that are sprinkled throughout the project tree, you will see that some of them have blocks like:

if(APPLE)
...
endif(APPLE)

maybe we don't have these setup correctly or maybe some are missing that need to be added. It would be great if you can help with this.

Thanks,
-Steve

Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
Environmental Engineering University of Virginia Charlottesville, VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de>
wrote:

Hi Razequl,

The currently used branch is named "sew-devel-2_0" (we're planning
to rename it to "develop" some time). You find all the necessary
steps to compile explained on the Github readme:
https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0

If you want to compile with support for "Driving Distance", then
you need to have CGAL libraries as dependency. GAUL dependency is
gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
<ziboncsedu@gmail.com> wrote: Hi Steve, I also want to have a look
at the possible problem. I am trying to set up the environment on
my machine. I have the previous version. What do I need to do to
get 2.0 working? Should I set up the environment from the scratch
or should an update will do. Please let me know how I should
proceed. I can also do the debugging once I have the environment in
place.

Thanks. - Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote: Hi Razequl,

I have been trying to integrate your bidirectional shortest path
code. I have merged the code into my pgrouting branch
"sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as
I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something
when I merged it, or for that matter that I even merged the correct
code because you sent email indicating that you fixed stuff. I
merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code
library, that the trsp broke, then take you code out and it works
again. I assume that there is some kind of function name or global
initialization issue. This does not seem to be an issue for trsp
now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug
environment setup and to familiarize yourself with the new source
code layout.

Let me know if you have time and I'll help point the way. If you
are tied up with class work, etc that clearly takes priority.

Thanks, -Steve

_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

-- Georepublic UG & Georepublic Japan eMail:
daniel.kastl@georepublic.de Web: http://georepublic.de
_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev mailing
list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

sanak · May 7, 2013, 10:05pm

Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private branch(“macports”) which is based on “sew-revel-2_0”,
and confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this weekend.

···

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com>

On 5/7/2013 10:27 AM, Alec Gosse wrote:

Hello all,

I am working on a bicycle routing project and converting from Open
Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under
ubuntu 12.10, but not on OSX 10.8 using dependencies installed
through Homebrew.

Homebrew is certainly the best way I’ve found to install open-source
tools on a mac, so I would like to help get pgRouting 2.0 installable
that way. Homebrew tends to use quite current packages such as boost
1.53, however, but I see in tool/NOTES.txt that pgRouting requires
boost 1.46.1? Since things build on Ubuntu using boost 1.49, I’m
wondering if this still applies?

Well the required version is whatever you can get to work. I know there are some problems with 1.47, but those might be specific to that version.

In either case, what’s the best way for me to help get things running
under OSX? Should I post errors I can’t resolve to the list, and or
is someone already working on this?

Yes, We can try to help if we know what errors you are seeing. I’m not sure anyone here has OSX so you might need to take some initiative to figure things out. If you look at the CMakeLists.txt files that are sprinkled throughout the project tree, you will see that some of them have blocks like:

if(APPLE)
…
endif(APPLE)

maybe we don’t have these setup correctly or maybe some are missing that need to be added. It would be great if you can help with this.

Thanks,
-Steve

Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
Environmental Engineering University of Virginia Charlottesville, VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de>
wrote:

Hi Razequl,

The currently used branch is named “sew-devel-2_0” (we’re planning
to rename it to “develop” some time). You find all the necessary
steps to compile explained on the Github readme:
https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0

If you want to compile with support for “Driving Distance”, then
you need to have CGAL libraries as dependency. GAUL dependency is
gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
<ziboncsedu@gmail.com> wrote: Hi Steve, I also want to have a look
at the possible problem. I am trying to set up the environment on
my machine. I have the previous version. What do I need to do to
get 2.0 working? Should I set up the environment from the scratch
or should an update will do. Please let me know how I should
proceed. I can also do the debugging once I have the environment in
place.

Thanks. - Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote: Hi Razequl,

I have been trying to integrate your bidirectional shortest path
code. I have merged the code into my pgrouting branch
“sew-devel-2_0”, but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great as
I would like to get this code working in 2.0.

I’m not sure if I found a bug in your code or I broke something
when I merged it, or for that matter that I even merged the correct
code because you sent email indicating that you fixed stuff. I
merged the code from master at https://github.com/zibon/pgrouting

I also ran into an issue that when I merged you code into the code
library, that the trsp broke, then take you code out and it works
again. I assume that there is some kind of function name or global
initialization issue. This does not seem to be an issue for trsp
now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug
environment setup and to familiarize yourself with the new source
code layout.

Let me know if you have time and I’ll help point the way. If you
are tied up with class work, etc that clearly takes priority.

Thanks, -Steve

_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

– Georepublic UG & Georepublic Japan eMail:
daniel.kastl@georepublic.de Web: http://georepublic.de
_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev mailing
list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Stephen_Woodbridge1 · May 8, 2013, 3:55pm

Hi sanak,

I looked at your changes below, and they do not seem to be based on my branch "sew-devel-2_0". The quick tell is that my source starts at "src/" and not "core/" as your changes reflect.

For linux I compile, install and test using:

tools/doit
(cd build; sudo make install)
tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef __APPLE__
...
#else
...
#endif

and in cmake you can use:

if(APPLE)
...
else(APPLE)
...
endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Thanks,
-Steve

On 5/7/2013 6:05 PM, sanak wrote:

Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private
branch("macports") which is based on "sew-revel-2_0",
and confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this
weekend.

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>

    On 5/7/2013 10:27 AM, Alec Gosse wrote:

        Hello all,

        I am working on a bicycle routing project and converting from Open
        Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
        PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under
        ubuntu 12.10, but not on OSX 10.8 using dependencies installed
        through Homebrew.

        Homebrew is certainly the best way I've found to install open-source
        tools on a mac, so I would like to help get pgRouting 2.0
        installable
        that way. Homebrew tends to use quite current packages such as boost
        1.53, however, but I see in tool/NOTES.txt that pgRouting requires
        boost 1.46.1? Since things build on Ubuntu using boost 1.49, I'm
        wondering if this still applies?

    Well the required version is whatever you can get to work. I know
    there are some problems with 1.47, but those might be specific to
    that version.

        In either case, what's the best way for me to help get things
        running
        under OSX? Should I post errors I can't resolve to the list, and or
        is someone already working on this?

    Yes, We can try to help if we know what errors you are seeing. I'm
    not sure anyone here has OSX so you might need to take some
    initiative to figure things out. If you look at the CMakeLists.txt
    files that are sprinkled throughout the project tree, you will see
    that some of them have blocks like:

    if(APPLE)
    ...
    endif(APPLE)

    maybe we don't have these setup correctly or maybe some are missing
    that need to be added. It would be great if you can help with this.

    Thanks,
       -Steve

        Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
        Environmental Engineering University of Virginia Charlottesville, VA

        On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de
        <mailto:daniel@georepublic.de>>
        wrote:

            Hi Razequl,

            The currently used branch is named "sew-devel-2_0" (we're
            planning
            to rename it to "develop" some time). You find all the necessary
            steps to compile explained on the Github readme:
            https://github.com/pgrouting/__pgrouting/tree/sew-devel-2_0
            <https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>

            If you want to compile with support for "Driving Distance", then
            you need to have CGAL libraries as dependency. GAUL
            dependency is
            gone.

            Daniel

            On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
            <ziboncsedu@gmail.com <mailto:ziboncsedu@gmail.com>> wrote:
            Hi Steve, I also want to have a look
            at the possible problem. I am trying to set up the
            environment on
            my machine. I have the previous version. What do I need to do to
            get 2.0 working? Should I set up the environment from the
            scratch
            or should an update will do. Please let me know how I should
            proceed. I can also do the debugging once I have the
            environment in
            place.

            Thanks. - Razequl

            On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
            <woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>>
            wrote: Hi Razequl,

            I have been trying to integrate your bidirectional shortest path
            code. I have merged the code into my pgrouting branch
            "sew-devel-2_0", but it is crashing the back-end with a segv.

            If you have time and want to look into this that would be
            great as
            I would like to get this code working in 2.0.

            I'm not sure if I found a bug in your code or I broke something
            when I merged it, or for that matter that I even merged the
            correct
            code because you sent email indicating that you fixed
            stuff. I
            merged the code from master at
            https://github.com/zibon/__pgrouting
            <https://github.com/zibon/pgrouting>

            I also ran into an issue that when I merged you code into
            the code
            library, that the trsp broke, then take you code out and it
            works
            again. I assume that there is some kind of function name or
            global
            initialization issue. This does not seem to be an issue for trsp
            now that the bi-dir code is in a separate library.

            This might give you a chance to get your development/test/debug
            environment setup and to familiarize yourself with the new
            source
            code layout.

            Let me know if you have time and I'll help point the way. If you
            are tied up with class work, etc that clearly takes priority.

            Thanks, -Steve

            _________________________________________________ pgrouting-dev
            mailing list pgrouting-dev@lists.osgeo.org
            <mailto:pgrouting-dev@lists.osgeo.org>
            http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
            <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>

            -- Georepublic UG & Georepublic Japan eMail:
            daniel.kastl@georepublic.de
            <mailto:daniel.kastl@georepublic.de> Web: http://georepublic.de
            _________________________________________________ pgrouting-dev
            mailing list pgrouting-dev@lists.osgeo.org
            <mailto:pgrouting-dev@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@lists.osgeo.org
        <mailto:pgrouting-dev@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@lists.osgeo.org <mailto:pgrouting-dev@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Alec_Gosse · May 8, 2013, 4:23pm

Hello,

Based on Sanak's changes, I think I've gotten it sorted out. The two primary problems were first, that some of the libraries weren't using the library type variable and were getting the compile flags mixed up between dynamiclibs and osx bundles. The second was that code like this:
property_map<graph_t, edge_weight_t>::type weightmap = get(edge_weight, graph);
needed to be commented out in boost-related files. I don't know what this does, but I've been commenting it based on Sanak's changes, and it at least compiles.

How do I go about contributing these edits once I get it all working?

Best,
Alec

On May 8, 2013, at 11:55 AM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi sanak,

I looked at your changes below, and they do not seem to be based on my branch "sew-devel-2_0". The quick tell is that my source starts at "src/" and not "core/" as your changes reflect.

For linux I compile, install and test using:

tools/doit
(cd build; sudo make install)
tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef __APPLE__
...
#else
...
#endif

and in cmake you can use:

if(APPLE)
...
else(APPLE)
...
endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Thanks,
-Steve

On 5/7/2013 6:05 PM, sanak wrote:

Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private
branch("macports") which is based on "sew-revel-2_0",
and confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this
weekend.

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>

   On 5/7/2013 10:27 AM, Alec Gosse wrote:

       Hello all,

       I am working on a bicycle routing project and converting from Open
       Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
       PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under
       ubuntu 12.10, but not on OSX 10.8 using dependencies installed
       through Homebrew.

       Homebrew is certainly the best way I've found to install open-source
       tools on a mac, so I would like to help get pgRouting 2.0
       installable
       that way. Homebrew tends to use quite current packages such as boost
       1.53, however, but I see in tool/NOTES.txt that pgRouting requires
       boost 1.46.1? Since things build on Ubuntu using boost 1.49, I'm
       wondering if this still applies?

   Well the required version is whatever you can get to work. I know
   there are some problems with 1.47, but those might be specific to
   that version.

       In either case, what's the best way for me to help get things
       running
       under OSX? Should I post errors I can't resolve to the list, and or
       is someone already working on this?

   Yes, We can try to help if we know what errors you are seeing. I'm
   not sure anyone here has OSX so you might need to take some
   initiative to figure things out. If you look at the CMakeLists.txt
   files that are sprinkled throughout the project tree, you will see
   that some of them have blocks like:

   if(APPLE)
   ...
   endif(APPLE)

   maybe we don't have these setup correctly or maybe some are missing
   that need to be added. It would be great if you can help with this.

   Thanks,
      -Steve

       Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
       Environmental Engineering University of Virginia Charlottesville, VA

       On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de
       <mailto:daniel@georepublic.de>>
       wrote:

           Hi Razequl,

           The currently used branch is named "sew-devel-2_0" (we're
           planning
           to rename it to "develop" some time). You find all the necessary
           steps to compile explained on the Github readme:
           https://github.com/pgrouting/__pgrouting/tree/sew-devel-2_0
           <https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>

           If you want to compile with support for "Driving Distance", then
           you need to have CGAL libraries as dependency. GAUL
           dependency is
           gone.

           Daniel

           On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
           <ziboncsedu@gmail.com <mailto:ziboncsedu@gmail.com>> wrote:
           Hi Steve, I also want to have a look
           at the possible problem. I am trying to set up the
           environment on
           my machine. I have the previous version. What do I need to do to
           get 2.0 working? Should I set up the environment from the
           scratch
           or should an update will do. Please let me know how I should
           proceed. I can also do the debugging once I have the
           environment in
           place.

           Thanks. - Razequl

           On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
           <woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>>
           wrote: Hi Razequl,

           I have been trying to integrate your bidirectional shortest path
           code. I have merged the code into my pgrouting branch
           "sew-devel-2_0", but it is crashing the back-end with a segv.

           If you have time and want to look into this that would be
           great as
           I would like to get this code working in 2.0.

           I'm not sure if I found a bug in your code or I broke something
           when I merged it, or for that matter that I even merged the
           correct
           code because you sent email indicating that you fixed
           stuff. I
           merged the code from master at
           https://github.com/zibon/__pgrouting
           <https://github.com/zibon/pgrouting>

           I also ran into an issue that when I merged you code into
           the code
           library, that the trsp broke, then take you code out and it
           works
           again. I assume that there is some kind of function name or
           global
           initialization issue. This does not seem to be an issue for trsp
           now that the bi-dir code is in a separate library.

           This might give you a chance to get your development/test/debug
           environment setup and to familiarize yourself with the new
           source
           code layout.

           Let me know if you have time and I'll help point the way. If you
           are tied up with class work, etc that clearly takes priority.

           Thanks, -Steve

           _________________________________________________ pgrouting-dev
           mailing list pgrouting-dev@lists.osgeo.org
           <mailto:pgrouting-dev@lists.osgeo.org>
           http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
           <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>

           -- Georepublic UG & Georepublic Japan eMail:
           daniel.kastl@georepublic.de
           <mailto:daniel.kastl@georepublic.de> Web: http://georepublic.de
           _________________________________________________ pgrouting-dev
           mailing list pgrouting-dev@lists.osgeo.org
           <mailto:pgrouting-dev@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@lists.osgeo.org
       <mailto:pgrouting-dev@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@lists.osgeo.org <mailto:pgrouting-dev@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Stephen_Woodbridge1 · May 8, 2013, 4:50pm

On 5/8/2013 12:23 PM, Alec Gosse wrote:

Hello,

Based on Sanak's changes, I think I've gotten it sorted out. The two
primary problems were first, that some of the libraries weren't using
the library type variable and were getting the compile flags mixed up
between dynamiclibs and osx bundles. The second was that code like
this: property_map<graph_t, edge_weight_t>::type weightmap =
get(edge_weight, graph); needed to be commented out in boost-related
files. I don't know what this does, but I've been commenting it based
on Sanak's changes, and it at least compiles.

How do I go about contributing these edits once I get it all
working?

Best way, is to fork the pgrouting respository, make your changes there and issue a pull request so we can merge your changes.

If there are not too many changes, you could do something like:

git diff > mychanges-diff.txt

And open a ticket and attache the diff file to the ticket.

-Steve

Best, Alec

On May 8, 2013, at 11:55 AM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi sanak,

I looked at your changes below, and they do not seem to be based on
my branch "sew-devel-2_0". The quick tell is that my source starts
at "src/" and not "core/" as your changes reflect.

For linux I compile, install and test using:

tools/doit (cd build; sudo make install) tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef __APPLE__ ... #else ... #endif

and in cmake you can use:

if(APPLE) ... else(APPLE) ... endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Thanks, -Steve

On 5/7/2013 6:05 PM, sanak wrote:

Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private
branch("macports") which is based on "sew-revel-2_0", and
confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this

weekend.

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>

On 5/7/2013 10:27 AM, Alec Gosse wrote:

Hello all,

I am working on a bicycle routing project and converting from
Open Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build
under ubuntu 12.10, but not on OSX 10.8 using dependencies
installed through Homebrew.

Homebrew is certainly the best way I've found to install
open-source tools on a mac, so I would like to help get pgRouting
2.0 installable that way. Homebrew tends to use quite current
packages such as boost 1.53, however, but I see in tool/NOTES.txt
that pgRouting requires boost 1.46.1? Since things build on
Ubuntu using boost 1.49, I'm wondering if this still applies?

Well the required version is whatever you can get to work. I
know there are some problems with 1.47, but those might be
specific to that version.

In either case, what's the best way for me to help get things
running under OSX? Should I post errors I can't resolve to the
list, and or is someone already working on this?

Yes, We can try to help if we know what errors you are seeing.
I'm not sure anyone here has OSX so you might need to take some
initiative to figure things out. If you look at the
CMakeLists.txt files that are sprinkled throughout the project
tree, you will see that some of them have blocks like:

if(APPLE) ... endif(APPLE)

maybe we don't have these setup correctly or maybe some are
missing that need to be added. It would be great if you can help
with this.

Thanks, -Steve

Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
Environmental Engineering University of Virginia Charlottesville,
VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de
<mailto:daniel@georepublic.de>> wrote:

Hi Razequl,

The currently used branch is named "sew-devel-2_0" (we're
planning to rename it to "develop" some time). You find all the
necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/__pgrouting/tree/sew-devel-2_0
<https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>

If you want to compile with support for "Driving Distance", then
you need to have CGAL libraries as dependency. GAUL dependency
is gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
<ziboncsedu@gmail.com <mailto:ziboncsedu@gmail.com>> wrote: Hi
Steve, I also want to have a look at the possible problem. I am
trying to set up the environment on my machine. I have the
previous version. What do I need to do to get 2.0 working? Should
I set up the environment from the scratch or should an update
will do. Please let me know how I should proceed. I can also do
the debugging once I have the environment in place.

Thanks. - Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:
Hi Razequl,

I have been trying to integrate your bidirectional shortest path
code. I have merged the code into my pgrouting branch
"sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great
as I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something
when I merged it, or for that matter that I even merged the
correct code because you sent email indicating that you fixed
stuff. I merged the code from master at
https://github.com/zibon/__pgrouting
<https://github.com/zibon/pgrouting>

I also ran into an issue that when I merged you code into the
code library, that the trsp broke, then take you code out and it
works again. I assume that there is some kind of function name
or global initialization issue. This does not seem to be an issue
for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug
environment setup and to familiarize yourself with the new
source code layout.

Let me know if you have time and I'll help point the way. If you
are tied up with class work, etc that clearly takes priority.

Thanks, -Steve

_________________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>

-- Georepublic UG & Georepublic Japan eMail:
daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de
_________________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev mailing
list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

dkastl · May 8, 2013, 5:15pm

How do I go about contributing these edits once I get it all

working?

Best way, is to fork the pgrouting respository, make your changes there
and issue a pull request so we can merge your changes.

For sure this would be easiest and best solution.

If there are not too many changes, you could do something like:

git diff > mychanges-diff.txt

And open a ticket and attache the diff file to the ticket.

I think Github doesn't allow to attach files to tickets (just looked for
it last week), but an alternative would be to use Gist:
https://gist.github.com/

Nevertheless, to fork the repository and then submit a pull request would
be better:
https://help.github.com/articles/using-pull-requests

Daniel

-Steve

Best, Alec

On May 8, 2013, at 11:55 AM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi sanak,

I looked at your changes below, and they do not seem to be based on
my branch "sew-devel-2_0". The quick tell is that my source starts
at "src/" and not "core/" as your changes reflect.

For linux I compile, install and test using:

tools/doit (cd build; sudo make install) tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef __APPLE__ ... #else ... #endif

and in cmake you can use:

if(APPLE) ... else(APPLE) ... endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Thanks, -Steve

On 5/7/2013 6:05 PM, sanak wrote:

Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private
branch("macports") which is based on "sew-revel-2_0", and
confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/**pgrouting4w/commit/**
7291a7b6be3bd37c9e507048bfe3ba**0fcf0c5c6e<https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e>

Now, I am busy for other task, but, I will check and test it in this

weekend.

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.**com <woodbri@swoodbridge.com>>>

On 5/7/2013 10:27 AM, Alec Gosse wrote:

Hello all,

I am working on a bicycle routing project and converting from
Open Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build
under ubuntu 12.10, but not on OSX 10.8 using dependencies
installed through Homebrew.

Homebrew is certainly the best way I've found to install
open-source tools on a mac, so I would like to help get pgRouting
2.0 installable that way. Homebrew tends to use quite current
packages such as boost 1.53, however, but I see in tool/NOTES.txt
that pgRouting requires boost 1.46.1? Since things build on
Ubuntu using boost 1.49, I'm wondering if this still applies?

Well the required version is whatever you can get to work. I
know there are some problems with 1.47, but those might be
specific to that version.

In either case, what's the best way for me to help get things
running under OSX? Should I post errors I can't resolve to the
list, and or is someone already working on this?

Yes, We can try to help if we know what errors you are seeing.
I'm not sure anyone here has OSX so you might need to take some
initiative to figure things out. If you look at the
CMakeLists.txt files that are sprinkled throughout the project
tree, you will see that some of them have blocks like:

if(APPLE) ... endif(APPLE)

maybe we don't have these setup correctly or maybe some are
missing that need to be added. It would be great if you can help
with this.

Thanks, -Steve

Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
Environmental Engineering University of Virginia Charlottesville,
VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de
<mailto:daniel@georepublic.de>**> wrote:

Hi Razequl,

The currently used branch is named "sew-devel-2_0" (we're
planning to rename it to "develop" some time). You find all the
necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/_**_pgrouting/tree/sew-devel-2_0<https://github.com/pgrouting/__pgrouting/tree/sew-devel-2_0>
<https://github.com/pgrouting/**pgrouting/tree/sew-devel-2_0<https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>
>

If you want to compile with support for "Driving Distance", then
you need to have CGAL libraries as dependency. GAUL dependency
is gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
<ziboncsedu@gmail.com <mailto:ziboncsedu@gmail.com>> wrote: Hi
Steve, I also want to have a look at the possible problem. I am
trying to set up the environment on my machine. I have the
previous version. What do I need to do to get 2.0 working? Should
I set up the environment from the scratch or should an update
will do. Please let me know how I should proceed. I can also do
the debugging once I have the environment in place.

Thanks. - Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.**com<woodbri@swoodbridge.com>>>
wrote:
Hi Razequl,

I have been trying to integrate your bidirectional shortest path
code. I have merged the code into my pgrouting branch
"sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great
as I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something
when I merged it, or for that matter that I even merged the
correct code because you sent email indicating that you fixed
stuff. I merged the code from master at
https://github.com/zibon/__**pgrouting<https://github.com/zibon/__pgrouting>
<https://github.com/zibon/**pgrouting<https://github.com/zibon/pgrouting>
>

I also ran into an issue that when I merged you code into the
code library, that the trsp broke, then take you code out and it
works again. I assume that there is some kind of function name
or global initialization issue. This does not seem to be an issue
for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug
environment setup and to familiarize yourself with the new
source code layout.

Let me know if you have time and I'll help point the way. If you
are tied up with class work, etc that clearly takes priority.

Thanks, -Steve

______________________________**___________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.**osgeo.org <pgrouting-dev@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<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
**>

-- Georepublic UG & Georepublic Japan eMail:
daniel.kastl@georepublic.de <mailto:daniel.kastl@**georepublic.de<daniel.kastl@georepublic.de>
>
Web: http://georepublic.de
______________________________**___________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.**osgeo.org <pgrouting-dev@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<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
**>

______________________________**___________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.**osgeo.org <pgrouting-dev@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<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
**>

______________________________**___________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.**osgeo.org <pgrouting-dev@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<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
**>

______________________________**_________________ pgrouting-dev
mailing list pgrouting-dev@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@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@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@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Alec_Gosse · May 8, 2013, 5:40pm

Thank you all for your guidance. I've submitted a pull request for my changes. As I noted in the text of the request, librouting_tsp and librouting_ksp are being built as static rather than dynamic libraries, so make install fails since they have the extension .a rather than .so. Any thoughts on this would be most appreciated.

The only other trouble I've run across is a very long list of warnings like this while compiling:
/usr/local/src/pgrouting/src/driving_distance/src/drivedist.c:220:34: warning: use of GNU old-style field designator extension [-Wgnu-designator]
edge_columns_t edge_columns = {id: -1, source: -1, target: -1,

Best,
Alec

On May 8, 2013, at 1:15 PM, Daniel Kastl <daniel@georepublic.de> wrote:

How do I go about contributing these edits once I get it all
working?

Best way, is to fork the pgrouting respository, make your changes there and issue a pull request so we can merge your changes.

For sure this would be easiest and best solution.

If there are not too many changes, you could do something like:

git diff > mychanges-diff.txt

And open a ticket and attache the diff file to the ticket.

I think Github doesn't allow to attach files to tickets (just looked for it last week), but an alternative would be to use Gist: https://gist.github.com/

Nevertheless, to fork the repository and then submit a pull request would be better:
https://help.github.com/articles/using-pull-requests

Daniel

-Steve

Best, Alec

On May 8, 2013, at 11:55 AM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi sanak,

I looked at your changes below, and they do not seem to be based on
my branch "sew-devel-2_0". The quick tell is that my source starts
at "src/" and not "core/" as your changes reflect.

For linux I compile, install and test using:

tools/doit (cd build; sudo make install) tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef __APPLE__ ... #else ... #endif

and in cmake you can use:

if(APPLE) ... else(APPLE) ... endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Thanks, -Steve

On 5/7/2013 6:05 PM, sanak wrote:
Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private
branch("macports") which is based on "sew-revel-2_0", and
confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this
weekend.

2013/5/8 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>

On 5/7/2013 10:27 AM, Alec Gosse wrote:

Hello all,

I am working on a bicycle routing project and converting from
Open Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build
under ubuntu 12.10, but not on OSX 10.8 using dependencies
installed through Homebrew.

Homebrew is certainly the best way I've found to install
open-source tools on a mac, so I would like to help get pgRouting
2.0 installable that way. Homebrew tends to use quite current
packages such as boost 1.53, however, but I see in tool/NOTES.txt
that pgRouting requires boost 1.46.1? Since things build on
Ubuntu using boost 1.49, I'm wondering if this still applies?

Well the required version is whatever you can get to work. I
know there are some problems with 1.47, but those might be
specific to that version.

In either case, what's the best way for me to help get things
running under OSX? Should I post errors I can't resolve to the
list, and or is someone already working on this?

Yes, We can try to help if we know what errors you are seeing.
I'm not sure anyone here has OSX so you might need to take some
initiative to figure things out. If you look at the
CMakeLists.txt files that are sprinkled throughout the project
tree, you will see that some of them have blocks like:

if(APPLE) ... endif(APPLE)

maybe we don't have these setup correctly or maybe some are
missing that need to be added. It would be great if you can help
with this.

Thanks, -Steve

Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
Environmental Engineering University of Virginia Charlottesville,
VA

On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel@georepublic.de
<mailto:daniel@georepublic.de>> wrote:

Hi Razequl,

The currently used branch is named "sew-devel-2_0" (we're
planning to rename it to "develop" some time). You find all the
necessary steps to compile explained on the Github readme:
https://github.com/pgrouting/__pgrouting/tree/sew-devel-2_0
<https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>

If you want to compile with support for "Driving Distance", then
you need to have CGAL libraries as dependency. GAUL dependency
is gone.

Daniel

On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
<ziboncsedu@gmail.com <mailto:ziboncsedu@gmail.com>> wrote: Hi
Steve, I also want to have a look at the possible problem. I am
trying to set up the environment on my machine. I have the
previous version. What do I need to do to get 2.0 working? Should
I set up the environment from the scratch or should an update
will do. Please let me know how I should proceed. I can also do
the debugging once I have the environment in place.

Thanks. - Razequl

On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:
Hi Razequl,

I have been trying to integrate your bidirectional shortest path
code. I have merged the code into my pgrouting branch
"sew-devel-2_0", but it is crashing the back-end with a segv.

If you have time and want to look into this that would be great
as I would like to get this code working in 2.0.

I'm not sure if I found a bug in your code or I broke something
when I merged it, or for that matter that I even merged the
correct code because you sent email indicating that you fixed
stuff. I merged the code from master at
https://github.com/zibon/__pgrouting
<https://github.com/zibon/pgrouting>

I also ran into an issue that when I merged you code into the
code library, that the trsp broke, then take you code out and it
works again. I assume that there is some kind of function name
or global initialization issue. This does not seem to be an issue
for trsp now that the bi-dir code is in a separate library.

This might give you a chance to get your development/test/debug
environment setup and to familiarize yourself with the new
source code layout.

Let me know if you have time and I'll help point the way. If you
are tied up with class work, etc that clearly takes priority.

Thanks, -Steve

_________________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>

-- Georepublic UG & Georepublic Japan eMail:
daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de
_________________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
<mailto:pgrouting-dev@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev
mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________ pgrouting-dev mailing
list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

sanak · May 8, 2013, 11:39pm

Hi Stephen,

···

2013/5/9 Stephen Woodbridge <woodbri@swoodbridge.com>

I looked at your changes below, and they do not seem to be based on my branch “sew-devel-2_0”. The quick tell is that my source starts at “src/” and not “core/” as your changes reflect.

Oh, sorry.
Thanks for notice.

For linux I compile, install and test using:

tools/doit
(cd build; sudo make install)
tools/testrunner.pl

In the C/C++ code you should be able to use:

#ifdef APPLE
…
#else
…
#endif

and in cmake you can use:

if(APPLE)
…
else(APPLE)
…
endif(APPLE)

Can you also post what the results of:

echo | g++ -dM -E -

when run on OSX.

No hurray, when you can get to it, this weekend is fine.

Okay, thanks for detail.

Regards,

sanak · May 8, 2013, 11:49pm

Hi Alec,

Thanks for your pull request!

···

2013/5/9 Alec Gosse <alec@thegosses.com>

Thank you all for your guidance. I’ve submitted a pull request for my changes. As I noted in the text of the request, librouting_tsp and librouting_ksp are being built as static rather than dynamic libraries, so make install fails since they have the extension .a rather than .so. Any thoughts on this would be most appreciated.

The only other trouble I’ve run across is a very long list of warnings like this while compiling:
/usr/local/src/pgrouting/src/driving_distance/src/drivedist.c:220:34: warning: use of GNU old-style field designator extension [-Wgnu-designator]
edge_columns_t edge_columns = {id: -1, source: -1, target: -1,

I guess that above warning cause is Clang(LLVM)'s g++ compatibility,
so, more custom CMake settings may be necessary.
I will check about it in this weekend (or later).

Thanks,
Sanak

Stephen_Woodbridge1 · May 9, 2013, 12:14am

On 5/8/2013 7:49 PM, sanak wrote:

Hi Alec,

Thanks for your pull request!

I'm merging the pull request and will push it shortly.

I have one question, does anyone know what the commented out code is supposed to do? IE: why is there in the first place? Commenting it out seems to be OK on Linux.

I google about but could not find an answer regarding why its there and I don't know C++. I suppose I could ask on the boost list if no one knows.

2013/5/9 Alec Gosse <alec@thegosses.com <mailto:alec@thegosses.com>>

    Thank you all for your guidance. I've submitted a pull request for
    my changes. As I noted in the text of the request, librouting_tsp
    and librouting_ksp are being built as static rather than dynamic
    libraries, so make install fails since they have the extension .a
    rather than .so. Any thoughts on this would be most appreciated.

    The only other trouble I've run across is a very long list of
    warnings like this while compiling:
    /usr/local/src/pgrouting/src/driving_distance/src/drivedist.c:220:34: warning:
    use of GNU old-style field designator extension [-Wgnu-designator]
       edge_columns_t edge_columns = {id: -1, source: -1, target: -1,

Before we #ifdef about this, it seems that there might be a better way to do this initialization, ie: NOT using the GNU old-style field designator extension but rather an ANSI C way of doing this.

I'll take a stab at it but if anyone knows how to change these please do a pull request.

Hi Alec,

So your pull request is generating *.a and not *.so, is this correct?

Thanks,
-Steve

I guess that above warning cause is Clang(LLVM)'s g++ compatibility,
so, more custom CMake settings may be necessary.
I will check about it in this weekend (or later).

Thanks,
Sanak

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev