#mapnik log: Saturday 28, February 2009

2009 | 02

previous | next
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