00:13:11 *** scruggs__ (n=chris@72-161-105-25.dyn.centurytel.net) has joined #mapnik 00:14:15 *** scruggs has quit (Read error: 110 (Connection timed out)) 00:57:56 *** kd has quit (Nick collision from services.) 00:58:10 *** kdl (n=kd@78-86-162-74.zone2.bethere.co.uk) has joined #mapnik 01:29:35 *** racicot has quit (Remote closed the connection) 02:55:37 *** dukeku_ (i=dukeku@adhd.irule.net) has joined #mapnik 02:56:32 *** dukeku has quit (brown.freenode.net irc.freenode.net) 03:07:29 *** migurski has quit () 03:48:09 *** racicot (n=chatzill@dsl-209-166-85-189.whidbey.net) has joined #mapnik 03:57:05 *** rcoup (n=rcoup@westplaza-gk2.knossos.net.nz) has joined #mapnik 04:04:15 *** scruggs__ is now known as scruggs 04:06:44 *** rcoup has quit () 05:23:10 *** D3f0 (n=defo@190.176.219.193) has joined #mapnik 05:39:50 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik 06:14:38 *** D3f0 has quit (Remote closed the connection) 06:46:44 *** w0lfie_ has quit (Read error: 110 (Connection timed out)) 07:00:43 *** Mrfo has quit ("(Deviant 1.0)") 07:41:18 *** aura (n=wolf@cpe-67-49-133-78.hawaii.res.rr.com) has joined #mapnik 08:16:20 *** aura is now known as w0lfie_ 09:33:39 *** migurski has quit () 10:48:57 <w0lfie_> I'm trying to get mapnik's wms working. Right now i'm getting an error that image/png is an unknown format. image/jpeg returns a black image. 13:46:09 *** jburgess_ (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik 14:02:19 *** ser has quit ("Changing server") 14:02:19 *** jburgess has quit (Read error: 110 (Connection timed out)) 14:16:21 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik 14:20:01 *** ser has quit (Client Quit) 14:22:29 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik 16:00:01 *** D3f0 (n=defo@190.176.219.193) has joined #mapnik 16:33:43 *** __d3f0__ (n=defo@190.176.219.193) has joined #mapnik 16:48:13 *** D3f0 has quit (Read error: 110 (Connection timed out)) 17:27:40 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik 18:37:05 *** __d3f0__ has quit (Remote closed the connection) 18:56:47 *** adakkak (n=adakkak@gres110.lis.illinois.edu) has joined #mapnik 18:57:24 <adakkak> are there bindings for java in mapnik? 19:04:26 *** migurski has quit () 19:05:03 <nikq> Mapnik Trac: Ticket #253 (crash in libagg when rendering extremely long lines) created | http://trac.mapnik.org/ticket/253 19:06:14 <nikq> Mapnik Trac: agg-fix-recursion-crash.patch attached to Ticket #253 | http://trac.mapnik.org/attachment/ticket/253/agg-fix-recursion-crash.patch 19:16:59 <nikq> Mapnik Trac: Ticket #253 (crash in libagg when rendering extremely long lines) updated | http://trac.mapnik.org/ticket/253#comment:1 19:38:25 *** D3f0 (n=defo@190.176.219.193) has joined #mapnik 20:00:07 *** migurski (n=migurski@m201-210.dsl.tsoft.com) has joined #mapnik 20:00:28 *** migurski has quit (Client Quit) 20:43:00 <w0lfie_> Hi I'm trying to get mapnikwms working. Having an issue with common.py's GetMap function throwing a 'unknown format: image/png' error. image/jpg returns a black image 20:48:41 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik 20:49:00 <w0lfie_> Anyway this is the error -> http://tinyurl.com/cu373b 20:49:19 <springmeyer> w0lfie_: its a bug in 0.5.1, upgrading to trunk will fix it 20:49:24 <w0lfie_> ah 20:49:29 <springmeyer> is that possible for you? (running trunk) 20:49:36 <w0lfie_> yeah i dont care what version I use 20:49:44 <springmeyer> r714 20:49:44 <nikq> http://trac.mapnik.org/changeset/714, at , by dave: Fix the OGCServer (would always throw invalid image format errors) 20:50:28 <springmeyer> w0lfie_: I've also been working on a few fixes to the OGCServer recently, so I recommend trunk for the OGCServer 20:50:34 <w0lfie_> okay 20:50:40 <w0lfie_> thanks 20:50:56 <springmeyer> w0lfie_: np, are you running as cgi? 20:51:09 <w0lfie_> mod_fcgid 20:51:44 <w0lfie_> is there a faster way to run it? 20:51:56 <springmeyer> k. sounds good. the wsgi setup is not documented yet but I find it very useful 20:52:11 <w0lfie_> okay, i'll try to get it working first then look at that ;) 20:52:27 <w0lfie_> even just with this it seems perfectly fast 20:52:39 <w0lfie_> granted its returning error tiles ;) 20:52:50 <springmeyer> heh 20:52:57 <springmeyer> I find wsgi best since 20:53:06 <springmeyer> since any application that meets the wsgi spec can be run as a local httpd process in python or emdedded in apache using mod_wsgi 20:53:17 <springmeyer> and mod_wsgi should be the fastest 20:53:21 <w0lfie_> right 20:54:21 <springmeyer> a script like this is all you need to use to kick off the wms server mounted at http://localhost:8000 20:54:23 <springmeyer> http://mapnik-utils.googlecode.com/svn/example_code/wms/localogc.py 20:54:40 <springmeyer> which I use to develop before deploying with mod_wsgi 20:54:55 <w0lfie_> I found the mapnikwms one after trying a number of other methods that.. seemed to refer to older ways of doing it 20:56:39 <springmeyer> ya, that one is simply legacy from the first time I set up the OGCServer 20:56:56 * springmeyer needs to do some spring cleaning 20:57:04 <w0lfie_> how appropriate.. 20:57:33 <w0lfie_> yeah i actually had downloaded the trunk last night but i fell asleep waiting for all the dependencies to install 20:58:11 <w0lfie_> since I made that one change to common.py related to um.. rawdata I think; I figured there could be other changes 20:58:47 <springmeyer> yes. trunk fixes the rawdata and image problems 20:59:47 <springmeyer> w0lfie_: dependencies shouldn't take that long :) 20:59:54 <springmeyer> just apt-get em all 20:59:58 <springmeyer> what platform? 21:00:30 <w0lfie_> lenny 21:00:42 <springmeyer> okay. cool 21:00:55 * springmeyer is about to commit a fix to trunk for lenny 21:00:57 <w0lfie_> nah it doesnt i was just exhausted 21:01:05 <springmeyer> for finding gdal 21:01:43 <springmeyer> w0lfie_: mind waiting for 21:02:00 <springmeyer> 5 minutes till you rebuild from trunk? 21:02:08 <w0lfie_> oh im installing dependencies 21:02:09 <w0lfie_> take your time 21:02:14 <springmeyer> cool 21:04:16 <w0lfie_> yeah i was just looking for a WMS to use for some layers in a flex app 21:09:06 <springmeyer> right on 21:09:29 <w0lfie_> im actually using the esri flex api haha 21:09:39 <w0lfie_> but i added wms support to it, so i can use it with whomever 21:10:14 <springmeyer> right on :) 21:11:03 <w0lfie_> but this is actually for a nonprofit, but if it works pretty fast i was thinking of trying it at work 21:11:35 <springmeyer> nice 21:11:51 <springmeyer> w0lfie_: what does 'gdal-config --libs' give you on lenny? 21:14:22 <w0lfie_> i'll let you know in a bit, its installing stuff 21:18:38 <nikq> Mapnik Trac: Changeset [977]: scons: switch to using pg_config and gdal-config for checking and adding ... | http://trac.mapnik.org/changeset/977 21:21:53 *** springmeyer has quit () 21:24:07 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik 21:28:44 <w0lfie_> -L/usr/lib -lgdal1.5.0 21:31:35 *** adakkak has quit ("Ex-Chat") 21:33:34 *** D3f0 has quit (Remote closed the connection) 21:39:03 <CIA-23> mapnik-utils: cmarqu42 * r575 /sandbox/cascadenik/hike_n_bike/ (46 files in 4 dirs): Render some of the way symbols in the Dresdner Heide. 21:39:04 <CIA-23> mapnik-utils: dane.springmeyer * r576 /example_code/wms/ (localogc.py openlayers_osm.html): 21:43:55 *** D3f0 (n=defo@190.176.219.193) has joined #mapnik 21:49:35 <nikq> Mapnik Trac: UsingScons edited | http://trac.mapnik.org/wiki/UsingScons?version=9 21:54:45 <jburgess_> springmeyer: I get an error with the latest code, seems to be because "gdal-config --libs" returns only '-lgdal' 21:55:20 <springmeyer> jburgess_: thanks, yes I am working on it now 21:55:32 <w0lfie_> compiling away over here 21:55:40 <springmeyer> I assumed thate gdal-config behaved just like xml2-config and freetype-config 21:55:45 <springmeyer> but surely does not 21:56:06 <springmeyer> "gdal-config --libs --cflags" returns only '-lgdal' 21:56:23 <w0lfie_> I get -lgdal1.5.0 21:56:28 <jburgess_> I think it does, but it assumes the /usr/lib is already in the default path so it does not include the -L... 21:56:29 <springmeyer> right 21:56:36 <w0lfie_> and -L/usr/lib 21:56:49 <jburgess_> none of those other 'configs return a -L... for me either 21:57:04 <w0lfie_> same 21:57:11 <jburgess_> because all the libs I have are standard OS installed ones rather than /usr/local custom installs 21:57:25 <w0lfie_> my gdal is the packaged one 21:57:26 <springmeyer> scons ParseConfig is looking for the -I/usr/include/gdal 21:57:42 <springmeyer> xml2-config and freetype-config return that on a second line 21:57:45 <w0lfie_> scons found all my libs - once i had them installed anyway 21:57:55 <jburgess_> again, I suspect that if the headers are in "/usr/include" then it won't bother to include that 21:58:06 <w0lfie_> yeah 21:58:10 <jburgess_> since those are in the default compiler / linker paths 21:58:17 <w0lfie_> i don't know why my gdal-config returns -L/usr/lib 21:58:43 <springmeyer> hmmm, so -I/usr/include/gdal would be in the default linker path? 21:58:55 <springmeyer> I figure only -I/usr/include 21:59:07 <springmeyer> would be... 21:59:09 <jburgess_> no, but /usr/include should be 21:59:24 <jburgess_> if the files are in the /gdal subdir then it should probably print that 21:59:44 <jburgess_> I get: -I/usr/include/gdal/ 22:00:12 <w0lfie_> -I/usr/include/gdal 22:00:12 <springmeyer> with 'gdal-config --libs --cflags' ? 22:00:39 <w0lfie_> hm 22:00:48 <w0lfie_> actually 22:00:58 <w0lfie_> with gdal-config --libs --cflags i get -L/usr/lib -lgdal1.5.0 22:01:18 <w0lfie_> it only processes the first arg 22:01:19 <jburgess_> "gdal-config --cflags --libs" seems to be broken 22:01:30 <jburgess_> it only seems to want to give the answer to the first argument 22:01:33 <w0lfie_> you have to run --cflags and --libs separate 22:01:33 <w0lfie_> yeah 22:01:39 <springmeyer> yes, seems so 22:02:20 <jburgess_> I was wondering why we go to the trouble of trying to split the strings instead of just having one set of cflags & another for libs 22:02:30 <jburgess_> let me rephrase that 22:02:46 <jburgess_> why do we try splitting up the --libs output into the -l, & -L ? 22:02:56 <jburgess_> why not just keep it all? 22:03:16 <jburgess_> for non standard directories you will need both parts 22:03:57 <springmeyer> hmm, in this case (with this change from using gdal-config instead of GDAL_LIBS and GDAL_INCLUDES) we are simply letting the scons 'ParseConfig' function grab both 22:04:16 <jburgess_> ok 22:04:21 <springmeyer> which avoids use needing to specify them separately and check them separately 22:04:28 <springmeyer> use/us 22:04:44 <jburgess_> I was wondering if it was some misguided attempt to control the ordering when you've got some libraries in two dirs, e.g. /usr/lib & /usr/local/lib 22:05:26 <springmeyer> well, that is surely an issue I could use advice with ^^^ (but in this case I'm letting scons handle things) 22:05:29 <jburgess_> in general, if you've got copies of some libraries in both, you can only reliably pick one or the other to take preference, 22:05:35 *** audifahrer (n=andreas@p57AF59D5.dip.t-dialin.net) has joined #mapnik 22:05:40 <audifahrer> Hello 22:06:43 <jburgess_> it is fine to have both directories in the search path, but then don't be surprised when it always prefers to take the libs from one dir in preference. 22:06:57 <springmeyer> right, jburgess_ so say we have sqlite libs by the same name in both /usr/lib and /usr/local/lib what is the best practice for which should take precendence? 22:07:17 <w0lfie_> /usr/local/lib should take precedence 22:07:24 <jburgess_> no 22:07:38 <jburgess_> well, I'm not so sure 22:07:41 <crschmidt> no? i believe that as well... 22:08:00 <crschmidt> /usr/lib ill have my debian stuff, which is old. then /usr/local/lib will have the newer ones i installed from source 22:08:04 <audifahrer> any ideas where the difference between map::query_point and map::query_map_point? 22:08:06 <jburgess_> I would have said that the default stance would be to prefer the system installed ones, and force the user to specifiy if he wants to use /usr/local/... 22:08:32 <jburgess_> but on the other hand, the default stance for installation is the opposite, to install into /usr/local unless the user forces the opposite 22:08:48 <w0lfie_> it seems to me that typically if you bothered to install libs yourself, you'd want to link against those 22:09:20 <jburgess_> in which case, why is it that default OS installs never include /usr/local/lib in the search path? 22:09:43 <jburgess_> it seems there they seem to believe you only get /usr/local/lib when you really ask for it 22:10:06 * springmeyer listens... 22:10:40 <jburgess_> I don't know, but I guess there may be some wisdom in either the LSB, some distro packagin guidelines, or the default behaviour of other tools 22:11:08 <jburgess_> I think you avoid this issue though if you stick to pkg-config / app-config etc 22:11:28 <w0lfie_> well that typically gives you an -L which overrides env vars 22:11:28 <jburgess_> then you get to link in whatever they tell you 22:11:45 <w0lfie_> i don't know what precedence for multiple -L's is though 22:11:57 <jburgess_> that is what I was getting at earlier 22:12:25 <jburgess_> as soon as you've got multiple -L's, don't expect predictable behaviour if you have similar libraries in both paths 22:12:57 <w0lfie_> according to the ld documentation, -L directories are searched in the order specified 22:13:52 <jburgess_> right, but then it depends on SConstruct etc as to which order it places the output of the various pkg-config results 22:14:32 <w0lfie_> what was the original problem again? 22:14:35 <springmeyer> right 22:14:38 <w0lfie_> i.e. why do we care about this 22:15:05 <springmeyer> 'say we have sqlite libs by the same name in both /usr/lib and /usr/local/lib' ... 22:15:09 <w0lfie_> oh right 22:15:21 <springmeyer> should scons try to let you link to one first? 22:15:31 <springmeyer> should scons even pay attention? 22:15:43 <springmeyer> (by scons here I mean our use of scons to build mapnik) 22:15:57 <w0lfie_> maybe tell you it's found more than one and ask you to choose? 22:16:30 <springmeyer> that would be quite a bit more code that we currently have 22:16:45 <w0lfie_> yeah disregard that 22:17:09 <jburgess_> In part, this is why average users should generally avoid self-compiled stuff and stick to distro packages if they want everything to run consistently 22:17:38 <springmeyer> yes 22:17:40 <springmeyer> :) 22:17:49 <w0lfie_> one way to handle this is to allow the compiler to specify the explicit path to the -config file in question 22:17:51 <springmeyer> which is what brought me to this issue this morning... 22:17:56 <w0lfie_> by which i mean the person compiling 22:18:17 <w0lfie_> XML_CONFIG=/usr/local/bin/xml-config, etc 22:18:18 <springmeyer> that the apt-get install of gdal creates a lib named 'gdal1.5.0' not gdal so scons bails :) 22:18:43 <springmeyer> unless we use 'gdal-config' 22:19:05 <w0lfie_> well the packaged version doesn't provide a libgdal.so, so it shouldn't advertise gdal 22:19:55 <springmeyer> right, and we were hardcoding the addition of 'lgdal' in scons previously 22:19:57 <w0lfie_> blame gdal for changing their interface so much ;) 22:21:05 <springmeyer> naw, is'nt is just packagers on debian doing wise things to allow the install of multiple versions of gdal? 22:21:16 <w0lfie_> i'm just joking ;) 22:21:27 <springmeyer> ah, :) 22:21:49 <w0lfie_> i still get that error hm 22:22:06 <w0lfie_> i probably did something wrong 22:22:54 <springmeyer> svn up now 22:22:57 <springmeyer> and try again 22:22:58 <nikq> Mapnik Trac: Changeset [978]: scons: gdal-config does not predicatably return config arguments when ... | http://trac.mapnik.org/changeset/978 22:23:21 <w0lfie_> lyr.datasource = obj.datasource => unknown format image/png 22:23:58 <springmeyer> ah, I thought you were talking about the gdal error during the build 22:24:11 <w0lfie_> no i never experienced that error 22:24:22 <springmeyer> okay, can you paste your whole error? 22:24:36 <audifahrer> could one please provide some documentation for the map::query_point and map::query_map_point call? 22:24:40 <w0lfie_> http://tinyurl.com/cu373b 22:25:03 <w0lfie_> should i not be using mapnikwms anymore? 22:25:31 <springmeyer> audifahrer: 22:25:32 <springmeyer> >>> from mapnik import Map 22:25:32 <springmeyer> >>> help(Map) 22:26:02 <springmeyer> oh wait: audifahrer you likely are not running trunk.... 22:26:40 <springmeyer> audifahrer: http://dpaste.com/3544/ 22:27:47 <springmeyer> okay jburgess_ : r978 fixes the bug i introduced in the previous switch to gdal-config for me on lenny 22:27:48 <nikq> http://trac.mapnik.org/changeset/978, at , by dane: scons: gdal-config does not predicatably return config arguments when multiple are requested, so call twice 22:28:01 <springmeyer> does it work for you now? 22:28:42 <jburgess_> no I still get the same error: details['lib'] = lib_result.split(' ')[1].lstrip('-l') 22:28:55 <jburgess_> since it is still looking to split a string on space, and there is none 22:29:11 <jburgess_> line 584 22:29:59 <audifahrer> springmeyer: sure I'm running trunk, but only looking at the C++ code. 22:30:04 <springmeyer> whew, sorry that would be a different error than I was seeting 22:30:14 <jburgess_> for me: $ gdal-config --libs ==> -lgdal 22:30:29 <springmeyer> k 22:30:36 <jburgess_> hence my questioning why we're trying to split the string instead of just taking all of it 22:30:43 <springmeyer> right, which will blow apart 22:30:48 <springmeyer> sorry, missed that 22:31:10 <springmeyer> okay, so, now I'm on the same page 22:31:28 <springmeyer> so, 1) I should switch to regex there 22:31:31 <jburgess_> do you try to remove the '-l' and then add it back later? 22:31:41 <springmeyer> but 2) the reason is I need to get the lib name back 22:31:56 <springmeyer> to be able to tell if we should build the plugin 22:32:17 <jburgess_> don't you just want to find something other than "none" ? 22:32:24 <springmeyer> and then in the /gdal/SConscript we need to know the lib name again to add it to a list of libs that scons needs 22:33:04 <jburgess_> what if the output is something like: -L/my/magical/version -lgdal1.4.0 22:33:17 <jburgess_> will the -L bit get preserved anywhere, or will it get lost? 22:33:48 <springmeyer> so, first conf.parse_config() pulls out the -lgdal1.4.0 22:33:52 <audifahrer> springmeyer: oh I see there's much more documented for python. I think nobody will complain if I add more docs for C++ :-) 22:34:05 <springmeyer> then I call it again to pull out the '-I' 22:34:18 <springmeyer> and then separately call gdal-config to get 'gdal1.4.0' 22:34:28 <springmeyer> audifahrer: awesome :) 22:35:02 <springmeyer> jburgess_: the -L if it exists should get sucked up by conf.parse_config (but I've not confirmed that) 22:35:30 <jburgess_> ok, I was wanting to check, after all it is just as important in the whole linker process as the -l part 22:36:01 <jburgess_> no good knowing what the library is called if you don't know which directory to go looking for it! 22:36:14 <springmeyer> :) got it! 22:36:37 * springmeyer is trusting the magic of scons's ParseConfig option to handle all that 22:37:16 <springmeyer> but I agree that I may be looking at more bugs specific to gdal-config if the behavior is non-standard 22:37:31 <jburgess_> this may not apply to gdal, but sometimes I think you see multiple -l's in the --libs output 22:37:48 <crschmidt> yes 22:38:04 <audifahrer> springmeyer: do you think x/y is a geo coordinat like lat/lon in the choosen map format? 22:38:11 <springmeyer> yes, ie (-L/opt/local/lib -lxml2 -lz -lpthread -liconv -lm) returned from xml2-config --libs 22:38:39 * springmeyer is pretty confident that ParseConfig handles that fine 22:38:56 <springmeyer> audifahrer: that would be my hunch, yes 22:39:22 <jburgess_> ok, I just thought I'd mention it in case you though you would only ever find a single -l option 22:39:43 <audifahrer> and whats "index"? 22:40:04 <springmeyer> okay. thanks 22:40:19 <audifahrer> ah, the layer index 22:40:24 <springmeyer> audifahrer: integer cooresponding to the layer 22:40:25 <springmeyer> right 22:40:27 <jburgess_> I have a feeling that with modern linkers on Linux at least, those extra ones are generally redundant. The linker figures out that libxml2 depends on lz, lm and they get pulled in automatically 22:41:13 <springmeyer> yes, makes sense 22:41:18 <springmeyer> it is here: http://trac.mapnik.org/browser/trunk/plugins/input/gdal/SConscript#L34 22:41:20 <w0lfie_> yes as long as it can find that dependency 22:41:33 <audifahrer> springmeyer: it's all so easy if documented. If I had a big wish that the one that every developer who ever writes code should document the API. :-) 22:41:48 <springmeyer> where we were previously hardcoding ... libraries = ['gdal'] 22:42:04 <jburgess_> and every user which asks a question should document the answer on the wiki :) 22:42:14 <w0lfie_> can i have world peace too 22:43:46 <springmeyer> audifahrer: are you offering to sponser documentation? ;) 22:44:11 <audifahrer> springmeyer: :-) 22:44:33 <w0lfie_> hm, doesnt even make sense - why do i get a format error when copying an object to a layer 22:45:06 <audifahrer> springmeyer: no I'll try to add them after each new call that I understood 22:45:18 <springmeyer> w0lfie_: have you restarted apache? 22:46:06 <w0lfie_> oh :P 22:46:09 <w0lfie_> thanks 22:46:29 <w0lfie_> hooray 22:46:41 <w0lfie_> http://oreo.entropy.net/wms/openlayers.html 22:46:53 <springmeyer> nice 22:46:58 <w0lfie_> i'd say that's pretty quick 22:47:11 <w0lfie_> it's running on a shitty xen box too 22:48:06 <audifahrer> the only difference between the two calls is "...of map projection." and "...f the pixmap or map surface.". Sorry I still don't see the difference when and why to use which one. 22:48:28 <springmeyer> so, regex is not my best card... 22:49:05 <springmeyer> to pull out gdal0.5.0 ... from: '-L/usr/local/lib -lgdal0.5.0' 22:49:29 <springmeyer> anyone have suggestions? 22:50:10 <springmeyer> audifahrer: the latter is in the coordinates of the non-protected graphic 22:50:27 <jburgess_> echo "'-L/usr/local/lib -lgdal0.5.0" | perl -pe 's/.*-l([^\s])/\1/' 22:50:27 <springmeyer> but, I agree that the wording could be improved there! 22:50:31 <jburgess_> gdal0.5.0 22:51:10 <springmeyer> rockin... thx! 22:51:31 <jburgess_> um.. not quite as I intended, it keeps stuff after the end 22:51:55 <jburgess_> I was trying to make the match end at the first whitespace character 22:55:16 <jburgess_> echo "-L/usr/local/lib -lgdal0.5.0 foo" | perl -pe 's/.*-l([^\s]*).*/\1/' 22:56:09 <jburgess_> that should work OK. I forgot the repeat and the stuff after the string 22:57:17 <jburgess_> interestingly, if there is more than one -l then it seems to give you the last one on the line 22:57:27 <jburgess_> I'm not sure this matters in this case though 22:57:56 *** springmeyer has quit () 23:08:16 *** D3f0 has quit (Read error: 60 (Operation timed out)) 23:08:33 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik 23:12:06 * springmeyer back 23:12:24 <springmeyer> hey jburgess_ : thx, this works in python... 23:12:29 <springmeyer> >>> pattern = r'\s.*-l([^\s]*).*\s' 23:12:29 <springmeyer> >>> re.findall(pattern, "-L/usr/local/lib -lgdal0.5.0 foo ") 23:12:45 <jburgess_> ok, cool 23:13:32 <jburgess_> as I mentioned above, this will give you the last -l on the line, but this is Ok for this example. 23:14:32 <springmeyer> yes, I think we'll be fine, but I will try to test the result of gdal-config --libs on a few more systems 23:15:05 <jburgess_> I don't think you want the \s on the front and rear 23:15:19 <springmeyer> k 23:15:19 <jburgess_> it won't work if there are no spaces, e.g. just "-lgdal" 23:16:19 <jburgess_> In fact it works fine with just: pattern = r'-l([^\s]*)' 23:16:46 <jburgess_> you even get an array back with multiple entries if you have multiple -l's 23:17:33 <springmeyer> ya, nice 23:17:38 <springmeyer> so should we even do... 23:17:40 <springmeyer> >>> pattern = r'-l(gdal[^\s]*)' 23:17:40 <springmeyer> >>> re.findall(pattern, "-L/usr/local/lib -lgdal0.5.0 -lgfoo") 23:17:41 <springmeyer> ['gdal0.5.0'] 23:18:27 <jburgess_> I guess that depends on whether we really only want ones with gdal in the name, if we do then that is fine 23:19:00 <springmeyer> k, ya in this case we just need the one name to link the gdal.input against 23:19:03 <jburgess_> but is a little less generic if you wanted to put this into some generic pkg-config output parsing routine. 23:20:08 <springmeyer> yes, I'll have to think about whether we'll end up needing to manually learn the lib name for other plugins 23:20:51 <jburgess_> $ pg_config --libs 23:20:57 <jburgess_> -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm 23:21:06 <springmeyer> I guess that will be the case if any systems/packagers also rename libpq and libsqlite by version 23:21:51 * springmeyer brb 23:38:21 <audifahrer> which one of the plugins would you suggest as example plugin to start a new one? 23:44:24 <audifahrer> bye 23:44:27 *** audifahrer has quit ("Verlassend") 23:55:08 <nikq> Mapnik Trac: Changeset [979]: scons: switch to regex to find and parse the (potentially custom) gdal ... | http://trac.mapnik.org/changeset/979 23:55:57 <springmeyer> okay, hopefully that works better across systems jburgess_ : thanks for your help so far