line 475.
all the best from deep in the South Pacific,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
ggest to use the mapsets' VAR file, not gisrc (g.gisenv),
to store per-mapset variables like that. Since gisrc is per-session
and ephemeral, not per-mapset and remembered after the session is
closed.
hope it helps,
Hamish
___
grass-dev maili
of fixing things which are not broken. e.g. WinGrass needs all
the time we can give to it to solve the last 2% of its problems.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Moritz wrote:
> Hamish and Frankie,
>
> What is the current status of packaging 6.4.4 for debian ?
Hi, sorry for the delay, I've been largely out of the office for the
last couple of weeks.
Mainly notes to Frankie, but may as well cc everyone to keep y'all in
the loop:
Hamish wrote:
> > yes, the old r.li.* daemon/worker system required unix sockets, and
> > so would only work in the cygwin build. We never figured out how to
> > properly support those natively on MS Windows.
Martin:
> r.li modules enabled in grass64 in r61153. Please test ne
author of r.li.* updates checked
>> also availability on Windows.
that's all of us; especially big jobs need many testers to check
all angles.
regards,
--
Hamish
.
Thought I should join the Yahoo mail diaspora before 30 days
worth of my emails got flushed from everyone's spa
n a osgeo trac ticket
please (LiveDVD component), cc 'hamish'.
>> Right, as far as I know Markus is off-line since 27/6. So let's start
>> with idea to mark RC2 as a final and release it _this_week_! I don't
>> know about any blockers. Any opinion? If you know
Mortiz wrote:
> How about my proposal from a few weeks ago: Nobody commits to
> grass64release, only to grass6dev, and Hamish is the official
> maintainer of grass64release and decides what can be backported ?
>
> This obviously can only work if Hamish has the time, so that 6.4.4
&
Hamish wrote:
> If it is useful to anyone I've just written an addon module which will
> let you export a grass raster map as a TMS tileset and uDig mapurl
> file ready to be copied into Geopaparazzi, which will then convert it
> to the MBTiles sqlite web tile database format. MB
the tiles.. many CPUs don't help if
you've already saturated the kernel %sys.
It's one day old and lightly tested; feedback is welcome.
regards,
--
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
don't do a 'svn commit' from the
top of the source tree it's harmless.
regards
--
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
lices as part of a raster3D import, when the import
data value for the raster is not the "z" column; see the r3.in.xyz.py module
for an example of how it is used. (unrelated, but I'd also note that the
parallelization method for z-level slice import in r3.in.xyz works out to be
su
king the previously installed
conflicting software). Of course with Linux rpm/deb package managed
system uninstalling and reinstalling typically does not change
anything, you usually would have more luck renaming away ~/.foorc/
and starting fresh that way.
Hamish
ps- wrt fubared email header ha
make sure everything gets
to where it needs to be for debian's particular rules (/var/lib/grass or
/usr/lib/grass). this is a lot cleaner in trunk already.
mv $GISBASE/etc/gui $GISBASE/
mv $GISBASE/etc/python $GISBASE/
seems ok to me. (although to be honest I don't really care)
I notic
Hamish wrote:
>> the grass website and wiki are both temporarily down due to a full disk.
>> Hope to
>> have it back up ASAP,it should be a quick fix after we figure out what's to
>> blame.
>
> ok, they are back up now.
what seems to have happened is
Hamish:
> the grass website and wiki are both temporarily down due to a full disk. Hope
> to
> have it back up ASAP,it should be a quick fix after we figure out what's to
> blame.
ok, they are back up now.
continued on the grass-d
Hi,
the grass website and wiki are both temporarily down due to a full disk. Hope
to have it back up ASAP,it should be a quick fix after we figure out what's to
blame.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
es
the command line on Windows, they will at some point run into the old
script-called-from-another-script problem.
?
regards,
Hamish
ps- this part of g.extension.py is fundamentally broken:
line = line.replace("%GISBASE%", "%GRASS_ADDON_PATH%") # options['prefix
line should probably
be category 0 or so, not the adjoining area's cat number for the "who does it
belong to?" reason above.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
as GSoC 2014 applications draw to a close, just a reminder for anyone wishing
to mentor to please sign up in melange ASAP. We already have a number of
interesting ideas to review.
thanks & regards,
Hamish
___
grass-dev mailing list
grass
ewhere in the middle is a nice balance point. :)
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
s been to ssh/putty in to the
server into a GNU Screen session, then have GRASS_PNGFILE=/var/www/map.png,
then just hit refresh in the web browser. works great for command line grass
junkies.
some ideas to think about where the end goal is and how/why that way would be
useful for end u
name() would
be best, but failing that, a white-list of allowed chars would
seem much more robust than a small black-list of disallowed
chars.
> Personally, I would prefer it if source code was 7-bit clean.
Me too. Not sure how to deal with non-ASCII chars in people's names though.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
> e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing
> anything wrt metadata that we could share development with?
see also deegree, qgis MetaSearch plugin, and the OSWLib library.
Hamish
___
grass-dev m
teams. is qgis doing
anything wrt metadata that we could share development with?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
o a search for e.g. XP but not Windows 8? (native
wingrass is all XP+ so none that I know of)
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
> >> note WinGRASS binaries are still 32 bit,
Helmut wrote:
> actually there is OSGeo4W-64bit ready for testing
> (http://trac.osgeo.org/osgeo4w/):
>
> (1) Download the 32bit or 64bit OSGeo4W network installer (previous 32bit
> only installer)
>
> wi
Vaclav wrote:
> Hamish and I did some changes in r.profile. X monitors-related parts
> of documentation removed, standard options introduced and most
> notably, Hamish added `coordinate_file` option to enable file input
> and make clear end checkable when standard input is used.
&
Hamish wrote:
>> what we should do is explicitly look for "profile=-" for
>> reading from stdin, to make it more clear that it exists. another
>> more GUI friendly way is to add a new option for an input file, which
>> would be mutually exclusive with t
k
with too). what we should do is explicitly look for "profile=-" for
reading from stdin, to make it more clear that it exists. another
more GUI friendly way is to add a new option for an input file, which
would be mutually exclusive with the profile=[east,north[,east,north,...]
method of using the module.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
), and that review will happen early next week.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ts.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ted for a little while yet..
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
applications
in though, often it is better to invest the time in a couple high-quality
proposals instead of putting in a whole bunch of applications which aren't as
well developed.
Massimo (epi) is our iPython Notebook expert, it would be good
make it sound so hard that
a good student decides not to apply. I'm sure it will work itself out, I just
don't want to put a new student in a rough
position.
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
l or architectural projects for existing student-devs
with a deep knowledge of the code and existing community buy-in/flameproof
clothing, and have new users to grass work on stand-alone modules or gui tools
in the sandbox or addons svn.
thanks,
Hamish
___
netbook's graphics hardware is pretty poor compared to the
graphics card in the remote workstation. It took ~10 times as long running it
remotely, but it did get there.
m.nviz.image didn't work (entirely from the command line) when the DISPLAY
enviro var wasn't set correctly i
it's a really critical time right
now to get everything in order & any linked-to pages well curated.
cheers,
Hamish
On Friday, January 31, 2014 4:58 PM, Vaclav Petras wrote:
>
>
>
>
>On Thu, Jan 30, 2014 at 10:23 PM, Hamish wrote:
>
>Hi,
>>
>&g
Hi,
[sorry yahoo mail trouble making me post out of thread]
please hold off on moving any historical GSoC wiki pages until further
discussion.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
ldn't object to bilinear + cubic though if each was considered
best in its class.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
Hamish wrote:
>> I just added in the dev branches two new flags for v.what.rast.
>> [...]
>>
>> The second flag changes the default containing-grid-cell method to a
>> weighted avg. of the 4 nearest raster cell centers (IDW). The search radius
>> is not ve
there is some critical need to release now, I don't mind putting
these other things off for a 6.4.5, but especially the 'running custom
python scripts' in 6.4 WinGrass seems like an important thing to have
working out of the box for end users.
thanks,
Hamish
___
Hi, coming back to and renaming this thread,
Moritz wrote:
> > Hamish, do you know what is going on for grass 6.4.3 ? I see that it hasn't
> > migrated to testing, yet, because of failure to build on ia64:
> >
> > http://release.debian.org/migration/testing.pl?package
Hamish:
>> what problems did you have with "i.fusion.hpf.tmp.$$" ?
Nikos:
> I think the problem was (among my misunderstanding) that $$
> was the same for a bunch of names fed as variables here and there.
'$$' gets replaced with the PID of the calling process, so
g out your curly brackets. :)
then cleanup is as simple as g.mremove 'tmp_gmodule.$$.*', and if maps
are left behind it's obvious later that they are temporary and where they
came from.
there's no automatic handling, but I don't see where that would save any time.
what probl
Hamish wrote:
> is there a lib function somewhere like Rast_get_row() which populates
> a row buffer, but instead of reading from a file just (re)sets all
> values in the row array to NULL?
>
> something like:
> Rast_fill_row_with_nulls(void *buf, RASTER_MAP_TYPE data_ty
l for() loop to do it, but seems like the
sort of thing a lib fn might help with, so might already exist somewhere.
?
note this is for working with the cell array values, not
writing an all-null row on the disk.
thanks,
Hamish
___
grass-dev mailing list
ng to use
shell scripting for everything because I know it well, and
others trying to use python for everything because they know it
well. And rather both use the most appropriate tool for the job
on a needs basis, and get better in both. :)
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
maging myth, only use them when you actually need
them (eg to protect the variable name from following characters, not its
contents).
Vaclav:
> Is GIS_OPT_MSX also in GRASS 7 (trunk)?
That's just going to be the contents of a msx= command line option defined in
the
script header&
r6. But it seems the latest
package build isn't complaining about ppc64 and s390x, so..?
http://bugs.debian.org/728150
http://bugs.debian.org/672719
thanks,
Hamish
> On Friday, November 1, 2013 2:28 AM, Markus Neteler wrote:
> > On Thu, Oct 31, 2013 at 2:19 PM, Moritz Lennert
&
release branch). for experimental/
development packages, do as you like as long as they are
clearly labeled as such.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
>> What can we do to get an updated qgis package into upstream debian/sid?
...
Jürgen:
> Me neither - I saw qgis activity on debian-gis and thought it was underway.
> I didn't notice that there are problems.
hmm, you're right, Sebastiaan was working on it las
dynamic symbol D__overlay_mode
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[4]: ***
[/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so]
Error 1
make[4]: Leaving directory `/«PKGBUILDDIR»/lib/display'
...
"""
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
uck at 1.7.4 and so all downstream ubuntus & friends are stuck
there too. I am happy to help but I'm not sure if there was a reason for it
being stuck?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/m
.
see for example
http://www.jwz.org/doc/threading.html
http://people.dsv.su.se/~jpalme/ietf/message-threading.html
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Yann wrote:
> wanted to make a Moon location and the option for Planetary Locations
> definitions is gone...
Hi,
How are you trying to access it? There should be a radio button to enable them
on the ellipsoid selection page.
regards,
x27; only one minor
one remains from gcc 4.4.5 using
CFLAGS="-g -march=native -Wall -Werror-implicit-function-declaration
-fno-common -Wextra -Wunused"
iscatt_core.c: In function 'compute_scatts_from_chunk_row':
iscatt_core.c:454: warning
';' before 'G_gettext'
...
> Is this only launchpad or anyone have problems because error message doesn't
> seems so
Hi,
I got cc'd on the launchpad error too and already fixed it in svn. Easy fix,
just a missing (). Perhaps some other c
avigation data ends
up in a .fnv file), then use the addon module to import those as
points or track lines.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
IEEE floating
point (not always obvious), ASCII vs. EBCDIC headers vs. both!...)
http://www.dmng.ru/seisview/
note SEG-Y positions are stored as integers, so if weird try UTM-as-
decimeters and lat/lon converted into milli-arc-seconds.
( {long,lat} = SOURCE_{X,Y}/(1000*60^2) )
Hamish
to get a median
using unix power tools, it's fairly trivial.
https://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/r.univar.sh/r.univar.sh#L135
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osg
Hamish wrote:
> see also the v.points.cog addons script:
> http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.points.cog
>
> although I haven't tried it for anything as big as lidar data.
oops, I completely forgot to mention the r.cog addon script too:
https://trac.osgeo.
thon/pygrass/docs/raster.rst#L308
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ype,
not the compression type used.)
perhaps the README should mention that r3.out.vtk + Paraview was used to make
the screenshot? (it looks like it anyway) Also, I'd also suggest to rename the
README to something more specific as it sits in a top-level dir and one might
assum
and what state they are in. Choosing the best
names for things can come after that. Of course for the long run we should
avoid name-space collisions if we can.
regards,
Hamish
>[1] https://trac.osgeo.org/grass/ticket/1321
>[2]
>http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GI
Margherita wrote:
>>> Any idea on how to (and IF it's possible to) redirect the graphic
>>> output of r.spread module to a gif or mov or avi file instead of
>>> to (or beside to) the monitor?
Hamish:
>> not directly, but you might see the "screencast&q
Margherita wrote:
> Any idea on how to (and IF it's possible to) redirect the graphic
> output of r.spread module to a gif or mov or avi file instead of
> to (or beside to) the monitor?
not directly, but you might see the "screencast" section in:
http://grasswiki.osgeo.o
see also the v.points.cog addons script:
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.points.cog
although I haven't tried it for anything as big as lidar data.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
t
the recent patch is perhaps fixing a problem actually rooted somewhere
else..
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
full module dialog GUIs, the idea sounds nice to me.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
le to anything.
regards,
Hamish
Johannes wrote:
>Hi,
>
>yes grass-gui package is now also installed and this made grass64 working.
>However the grass-gui package did not solve the problem with launching the gui
>of grass70.
>
...
>Johannes:
>>
>>> However w
Johannes:
> However when I try to launch both from the console (freshly installed
> precise) via grass64 or grass70 I get an error:
>
> python: can't open file '/usr/lib/grass64/etc/wxpython/gis_set.py': [Errno 2]
> No such file or directory
is the grass-g
e for search-paths were
MPI-enabled they'd certainly get used by our power users & teams using it
for back-end server satellite image number crunching!
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
t.new. d.text.new is built with the d.text
name, and d.text.freetype is a wrapper script calling d.text.
I only see the -c flag in the d.text.freetype/ code currently,
which was to put it into "command mode" (compatibility with
a d.text(.old) feature which no longer exists).
Hamish
these days, both desktop and laptop, and so top menu bars will fit even
better than they used to, we just have to make the windows a bit wider to
compensate. Luckily these days there's space for that. (2c)
regards,
Hamish
___
grass-dev mailing list
Ben:
> It needs to be a string, so that you can use
> common lat/lon notations in the format "°dd'mm''ss".
technically it's like ddd:mm:ss.H.
see the v.in.ascii man page. fwiw GMT mapping uses something similar.
regards,
Hamish
ps- the wxgui loc
rser override? If so I'd be very
hesitant about touching that in libgis as it breaks predictability of parser
usage. that consistency is a very strong selling point &/or any inconsistency
makes the learning curve that much harder and messier. To me that consistency
is more important than the pain
. (2c)
probably the "none" values for 'r.info -e' should just be empty,
to make them easier to parse & work with `eval` directly.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
s (as ongoing) or just because
someone likes to use it for whatever reason.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
taking the liberty of fwd'd Tim's email here, as the basic idea
can be quite an important one for maintainers of cadastral data.
Paper-trails of changes and formal metadata hooks (eg for INSPIRE)
remain major missing features in GRASS.
regards,
Hamish
- Forward
Hamish wrote:
> # example of adding an RGB border color with a #RRGGBB code:
> echo -ne "\033]11;#53186f\007"
...
> But I think changing the border with a RGB color per mapset
> or location would scale better if you were having a different
> color for each mapset/locat
Hamish wrote:
> # example of adding an RGB border color with a #RRGGBB code:
> echo -ne "\033]11;#53186f\007"
...
> But I think changing the border with a RGB color per mapset
> or location would scale better if you were having a different
> color for each mapset/locat
r --param=ssp-buffer-size=4 -Wformat
-Werror=format-security"
LDFLAGS="-Wl,-z,relro"
# then
CFLAGS+=$(HARDENING_CFLAGS)
LDFLAGS+=$(HARDENING_LDFLAGS)
(I'll echo those out in the morning if you need them)
# TODO: fix these
CFLAGS+=-Wno-error=format-security
...
gcc -I/home/hamish/
t;G_fatal_error(buff);", can anything
be done in the lib fn for them or do they all have to be changed to
"G_fatal_error("%s", buff);" ? [* many of those are hold-overs from pre-
GRASS 5 and a sprintf(buff,..) in the lines above can be moved into the
G_fatal_error()]
Lots of &
f you were having a different color for each mapset/location.
Or, for the "MASK present" I'd prefer a red terminal border to the extra line
on the command prompt, so it might be nice to search out what the different
escape codes for gnome-terminal et al. might be.
Hamish
__
Hamish:
>> re r57291, it's not safe to modify core files after the last RC :-(
Martin:
> but sure, you are right. It was not a good idea.
but seems no harm done :)
It's an interesting conflict -- on one side if we know a fix we wouldn't want
to release without it, on t
Hi,
re r57291, it's not safe to modify core files after the last RC :-(
http://trac.osgeo.org/grass/changeset/57291/grass/branches/releasebranch_6_4/configure.in
There's a missing " quote at the end of line 110. One thousand times lucky this
was in a commented out part!!
Ha
path gets much too long, especially on WinGrass where the
terminal width is a pain to resize.
For simplicity one of my favourites is still just:
export PS1='GRASS$SHORT_VER> '
If you do most of your work with a small set of locations, it might
also be an idea to figure something out wit
;d planned to remove
those two r.sun input options.
(it was otherwise added to r.sun in years past to allow r.sun to
work in an XY location, but I don't think that justifies the extra module
complexity)
?
thanks,
Hamish
___
grass-d
rom memory & educated guessing from when I first saw it in the
ubuntu ppa failed nightly build report; may not be entirely accurate]
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
gt;>> GRASS 6.4.2 (nc_spm_08):~ > error reading package index
>>> file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got
>>> "0.0."
Hamish:
>> /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package,
>> but that is not used
Anna:
>>> Unable to fetch interface description for command 'd.rast3d.py'.
>>> ...
>>> Details: C:\OSGeo4W_dev\bin\python.exe: can't open file
>>> 'd.rast3d.py': [Errno 2] No such file or directory
>>>
>>> [1] http
me known-good transforms of modern and pre-satellite
era datum transforms into a new m.proj test_suite/ script.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
; to avoid the gui at startup)
see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
worked ok. I did get the same error
message
if I manually installed the libsqlite-tcl package (even with dbf as the
db.connect
default), but other than the message in the terminal gis.m seemed to work ok.
So I'd guess an error in the other package and grass users can ignore it?
?,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
se and not very enjoyable to code.
You might also explore how GEM + gis.m organized this in GRASS 6 for
some ideas.
where does the ubuntu recipe install them on the disk now?
I am sure it is possible, somehow.. :)
regards,
Hamish
___
grass-dev mai
#x27;), 'etc', 'gui', 'scripts')
if wxbase not in sys.path:
sys.path.append(wxbase)
?
(probably won't help, but worth a try)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ot let them?)
it's not broken == don't fix it
... my suggestion is just leave the thing alone. why make work for people?
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
TES
Under Linux apart from the permission bits, only the S_ISVTX mode bit
is honored. That is, under Linux the created directory actually gets
mode (mode & ~umask & 01777). See also stat(2).
"""
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ncy for the wxGUI is not adding the
dependency to GRASS, since GRASS can be built and run without the wxGUI.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
1 - 100 of 1773 matches
Mail list logo
