Menu
▾
▴
pagc-devel — Development mailing list for the PAGC project
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(12) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(4) |
Oct
(16) |
Nov
(7) |
Dec
|
| 2008 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(31) |
Sep
(14) |
Oct
(6) |
Nov
(42) |
Dec
(105) |
| 2009 |
Jan
(52) |
Feb
(38) |
Mar
(49) |
Apr
(1) |
May
(22) |
Jun
(9) |
Jul
(25) |
Aug
(43) |
Sep
(6) |
Oct
(18) |
Nov
(15) |
Dec
(21) |
| 2010 |
Jan
(1) |
Feb
|
Mar
(12) |
Apr
|
May
|
Jun
(14) |
Jul
(27) |
Aug
(18) |
Sep
(28) |
Oct
|
Nov
(29) |
Dec
(36) |
| 2011 |
Jan
(22) |
Feb
|
Mar
(7) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
|
From: Stephen W. <wo...@sw...> - 2011-09-24 15:06:06
|
Also fixed a minor type in branches/datastore/geocode_response/main.c and checked that into svn. So to answer my previous questions, pagc and geocode_response works built with THREE_SOURCE_IDS that was built without that option. http://imaptools.com:8080/cgi-bin/gc-tiger?methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=&CompleteAddressNumber=11&CompleteStreetName=Radcliffe+Rd&CompleteStreetName2=&PlaceName=North+Chelmsford&StateName=MA&ZipCode=01863&CountryCode=US&ResponseFormat=XML Thanks for the help. My next step is to build a new instance that populates those fields. Thanks for the help, -Steve On 9/24/2011 1:44 AM, whi...@de... wrote: > Hi Steve : I posted changes for the below in revision 257. Thanks,<= w => > >> Hi Walter, >> >> build.c has some other problems also related to WITH_ALT_LEFT_RIGHT >> being set or not. >> >> at line 552 you have: >> >> #ifdef WITH_ALT_LEFT_RIGHT >> int stand_alt_macro_right ; /* 2011-08-13 new */ >> char unstandard_mac_alternate_right[ MAXSTRLEN ] ; /* 2011-08-13 new >> */ >> #else >> char unstandard_mac_alternate[ MAXSTRLEN ] ; /* 2008-07-30 new */ >> #endif >> >> But later at line 597 you have: >> >> error_code = read_unstandardized( sch_p , >> _alpha_table , >> alpha_row_num , >> &sides_to_do , >> &stand_alt_macro , >> #ifdef WITH_ALT_LEFT_RIGHT >> &stand_alt_macro_right , /* >> 2011-08-13 */ >> #endif >> house_address , >> check_dir , >> unstandard_mic , >> unstandard_mac_left, >> ( is_arc? unstandard_mac_right : >> NULL ) , >> unstandard_mac_alternate , /* >> 2008-07-30 */ >> #ifdef WITH_ALT_LEFT_RIGHT >> unstandard_mac_alternate_right , >> /* 2011-08-13 */ >> #endif >> unstandard_occupancy , >> official_buffers , >> official_fields , >> &off_cnt , >> err_p ) ; >> >> So this leaves unstandard_mac_alternate undefined up top if >> WITH_ALT_LEFT_RIGHT is define and referenced here regardless. So it >> compiles only when WITH_ALT_LEFT_RIGHT is not defined. >> >> And this also has the untermined #ifdef WITH_ALT_LEFT_RIGHT that I >> mentioned in the prior email. >> >> Hope this helps, >> -Steve >> >> >> On 9/23/2011 11:39 AM, Stephen Woodbridge wrote: >>> Hi Walter, >>> >>> That seems to have fixed the first two issues. At 734 the problem is the >>> colon following the "switch () :" just remove it. >>> >>> svn diff alpharef.c >>> Index: alpharef.c >>> =================================================================== >>> --- alpharef.c (revision 256) >>> +++ alpharef.c (working copy) >>> @@ -731,7 +731,7 @@ >>> case PROV : >>> #ifdef WITH_ALT_LEFT_RIGHT >>> /* 2011-08-17 : enable left_right for PROV */ >>> - switch ( cmp ) : >>> + switch ( cmp ) >>> { >>> case NO_COMPARISON : >>> break ; >>> >>> In pagc.h I commented out WITH_ALT_LEFT_RIGHT because I am build single >>> sided records: >>> >>> svn diff pagc.h >>> Index: pagc.h >>> =================================================================== >>> --- pagc.h (revision 256) >>> +++ pagc.h (working copy) >>> @@ -34,7 +34,7 @@ >>> #include<math.h> >>> #include "ds.h" >>> >>> -#define WITH_ALT_LEFT_RIGHT >>> +//#define WITH_ALT_LEFT_RIGHT >>> >>> /* 2009-07-21 : keep track of version >>> 2010-02-01 : increase to 0.3.0 >>> >>> I also show this random change in score.c: >>> >>> svn diff score.c >>> Index: score.c >>> =================================================================== >>> --- score.c (revision 256) >>> +++ score.c (working copy) >>> @@ -106,6 +106,7 @@ >>> >>> #ifdef DEFER >>> DS_Flag_t defer_bit = 0 ; >>> + DS_Score_t absent_score = 0.00 ; >>> DS_Score_t absent_match = 0.00 ; >>> DS_Score_t absent_unmatch = 0.00 ; >>> DS_Score_t present_norm = 0.00 ; >>> >>> And finally I'm now hitting an issue compiling build.c it looks like >>> there is an issue with an unclosed #ifdef blobk near the bottom. But I >>> also suspect that there may be an issue with WITH_ALT_LEFT_RIGHT not >>> being defined. >>> >>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make >>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\" >>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\" >>> -DPACKAGE_STRING=\"pagc\ 0.4.0\" >>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 >>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\"" >>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD >>> -MP -MF .deps/libpagc_la-build.Tpo -c -o libpagc_la-build.lo `test -f >>> 'build.c' || echo './'`build.c >>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\" >>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\"" >>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 >>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\" >>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD >>> -MP -MF .deps/libpagc_la-build.Tpo -c build.c -fPIC -DPIC -o >>> .libs/libpagc_la-build.o >>> build.c:1008:1: error: unterminated #ifdef >>> build.c:987:1: error: unterminated #else >>> build.c: In function âbuild_rowâ: >>> build.c:1006: error: expected declaration or statement at end of input >>> build.c:1006: error: expected declaration or statement at end of input >>> make: *** [libpagc_la-build.lo] Error 1 >>> >>> Thanks, >>> -Steve >>> >>> On 9/23/2011 2:02 AM, whi...@de... wrote: >>>> Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if >>>> there >>>> is one. >>>> >>>>> Hi Walter, >>>>> >>>>> I'm having a problem building pagc. >>>>> >>>>> cd ~/work/pagc/pagc/branches/datastore/ds >>>>> ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f >>>>> make clean >>>>> make >>>>> sudo make install >>>>> sudo ldconfig >>>>> >>>>> cd ../pagclib >>>>> ./configure --disable-threads >>>>> vi makefile >>>>> # append to DEFS=... -DTHREE_SOURCE_IDS=1 >>>>> make clean >>>>> make >>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make >>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc >>>>> -DPACKAGE_NAME=\"pagc\" >>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\" >>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\" >>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER >>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\"" >>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo >>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo >>>>> `test -f 'alpharef.c' || echo './'`alpharef.c >>>>> mkdir .libs >>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\" >>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\"" >>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER >>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\" >>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo >>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC >>>>> -o >>>>> .libs/libpagc_la-alpharef.o >>>>> alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ >>>>> alpharef.c: In function âread_unstandardizedâ: >>>>> alpharef.c:734: error: expected expression before â:â token >>>>> make: *** [libpagc_la-alpharef.lo] Error 1 >>>>> >>>>> Fixed this by changing (notice missing '_' char: >>>>> char *dest primary_right >>>>> to: >>>>> char *dest_primary_right >>>>> >>>>> Now getting: >>>>> >>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make >>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc >>>>> -DPACKAGE_NAME=\"pagc\" >>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\" >>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\" >>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 >>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\"" >>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo >>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo >>>>> `test -f 'alpharef.c' || echo './'`alpharef.c >>>>> mkdir .libs >>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\" >>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\"" >>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" >>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 >>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 >>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 >>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\" >>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo >>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC >>>>> -o >>>>> .libs/libpagc_la-alpharef.o >>>>> alpharef.c: In function âleft_right_alt_macroâ: >>>>> alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in >>>>> this function) >>>>> alpharef.c:242: error: (Each undeclared identifier is reported only >>>>> once >>>>> alpharef.c:242: error: for each function it appears in.) >>>>> alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first >>>>> use >>>>> in this function) >>>>> alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in >>>>> this function) >>>>> alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared >>>>> (first use in this function) >>>>> alpharef.c: In function âread_unstandardizedâ: >>>>> alpharef.c:734: error: expected expression before â:â token >>>>> make: *** [libpagc_la-alpharef.lo] Error 1 >>>>> >>>>> Can you check that everything you changed has been checked in. >>>>> >>>>> Thanks, >>>>> -Steve >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> All the data continuously generated in your IT infrastructure contains >>>>> a >>>>> definitive record of customers, application performance, security >>>>> threats, fraudulent activity and more. Splunk takes this data and >>>>> makes >>>>> sense of it. Business sense. IT sense. Common sense. >>>>> http://p.sf.net/sfu/splunk-d2dcopy1 >>>>> _______________________________________________ >>>>> Pagc-devel mailing list >>>>> Pag...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> All of the data generated in your IT infrastructure is seriously >>>> valuable. >>>> Why? It contains a definitive record of application performance, >>>> security >>>> threats, fraudulent activity, and more. Splunk takes this data and >>>> makes >>>> sense of it. IT sense. And common sense. >>>> http://p.sf.net/sfu/splunk-d2dcopy2 >>>> _______________________________________________ >>>> Pagc-devel mailing list >>>> Pag...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously >>> valuable. >>> Why? It contains a definitive record of application performance, >>> security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2dcopy2 >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2dcopy2 >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Stephen W. <wo...@sw...> - 2011-09-24 14:28:26
|
Thanks Walter,
I also checking a couple of more changes in rev 258 in files
pagc_client.c and candform.c so do an update when you have a chance to
stay in sync.
So pagclib now compiles.
I forgot to ask, with THREE_SOURCE_IDS enabled, I assume that the actual
use is based on the schema file and if the fields are defined there.
Correct?
And I assume that a pagc database built without this code is not
compatible with pagclib built with THREE_SOURCE_IDS defined, regardless
of the schema file. Correct?
-Steve
On 9/24/2011 1:44 AM, whi...@de... wrote:
> Hi Steve : I posted changes for the below in revision 257. Thanks,<= w =>
>
>> Hi Walter,
>>
>> build.c has some other problems also related to WITH_ALT_LEFT_RIGHT
>> being set or not.
>>
>> at line 552 you have:
>>
>> #ifdef WITH_ALT_LEFT_RIGHT
>> int stand_alt_macro_right ; /* 2011-08-13 new */
>> char unstandard_mac_alternate_right[ MAXSTRLEN ] ; /* 2011-08-13 new
>> */
>> #else
>> char unstandard_mac_alternate[ MAXSTRLEN ] ; /* 2008-07-30 new */
>> #endif
>>
>> But later at line 597 you have:
>>
>> error_code = read_unstandardized( sch_p ,
>> _alpha_table ,
>> alpha_row_num ,
>> &sides_to_do ,
>> &stand_alt_macro ,
>> #ifdef WITH_ALT_LEFT_RIGHT
>> &stand_alt_macro_right , /*
>> 2011-08-13 */
>> #endif
>> house_address ,
>> check_dir ,
>> unstandard_mic ,
>> unstandard_mac_left,
>> ( is_arc? unstandard_mac_right :
>> NULL ) ,
>> unstandard_mac_alternate , /*
>> 2008-07-30 */
>> #ifdef WITH_ALT_LEFT_RIGHT
>> unstandard_mac_alternate_right ,
>> /* 2011-08-13 */
>> #endif
>> unstandard_occupancy ,
>> official_buffers ,
>> official_fields ,
>> &off_cnt ,
>> err_p ) ;
>>
>> So this leaves unstandard_mac_alternate undefined up top if
>> WITH_ALT_LEFT_RIGHT is define and referenced here regardless. So it
>> compiles only when WITH_ALT_LEFT_RIGHT is not defined.
>>
>> And this also has the untermined #ifdef WITH_ALT_LEFT_RIGHT that I
>> mentioned in the prior email.
>>
>> Hope this helps,
>> -Steve
>>
>>
>> On 9/23/2011 11:39 AM, Stephen Woodbridge wrote:
>>> Hi Walter,
>>>
>>> That seems to have fixed the first two issues. At 734 the problem is the
>>> colon following the "switch () :" just remove it.
>>>
>>> svn diff alpharef.c
>>> Index: alpharef.c
>>> ===================================================================
>>> --- alpharef.c (revision 256)
>>> +++ alpharef.c (working copy)
>>> @@ -731,7 +731,7 @@
>>> case PROV :
>>> #ifdef WITH_ALT_LEFT_RIGHT
>>> /* 2011-08-17 : enable left_right for PROV */
>>> - switch ( cmp ) :
>>> + switch ( cmp )
>>> {
>>> case NO_COMPARISON :
>>> break ;
>>>
>>> In pagc.h I commented out WITH_ALT_LEFT_RIGHT because I am build single
>>> sided records:
>>>
>>> svn diff pagc.h
>>> Index: pagc.h
>>> ===================================================================
>>> --- pagc.h (revision 256)
>>> +++ pagc.h (working copy)
>>> @@ -34,7 +34,7 @@
>>> #include<math.h>
>>> #include "ds.h"
>>>
>>> -#define WITH_ALT_LEFT_RIGHT
>>> +//#define WITH_ALT_LEFT_RIGHT
>>>
>>> /* 2009-07-21 : keep track of version
>>> 2010-02-01 : increase to 0.3.0
>>>
>>> I also show this random change in score.c:
>>>
>>> svn diff score.c
>>> Index: score.c
>>> ===================================================================
>>> --- score.c (revision 256)
>>> +++ score.c (working copy)
>>> @@ -106,6 +106,7 @@
>>>
>>> #ifdef DEFER
>>> DS_Flag_t defer_bit = 0 ;
>>> + DS_Score_t absent_score = 0.00 ;
>>> DS_Score_t absent_match = 0.00 ;
>>> DS_Score_t absent_unmatch = 0.00 ;
>>> DS_Score_t present_norm = 0.00 ;
>>>
>>> And finally I'm now hitting an issue compiling build.c it looks like
>>> there is an issue with an unclosed #ifdef blobk near the bottom. But I
>>> also suspect that there may be an issue with WITH_ALT_LEFT_RIGHT not
>>> being defined.
>>>
>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
>>> -MP -MF .deps/libpagc_la-build.Tpo -c -o libpagc_la-build.lo `test -f
>>> 'build.c' || echo './'`build.c
>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
>>> -MP -MF .deps/libpagc_la-build.Tpo -c build.c -fPIC -DPIC -o
>>> .libs/libpagc_la-build.o
>>> build.c:1008:1: error: unterminated #ifdef
>>> build.c:987:1: error: unterminated #else
>>> build.c: In function âbuild_rowâ:
>>> build.c:1006: error: expected declaration or statement at end of input
>>> build.c:1006: error: expected declaration or statement at end of input
>>> make: *** [libpagc_la-build.lo] Error 1
>>>
>>> Thanks,
>>> -Steve
>>>
>>> On 9/23/2011 2:02 AM, whi...@de... wrote:
>>>> Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if
>>>> there
>>>> is one.
>>>>
>>>>> Hi Walter,
>>>>>
>>>>> I'm having a problem building pagc.
>>>>>
>>>>> cd ~/work/pagc/pagc/branches/datastore/ds
>>>>> ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
>>>>> make clean
>>>>> make
>>>>> sudo make install
>>>>> sudo ldconfig
>>>>>
>>>>> cd ../pagclib
>>>>> ./configure --disable-threads
>>>>> vi makefile
>>>>> # append to DEFS=... -DTHREE_SOURCE_IDS=1
>>>>> make clean
>>>>> make
>>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc
>>>>> -DPACKAGE_NAME=\"pagc\"
>>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>>>> mkdir .libs
>>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC
>>>>> -o
>>>>> .libs/libpagc_la-alpharef.o
>>>>> alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ
>>>>> alpharef.c: In function âread_unstandardizedâ:
>>>>> alpharef.c:734: error: expected expression before â:â token
>>>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>>>
>>>>> Fixed this by changing (notice missing '_' char:
>>>>> char *dest primary_right
>>>>> to:
>>>>> char *dest_primary_right
>>>>>
>>>>> Now getting:
>>>>>
>>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc
>>>>> -DPACKAGE_NAME=\"pagc\"
>>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>>>> mkdir .libs
>>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC
>>>>> -o
>>>>> .libs/libpagc_la-alpharef.o
>>>>> alpharef.c: In function âleft_right_alt_macroâ:
>>>>> alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in
>>>>> this function)
>>>>> alpharef.c:242: error: (Each undeclared identifier is reported only
>>>>> once
>>>>> alpharef.c:242: error: for each function it appears in.)
>>>>> alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first
>>>>> use
>>>>> in this function)
>>>>> alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in
>>>>> this function)
>>>>> alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared
>>>>> (first use in this function)
>>>>> alpharef.c: In function âread_unstandardizedâ:
>>>>> alpharef.c:734: error: expected expression before â:â token
>>>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>>>
>>>>> Can you check that everything you changed has been checked in.
>>>>>
>>>>> Thanks,
>>>>> -Steve
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure contains
>>>>> a
>>>>> definitive record of customers, application performance, security
>>>>> threats, fraudulent activity and more. Splunk takes this data and
>>>>> makes
>>>>> sense of it. Business sense. IT sense. Common sense.
>>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>>> _______________________________________________
>>>>> Pagc-devel mailing list
>>>>> Pag...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All of the data generated in your IT infrastructure is seriously
>>>> valuable.
>>>> Why? It contains a definitive record of application performance,
>>>> security
>>>> threats, fraudulent activity, and more. Splunk takes this data and
>>>> makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy2
>>>> _______________________________________________
>>>> Pagc-devel mailing list
>>>> Pag...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance,
>>> security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy2
>>> _______________________________________________
>>> Pagc-devel mailing list
>>> Pag...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> _______________________________________________
>> Pagc-devel mailing list
>> Pag...@li...
>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Pagc-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagc-devel
|
|
From: <whi...@de...> - 2011-09-24 05:44:36
|
Hi Steve : I posted changes for the below in revision 257. Thanks, <= w =>
> Hi Walter,
>
> build.c has some other problems also related to WITH_ALT_LEFT_RIGHT
> being set or not.
>
> at line 552 you have:
>
> #ifdef WITH_ALT_LEFT_RIGHT
> int stand_alt_macro_right ; /* 2011-08-13 new */
> char unstandard_mac_alternate_right[ MAXSTRLEN ] ; /* 2011-08-13 new
> */
> #else
> char unstandard_mac_alternate[ MAXSTRLEN ] ; /* 2008-07-30 new */
> #endif
>
> But later at line 597 you have:
>
> error_code = read_unstandardized( sch_p ,
> _alpha_table ,
> alpha_row_num ,
> &sides_to_do ,
> &stand_alt_macro ,
> #ifdef WITH_ALT_LEFT_RIGHT
> &stand_alt_macro_right , /*
> 2011-08-13 */
> #endif
> house_address ,
> check_dir ,
> unstandard_mic ,
> unstandard_mac_left,
> ( is_arc? unstandard_mac_right :
> NULL ) ,
> unstandard_mac_alternate , /*
> 2008-07-30 */
> #ifdef WITH_ALT_LEFT_RIGHT
> unstandard_mac_alternate_right ,
> /* 2011-08-13 */
> #endif
> unstandard_occupancy ,
> official_buffers ,
> official_fields ,
> &off_cnt ,
> err_p ) ;
>
> So this leaves unstandard_mac_alternate undefined up top if
> WITH_ALT_LEFT_RIGHT is define and referenced here regardless. So it
> compiles only when WITH_ALT_LEFT_RIGHT is not defined.
>
> And this also has the untermined #ifdef WITH_ALT_LEFT_RIGHT that I
> mentioned in the prior email.
>
> Hope this helps,
> -Steve
>
>
> On 9/23/2011 11:39 AM, Stephen Woodbridge wrote:
>> Hi Walter,
>>
>> That seems to have fixed the first two issues. At 734 the problem is the
>> colon following the "switch () :" just remove it.
>>
>> svn diff alpharef.c
>> Index: alpharef.c
>> ===================================================================
>> --- alpharef.c (revision 256)
>> +++ alpharef.c (working copy)
>> @@ -731,7 +731,7 @@
>> case PROV :
>> #ifdef WITH_ALT_LEFT_RIGHT
>> /* 2011-08-17 : enable left_right for PROV */
>> - switch ( cmp ) :
>> + switch ( cmp )
>> {
>> case NO_COMPARISON :
>> break ;
>>
>> In pagc.h I commented out WITH_ALT_LEFT_RIGHT because I am build single
>> sided records:
>>
>> svn diff pagc.h
>> Index: pagc.h
>> ===================================================================
>> --- pagc.h (revision 256)
>> +++ pagc.h (working copy)
>> @@ -34,7 +34,7 @@
>> #include<math.h>
>> #include "ds.h"
>>
>> -#define WITH_ALT_LEFT_RIGHT
>> +//#define WITH_ALT_LEFT_RIGHT
>>
>> /* 2009-07-21 : keep track of version
>> 2010-02-01 : increase to 0.3.0
>>
>> I also show this random change in score.c:
>>
>> svn diff score.c
>> Index: score.c
>> ===================================================================
>> --- score.c (revision 256)
>> +++ score.c (working copy)
>> @@ -106,6 +106,7 @@
>>
>> #ifdef DEFER
>> DS_Flag_t defer_bit = 0 ;
>> + DS_Score_t absent_score = 0.00 ;
>> DS_Score_t absent_match = 0.00 ;
>> DS_Score_t absent_unmatch = 0.00 ;
>> DS_Score_t present_norm = 0.00 ;
>>
>> And finally I'm now hitting an issue compiling build.c it looks like
>> there is an issue with an unclosed #ifdef blobk near the bottom. But I
>> also suspect that there may be an issue with WITH_ALT_LEFT_RIGHT not
>> being defined.
>>
>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
>> -MP -MF .deps/libpagc_la-build.Tpo -c -o libpagc_la-build.lo `test -f
>> 'build.c' || echo './'`build.c
>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
>> -MP -MF .deps/libpagc_la-build.Tpo -c build.c -fPIC -DPIC -o
>> .libs/libpagc_la-build.o
>> build.c:1008:1: error: unterminated #ifdef
>> build.c:987:1: error: unterminated #else
>> build.c: In function âbuild_rowâ:
>> build.c:1006: error: expected declaration or statement at end of input
>> build.c:1006: error: expected declaration or statement at end of input
>> make: *** [libpagc_la-build.lo] Error 1
>>
>> Thanks,
>> -Steve
>>
>> On 9/23/2011 2:02 AM, whi...@de... wrote:
>>> Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if
>>> there
>>> is one.
>>>
>>>> Hi Walter,
>>>>
>>>> I'm having a problem building pagc.
>>>>
>>>> cd ~/work/pagc/pagc/branches/datastore/ds
>>>> ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
>>>> make clean
>>>> make
>>>> sudo make install
>>>> sudo ldconfig
>>>>
>>>> cd ../pagclib
>>>> ./configure --disable-threads
>>>> vi makefile
>>>> # append to DEFS=... -DTHREE_SOURCE_IDS=1
>>>> make clean
>>>> make
>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc
>>>> -DPACKAGE_NAME=\"pagc\"
>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>>> mkdir .libs
>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC
>>>> -o
>>>> .libs/libpagc_la-alpharef.o
>>>> alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ
>>>> alpharef.c: In function âread_unstandardizedâ:
>>>> alpharef.c:734: error: expected expression before â:â token
>>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>>
>>>> Fixed this by changing (notice missing '_' char:
>>>> char *dest primary_right
>>>> to:
>>>> char *dest_primary_right
>>>>
>>>> Now getting:
>>>>
>>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>>> /bin/sh ./libtool --tag=CC --mode=compile gcc
>>>> -DPACKAGE_NAME=\"pagc\"
>>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>>> mkdir .libs
>>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC
>>>> -o
>>>> .libs/libpagc_la-alpharef.o
>>>> alpharef.c: In function âleft_right_alt_macroâ:
>>>> alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in
>>>> this function)
>>>> alpharef.c:242: error: (Each undeclared identifier is reported only
>>>> once
>>>> alpharef.c:242: error: for each function it appears in.)
>>>> alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first
>>>> use
>>>> in this function)
>>>> alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in
>>>> this function)
>>>> alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared
>>>> (first use in this function)
>>>> alpharef.c: In function âread_unstandardizedâ:
>>>> alpharef.c:734: error: expected expression before â:â token
>>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>>
>>>> Can you check that everything you changed has been checked in.
>>>>
>>>> Thanks,
>>>> -Steve
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure contains
>>>> a
>>>> definitive record of customers, application performance, security
>>>> threats, fraudulent activity and more. Splunk takes this data and
>>>> makes
>>>> sense of it. Business sense. IT sense. Common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>> _______________________________________________
>>>> Pagc-devel mailing list
>>>> Pag...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance,
>>> security
>>> threats, fraudulent activity, and more. Splunk takes this data and
>>> makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy2
>>> _______________________________________________
>>> Pagc-devel mailing list
>>> Pag...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously
>> valuable.
>> Why? It contains a definitive record of application performance,
>> security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> _______________________________________________
>> Pagc-devel mailing list
>> Pag...@li...
>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Pagc-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>
|
|
From: Stephen W. <wo...@sw...> - 2011-09-23 18:10:53
|
Hi Walter,
build.c has some other problems also related to WITH_ALT_LEFT_RIGHT
being set or not.
at line 552 you have:
#ifdef WITH_ALT_LEFT_RIGHT
int stand_alt_macro_right ; /* 2011-08-13 new */
char unstandard_mac_alternate_right[ MAXSTRLEN ] ; /* 2011-08-13 new */
#else
char unstandard_mac_alternate[ MAXSTRLEN ] ; /* 2008-07-30 new */
#endif
But later at line 597 you have:
error_code = read_unstandardized( sch_p ,
_alpha_table ,
alpha_row_num ,
&sides_to_do ,
&stand_alt_macro ,
#ifdef WITH_ALT_LEFT_RIGHT
&stand_alt_macro_right , /*
2011-08-13 */
#endif
house_address ,
check_dir ,
unstandard_mic ,
unstandard_mac_left,
( is_arc? unstandard_mac_right :
NULL ) ,
unstandard_mac_alternate , /*
2008-07-30 */
#ifdef WITH_ALT_LEFT_RIGHT
unstandard_mac_alternate_right ,
/* 2011-08-13 */
#endif
unstandard_occupancy ,
official_buffers ,
official_fields ,
&off_cnt ,
err_p ) ;
So this leaves unstandard_mac_alternate undefined up top if
WITH_ALT_LEFT_RIGHT is define and referenced here regardless. So it
compiles only when WITH_ALT_LEFT_RIGHT is not defined.
And this also has the untermined #ifdef WITH_ALT_LEFT_RIGHT that I
mentioned in the prior email.
Hope this helps,
-Steve
On 9/23/2011 11:39 AM, Stephen Woodbridge wrote:
> Hi Walter,
>
> That seems to have fixed the first two issues. At 734 the problem is the
> colon following the "switch () :" just remove it.
>
> svn diff alpharef.c
> Index: alpharef.c
> ===================================================================
> --- alpharef.c (revision 256)
> +++ alpharef.c (working copy)
> @@ -731,7 +731,7 @@
> case PROV :
> #ifdef WITH_ALT_LEFT_RIGHT
> /* 2011-08-17 : enable left_right for PROV */
> - switch ( cmp ) :
> + switch ( cmp )
> {
> case NO_COMPARISON :
> break ;
>
> In pagc.h I commented out WITH_ALT_LEFT_RIGHT because I am build single
> sided records:
>
> svn diff pagc.h
> Index: pagc.h
> ===================================================================
> --- pagc.h (revision 256)
> +++ pagc.h (working copy)
> @@ -34,7 +34,7 @@
> #include<math.h>
> #include "ds.h"
>
> -#define WITH_ALT_LEFT_RIGHT
> +//#define WITH_ALT_LEFT_RIGHT
>
> /* 2009-07-21 : keep track of version
> 2010-02-01 : increase to 0.3.0
>
> I also show this random change in score.c:
>
> svn diff score.c
> Index: score.c
> ===================================================================
> --- score.c (revision 256)
> +++ score.c (working copy)
> @@ -106,6 +106,7 @@
>
> #ifdef DEFER
> DS_Flag_t defer_bit = 0 ;
> + DS_Score_t absent_score = 0.00 ;
> DS_Score_t absent_match = 0.00 ;
> DS_Score_t absent_unmatch = 0.00 ;
> DS_Score_t present_norm = 0.00 ;
>
> And finally I'm now hitting an issue compiling build.c it looks like
> there is an issue with an unclosed #ifdef blobk near the bottom. But I
> also suspect that there may be an issue with WITH_ALT_LEFT_RIGHT not
> being defined.
>
> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
> -MP -MF .deps/libpagc_la-build.Tpo -c -o libpagc_la-build.lo `test -f
> 'build.c' || echo './'`build.c
> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
> -MP -MF .deps/libpagc_la-build.Tpo -c build.c -fPIC -DPIC -o
> .libs/libpagc_la-build.o
> build.c:1008:1: error: unterminated #ifdef
> build.c:987:1: error: unterminated #else
> build.c: In function âbuild_rowâ:
> build.c:1006: error: expected declaration or statement at end of input
> build.c:1006: error: expected declaration or statement at end of input
> make: *** [libpagc_la-build.lo] Error 1
>
> Thanks,
> -Steve
>
> On 9/23/2011 2:02 AM, whi...@de... wrote:
>> Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if there
>> is one.
>>
>>> Hi Walter,
>>>
>>> I'm having a problem building pagc.
>>>
>>> cd ~/work/pagc/pagc/branches/datastore/ds
>>> ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
>>> make clean
>>> make
>>> sudo make install
>>> sudo ldconfig
>>>
>>> cd ../pagclib
>>> ./configure --disable-threads
>>> vi makefile
>>> # append to DEFS=... -DTHREE_SOURCE_IDS=1
>>> make clean
>>> make
>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>> mkdir .libs
>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
>>> .libs/libpagc_la-alpharef.o
>>> alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ
>>> alpharef.c: In function âread_unstandardizedâ:
>>> alpharef.c:734: error: expected expression before â:â token
>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>
>>> Fixed this by changing (notice missing '_' char:
>>> char *dest primary_right
>>> to:
>>> char *dest_primary_right
>>>
>>> Now getting:
>>>
>>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>>> `test -f 'alpharef.c' || echo './'`alpharef.c
>>> mkdir .libs
>>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
>>> .libs/libpagc_la-alpharef.o
>>> alpharef.c: In function âleft_right_alt_macroâ:
>>> alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in
>>> this function)
>>> alpharef.c:242: error: (Each undeclared identifier is reported only once
>>> alpharef.c:242: error: for each function it appears in.)
>>> alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first use
>>> in this function)
>>> alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in
>>> this function)
>>> alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared
>>> (first use in this function)
>>> alpharef.c: In function âread_unstandardizedâ:
>>> alpharef.c:734: error: expected expression before â:â token
>>> make: *** [libpagc_la-alpharef.lo] Error 1
>>>
>>> Can you check that everything you changed has been checked in.
>>>
>>> Thanks,
>>> -Steve
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Pagc-devel mailing list
>>> Pag...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> _______________________________________________
>> Pagc-devel mailing list
>> Pag...@li...
>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Pagc-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagc-devel
|
|
From: Stephen W. <wo...@sw...> - 2011-09-23 15:46:27
|
Hi Walter,
That seems to have fixed the first two issues. At 734 the problem is the
colon following the "switch () :" just remove it.
svn diff alpharef.c
Index: alpharef.c
===================================================================
--- alpharef.c (revision 256)
+++ alpharef.c (working copy)
@@ -731,7 +731,7 @@
case PROV :
#ifdef WITH_ALT_LEFT_RIGHT
/* 2011-08-17 : enable left_right for PROV */
- switch ( cmp ) :
+ switch ( cmp )
{
case NO_COMPARISON :
break ;
In pagc.h I commented out WITH_ALT_LEFT_RIGHT because I am build single
sided records:
svn diff pagc.h
Index: pagc.h
===================================================================
--- pagc.h (revision 256)
+++ pagc.h (working copy)
@@ -34,7 +34,7 @@
#include <math.h>
#include "ds.h"
-#define WITH_ALT_LEFT_RIGHT
+//#define WITH_ALT_LEFT_RIGHT
/* 2009-07-21 : keep track of version
2010-02-01 : increase to 0.3.0
I also show this random change in score.c:
svn diff score.c
Index: score.c
===================================================================
--- score.c (revision 256)
+++ score.c (working copy)
@@ -106,6 +106,7 @@
#ifdef DEFER
DS_Flag_t defer_bit = 0 ;
+ DS_Score_t absent_score = 0.00 ;
DS_Score_t absent_match = 0.00 ;
DS_Score_t absent_unmatch = 0.00 ;
DS_Score_t present_norm = 0.00 ;
And finally I'm now hitting an issue compiling build.c it looks like
there is an issue with an unclosed #ifdef blobk near the bottom. But I
also suspect that there may be an issue with WITH_ALT_LEFT_RIGHT not
being defined.
woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
/bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
-DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
-DPACKAGE_STRING=\"pagc\ 0.4.0\"
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
-MP -MF .deps/libpagc_la-build.Tpo -c -o libpagc_la-build.lo `test -f
'build.c' || echo './'`build.c
gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
-DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-build.lo -MD
-MP -MF .deps/libpagc_la-build.Tpo -c build.c -fPIC -DPIC -o
.libs/libpagc_la-build.o
build.c:1008:1: error: unterminated #ifdef
build.c:987:1: error: unterminated #else
build.c: In function âbuild_rowâ:
build.c:1006: error: expected declaration or statement at end of input
build.c:1006: error: expected declaration or statement at end of input
make: *** [libpagc_la-build.lo] Error 1
Thanks,
-Steve
On 9/23/2011 2:02 AM, whi...@de... wrote:
> Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if there
> is one.
>
>> Hi Walter,
>>
>> I'm having a problem building pagc.
>>
>> cd ~/work/pagc/pagc/branches/datastore/ds
>> ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
>> make clean
>> make
>> sudo make install
>> sudo ldconfig
>>
>> cd ../pagclib
>> ./configure --disable-threads
>> vi makefile
>> # append to DEFS=... -DTHREE_SOURCE_IDS=1
>> make clean
>> make
>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>> `test -f 'alpharef.c' || echo './'`alpharef.c
>> mkdir .libs
>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
>> .libs/libpagc_la-alpharef.o
>> alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ
>> alpharef.c: In function âread_unstandardizedâ:
>> alpharef.c:734: error: expected expression before â:â token
>> make: *** [libpagc_la-alpharef.lo] Error 1
>>
>> Fixed this by changing (notice missing '_' char:
>> char *dest primary_right
>> to:
>> char *dest_primary_right
>>
>> Now getting:
>>
>> woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
>> /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
>> -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
>> -DPACKAGE_STRING=\"pagc\ 0.4.0\"
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
>> `test -f 'alpharef.c' || echo './'`alpharef.c
>> mkdir .libs
>> gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
>> -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
>> -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
>> -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
>> -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
>> -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
>> -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
>> .libs/libpagc_la-alpharef.o
>> alpharef.c: In function âleft_right_alt_macroâ:
>> alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in
>> this function)
>> alpharef.c:242: error: (Each undeclared identifier is reported only once
>> alpharef.c:242: error: for each function it appears in.)
>> alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first use
>> in this function)
>> alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in
>> this function)
>> alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared
>> (first use in this function)
>> alpharef.c: In function âread_unstandardizedâ:
>> alpharef.c:734: error: expected expression before â:â token
>> make: *** [libpagc_la-alpharef.lo] Error 1
>>
>> Can you check that everything you changed has been checked in.
>>
>> Thanks,
>> -Steve
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Pagc-devel mailing list
>> Pag...@li...
>> https://lists.sourceforge.net/lists/listinfo/pagc-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Pagc-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagc-devel
|
|
From: <whi...@de...> - 2011-09-23 06:28:55
|
Hi Steve : I fixed 242 and 262. I'm not grokking the one at 734, if there is one. > Hi Walter, > > I'm having a problem building pagc. > > cd ~/work/pagc/pagc/branches/datastore/ds > ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f > make clean > make > sudo make install > sudo ldconfig > > cd ../pagclib > ./configure --disable-threads > vi makefile > # append to DEFS=... -DTHREE_SOURCE_IDS=1 > make clean > make > woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make > /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\" > -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\" > -DPACKAGE_STRING=\"pagc\ 0.4.0\" > -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" > -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 > -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER > -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\"" > -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo > -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo > `test -f 'alpharef.c' || echo './'`alpharef.c > mkdir .libs > gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\" > -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\"" > -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" > -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 > -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER > -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\" > -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo > -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o > .libs/libpagc_la-alpharef.o > alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ > alpharef.c: In function âread_unstandardizedâ: > alpharef.c:734: error: expected expression before â:â token > make: *** [libpagc_la-alpharef.lo] Error 1 > > Fixed this by changing (notice missing '_' char: > char *dest primary_right > to: > char *dest_primary_right > > Now getting: > > woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make > /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\" > -DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\" > -DPACKAGE_STRING=\"pagc\ 0.4.0\" > -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" > -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 > -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 > -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\"" > -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo > -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo > `test -f 'alpharef.c' || echo './'`alpharef.c > mkdir .libs > gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\" > -DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\"" > -DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\" > -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 > -DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 > -DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\" > -I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo > -MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o > .libs/libpagc_la-alpharef.o > alpharef.c: In function âleft_right_alt_macroâ: > alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in > this function) > alpharef.c:242: error: (Each undeclared identifier is reported only once > alpharef.c:242: error: for each function it appears in.) > alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first use > in this function) > alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in > this function) > alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared > (first use in this function) > alpharef.c: In function âread_unstandardizedâ: > alpharef.c:734: error: expected expression before â:â token > make: *** [libpagc_la-alpharef.lo] Error 1 > > Can you check that everything you changed has been checked in. > > Thanks, > -Steve > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > |
|
From: Stephen W. <wo...@sw...> - 2011-09-22 22:24:33
|
Hi Walter,
I'm having a problem building pagc.
cd ~/work/pagc/pagc/branches/datastore/ds
./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
make clean
make
sudo make install
sudo ldconfig
cd ../pagclib
./configure --disable-threads
vi makefile
# append to DEFS=... -DTHREE_SOURCE_IDS=1
make clean
make
woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
/bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
-DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
-DPACKAGE_STRING=\"pagc\ 0.4.0\"
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
-MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
`test -f 'alpharef.c' || echo './'`alpharef.c
mkdir .libs
gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
-DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DDEFER
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
-MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
.libs/libpagc_la-alpharef.o
alpharef.c:240: error: expected â;â, â,â or â)â before âprimary_rightâ
alpharef.c: In function âread_unstandardizedâ:
alpharef.c:734: error: expected expression before â:â token
make: *** [libpagc_la-alpharef.lo] Error 1
Fixed this by changing (notice missing '_' char:
char *dest primary_right
to:
char *dest_primary_right
Now getting:
woodbri@mappy:~/work/pagc/pagc/branches/datastore/pagclib$ make
/bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"pagc\"
-DPACKAGE_TARNAME=\"pagc\" -DPACKAGE_VERSION=\"0.4.0\"
-DPACKAGE_STRING=\"pagc\ 0.4.0\"
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR="\"/usr/local/share/pagc\""
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
-MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c -o libpagc_la-alpharef.lo
`test -f 'alpharef.c' || echo './'`alpharef.c
mkdir .libs
gcc -DPACKAGE_NAME=\"pagc\" -DPACKAGE_TARNAME=\"pagc\"
-DPACKAGE_VERSION=\"0.4.0\" "-DPACKAGE_STRING=\"pagc 0.4.0\""
-DPACKAGE_BUGREPORT=\"whi...@de...\" -DPACKAGE=\"pagc\"
-DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1
-DSTDC_HEADERS=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1
-DTHREE_SOURCE_IDS=1 -I. -DSTZ_DIR=\"/usr/local/share/pagc\"
-I/usr/local/include -DPAGC_EXPORTS -g -O2 -MT libpagc_la-alpharef.lo
-MD -MP -MF .deps/libpagc_la-alpharef.Tpo -c alpharef.c -fPIC -DPIC -o
.libs/libpagc_la-alpharef.o
alpharef.c: In function âleft_right_alt_macroâ:
alpharef.c:242: error: âunstandard_mac_leftâ undeclared (first use in
this function)
alpharef.c:242: error: (Each undeclared identifier is reported only once
alpharef.c:242: error: for each function it appears in.)
alpharef.c:242: error: âunstandard_mac_alternateâ undeclared (first use
in this function)
alpharef.c:262: error: âunstandard_mac_rightâ undeclared (first use in
this function)
alpharef.c:262: error: âunstandard_mac_alternate_rightâ undeclared
(first use in this function)
alpharef.c: In function âread_unstandardizedâ:
alpharef.c:734: error: expected expression before â:â token
make: *** [libpagc_la-alpharef.lo] Error 1
Can you check that everything you changed has been checked in.
Thanks,
-Steve
|
|
From: Dan P. <dan...@sa...> - 2011-05-11 15:05:23
|
Hi Walter and Steve, I'll look through the documentation and see what seems unclear to me. In addition, I'll also ready an up to date web site. Dan On 05/11/2011 12:20 AM, whi...@de... wrote: > Hi Steve : your list looks like it should cover it. I've tried to update > version numbers and copyright dates as I went on the libraries, and > likewise with the documentation. I'm sure the documentation can be > improved, so if anyone has suggestions there I can follow up. I can do the > windows package, although I will need to do some rewriting of my build > scripts. I haven't been doing much with the change log since the SVN > itself seems to make it redundant. Thanks,<= walter => > >> Dan, Walter, >> >> I think things are reasonable stable in branches/datastore. I just >> checked in my fix for the parseaddress. I haven't built a regression >> test yet. >> >> Are we ready to try can cut a release? >> What still needs to get done? Beyond my list below? >> >> I'm willing to help out on this. Walter do you have time to work on >> cutting a release now or would waiting be better for you? >> >> Thoughts, >> -Steve >> >> On 5/8/2011 10:33 PM, Dan Putler wrote: >>> Hi Steve, >>> >>> Dave Sampson managed the last release, but my sense is that a number of >>> things are keeping him out of FOSS software development at this point in >>> time. As a result, the steps you indicated are likely to become the >>> basis of the release process going forward. >>> >>> Dan >>> >>> On 05/08/2011 04:55 PM, Stephen Woodbridge wrote: >>>> On 5/8/2011 1:53 PM, Dan Putler wrote: >>>>> Hi all, >>>>> >>>>> Given Walter Sinclair's work on the SQLite datastore and Stephen >>>>> Woodbridge's on a one line address parser, this seem like a good time >>>>> to >>>>> formally start planning a 0.4.0 release of PAGC. Steve and Walter, any >>>>> sense of the time line needed to do this? >>>> Dan, >>>> >>>> The last change to the single line parser, broke some cases, but I >>>> should have a little time this week to look into that. I also want to >>>> make up some test cases to regression test against when changes are >>>> made. >>>> >>>> Beyond that, I'm not sure what the release process is. Currently all >>>> the >>>> changes are in branches/datastore/ So I guess we need to do something >>>> like the following: >>>> >>>> 1. merge branches/datastore into trunk >>>> 2. update version numbers, copyright dates, etc >>>> 3. update the change log >>>> 4. update the documentation as needed >>>> 5. create release packages for Linux and Windows >>>> 6. post the release candidate to the website and send up announcements >>>> 7. copy trunk to branches/RC-0.4.0 or branches/REL-0.4.0 >>>> 8. fix any release critical bugs >>>> 9. while not ready for release; goto 2. >>>> >>>> Or do you guys already have a release process? >>>> >>>> -Steve >>>> >>>> ------------------------------------------------------------------------------ >>>> WhatsUp Gold - Download Free Network Management Software >>>> The most intuitive, comprehensive, and cost-effective network >>>> management toolset available today. Delivers lowest initial >>>> acquisition cost and overall TCO of any competing solution. >>>> http://p.sf.net/sfu/whatsupgold-sd >>>> _______________________________________________ >>>> Pagc-devel mailing list >>>> Pag...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Achieve unprecedented app performance and reliability >> What every C/C++ and Fortran developer should know. >> Learn how Intel has extended the reach of its next-generation tools >> to help boost performance applications - inlcuding clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: <whi...@de...> - 2011-05-11 07:56:41
|
Hi Steve : your list looks like it should cover it. I've tried to update version numbers and copyright dates as I went on the libraries, and likewise with the documentation. I'm sure the documentation can be improved, so if anyone has suggestions there I can follow up. I can do the windows package, although I will need to do some rewriting of my build scripts. I haven't been doing much with the change log since the SVN itself seems to make it redundant. Thanks, <= walter => > Dan, Walter, > > I think things are reasonable stable in branches/datastore. I just > checked in my fix for the parseaddress. I haven't built a regression > test yet. > > Are we ready to try can cut a release? > What still needs to get done? Beyond my list below? > > I'm willing to help out on this. Walter do you have time to work on > cutting a release now or would waiting be better for you? > > Thoughts, > -Steve > > On 5/8/2011 10:33 PM, Dan Putler wrote: >> Hi Steve, >> >> Dave Sampson managed the last release, but my sense is that a number of >> things are keeping him out of FOSS software development at this point in >> time. As a result, the steps you indicated are likely to become the >> basis of the release process going forward. >> >> Dan >> >> On 05/08/2011 04:55 PM, Stephen Woodbridge wrote: >>> On 5/8/2011 1:53 PM, Dan Putler wrote: >>>> Hi all, >>>> >>>> Given Walter Sinclair's work on the SQLite datastore and Stephen >>>> Woodbridge's on a one line address parser, this seem like a good time >>>> to >>>> formally start planning a 0.4.0 release of PAGC. Steve and Walter, any >>>> sense of the time line needed to do this? >>> Dan, >>> >>> The last change to the single line parser, broke some cases, but I >>> should have a little time this week to look into that. I also want to >>> make up some test cases to regression test against when changes are >>> made. >>> >>> Beyond that, I'm not sure what the release process is. Currently all >>> the >>> changes are in branches/datastore/ So I guess we need to do something >>> like the following: >>> >>> 1. merge branches/datastore into trunk >>> 2. update version numbers, copyright dates, etc >>> 3. update the change log >>> 4. update the documentation as needed >>> 5. create release packages for Linux and Windows >>> 6. post the release candidate to the website and send up announcements >>> 7. copy trunk to branches/RC-0.4.0 or branches/REL-0.4.0 >>> 8. fix any release critical bugs >>> 9. while not ready for release; goto 2. >>> >>> Or do you guys already have a release process? >>> >>> -Steve >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > |
|
From: Stephen W. <wo...@sw...> - 2011-05-11 04:17:31
|
Dan, Walter, I think things are reasonable stable in branches/datastore. I just checked in my fix for the parseaddress. I haven't built a regression test yet. Are we ready to try can cut a release? What still needs to get done? Beyond my list below? I'm willing to help out on this. Walter do you have time to work on cutting a release now or would waiting be better for you? Thoughts, -Steve On 5/8/2011 10:33 PM, Dan Putler wrote: > Hi Steve, > > Dave Sampson managed the last release, but my sense is that a number of > things are keeping him out of FOSS software development at this point in > time. As a result, the steps you indicated are likely to become the > basis of the release process going forward. > > Dan > > On 05/08/2011 04:55 PM, Stephen Woodbridge wrote: >> On 5/8/2011 1:53 PM, Dan Putler wrote: >>> Hi all, >>> >>> Given Walter Sinclair's work on the SQLite datastore and Stephen >>> Woodbridge's on a one line address parser, this seem like a good time to >>> formally start planning a 0.4.0 release of PAGC. Steve and Walter, any >>> sense of the time line needed to do this? >> Dan, >> >> The last change to the single line parser, broke some cases, but I >> should have a little time this week to look into that. I also want to >> make up some test cases to regression test against when changes are made. >> >> Beyond that, I'm not sure what the release process is. Currently all the >> changes are in branches/datastore/ So I guess we need to do something >> like the following: >> >> 1. merge branches/datastore into trunk >> 2. update version numbers, copyright dates, etc >> 3. update the change log >> 4. update the documentation as needed >> 5. create release packages for Linux and Windows >> 6. post the release candidate to the website and send up announcements >> 7. copy trunk to branches/RC-0.4.0 or branches/REL-0.4.0 >> 8. fix any release critical bugs >> 9. while not ready for release; goto 2. >> >> Or do you guys already have a release process? >> >> -Steve >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Dan P. <dan...@sa...> - 2011-05-09 02:33:25
|
Hi Steve, Dave Sampson managed the last release, but my sense is that a number of things are keeping him out of FOSS software development at this point in time. As a result, the steps you indicated are likely to become the basis of the release process going forward. Dan On 05/08/2011 04:55 PM, Stephen Woodbridge wrote: > On 5/8/2011 1:53 PM, Dan Putler wrote: >> Hi all, >> >> Given Walter Sinclair's work on the SQLite datastore and Stephen >> Woodbridge's on a one line address parser, this seem like a good time to >> formally start planning a 0.4.0 release of PAGC. Steve and Walter, any >> sense of the time line needed to do this? > Dan, > > The last change to the single line parser, broke some cases, but I > should have a little time this week to look into that. I also want to > make up some test cases to regression test against when changes are made. > > Beyond that, I'm not sure what the release process is. Currently all the > changes are in branches/datastore/ So I guess we need to do something > like the following: > > 1. merge branches/datastore into trunk > 2. update version numbers, copyright dates, etc > 3. update the change log > 4. update the documentation as needed > 5. create release packages for Linux and Windows > 6. post the release candidate to the website and send up announcements > 7. copy trunk to branches/RC-0.4.0 or branches/REL-0.4.0 > 8. fix any release critical bugs > 9. while not ready for release; goto 2. > > Or do you guys already have a release process? > > -Steve > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Stephen W. <wo...@sw...> - 2011-05-09 00:38:06
|
On 5/8/2011 1:53 PM, Dan Putler wrote: > Hi all, > > Given Walter Sinclair's work on the SQLite datastore and Stephen > Woodbridge's on a one line address parser, this seem like a good time to > formally start planning a 0.4.0 release of PAGC. Steve and Walter, any > sense of the time line needed to do this? Dan, The last change to the single line parser, broke some cases, but I should have a little time this week to look into that. I also want to make up some test cases to regression test against when changes are made. Beyond that, I'm not sure what the release process is. Currently all the changes are in branches/datastore/ So I guess we need to do something like the following: 1. merge branches/datastore into trunk 2. update version numbers, copyright dates, etc 3. update the change log 4. update the documentation as needed 5. create release packages for Linux and Windows 6. post the release candidate to the website and send up announcements 7. copy trunk to branches/RC-0.4.0 or branches/REL-0.4.0 8. fix any release critical bugs 9. while not ready for release; goto 2. Or do you guys already have a release process? -Steve |
|
From: Dan P. <dan...@sa...> - 2011-05-08 17:53:15
|
Hi all, Given Walter Sinclair's work on the SQLite datastore and Stephen Woodbridge's on a one line address parser, this seem like a good time to formally start planning a 0.4.0 release of PAGC. Steve and Walter, any sense of the time line needed to do this? Dan |
|
From: Dan P. <dan...@sa...> - 2011-05-03 18:07:18
|
Hi all, Walter Sinclair, Stephen Woodbridge, and I have submitted an abstract for a presentation showcasing recent developments in PAGC at FOSS4G. If you have an interest in seeing this presentation, expressing your interest in it at the FOSS4G community review site would be greatly appreciated. The URL for the site is: http://community-review.foss4g.org/ The presentation abstract is given below: Dan ------------ The Postal Address Geocoder (or PAGC) is an open source library and web service framework for geocoding locations based on either postal addresses, street intersections, or landmarks. The system offers a number of features that differentiate it from other open source geocoding software solutions: * PAGC is written in ANSI C it runs on all major operating systems, and can be easily ported to nearly all operating systems * PAGC is pre-configured to use data from several different providers (TIGER/Line, Statistics Canada's Road Network File, and others), and through the creation of a simple configuration file, it can easily work with data from a large number of other providers * PAGC makes use of an advanced three-method probabilistic matching algorithm to provide the greatest possible match rate for street addresses * PAGC can be used with multiple input data sources (shapefiles, SQLite database tables, and, soon, PostgreSQL/PostGIS database tables), and data stores (BerkeleyDB, SQLite, with PostgreSQL in the works) * PAGC has the ability to provide an ID number in addition to geographic coordinates, which can greatly simplify database operations for location-based applications * PAGC allows the user to edit road segment address ranges on the fly, enabling the user to overcome suppressed or altered address ranges frequently encountered in government originated road network layers In this talk we will briefly discuss the history of the PAGC project, but really focus on the product's features and recent developments (particularly as it relates to advances in data source and data store options) and the PAGC feature set road map (including better internationalization, a reverse geocoder, and a number of others) . In addition, we will present a demonstration of a location-based service that is made possible by using PAGC as a core underlying technology. |
|
From: Dan P. <dan...@sa...> - 2011-03-09 05:51:34
|
Hi Steve, Quick follow-up. Quiting from Firefox and restarting makes things work. I still have the la Mesa vs. La Mesa problem. Dan On 03/08/2011 08:12 PM, Stephen Woodbridge wrote: > On 3/8/2011 9:28 PM, Dan Putler wrote: >> Hi Steve, >> >> This is great. I've done some testing, and run into one address that >> geocoded using geocoder.us, but not the PAGC service. I'll look at the >> underlying 2010 Tiger data and see if that could be the issue (its >> possible geocoder.us is using an earlier version). The online service > Dan, > > You can also try that using my old geocoder that is loaded with Tiger > 2006 data: > > http://imaptools.com/cgi-bin/geo?DEBUG=1 > > Select one of these options to avoid getting redirected to a map: > Display SERVER output: > Display XML output: > > What address were you trying. I think building a list of addresses is a > great idea. I have a pretty large collection of various address lists. > > I have one that is about 75K addresses that I used to use to track > statistics when I was evaluating geocoders. Basically I geocoded the > list and made that an expected response list, then on successive runs I > compared the results to the standard results and any response that > exceeded some limit distance was considered suspect and needed to be > looked at and obviously any new successes or new failures. It was more > about the relative results than trying to say the absolute results were > good or bad. This was also very handy for evaluating changes to the > geocoder and detecting improvements or regressions. > > My experience with Tiger is that the old Tiger2006 was in many ways a > very mature product in spite of being somewhat dated. The new Tiger > shapfiles have the advantage of being better from the point of view of > road segment completeness because of the heads up satellite imagery > digitizing of new streets and water areas. But it has the down side in > the fact that many of the new segments do not have street names and > address ranges on them. It will take time for the new data to improve. > I'm hoping that we will continue to see improvements as local > stakeholders and the Census update this data post 2010 Census. > > Thanks, > -Steve > > >> does a lot in terms of improving the ability to test potential geocoding >> problems. Coming up with a test suite of addresses might be really >> helpful. I've started a function that does it in R, but I think I'll >> port what I have to Python. >> >> Dan >> >> On 03/08/2011 12:13 PM, Stephen Woodbridge wrote: >>> Hi all, >>> >>> As promised: >>> >>> http://imaptools.com:8080/geocode/ >>> >>> OK, so as I noted before there is still a bug in PAGC that Walter and I >>> need to find a fix related to including the Postal Code. It causes a >>> high geocode failure rate, but PAGC finds things fine without the Postal >>> Code so Just leave it out for now. Or try with it and remove it if it fails. >>> >>> Here are some stats: >>> >>> It took about 5-6 days to do the Tiger join and load it into PAGC. I >>> think part of this time is because I have a Postgresql autovacuum >>> process running which was creating a lot of disk contention. Which, BTW, >>> are still running: >>> >>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> 21975 postgres 20 0 125m 4320 692 S 1 0.1 132:37.13 postgres >>> 21976 postgres 20 0 72952 3556 464 S 1 0.1 766:16.90 postgres >>> >>> and impacts on the response of anything try to do disk I/O, including >>> the URL above. >>> >>> woodbri@mappy:~$ ls /u/data/tgr2010-geo-v2/streets/ -lh >>> total 28G >>> -rw-r--r-- 1 woodbri woodbri 255M 2011-03-08 03:20 build_log.err >>> -rw-r--r-- 1 woodbri woodbri 286K 2011-03-08 03:20 last_append_log.err >>> -rw-r--r-- 1 woodbri woodbri 307M 2011-03-08 03:20 Streets.ix3 >>> -rw-r--r-- 1 woodbri woodbri 27G 2011-03-08 03:20 Streets.pagc >>> >>> So the SQLite database is 27 GB and the Streets.ix3 is 307 MB >>> >>> woodbri@mappy:/u/data/tgr2010-geo-v2/streets$ sqlite3 Streets.pagc >>> SQLite version 3.5.9 >>> Enter ".help" for instructions >>> sqlite> .schema >>> CREATE TABLE ix0 ( pagc_key text, pagc_data integer ); >>> CREATE TABLE ix1 ( pagc_key text, pagc_data integer ); >>> CREATE TABLE ix2 ( pagc_key text, pagc_data integer ); >>> CREATE TABLE ix5 ( pagc_key integer, pagc_data blob ); >>> CREATE TABLE pagc_cfg ( pagc_key text, pagc_data blob ); >>> CREATE TABLE pgx ( pagc_key integer, pagc_data text ); >>> CREATE INDEX 'x_ix0' ON 'ix0' ( pagc_key ); >>> CREATE INDEX 'x_ix1' ON 'ix1' ( pagc_key ); >>> CREATE INDEX 'x_ix2' ON 'ix2' ( pagc_key ); >>> CREATE INDEX 'x_ix5' ON 'ix5' ( pagc_key ); >>> CREATE INDEX 'x_pgx' ON 'pgx' ( pagc_key ); >>> sqlite> select count(*) from ix0; >>> 100792158 >>> sqlite> select count(*) from pgx; >>> 50583769 >>> >>> Yikes! a whole lot of something in those tables! >>> >>> -Steve >>> >>> ------------------------------------------------------------------------------ >>> What You Don't Know About Data Connectivity CAN Hurt You >>> This paper provides an overview of data connectivity, details >>> its effect on application quality, and explores various alternative >>> solutions. http://p.sf.net/sfu/progress-d2d >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Stephen W. <wo...@sw...> - 2011-03-09 04:14:44
|
On 3/8/2011 9:28 PM, Dan Putler wrote: > Hi Steve, > > This is great. I've done some testing, and run into one address that > geocoded using geocoder.us, but not the PAGC service. I'll look at the > underlying 2010 Tiger data and see if that could be the issue (its > possible geocoder.us is using an earlier version). The online service Dan, You can also try that using my old geocoder that is loaded with Tiger 2006 data: http://imaptools.com/cgi-bin/geo?DEBUG=1 Select one of these options to avoid getting redirected to a map: Display SERVER output: Display XML output: What address were you trying. I think building a list of addresses is a great idea. I have a pretty large collection of various address lists. I have one that is about 75K addresses that I used to use to track statistics when I was evaluating geocoders. Basically I geocoded the list and made that an expected response list, then on successive runs I compared the results to the standard results and any response that exceeded some limit distance was considered suspect and needed to be looked at and obviously any new successes or new failures. It was more about the relative results than trying to say the absolute results were good or bad. This was also very handy for evaluating changes to the geocoder and detecting improvements or regressions. My experience with Tiger is that the old Tiger2006 was in many ways a very mature product in spite of being somewhat dated. The new Tiger shapfiles have the advantage of being better from the point of view of road segment completeness because of the heads up satellite imagery digitizing of new streets and water areas. But it has the down side in the fact that many of the new segments do not have street names and address ranges on them. It will take time for the new data to improve. I'm hoping that we will continue to see improvements as local stakeholders and the Census update this data post 2010 Census. Thanks, -Steve > does a lot in terms of improving the ability to test potential geocoding > problems. Coming up with a test suite of addresses might be really > helpful. I've started a function that does it in R, but I think I'll > port what I have to Python. > > Dan > > On 03/08/2011 12:13 PM, Stephen Woodbridge wrote: >> Hi all, >> >> As promised: >> >> http://imaptools.com:8080/geocode/ >> >> OK, so as I noted before there is still a bug in PAGC that Walter and I >> need to find a fix related to including the Postal Code. It causes a >> high geocode failure rate, but PAGC finds things fine without the Postal >> Code so Just leave it out for now. Or try with it and remove it if it fails. >> >> Here are some stats: >> >> It took about 5-6 days to do the Tiger join and load it into PAGC. I >> think part of this time is because I have a Postgresql autovacuum >> process running which was creating a lot of disk contention. Which, BTW, >> are still running: >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 21975 postgres 20 0 125m 4320 692 S 1 0.1 132:37.13 postgres >> 21976 postgres 20 0 72952 3556 464 S 1 0.1 766:16.90 postgres >> >> and impacts on the response of anything try to do disk I/O, including >> the URL above. >> >> woodbri@mappy:~$ ls /u/data/tgr2010-geo-v2/streets/ -lh >> total 28G >> -rw-r--r-- 1 woodbri woodbri 255M 2011-03-08 03:20 build_log.err >> -rw-r--r-- 1 woodbri woodbri 286K 2011-03-08 03:20 last_append_log.err >> -rw-r--r-- 1 woodbri woodbri 307M 2011-03-08 03:20 Streets.ix3 >> -rw-r--r-- 1 woodbri woodbri 27G 2011-03-08 03:20 Streets.pagc >> >> So the SQLite database is 27 GB and the Streets.ix3 is 307 MB >> >> woodbri@mappy:/u/data/tgr2010-geo-v2/streets$ sqlite3 Streets.pagc >> SQLite version 3.5.9 >> Enter ".help" for instructions >> sqlite> .schema >> CREATE TABLE ix0 ( pagc_key text, pagc_data integer ); >> CREATE TABLE ix1 ( pagc_key text, pagc_data integer ); >> CREATE TABLE ix2 ( pagc_key text, pagc_data integer ); >> CREATE TABLE ix5 ( pagc_key integer, pagc_data blob ); >> CREATE TABLE pagc_cfg ( pagc_key text, pagc_data blob ); >> CREATE TABLE pgx ( pagc_key integer, pagc_data text ); >> CREATE INDEX 'x_ix0' ON 'ix0' ( pagc_key ); >> CREATE INDEX 'x_ix1' ON 'ix1' ( pagc_key ); >> CREATE INDEX 'x_ix2' ON 'ix2' ( pagc_key ); >> CREATE INDEX 'x_ix5' ON 'ix5' ( pagc_key ); >> CREATE INDEX 'x_pgx' ON 'pgx' ( pagc_key ); >> sqlite> select count(*) from ix0; >> 100792158 >> sqlite> select count(*) from pgx; >> 50583769 >> >> Yikes! a whole lot of something in those tables! >> >> -Steve >> >> ------------------------------------------------------------------------------ >> What You Don't Know About Data Connectivity CAN Hurt You >> This paper provides an overview of data connectivity, details >> its effect on application quality, and explores various alternative >> solutions. http://p.sf.net/sfu/progress-d2d >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Dan P. <dan...@sa...> - 2011-03-09 02:41:14
|
Hi Steve, This is great. I've done some testing, and run into one address that geocoded using geocoder.us, but not the PAGC service. I'll look at the underlying 2010 Tiger data and see if that could be the issue (its possible geocoder.us is using an earlier version). The online service does a lot in terms of improving the ability to test potential geocoding problems. Coming up with a test suite of addresses might be really helpful. I've started a function that does it in R, but I think I'll port what I have to Python. Dan On 03/08/2011 12:13 PM, Stephen Woodbridge wrote: > Hi all, > > As promised: > > http://imaptools.com:8080/geocode/ > > OK, so as I noted before there is still a bug in PAGC that Walter and I > need to find a fix related to including the Postal Code. It causes a > high geocode failure rate, but PAGC finds things fine without the Postal > Code so Just leave it out for now. Or try with it and remove it if it fails. > > Here are some stats: > > It took about 5-6 days to do the Tiger join and load it into PAGC. I > think part of this time is because I have a Postgresql autovacuum > process running which was creating a lot of disk contention. Which, BTW, > are still running: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 21975 postgres 20 0 125m 4320 692 S 1 0.1 132:37.13 postgres > 21976 postgres 20 0 72952 3556 464 S 1 0.1 766:16.90 postgres > > and impacts on the response of anything try to do disk I/O, including > the URL above. > > woodbri@mappy:~$ ls /u/data/tgr2010-geo-v2/streets/ -lh > total 28G > -rw-r--r-- 1 woodbri woodbri 255M 2011-03-08 03:20 build_log.err > -rw-r--r-- 1 woodbri woodbri 286K 2011-03-08 03:20 last_append_log.err > -rw-r--r-- 1 woodbri woodbri 307M 2011-03-08 03:20 Streets.ix3 > -rw-r--r-- 1 woodbri woodbri 27G 2011-03-08 03:20 Streets.pagc > > So the SQLite database is 27 GB and the Streets.ix3 is 307 MB > > woodbri@mappy:/u/data/tgr2010-geo-v2/streets$ sqlite3 Streets.pagc > SQLite version 3.5.9 > Enter ".help" for instructions > sqlite> .schema > CREATE TABLE ix0 ( pagc_key text, pagc_data integer ); > CREATE TABLE ix1 ( pagc_key text, pagc_data integer ); > CREATE TABLE ix2 ( pagc_key text, pagc_data integer ); > CREATE TABLE ix5 ( pagc_key integer, pagc_data blob ); > CREATE TABLE pagc_cfg ( pagc_key text, pagc_data blob ); > CREATE TABLE pgx ( pagc_key integer, pagc_data text ); > CREATE INDEX 'x_ix0' ON 'ix0' ( pagc_key ); > CREATE INDEX 'x_ix1' ON 'ix1' ( pagc_key ); > CREATE INDEX 'x_ix2' ON 'ix2' ( pagc_key ); > CREATE INDEX 'x_ix5' ON 'ix5' ( pagc_key ); > CREATE INDEX 'x_pgx' ON 'pgx' ( pagc_key ); > sqlite> select count(*) from ix0; > 100792158 > sqlite> select count(*) from pgx; > 50583769 > > Yikes! a whole lot of something in those tables! > > -Steve > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Stephen W. <wo...@sw...> - 2011-03-08 20:16:01
|
Hi all, As promised: http://imaptools.com:8080/geocode/ OK, so as I noted before there is still a bug in PAGC that Walter and I need to find a fix related to including the Postal Code. It causes a high geocode failure rate, but PAGC finds things fine without the Postal Code so Just leave it out for now. Or try with it and remove it if it fails. Here are some stats: It took about 5-6 days to do the Tiger join and load it into PAGC. I think part of this time is because I have a Postgresql autovacuum process running which was creating a lot of disk contention. Which, BTW, are still running: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21975 postgres 20 0 125m 4320 692 S 1 0.1 132:37.13 postgres 21976 postgres 20 0 72952 3556 464 S 1 0.1 766:16.90 postgres and impacts on the response of anything try to do disk I/O, including the URL above. woodbri@mappy:~$ ls /u/data/tgr2010-geo-v2/streets/ -lh total 28G -rw-r--r-- 1 woodbri woodbri 255M 2011-03-08 03:20 build_log.err -rw-r--r-- 1 woodbri woodbri 286K 2011-03-08 03:20 last_append_log.err -rw-r--r-- 1 woodbri woodbri 307M 2011-03-08 03:20 Streets.ix3 -rw-r--r-- 1 woodbri woodbri 27G 2011-03-08 03:20 Streets.pagc So the SQLite database is 27 GB and the Streets.ix3 is 307 MB woodbri@mappy:/u/data/tgr2010-geo-v2/streets$ sqlite3 Streets.pagc SQLite version 3.5.9 Enter ".help" for instructions sqlite> .schema CREATE TABLE ix0 ( pagc_key text, pagc_data integer ); CREATE TABLE ix1 ( pagc_key text, pagc_data integer ); CREATE TABLE ix2 ( pagc_key text, pagc_data integer ); CREATE TABLE ix5 ( pagc_key integer, pagc_data blob ); CREATE TABLE pagc_cfg ( pagc_key text, pagc_data blob ); CREATE TABLE pgx ( pagc_key integer, pagc_data text ); CREATE INDEX 'x_ix0' ON 'ix0' ( pagc_key ); CREATE INDEX 'x_ix1' ON 'ix1' ( pagc_key ); CREATE INDEX 'x_ix2' ON 'ix2' ( pagc_key ); CREATE INDEX 'x_ix5' ON 'ix5' ( pagc_key ); CREATE INDEX 'x_pgx' ON 'pgx' ( pagc_key ); sqlite> select count(*) from ix0; 100792158 sqlite> select count(*) from pgx; 50583769 Yikes! a whole lot of something in those tables! -Steve |
|
From: Stephen W. <wo...@sw...> - 2011-03-05 01:43:25
|
Hi all, I just wanted to give an update on my experiences working with the datastore branch in SVN. First for those not on the devel list, I have merged single line parseaddress branch into the datastore branch, so all the new features are now integrated into branches/datastore. I say all, but there may be some missing code from the landmarks branch as I found geocode_response on datastore had not been merged so I merged that with my own changes. If you find stuff missing or broken please let us know and Walter I and will try to attend to it. Ok next, I'm really loving the new datastore branch. I build mine using shapefiles as input and sqlite as the datastore and plain files for the cache. I explain how I built stuff below. So I'm trying to build PAGC and a geocode response that will have the whole US loaded into it. Working with Tiger that mean you have to load one county and then append to that about 3300 more counties. Needless to say this is time consuming especially if your process blows up along the way! Ah, more than once! One of the very cool benefits of using SQLite is that it is an ACID compliant database which means that it protects the database at all costs and keeps it in a stable usable state, even when it crashes! So some 200 appends and 4 hours into the load I ran across a file that caused pagc_build_schema to SEGV and crash. I'm now thinking I have to spend 4 hrs to rebuild the database up to the file before the crash just so I can debug it. But wait, I say, why not see what happens if I just rerun the command that crashed. So I start up the debugger, rerun the command, and it appears to be hung. :( I ^C out of it and there is a long delay and it eventually returns, and I exit the debugger, look at the file system again and notice the sqlite journal file is no longer there and the database is slightly smaller than before. Oh, the big delay, like it was hung, was SQLite using the journal file to ROLLBACK the transaction that was open when it crashed, restoring the database back to a usable state. Cool, I get back into the debugger and rerun the command and it runs and SEGVs like before and I can now see what is broken. The shapefile had a shape that was too big for a fixed size buffer, I up the buffer size and rebuild PAGC. Now when I rerun the command it does the rollback again because I crashed it again and then completes without a failure and the database is still in good shape! So I restart my script appending to the existing database and another 6 hours into loading data, my tiger join process barfs and causes pagc_build_schema to die again. I little more debugging, some bug fixes and we are off and running again! I currently have 8.4 GB SQLite database which contains 836 or 3300 counties and the load continues. This resiliency is what makes SQLite such an awesome database and it is very fast and has zero management so it is ideal for deploying to production sites. Walter has done a great job with the datastore branch. I look forward to check out some of the other options that he has built into the code. I'm giving my config a major workout as we speak loading data and will post the geocode_response URL when its ready for some testing. OK, here is how I built stuff cd branches/datastore/ds ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f make sudo make install sudo ldconfig cd ../pagclib ./configure make sudo make install sudo ldconfig cd ../parseaddress ./configure make sudo make install sudo ldconfig cd ../geocode_response ## edit data_cap.h as required ./configure --with-parseaddress # add other options you want make sudo make install sudo ldconfig sudo cp geocode_response /usr/lib/cgi-bin/geocode_response This is great stuff, I hope you enjoy it as much as I am - Well maybe I enjoy this just a little too much ;) -Steve |
|
From: Stephen W. <wo...@sw...> - 2011-03-02 20:37:45
|
Hi all,
I have just finished merging the branches/parseaddress changes into
branches/datastore.
The follow changes have been made:
branches/datastore/data/xml/GeocodeService.xsd
- updated to reflect additional fields in the request and response
branches/datastore/geocode_response/configure.ac
- added --with-parseaddress to optional build the code
branches/datastore/geocode_response/format.c
- fixed a bug where address data was not getting encoded for XML out
branches/datastore/geocode_response/main.c
- integration of parseaddress library into geocode_response
branches/datastore/pagc_build_schema/main.c
- minor change so all error exits set the return code to 1 on error
so scripts can detect if an error occurs and take appropriate action
branches/datastore/parseaddress/*
- added the parseaddress library that is needed for geocode_response
I have been working with the datastore branch and it is looking pretty
good so far. I have restricted my testing to:
./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f
which is:
sqlite for the runtime data store
files for the cache
shapefile for the input reference set and schema definition
Best regards,
-Steve
|
|
From: Stephen W. <wo...@sw...> - 2011-03-01 20:29:02
|
OK, a few steps forward and one step back to this problem. With Walter's generous support and help, I have been able to use the new datastores code to load my version of Tiger data into PAGC. I built ds with: ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f And I have been able to load each county of Massachusetts by appending it to the previous. And geocoding works as well as before. BUT sadly, the zipcode issue still exists! So to review on this issue. This works (NO ZIPCODE): > http://imaptools.com:8080/cgi-bin/gc-tiger?methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=&CompleteAddressNumber=1&CompleteStreetName=rote+hill+rd&CompleteStreetName2=&PlaceName=sheffield&StateName=MA&ZipCode=&CountryCode=US&ResponseFormat=XML This does not (HAS ZIPCODE): > http://imaptools.com:8080/cgi-bin/gc-tiger?methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=&CompleteAddressNumber=1&CompleteStreetName=rote+hill+rd&CompleteStreetName2=&PlaceName=sheffield&StateName=MA&ZipCode=01257&CountryCode=US&ResponseFormat=XML The only difference is that the second request includes the zipcode. So trying the addresses below (fails means fails with zipcode): 177-205 work (record 1) 176 fails, but 178-204 work (record 2) 125-161 fails (record 3) 126-160 fails (record 4) 163-175 fails (record 5) I did not try every address beyond these but tried random ones with no luck at finding any that worked. So this a a large percentage of records that are failing in this sample for exact matches. > woodbri@mappy:/u/data/tgr2009-test/streets$ dbfdump Streets > 3942309:177:205:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942309:176:204:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942326:125:161:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942326:126:160:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942327:163:175:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942327:162:174:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942332:207:457:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3942332:206:456:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3947098:459:495:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3947098:458:494:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3963810:1:11:FM99:{}:%2d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3963810:2:12:FM99:{}:%2d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3968133:13:93:FM99:{}:%2d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3968133:14:94:FM99:{}:%2d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3968134:95:123:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3968134:96:124:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3982370:497:531:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 3982370:496:530:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 618744647:533:565:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 618744647:532:564:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 > 618744648:567:569:FM999:{}:%3d:Rote Hill:::::Rd::L:SHEFFIELD:New Marlborough:Berkshire:MA:US:01257 > 618744648:566:568:FM999:{}:%3d:Rote Hill:::::Rd::R:SHEFFIELD:New Marlborough:Berkshire:MA:US:01257 I have created a shapefile with just the records above that should reproduce this problem and can be downloaded from: http://imaptools.com:8080/dl/tgr2009-test.tbz This contains: > tar tvjf /u/www/html/dl/tgr2009-test.tbz > -rw-r--r-- woodbri/woodbri 11717 2011-01-01 00:34 tgr2009-test/streets/Streets.dbf > -rw-r--r-- woodbri/woodbri 3860 2011-01-01 00:34 tgr2009-test/streets/Streets.shp > -rw-r--r-- woodbri/woodbri 276 2011-01-01 00:34 tgr2009-test/streets/Streets.shx > -rwxr-xr-x woodbri/woodbri 325 2010-12-30 11:43 tgr2009-test/testgc > -rw-r--r-- woodbri/woodbri 11833 2010-12-30 10:17 tgr2009-test/standard/gazeteer.csv > -rw-r--r-- woodbri/woodbri 84943 2010-12-30 10:17 tgr2009-test/standard/featwords.csv > -rw-r--r-- woodbri/woodbri 2242 2010-12-30 10:17 tgr2009-test/standard/tgr2pagc-single.dbf > -rw-r--r-- woodbri/woodbri 75537 2010-12-30 10:17 tgr2009-test/standard/lexicon.csv > -rw-r--r-- woodbri/woodbri 1090 2010-12-30 10:17 tgr2009-test/standard/landmarks09.dbf So it looks like, this problem still remains in the code. I think I have taken this about as far as I can. There is a lot of research below in this thread. If there is anyway that I can help Walter, please let me know. Seems like we are very close to having this working. Best regards, -Steve On 1/11/2011 10:59 AM, Stephen Woodbridge wrote: > On 1/11/2011 5:12 AM, whi...@de... wrote: >> Hi Steve : Did you try without the commas, just spaces? > > I think I can reproduce the problem using just your hardcoded tested > program so no commas involved. > > 1. without zipcode, I get 22 records, record 10 is geocoded with lat,lon > 2. with zipcode, I get one record that is not geocoded with lat, lon > > This is using pagclib based on branches/landmarks svn code. If you are > using the datastore branch then you are using DBVER45 and I'm using > DBVER42 so there might be a bug in that also. > >> Another thing to >> consider is that I'm using the new library. Bugs. > > What code is this? From branches/datastore? > Can you give a brief intro on how to build this? Looking at the code > maybe something like this: > > cd branches/datastrore/ds > aclocal > libtoolize > automake -a > autoconf > > ### looks like configure.ac is hardcoded to your BDB version !!! > ### also looks like it is hardcoded to DBVER45 > ### I realize this is not ready for primetime yet > ### I'll try to hack this to use DBVER42 that I have installed > ### Can I specify it as an argument??? > > ### defaults look to build BDB and Shapefile like before > ./configure > ### or ### > ./configure --with-norm=b --with-raw=d --with-sch=d --with-cache=b > > ### or to build with SQLite and shapefile (ie: no BDB) > ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f > > ### This configured ok, but make fails with: > woodbri@mappy:~/work/pagc/pagc/branches/datastore/ds$ make > make: *** No rule to make target `sqlite3.c', needed by > `libds_la-sqlite3.lo'. Stop. > > ### I don't see this file in the sqlite3 source tree, so > ### I'm guessing you have stuff that is nor checked in yet or this is > ### just not ready for testing yet. > > make > ### does old version of pagc need to be removed? > sudo make install > > Then build the rest of the tools as normal? > > Is SQLite stable enough to try yet? > > Anyway, no worries on the new stuff. I thought I would give it a try and > see how far I could get. I'll see if I can hack configure.ac to work for > my version of BDB. > >> Have been hit with cold, >> then flu, so I'm not concentrating well right now. Thanks,<= walter => > > My sympathies. I had some 24hr bug and basically sleep all day on the > sofa. Hope you feel better quickly. > > -Steve > >>> Hi Walter, >>> >>> OK, when the zipcode is left off, I get item (10) that is geocoded. So >>> this is consistent with my geocode_response. On when I run your test >>> program with the zipcode it does not find that record. >>> >>> So, this is not the same result that you get? >>> >>> I'm not sure how to proceed with this. Thoughts? >>> >>> -Steve >>> >>> On 1/9/2011 12:48 AM, whi...@de... wrote: >>>> Hi Steve : every one of them except one will have that geocode -- it >>>> just >>>> means that the target house address does not fit in the interval. There >>>> should be one on your candidate list (somewhere in the middle) that has >>>> the right coordinates. Thanks,<= walter => >>>> >>>>> Walter, >>>>> >>>>> Is it normal for your test program to always return the geocoded >>>>> location as (-181.000000,-181.000000)? >>>>> >>>>> woodbri@mappy:/u/data/tgr2009-test/streets$ ../testit >>>>> Log name is test_log >>>>> Reference is >>>>> (0) (<SiteAddress><CompleteAddressNumber>1</CompleteAddressNumber> >>>>> <CompleteStreetName><StreetName>Rote Hill</StreetName> >>>>> <PostType>Rd</PostType></CompleteStreetName> >>>>> <PlaceName>SHEFFIELD</PlaceName> >>>>> <PlaceName_USPS>Sheffield</PlaceName_USPS> >>>>> <StateName>MASSACHUSETTS</StateName> >>>>> <ZipCode>01257</ZipCode></SiteAddress>) (1.000000) >>>>> (-181.000000,-181.000000) >>>>> woodbri@mappy:/u/data/tgr2009-test/streets$ >>>>> >>>>> Like wise if I remove the zipcode, I get back 22 responses and all have >>>>> the same (-181.000000,-181.000000) location. >>>>> >>>>> -Steve >>>>> >>>>> >>>>> On 1/8/2011 12:28 AM, Stephen Woodbridge wrote: >>>>>> Hi Walter, >>>>>> >>>>>> Running the geocode_response in gdb and looking at the output of your >>>>>> test script I notice that the macro I use to combine that parseaddress >>>>>> fields is a little different. Below is the gc_req_p object that I >>>>>> create. Notice that I have "," instead of spaces " " in: >>>>>> >>>>>> complete_feature_address = "1,rote hill rd", '\0'<repeats 4081 times>, >>>>>> place_state_zip = "sheffield,MA,01257", '\0'<repeats 4077 times>, >>>>>> >>>>>> Too bleary eyed to continue tonight. I can change this and try it >>>>>> again, >>>>>> but I dont think this is the issue because I can reproduce this >>>>>> behavior >>>>>> using just the landmarks branch, so it is something broken in >>>>>> geocode_response. But after 2.5 hours of stepping through code in the >>>>>> debugger, I don't have a clue what to look for. >>>>>> >>>>>> -Steve >>>>>> >>>>>> (gdb) p *gc_req_p >>>>>> $2 = {context_idx = 1, match_schema_idx = {0}, landmark_schema_idx = >>>>>> {0}, >>>>>> interpolate_schema_idx = 1, collect_all_points = 0, >>>>>> client_max_responses = 30, num_cgi_entries = 5, numb_cands = 0, >>>>>> cand_list = 0xa87610, cand_list_cutoff = 0, >>>>>> client_format_requested >>>>>> = 2, >>>>>> base_geocode_method = 0, base_geocode_strategy = 1, >>>>>> site_strategy_switch = 1, client_interpolation_offset = 10, >>>>>> client_intersection_cutoff_radius = 30, pagc_handle = 0x608010, >>>>>> mini_hash_table = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, >>>>>> 0x0, >>>>>> 0x7fb1f1c5aa00, 0x0, 0x0, 0x7fb1f1c5a3e8, 0x0<repeats 13 >>>>>> times>, >>>>>> 0x7fb1f1c5a5f0, 0x0<repeats 18 times>, 0x7fb1f1c5a7f8}, >>>>>> cgi_entry_buf = {{ >>>>>> name = "methodName", '\0'<repeats 245 times>, >>>>>> value = "GeocodeRequest", '\0'<repeats 241 times>, next = >>>>>> 0x0}, >>>>>> { >>>>>> name = "Version", '\0'<repeats 248 times>, >>>>>> value = "1.1", '\0'<repeats 252 times>, next = 0x0}, { >>>>>> name = "InterpolationOffset", '\0'<repeats 236 times>, >>>>>> value = "10.0", '\0'<repeats 251 times>, next = 0x0}, { >>>>>> name = "UnParsedAddress", '\0'<repeats 240 times>, >>>>>> value = "1 rote hill rd sheffield ma 01257", '\0'<repeats 222 >>>>>> times>, >>>>>> next = 0x7fb1f1c5a1e0}, { >>>>>> name = "ResponseFormat", '\0'<repeats 241 times>, >>>>>> value = "XML", '\0'<repeats 252 times>, next = 0x0}, { >>>>>> name = '\0'<repeats 255 times>, value = '\0'<repeats 255 >>>>>> times>, >>>>>> next = 0x0}<repeats 95 times>}, >>>>>> country_code = "US\000\000\000\000\000", >>>>>> geocode_buf = '\0'<repeats 65135 times>, >>>>>> fault_buf = '\0'<repeats 4095 times>, >>>>>> interface_version = "1.1\000\000\000\000\000", >>>>>> complete_feature_address = "1,rote hill rd", '\0'<repeats 4081 >>>>>> times>, >>>>>> complete_feature_address_B = '\0'<repeats 4095 times>, >>>>>> county_name = '\0'<repeats 255 times>, >>>>>> place_state_zip = "sheffield,MA,01257", '\0'<repeats 4077 times>, >>>>>> client_request_id = '\0'<repeats 255 times>, >>>>>> requested_address = "<UnParsedAddress>1 rote hill rd sheffield ma >>>>>> 01257</UnParsedAddress>\n<CompleteAddressNumber>1</CompleteAddressNumber>\n<CompleteStreetName>rote >>>>>> hill rd</CompleteStreetName>\n<PlaceName>sheffield</PlaceN"..., >>>>>> header_str = '\0'<repeats 4095 times>} >>>>>> >>>>>> >>>>>> On 1/4/2011 4:46 AM, whi...@de... wrote: >>>>>>> Hi Steve : >>>>>>> No, I didn't notice your shell script -- thanks -- I'll try it out. >>>>>>> I'm >>>>>>> working on my cache right now -- it seems to be working for the >>>>>>> approx >>>>>>> 5000 record landmark file. I need to try it on really large file so I >>>>>>> know >>>>>>> it's evicting the right victims. The sqlite also appears to be >>>>>>> working >>>>>>> and >>>>>>> is faster than I expected, after you dispense with all the journaling >>>>>>> and >>>>>>> other rigamarole. Again, I need to try it on a larger dataset. >>>>>>> I have a command line program that takes no commands from the >>>>>>> command >>>>>>> line (see below) which I use to cycle through the library interfaces >>>>>>> in >>>>>>> basically the same order as the geocoding service. I wrote it to test >>>>>>> one >>>>>>> address, hardwired into the code -- I just change the address and the >>>>>>> relevant variables (coverage name, strategy etc) and recompile. For >>>>>>> interpolation candidates it scores and includes blockranges into >>>>>>> which >>>>>>> the target number doesn't fit -- just geocodes with -181, 181 >>>>>>> coordinates >>>>>>> to indicate failure. So the match I got was : >>>>>>> >>>>>>> (10) (<SiteAddress><CompleteAddressNumber>1</CompleteAddressNumber> >>>>>>> <CompleteStreetName><StreetName>Rote Hill</StreetName> >>>>>>> <PostType>Rd</PostType></CompleteStreetName> >>>>>>> <PlaceName>SHEFFIELD</PlaceName> >>>>>>> <PlaceName_USPS>Sheffield</PlaceName_USPS> >>>>>>> <StateName>MASSACHUSETTS</StateName> >>>>>>> <ZipCode>01257</ZipCode></SiteAddress>) (0.809667) >>>>>>> (-73.326481,42.098817) >>>>>>> >>>>>>> I'm not including parity and id fields etc in this stripped down >>>>>>> tester, >>>>>>> nor dealing with the more complicated merged lists of candidates. >>>>>>> Code >>>>>>> for >>>>>>> tester follows. Thanks,<= walter => >>>>>>> >>>>>>> >>>>>>> #include<string.h> >>>>>>> #include<stdio.h> >>>>>>> #include "pagc_client.h" >>>>>>> #include "pagc_tools.h" >>>>>>> >>>>>>> #define FAILED_EXIT( MSG ) \ >>>>>>> printf( "%s\n" , MSG ) ; \ >>>>>>> fflush( stdout ) ; \ >>>>>>> pagc_close( pagc_p ) ; \ >>>>>>> return 0 >>>>>>> >>>>>>> >>>>>>> #define POST_BUF_SIZE 4096 >>>>>>> >>>>>>> static const char *log_name_string = "test_log" ; >>>>>>> static const char *hardwired_refname = "streets" ; >>>>>>> /*static const char *hardwired_refname = >>>>>>> "clipped_to_metro2_lat_point" >>>>>>> ;*/ >>>>>>> static int base_geocode_strategy = SITE_INTERPOLATE ; >>>>>>> static int start_schema_op = BOTH ; >>>>>>> static int client_format_requested = XML ; >>>>>>> >>>>>>> int main( int argc , char *argv[] ) { >>>>>>> int num_candidates , cand_sel , error_code , >>>>>>> is_parity_mismatch ; >>>>>>> int interpolation_hn , cur_context ; >>>>>>> int score_card ; >>>>>>> int client_max_responses = 30 ; >>>>>>> int retain_cands = FALSE ; >>>>>>> int collect_all_points = TRUE ; >>>>>>> int client_intersection_cutoff_radius = 20 ; >>>>>>> int client_interpolation_offset = 0 ; >>>>>>> double cur_score ; >>>>>>> PAGC_POINT match_point ; >>>>>>> char local_result_str[ POST_BUF_SIZE ] ; >>>>>>> char record_id_str[ POST_BUF_SIZE ] ; >>>>>>> char complete_feature_address[ POST_BUF_SIZE ] ; >>>>>>> char complete_feature_address_B[ POST_BUF_SIZE ] ; >>>>>>> char place_state_zip[ POST_BUF_SIZE ] ; >>>>>>> char landmark_name_buf[ MAXSTRLEN ] ; >>>>>>> char landmark_type_buf[ MAXSTRLEN ] ; >>>>>>> char landmark_county_buf[ MAXSTRLEN ] ; >>>>>>> char county_name[ POST_BUF_SIZE ] ; >>>>>>> char macro_buf[ MAXSTRLEN ] ; >>>>>>> char current_working[ PATHNAME_LEN ] ; >>>>>>> char ref_path[ PATHNAME_LEN ] ; >>>>>>> char log_path_name[ PATHNAME_LEN ] ; >>>>>>> char ref_name[ PATHNAME_LEN ] ; >>>>>>> char path_sep ; >>>>>>> >>>>>>> current_working[ 0 ] = SENTINEL ; >>>>>>> ref_path[ 0 ] = SENTINEL ; >>>>>>> log_path_name[ 0 ] = SENTINEL ; >>>>>>> ref_name[ 0 ] = SENTINEL ; >>>>>>> if ( !establish_directory( current_working ,&path_sep ) ) { >>>>>>> printf( "Could not establish current working directory" ) ; >>>>>>> return 0 ; >>>>>>> } >>>>>>> parse_file_name( hardwired_refname , path_sep , ref_name , ref_path >>>>>>> ) >>>>>>> ; >>>>>>> combine_path_file( path_sep , ref_path , (char *) log_name_string , >>>>>>> log_path_name ) ; >>>>>>> printf( "Log name is %s\n" , log_path_name ) ; >>>>>>> printf( "Reference is %s\n" , ref_path ) ; >>>>>>> >>>>>>> PAGC_HANDLE pagc_p = pagc_init( TRUE , ref_path , log_path_name ) ; >>>>>>> if ( pagc_p == NULL ) { >>>>>>> FAILED_EXIT( "No pagc library found" ) ; >>>>>>> } >>>>>>> int schema_idx = pagc_add_schema( pagc_p , hardwired_refname , 0 , >>>>>>> TRUE ) ; >>>>>>> if ( schema_idx == 0 ) { >>>>>>> FAILED_EXIT( "Schema did not open" ) ; >>>>>>> } >>>>>>> int context_idx = pagc_add_context( pagc_p , schema_idx , >>>>>>> start_schema_op >>>>>>> , TRUE , NULL ) ; >>>>>>> if ( context_idx == 0 ) { >>>>>>> FAILED_EXIT( "Context did not open" ) ; >>>>>>> } >>>>>>> >>>>>>> /* hardwired address assignments */ >>>>>>> >>>>>>> strcpy( complete_feature_address , "1 rote hill rd" ) ; >>>>>>> strcpy( place_state_zip , "sheffield ma 01257" ) ; >>>>>>> BLANK_STRING( complete_feature_address_B ) ; >>>>>>> BLANK_STRING( county_name ) ; >>>>>>> /* BLANK_STRING( place_state_zip ) ; */ >>>>>>> retain_cands = FALSE ; >>>>>>> client_max_responses = 20 ; >>>>>>> /*--------------------------------*/ >>>>>>> >>>>>>> if ( !pagc_reset_context_schema( pagc_p , schema_idx , context_idx ) >>>>>>> ) >>>>>>> { >>>>>>> } >>>>>>> switch ( base_geocode_strategy ) { >>>>>>> case LANDMARK_NAME : >>>>>>> error_code = pagc_match_landmark_item( pagc_p , context_idx , >>>>>>> complete_feature_address , complete_feature_address_B , county_name , >>>>>>> place_state_zip , client_max_responses , retain_cands ) ; >>>>>>> if ( error_code == FAIL || error_code == ERR_FAIL ) { >>>>>>> FAILED_EXIT( "Match failed" ) ; >>>>>>> } >>>>>>> if ( error_code == NULL_READ ) { >>>>>>> FAILED_EXIT( "Match failed: NULL" ) ; >>>>>>> } >>>>>>> break ; >>>>>>> case SITE_MATCH : >>>>>>> case SITE_INTERPOLATE : >>>>>>> error_code = pagc_match_item( pagc_p , context_idx , >>>>>>> complete_feature_address , NULL , place_state_zip , NULL , >>>>>>> client_max_responses , retain_cands ) ; >>>>>>> if ( error_code == FAIL || error_code == ERR_FAIL ) { >>>>>>> FAILED_EXIT( "Match failed" ) ; >>>>>>> } >>>>>>> if ( error_code == NULL_READ ) { >>>>>>> FAILED_EXIT( "Match failed: NULL" ) ; >>>>>>> } >>>>>>> break ; >>>>>>> case INTERSECTION : >>>>>>> /* -- set cutoff parameters before matching -- */ >>>>>>> if ( !pagc_set_intersection_cutoff( pagc_p , context_idx >>>>>>> ,collect_all_points , client_intersection_cutoff_radius ) ) { >>>>>>> FAILED_EXIT( "Match failed" ) ; >>>>>>> } >>>>>>> error_code = pagc_match_item( pagc_p , context_idx , >>>>>>> complete_feature_address , complete_feature_address_B , >>>>>>> place_state_zip , NULL , client_max_responses , FALSE ) ; >>>>>>> if ( error_code == FAIL || error_code == ERR_FAIL ) { >>>>>>> FAILED_EXIT( "Match failed" ) ; >>>>>>> } >>>>>>> if ( error_code == NULL_READ ) { >>>>>>> FAILED_EXIT( "Match failed: NULL" ) ; >>>>>>> } >>>>>>> break ; >>>>>>> } >>>>>>> if (!pagc_numb_cands( pagc_p , context_idx ,&num_candidates ) ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> candidate >>>>>>> numbers" ) ; >>>>>>> FAILED_EXIT( "Exit: no candidate numbers" ) ; >>>>>>> } >>>>>>> if ( num_candidates<= 0 ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> candidates" ) ; >>>>>>> FAILED_EXIT( "Exit: no candidates found" ) ; >>>>>>> } >>>>>>> for ( cand_sel = 0 ; cand_sel< num_candidates ; cand_sel ++ ) { >>>>>>> *local_result_str = SENTINEL ; >>>>>>> switch ( base_geocode_strategy ) { >>>>>>> case LANDMARK_NAME : >>>>>>> error_code = pagc_geocode_landmark_candidate( pagc_p , >>>>>>> context_idx >>>>>>> , >>>>>>> cand_sel ,&match_point ) ; >>>>>>> if ( error_code == FAIL ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> geocoding of candidate" ) ; >>>>>>> FAILED_EXIT( "Exit: no geocode" ) ; >>>>>>> } >>>>>>> break ; >>>>>>> case SITE_INTERPOLATE : >>>>>>> case SITE_MATCH : >>>>>>> /* -- get the coords in match_point and house number in >>>>>>> interpolation_hn --*/ >>>>>>> error_code = pagc_geocode_address_candidate( pagc_p , context_idx >>>>>>> , >>>>>>> cand_sel ,&match_point ,&interpolation_hn , >>>>>>> client_interpolation_offset ) ; >>>>>>> if ( error_code == FAIL ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> geocoding of candidate" ) ; >>>>>>> FAILED_EXIT( "Exit: no geocode" ) ; >>>>>>> } >>>>>>> if ( !error_code ) { >>>>>>> /* -- non-geocodable address range -- */ >>>>>>> break ; >>>>>>> } >>>>>>> break ; >>>>>>> case INTERSECTION : >>>>>>> error_code = pagc_geocode_intersection_candidate( pagc_p , >>>>>>> context_idx >>>>>>> , cand_sel ,&match_point ) ; >>>>>>> if ( error_code == FAIL ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> geocoding of candidate" ) ; >>>>>>> FAILED_EXIT( "Exit: no geocode" ) ; >>>>>>> } >>>>>>> break ; >>>>>>> default : >>>>>>> FAILED_EXIT( "Exit: no strategy found" ) ; >>>>>>> } >>>>>>> /* -- copy adt into local_result_str --*/ >>>>>>> if ( !pagc_format_candidate( pagc_p , context_idx , cand_sel , >>>>>>> local_result_str , interpolation_hn , client_format_requested , >>>>>>> base_geocode_strategy ,&is_parity_mismatch , record_id_str ) ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "Can't >>>>>>> format candidate\n" ) ; >>>>>>> FAILED_EXIT( "Exit: no formatting" ) ; >>>>>>> } >>>>>>> if ( !pagc_get_normalized_score( pagc_p , context_idx , cand_sel , >>>>>>> base_geocode_strategy ,&cur_score ,&score_card ) ) { >>>>>>> pagc_register_context_error( pagc_p , context_idx , TRUE , "No >>>>>>> scoring >>>>>>> of candidate" ) ; >>>>>>> FAILED_EXIT( "Exit: no scoring" ) ; >>>>>>> } >>>>>>> /* output candidate result */ >>>>>>> printf( "(%d) (%s) (%lf) (%lf,%lf)\n" , cand_sel , local_result_str >>>>>>> , >>>>>>> cur_score , match_point . X , match_point . Y ) ; >>>>>>> } >>>>>>> pagc_close( pagc_p ) ; >>>>>>> return 0 ; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Walter, >>>>>>>> >>>>>>>> Thanks that is good to know and if the data looks ok then I can >>>>>>>> start >>>>>>>> loading all the Tiger data. >>>>>>>> >>>>>>>> Did you notice my testgc shell script? This is a handy way to test >>>>>>>> the >>>>>>>> geocode_response in a commandline You can even envoke it in gdb >>>>>>>> with: >>>>>>>> >>>>>>>> ./testgc >>>>>>>> 'methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=1+rote+hill+rd+sheffield+ma+01257&ResponseFormat=XML' >>>>>>>> gdb >>>>>>>> >>>>>>>> notice that the last commandline argument is gdb. the script sets up >>>>>>>> the >>>>>>>> environment then starts geocode_response in gdb and puts you in the >>>>>>>> gdb >>>>>>>> commandline environment. But that might be be useful if you are >>>>>>>> using >>>>>>>> a >>>>>>>> GUI based development environment. >>>>>>>> >>>>>>>> Also, I am pretty sure that I tested this in geocode_response from >>>>>>>> the >>>>>>>> landmark branch passing in the parsed arguments and got the same >>>>>>>> results. I'll give this another try to confirm it. >>>>>>>> >>>>>>>> OK, so how did you test it using just the library? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Steve >>>>>>>> >>>>>>>> On 1/3/2011 8:24 PM, whi...@de... wrote: >>>>>>>>> Hi Steve -- I built it with the new library (just library, no >>>>>>>>> geocode >>>>>>>>> service) and it works properly. So there's no problem with the >>>>>>>>> data. >>>>>>>>> So >>>>>>>>> it's somewhere in the service, either with the input itself, or >>>>>>>>> with >>>>>>>>> the >>>>>>>>> handling of the candidates. But I'm not yet in a position to test >>>>>>>>> the >>>>>>>>> geocode service. Thanks,<= walter => >>>>>>>>> >>>>>>>>>> Walter, >>>>>>>>>> >>>>>>>>>> Sorry for so many emails on this, I was trying to simplify the >>>>>>>>>> problem >>>>>>>>>> to make it easier to debug. So I have a shapefile with about 22 >>>>>>>>>> records >>>>>>>>>> the reproduces this problem. The tar file at >>>>>>>>>> http://imaptools.com:8080/dl/tgr2009-test.tbz >>>>>>>>>> has the files need to build. >>>>>>>>>> >>>>>>>>>> I'll leave it at this since this demonstrates the problem and 22 >>>>>>>>>> records >>>>>>>>>> is small enough I hope it will be easy to identify the problem. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Steve >>>>>>>>>> >>>>>>>>>> Here is the failure that includes the zipcode: >>>>>>>>>> >>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test$ ./testgc >>>>>>>>>> 'methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=1+rote+hill+rd+sheffield+ma+01257&ResponseFormat=XML' >>>>>>>>>> Content-type: text/xml >>>>>>>>>> >>>>>>>>>> <?xml version="1.0" encoding="UTF-8" ?> >>>>>>>>>> <GeocodeService xmlns="http://www.metrogis.org/geocode" >>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>>>>>>>> xsi:schemaLocation="http://www.metrogis.org/geocode >>>>>>>>>> GeocodeService.xsd" >>>>>>>>>> xmlns:gml="http://www.opengis.net/gml"> >>>>>>>>>> <ResponseHeader /> >>>>>>>>>> <Response Version="1.1" RequestID=""> >>>>>>>>>> <GeocodeResponse><GeocodeResponseList >>>>>>>>>> numberOfGeocodedAddresses="0"> >>>>>>>>>> </GeocodeResponseList> >>>>>>>>>> </GeocodeResponse> >>>>>>>>>> <requestedAddress> >>>>>>>>>> <UnParsedAddress>1 rote hill rd sheffield ma >>>>>>>>>> 01257</UnParsedAddress> >>>>>>>>>> <CompleteAddressNumber>1</CompleteAddressNumber> >>>>>>>>>> <CompleteStreetName>rote hill rd</CompleteStreetName> >>>>>>>>>> <PlaceName>sheffield</PlaceName> >>>>>>>>>> <StateName>MA</StateName> >>>>>>>>>> <ZipCode>01257</ZipCode> >>>>>>>>>> <CountryCode>US</CountryCode></requestedAddress> >>>>>>>>>> </Response></GeocodeService> >>>>>>>>>> >>>>>>>>>> Here is the same address without the zipcode that works: >>>>>>>>>> >>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test$ ./testgc >>>>>>>>>> 'methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=1+rote+hill+rd+sheffield+ma&ResponseFormat=XML' >>>>>>>>>> Content-type: text/xml >>>>>>>>>> >>>>>>>>>> <?xml version="1.0" encoding="UTF-8" ?> >>>>>>>>>> <GeocodeService xmlns="http://www.metrogis.org/geocode" >>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>>>>>>>> xsi:schemaLocation="http://www.metrogis.org/geocode >>>>>>>>>> GeocodeService.xsd" >>>>>>>>>> xmlns:gml="http://www.opengis.net/gml"> >>>>>>>>>> <ResponseHeader /> >>>>>>>>>> <Response Version="1.1" RequestID=""> >>>>>>>>>> <GeocodeResponse><GeocodeResponseList >>>>>>>>>> numberOfGeocodedAddresses="1"> >>>>>>>>>> <GeocodedAddress> >>>>>>>>>> <Address> >>>>>>>>>> <SiteAddress><CompleteAddressNumber>1</CompleteAddressNumber> >>>>>>>>>> <CompleteStreetName><StreetName>Rote Hill</StreetName> >>>>>>>>>> <PostType>Rd</PostType></CompleteStreetName> >>>>>>>>>> <PlaceName>SHEFFIELD</PlaceName> >>>>>>>>>> <PlaceName_USPS>Sheffield</PlaceName_USPS> >>>>>>>>>> <StateName>MASSACHUSETTS</StateName> >>>>>>>>>> <ZipCode>01257</ZipCode></SiteAddress></Address> >>>>>>>>>> <gml:Point><gml:pos>-73.326481 42.098817</gml:pos></gml:Point> >>>>>>>>>> <GeocodeMatchCode accuracy="0.915095" matchType="INTERPOLATED" >>>>>>>>>> note="P"/> >>>>>>>>>> <source><dataSource>Streets</dataSource><addressIdentifier>3963810</addressIdentifier></source></GeocodedAddress> >>>>>>>>>> </GeocodeResponseList> >>>>>>>>>> </GeocodeResponse> >>>>>>>>>> <requestedAddress> >>>>>>>>>> <UnParsedAddress>1 rote hill rd sheffield ma</UnParsedAddress> >>>>>>>>>> <CompleteAddressNumber>1</CompleteAddressNumber> >>>>>>>>>> <CompleteStreetName>rote hill rd</CompleteStreetName> >>>>>>>>>> <PlaceName>sheffield</PlaceName> >>>>>>>>>> <StateName>MA</StateName> >>>>>>>>>> <CountryCode>US</CountryCode></requestedAddress> >>>>>>>>>> </Response></GeocodeService> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/31/2010 5:54 PM, Stephen Woodbridge wrote: >>>>>>>>>>> Arggh, ignore this. The three record version appears to be >>>>>>>>>>> working, >>>>>>>>>>> I >>>>>>>>>>> need to rebuild the file with more records and post it again, >>>>>>>>>>> after >>>>>>>>>>> I >>>>>>>>>>> get back from some New Years partying :) >>>>>>>>>>> >>>>>>>>>>> Enjoy and be safe, >>>>>>>>>>> -Steve >>>>>>>>>>> >>>>>>>>>>> On 12/31/2010 12:24 PM, Stephen Woodbridge wrote: >>>>>>>>>>>> Hi Walter, >>>>>>>>>>>> >>>>>>>>>>>> I did some more testing and was able to get this problem down to >>>>>>>>>>>> 3 >>>>>>>>>>>> records: >>>>>>>>>>>> >>>>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test/streets$ dbfdump Streets.dbf >>>>>>>>>>>> 3963810:1:11:FM99:{}:%2d:Rote >>>>>>>>>>>> Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 >>>>>>>>>>>> 3963810:2:12:FM99:{}:%2d:Rote >>>>>>>>>>>> Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 >>>>>>>>>>>> 3963816:768:924:FM999:{}:%3d:East:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>> >>>>>>>>>>>> I updated the tar file referenced below to contain this >>>>>>>>>>>> shapefile. >>>>>>>>>>>> >>>>>>>>>>>> Everything else is the same. Also the code I am running is from >>>>>>>>>>>> the >>>>>>>>>>>> pagc/branches/parseaddress/ branch which should be identical to >>>>>>>>>>>> the >>>>>>>>>>>> landmarks except for the parseaddress code I added. >>>>>>>>>>>> >>>>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test/streets$ pagc_dump -rStreets >>>>>>>>>>>> -b >>>>>>>>>>>> 0 : |1,11,,,,,,,ROTE HILL,Rote >>>>>>>>>>>> Hill,ROAD,Rd,,,SHEFFIELD,SHEFFIELD,SHEFFIELD,Sheffield,MASSACHUSETTS,,01257,3963810,| >>>>>>>>>>>> 1 : |2,12,,,,,,,ROTE HILL,Rote >>>>>>>>>>>> Hill,ROAD,Rd,,,SHEFFIELD,SHEFFIELD,SHEFFIELD,Sheffield,MASSACHUSETTS,,01257,3963810,| >>>>>>>>>>>> 2 : >>>>>>>>>>>> |768,924,,,,,,,EAST,East,ROAD,Rd,,,RICHMOND,RICHMOND,RICHMOND,Richmond,MASSACHUSETTS,,01254,3963816,| >>>>>>>>>>>> >>>>>>>>>>>> OK >>>>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test/streets$ pagc_dump -rStreets >>>>>>>>>>>> -i0 >>>>>>>>>>>> EAST,ROAD : 2 >>>>>>>>>>>> EAST,ROAD,01254 : 2 >>>>>>>>>>>> ROTE HILL,ROAD : 0 >>>>>>>>>>>> ROTE HILL,ROAD : 1 >>>>>>>>>>>> ROTE HILL,ROAD,01257 : 0 >>>>>>>>>>>> ROTE HILL,ROAD,01257 : 1 >>>>>>>>>>>> >>>>>>>>>>>> OK >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Steve >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12/31/2010 10:46 AM, Stephen Woodbridge wrote: >>>>>>>>>>>>> Hi Walter, >>>>>>>>>>>>> >>>>>>>>>>>>> I have narrowed the problem down to loading a shapefile with 13 >>>>>>>>>>>>> records >>>>>>>>>>>>> as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test$ dbfdump streets/Streets >>>>>>>>>>>>> 3963802:1:73:FM99:{}:%2d:Railroad:::::St::L:GREAT >>>>>>>>>>>>> BARRINGTON:Great >>>>>>>>>>>>> Barrington:Berkshire:MA:US:01230 >>>>>>>>>>>>> 3963802:2:72:FM99:{}:%2d:Railroad:::::St::R:GREAT >>>>>>>>>>>>> BARRINGTON:Great >>>>>>>>>>>>> Barrington:Berkshire:MA:US:01230 >>>>>>>>>>>>> 3963803:75:99:FM99:{}:%2d:Railroad:::::St::L:GREAT >>>>>>>>>>>>> BARRINGTON:Great >>>>>>>>>>>>> Barrington:Berkshire:MA:US:01230 >>>>>>>>>>>>> 3963803:74:98:FM99:{}:%2d:Railroad:::::St::R:GREAT >>>>>>>>>>>>> BARRINGTON:Great >>>>>>>>>>>>> Barrington:Berkshire:MA:US:01230 >>>>>>>>>>>>> 3963808:89:97:FM99:{}:%2d:Shore:::::Rd::L:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963808:100:108:FM999:{}:%3d:Shore:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963809:99:143:FM999:{}:%3d:Shore:::::Rd::L:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963809:110:150:FM999:{}:%3d:Shore:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963810:1:11:FM99:{}:%2d:Rote >>>>>>>>>>>>> Hill:::::Rd::L:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 >>>>>>>>>>>>> 3963810:2:12:FM99:{}:%2d:Rote >>>>>>>>>>>>> Hill:::::Rd::R:SHEFFIELD:Sheffield:Berkshire:MA:US:01257 >>>>>>>>>>>>> 3963816:768:924:FM999:{}:%3d:East:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963817:1066:1134:FM9999:{}:%4d:East:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> 3963817:926:1064:FM9999:{}:%4d:East:::::Rd::R:RICHMOND:Richmond:Berkshire:MA:US:01254 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> woodbri@mappy:/u/data/tgr2009-test$ pagc_build_schema -r >>>>>>>>>>>>> /u/data/tgr2009-test/streets/Streets -s >>>>>>>>>>>>> /u/data/tgr2009-test/standard/tgr2pagc-single.dbf -p -l >>>>>>>>>>>>> 10 percent complete >>>>>>>>>>>>> 20 percent complete >>>>>>>>>>>>> 30 percent complete >>>>>>>>>>>>> 40 percent complete >>>>>>>>>>>>> 50 percent complete >>>>>>>>>>>>> 60 percent complete >>>>>>>>>>>>> 70 percent complete >>>>>>>>>>>>> 80 percent complete >>>>>>>>>>>>> 90 percent complete >>>>>>>>>>>>> 100 percent complete >>>>>>>>>>>>> 110 percent complete<<<< Whoa! >>>>>>>>>>>>> 120 percent complete<<<< Whoa! I have seen that before! >>>>>>>>>>>>> >>>>>>>>>>>>> OK >>>>>>>>>>>>> >>>>>>>>>>>>> You can download the data from: >>>>>>>>>>>>> http://imaptools.com:8080/dl/tgr2009-test.tbz >>>>>>>>>>>>> >>>>>>>>>>>>> tar xjf tgr2009-test.tbz >>>>>>>>>>>>> cd tgr2009-test >>>>>>>>>>>>> pagc_build_schema -r /u/data/tgr2009-test/streets/Streets -s >>>>>>>>>>>>> /u/data/tgr2009-test/standard/tgr2pagc-single.dbf -p -l >>>>>>>>>>>>> >>>>>>>>>>>>> # this fails >>>>>>>>>>>>> ./testgc >>>>>>>>>>>>> 'methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=1+rote+hill+rd+sheffield+ma+01257&ResponseFormat=XML' >>>>>>>>>>>>> >>>>>>>>>>>>> # this works >>>>>>>>>>>>> ./testgc >>>>>>>>>>>>> 'methodName=GeocodeRequest&Version=1.1&InterpolationOffset=10.0&UnParsedAddress=1+rote+hill+rd+sheffield+ma&ResponseFormat=XML' >>>>>>>>>>>>> >>>>>>>>>>>>> Hopefully this will shead some light on the problem and make it >>>>>>>>>>>>> easier >>>>>>>>>>>>> to debug. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> -Steve >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node >>>>>>>>>>>>> allows >>>>>>>>>>>>> customers >>>>>>>>>>>>> to consolidate database storage, standardize their database >>>>>>>>>>>>> environment, and, >>>>>>>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>>>>>>> database >>>>>>>>>>>>> without downtime or disruption >>>>>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Pagc-devel mailing list >>>>>>>>>>>>> Pag...@li... >>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>>>>>>> customers >>>>>>>>>>>> to consolidate database storage, standardize their database >>>>>>>>>>>> environment, and, >>>>>>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>>>>>> database >>>>>>>>>>>> without downtime or disruption >>>>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Pagc-devel mailing list >>>>>>>>>>>> Pag...@li... >>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>>>>>> customers >>>>>>>>>>> to consolidate database storage, standardize their database >>>>>>>>>>> environment, >>>>>>>>>>> and, >>>>>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>>>>> database >>>>>>>>>>> without downtime or disruption >>>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Pagc-devel mailing list >>>>>>>>>>> Pag...@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>>>>> customers >>>>>>>>>> to consolidate database storage, standardize their database >>>>>>>>>> environment, >>>>>>>>>> and, >>>>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>>>> database >>>>>>>>>> without downtime or disruption >>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>>>> _______________________________________________ >>>>>>>>>> Pagc-devel mailing list >>>>>>>>>> Pag...@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>>>> customers >>>>>>>>> to consolidate database storage, standardize their database >>>>>>>>> environment, >>>>>>>>> and, >>>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>>> database >>>>>>>>> without downtime or disruption >>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>>> _______________________________________________ >>>>>>>>> Pagc-devel mailing list >>>>>>>>> Pag...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>>> customers >>>>>>>> to consolidate database storage, standardize their database >>>>>>>> environment, >>>>>>>> and, >>>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>>> database >>>>>>>> without downtime or disruption >>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>> _______________________________________________ >>>>>>>> Pagc-devel mailing list >>>>>>>> Pag...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>>>>>> customers >>>>>>> to consolidate database storage, standardize their database >>>>>>> environment, and, >>>>>>> should the need arise, upgrade to a full multi-node Oracle RAC >>>>>>> database >>>>>>> without downtime or disruption >>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>> _______________________________________________ >>>>>>> Pagc-devel mailing list >>>>>>> Pag...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Gaining the trust of online customers is vital for the success of any >>>>>> company >>>>>> that requires sensitive data to be transmitted over the Web. Learn >>>>>> how >>>>>> to >>>>>> best implement a security strategy that keeps consumers' information >>>>>> secure >>>>>> and instills the confidence they need to proceed with transactions. >>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>> _______________________________________________ >>>>>> Pagc-devel mailing list >>>>>> Pag...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Gaining the trust of online customers is vital for the success of any >>>>> company >>>>> that requires sensitive data to be transmitted over the Web. Learn >>>>> how >>>>> to >>>>> best implement a security strategy that keeps consumers' information >>>>> secure >>>>> and instills the confidence they need to proceed with transactions. >>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>> _______________________________________________ >>>>> Pagc-devel mailing list >>>>> Pag...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Gaining the trust of online customers is vital for the success of any >>>> company >>>> that requires sensitive data to be transmitted over the Web. Learn how >>>> to >>>> best implement a security strategy that keeps consumers' information >>>> secure >>>> and instills the confidence they need to proceed with transactions. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Pagc-devel mailing list >>>> Pag...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Gaining the trust of online customers is vital for the success of any >>> company >>> that requires sensitive data to be transmitted over the Web. Learn how >>> to >>> best implement a security strategy that keeps consumers' information >>> secure >>> and instills the confidence they need to proceed with transactions. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> Gaining the trust of online customers is vital for the success of any company >> that requires sensitive data to be transmitted over the Web. Learn how to >> best implement a security strategy that keeps consumers' information secure >> and instills the confidence they need to proceed with transactions. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Bill H. <bha...@bc...> - 2011-01-18 18:34:32
|
Dan: I've only built streets at this time. I'll need to brush up on building both streets and parcels. Thanks, Baldwin County Public Schools Bill Harbour GIS Coordinator Information Technology Services Baldwin County Board of Education 1071 B Ave Loxley, AL 36551 V 251-580-1916 F 251-972-6851 Office 251-972-6850 bha...@bc... http://www.bcbe.org "When life gets too unreal, sit down with a good book." - Garrison Keillor -----Original Message----- From: Dan Putler [mailto:dan...@sa...] Sent: Tuesday, January 18, 2011 11:52 AM To: pag...@li... Subject: Re: [Pagc-devel] Parsing an unusual road name. Hi Bill, Is Avenida Alberto the only street in your service area that is done this way? My guess is there may be other streets in housing developments built around the same time that have this problem. If there are, you might want to think about augmenting the centerline road data with parcel address points to address the problem. Dan On 01/18/2011 07:43 AM, Bill Harbour wrote: > Steve and others. It turns out that PAGC is properly parsing the street name of Avenida Alberto. The culprit is how the segments for that street are addressed....there is no parity. Addresses were based on lot numbers and make no sense. These addresses were issued way before the County went digital and the person issuing them had now idea of what they were doing. PAGC finds the addresses for the beginning and ending segments, but nothing in between. > > Thanks for the help!! > > Baldwin County Public Schools > Bill Harbour > GIS Coordinator > Information Technology Services > Baldwin County Board of Education > 1071 B Ave > Loxley, AL 36551 > V 251-580-1916 > F 251-972-6851 > Office 251-972-6850 > bha...@bc... > http://www.bcbe.org > "When life gets too unreal, sit down with a good book." - Garrison Keillor > > -----Original Message----- > From: whi...@de... [mailto:whi...@de...] > Sent: Tuesday, January 18, 2011 2:51 AM > To: pag...@li... > Subject: Re: [Pagc-devel] Parsing an unusual road name. > > Hi Bill, Steve : Hopefully things are working now with this. If not, and > if you build with the -l option on the command line, there should be an > entry in the error log if PAGC was unable to standardize it. There is also > a utility included in the installer that allows you to test > standardization for individual addresses. > Thanks,<= walter => > >> Steve: >> >> I'm assuming I have the standard file where PAGC can find >> them...everything else seems to be geocoding propery. >> >> But I'll start there to see if I can get things to work, and will submit a >> bug report if I fail. >> >> Tnx, >> >> Baldwin County Public Schools >> Bill Harbour >> GIS Coordinator >> Information Technology Services >> Baldwin County Board of Education >> 1071 B Ave >> Loxley, AL 36551 >> V 251-580-1916 >> F 251-972-6851 >> Office 251-972-6850 >> bha...@bc... >> http://www.bcbe.org >> "When life gets too unreal, sit down with a good book." - Garrison Keillor >> >> -----Original Message----- >> From: Stephen Woodbridge [mailto:wo...@sw...] >> Sent: Friday, January 14, 2011 2:50 PM >> To: pag...@li... >> Subject: Re: [Pagc-devel] Parsing an unusual road name. >> >> Bill, >> >> Do you have the standard files where pagc can find them? >> >> woodbri@mappy:~/work/pagc/pagc/branches/parseaddress$ ls data/standard/ >> featwords.csv gazeteer.csv lexicon.csv rules.txt >> >> woodbri@mappy:~/work/pagc/pagc/branches/parseaddress/data/standard$ grep >> AVENIDA * >> featwords.csv:"1","AVA",1,"AVENIDA" >> featwords.csv:"1","AVENIDA",1,"AVENIDA" >> lexicon.csv:"1","AVA",2,"AVENIDA" >> lexicon.csv:"1","AVENIDA",2,"AVENIDA" >> >> I do not remember the details of how to set this up, but I think it is >> in the documentation. A few years ago I modified my versions of these >> files to add tokens I found in the Canadian data and maybe some I found >> in the Tiger data that were not included. I believe I submitted them at >> the time. >> >> Regardless, I think pagc should be able to handle "Avenida Alberto" >> without a problem. If not, you might create a shapefile with just that >> street in it and attach it to a bug report with some details of you >> setup, like software version, directory structure, how to reproduce the >> failure, etc >> >> Thanks, >> -Steve W >> >> On 1/14/2011 2:28 PM, Bill Harbour wrote: >>> We have a street called Avenida Alberto. I fixed it in ArcGIS by putting >>> Ave in Pre-Type and Alberto in the street name. Once a locator is built, >>> ArcGIS parses it properly and finds it. >>> >>> But, I've had no luck in PAGC doing the same (Ave in PRETYPE, Alberto in >>> FENAME). Any suggestions?? >>> >>> Thanks, >>> >>> Baldwin County Public Schools >>> >>> Bill Harbour >>> >>> GIS Coordinator >>> >>> Information Technology Services >>> >>> Baldwin County Board of Education >>> >>> 1071**** B Ave >>> >>> Loxley , AL 36551 >>> >>> V 251-580-1916 >>> >>> F 251-972-6851 >>> >>> Office 251-972-6850 >>> >>> bha...@bc...<mailto:bha...@bc...> >>> >>> http://www.bcbe.org >>> >>> //"When life gets too unreal, sit down with a good book." // - Garrison >>> Keillor >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. Understand >>> malware threats, the impact they can have on your business, and how you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> >>> >>> >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Pagc-devel mailing list Pag...@li... https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Dan P. <dan...@sa...> - 2011-01-18 17:52:35
|
Hi Bill, Is Avenida Alberto the only street in your service area that is done this way? My guess is there may be other streets in housing developments built around the same time that have this problem. If there are, you might want to think about augmenting the centerline road data with parcel address points to address the problem. Dan On 01/18/2011 07:43 AM, Bill Harbour wrote: > Steve and others. It turns out that PAGC is properly parsing the street name of Avenida Alberto. The culprit is how the segments for that street are addressed....there is no parity. Addresses were based on lot numbers and make no sense. These addresses were issued way before the County went digital and the person issuing them had now idea of what they were doing. PAGC finds the addresses for the beginning and ending segments, but nothing in between. > > Thanks for the help!! > > Baldwin County Public Schools > Bill Harbour > GIS Coordinator > Information Technology Services > Baldwin County Board of Education > 1071 B Ave > Loxley, AL 36551 > V 251-580-1916 > F 251-972-6851 > Office 251-972-6850 > bha...@bc... > http://www.bcbe.org > "When life gets too unreal, sit down with a good book." - Garrison Keillor > > -----Original Message----- > From: whi...@de... [mailto:whi...@de...] > Sent: Tuesday, January 18, 2011 2:51 AM > To: pag...@li... > Subject: Re: [Pagc-devel] Parsing an unusual road name. > > Hi Bill, Steve : Hopefully things are working now with this. If not, and > if you build with the -l option on the command line, there should be an > entry in the error log if PAGC was unable to standardize it. There is also > a utility included in the installer that allows you to test > standardization for individual addresses. > Thanks,<= walter => > >> Steve: >> >> I'm assuming I have the standard file where PAGC can find >> them...everything else seems to be geocoding propery. >> >> But I'll start there to see if I can get things to work, and will submit a >> bug report if I fail. >> >> Tnx, >> >> Baldwin County Public Schools >> Bill Harbour >> GIS Coordinator >> Information Technology Services >> Baldwin County Board of Education >> 1071 B Ave >> Loxley, AL 36551 >> V 251-580-1916 >> F 251-972-6851 >> Office 251-972-6850 >> bha...@bc... >> http://www.bcbe.org >> "When life gets too unreal, sit down with a good book." - Garrison Keillor >> >> -----Original Message----- >> From: Stephen Woodbridge [mailto:wo...@sw...] >> Sent: Friday, January 14, 2011 2:50 PM >> To: pag...@li... >> Subject: Re: [Pagc-devel] Parsing an unusual road name. >> >> Bill, >> >> Do you have the standard files where pagc can find them? >> >> woodbri@mappy:~/work/pagc/pagc/branches/parseaddress$ ls data/standard/ >> featwords.csv gazeteer.csv lexicon.csv rules.txt >> >> woodbri@mappy:~/work/pagc/pagc/branches/parseaddress/data/standard$ grep >> AVENIDA * >> featwords.csv:"1","AVA",1,"AVENIDA" >> featwords.csv:"1","AVENIDA",1,"AVENIDA" >> lexicon.csv:"1","AVA",2,"AVENIDA" >> lexicon.csv:"1","AVENIDA",2,"AVENIDA" >> >> I do not remember the details of how to set this up, but I think it is >> in the documentation. A few years ago I modified my versions of these >> files to add tokens I found in the Canadian data and maybe some I found >> in the Tiger data that were not included. I believe I submitted them at >> the time. >> >> Regardless, I think pagc should be able to handle "Avenida Alberto" >> without a problem. If not, you might create a shapefile with just that >> street in it and attach it to a bug report with some details of you >> setup, like software version, directory structure, how to reproduce the >> failure, etc >> >> Thanks, >> -Steve W >> >> On 1/14/2011 2:28 PM, Bill Harbour wrote: >>> We have a street called Avenida Alberto. I fixed it in ArcGIS by putting >>> Ave in Pre-Type and Alberto in the street name. Once a locator is built, >>> ArcGIS parses it properly and finds it. >>> >>> But, I've had no luck in PAGC doing the same (Ave in PRETYPE, Alberto in >>> FENAME). Any suggestions?? >>> >>> Thanks, >>> >>> Baldwin County Public Schools >>> >>> Bill Harbour >>> >>> GIS Coordinator >>> >>> Information Technology Services >>> >>> Baldwin County Board of Education >>> >>> 1071**** B Ave >>> >>> Loxley , AL 36551 >>> >>> V 251-580-1916 >>> >>> F 251-972-6851 >>> >>> Office 251-972-6850 >>> >>> bha...@bc...<mailto:bha...@bc...> >>> >>> http://www.bcbe.org >>> >>> //"When life gets too unreal, sit down with a good book." // - Garrison >>> Keillor >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. Understand >>> malware threats, the impact they can have on your business, and how you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> >>> >>> >>> _______________________________________________ >>> Pagc-devel mailing list >>> Pag...@li... >>> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel >> > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: Bill H. <bha...@bc...> - 2011-01-18 15:43:31
|
Steve and others. It turns out that PAGC is properly parsing the street name of Avenida Alberto. The culprit is how the segments for that street are addressed....there is no parity. Addresses were based on lot numbers and make no sense. These addresses were issued way before the County went digital and the person issuing them had now idea of what they were doing. PAGC finds the addresses for the beginning and ending segments, but nothing in between. Thanks for the help!! Baldwin County Public Schools Bill Harbour GIS Coordinator Information Technology Services Baldwin County Board of Education 1071 B Ave Loxley, AL 36551 V 251-580-1916 F 251-972-6851 Office 251-972-6850 bha...@bc... http://www.bcbe.org "When life gets too unreal, sit down with a good book." - Garrison Keillor -----Original Message----- From: whi...@de... [mailto:whi...@de...] Sent: Tuesday, January 18, 2011 2:51 AM To: pag...@li... Subject: Re: [Pagc-devel] Parsing an unusual road name. Hi Bill, Steve : Hopefully things are working now with this. If not, and if you build with the -l option on the command line, there should be an entry in the error log if PAGC was unable to standardize it. There is also a utility included in the installer that allows you to test standardization for individual addresses. Thanks, <= walter => > Steve: > > I'm assuming I have the standard file where PAGC can find > them...everything else seems to be geocoding propery. > > But I'll start there to see if I can get things to work, and will submit a > bug report if I fail. > > Tnx, > > Baldwin County Public Schools > Bill Harbour > GIS Coordinator > Information Technology Services > Baldwin County Board of Education > 1071 B Ave > Loxley, AL 36551 > V 251-580-1916 > F 251-972-6851 > Office 251-972-6850 > bha...@bc... > http://www.bcbe.org > "When life gets too unreal, sit down with a good book." - Garrison Keillor > > -----Original Message----- > From: Stephen Woodbridge [mailto:wo...@sw...] > Sent: Friday, January 14, 2011 2:50 PM > To: pag...@li... > Subject: Re: [Pagc-devel] Parsing an unusual road name. > > Bill, > > Do you have the standard files where pagc can find them? > > woodbri@mappy:~/work/pagc/pagc/branches/parseaddress$ ls data/standard/ > featwords.csv gazeteer.csv lexicon.csv rules.txt > > woodbri@mappy:~/work/pagc/pagc/branches/parseaddress/data/standard$ grep > AVENIDA * > featwords.csv:"1","AVA",1,"AVENIDA" > featwords.csv:"1","AVENIDA",1,"AVENIDA" > lexicon.csv:"1","AVA",2,"AVENIDA" > lexicon.csv:"1","AVENIDA",2,"AVENIDA" > > I do not remember the details of how to set this up, but I think it is > in the documentation. A few years ago I modified my versions of these > files to add tokens I found in the Canadian data and maybe some I found > in the Tiger data that were not included. I believe I submitted them at > the time. > > Regardless, I think pagc should be able to handle "Avenida Alberto" > without a problem. If not, you might create a shapefile with just that > street in it and attach it to a bug report with some details of you > setup, like software version, directory structure, how to reproduce the > failure, etc > > Thanks, > -Steve W > > On 1/14/2011 2:28 PM, Bill Harbour wrote: >> We have a street called Avenida Alberto. I fixed it in ArcGIS by putting >> Ave in Pre-Type and Alberto in the street name. Once a locator is built, >> ArcGIS parses it properly and finds it. >> >> But, I've had no luck in PAGC doing the same (Ave in PRETYPE, Alberto in >> FENAME). Any suggestions?? >> >> Thanks, >> >> Baldwin County Public Schools >> >> Bill Harbour >> >> GIS Coordinator >> >> Information Technology Services >> >> Baldwin County Board of Education >> >> 1071**** B Ave >> >> Loxley , AL 36551 >> >> V 251-580-1916 >> >> F 251-972-6851 >> >> Office 251-972-6850 >> >> bha...@bc... <mailto:bha...@bc...> >> >> http://www.bcbe.org >> >> //"When life gets too unreal, sit down with a good book." // - Garrison >> Keillor >> >> >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> >> >> >> _______________________________________________ >> Pagc-devel mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagc-devel > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Pagc-devel mailing list Pag...@li... https://lists.sourceforge.net/lists/listinfo/pagc-devel |
|
From: <whi...@de...> - 2011-01-18 09:07:03
|
Hi Steve : I've added some comments below. Thanks, <= walter => > Hi Walter, > > I tried to build the datastore branch, which I know you have not > released yet. So feel free to stop reading here if you want. > > I started in ds: > > 1. I was able to run: > cd pagc/branches/datastore/ds > ./configure --with-norm=s --with-raw=d --with-sch=d --with-cache=f > > make failed looking for sqlite3.c which is not checked into svn I've added sqlite3.c and the header. The configuration uses the amalgamation approach (see README in ds for more details). I'm not sure whether we should include it in our tree or not. > > 2. Tried to build the default version with: > ./configure > > This failed with erroneous message about not finding getcwd, this was > due to not finding -lws2_32. I commented out line 257 in configure.ac: > > # LIBS="$LIBS -lws2_32" > This flag, for winsockets, was needed to get Berkeley 4.5 to work on mingw. It isn't a permanent resident of that file. > Also configure.ac is hard coded to use the Oracle source release of > Berkeley DB 4.5 installed in /usr/local/Berkeley.... Again, that isn't permanent. > > I downloaded and installed that and was able to get past that issue. > > ./configure > make > sudo make install > > worked. > > 3. Next tried to build and install pagclib > > cd ../pagclib > ./configure > make > > # this errored out, uninstalled the old copy of pagc and > # was able to get further > > In file included from candform.c:22: > pagc.h:513: error: expected specifier-qualifier-list before > 'pthread_mutex_t' > make: *** [libpagc_la-candform.lo] Error 1 > > make clean > ./configure --disable-threads > # this worked > make > ... > make: *** No rule to make target `select.c', needed by > `libpagc_la-select.lo'. Stop. > > 'select.c' is not checked in to svn in branches/datastore/pagclib. > No, select.c won't be in this version. > Stopped here because I was not sure I could just copy one from landmarks > and it would be compatible with the ds code. > > So all-in-all, it is looking pretty good. These all seem like minor > issues that you have not gotten around to cleaning up yet. I was hoping > that I could test my zipcode problem with this code, but it looks like > I'll have to wait on that until you are feeling better. > > Best regards, > -Steve > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pagc-devel mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagc-devel > |
16 messages has been excluded from this view by a project administrator.
