straight forward
for someone who knew the vector API, and less than a day's work for
someone who didn't but wanted to learn it based on cutting and pasting
from other v.* modules. ;)
free hi-res versions of this data can be hard to come by, and the NOAA
shor
rally
kept in check by the PITA that it is to sync things.
A question remains for me wrt after 6.4.0 is released if grass7<->devbr6
development will be kept in sync as it is now. (for possible 6.5/6)
I'll defer an opinion about that until the time of the last 6.4.0 RC.
Hamish
Glynn wrote:
> Re:
>
> r33944 | hamish | 2008-10-21 03:35:40 +0100 (Tue, 21 Oct 2008) | 1 line
> remove code based on Vask_lib+Xmons; porting will happen in
> develbranch6 then when operational be merged back into grass7 SVN
>
> Isn't this backwards
-lgrass_linkm
-lgrass_rtree
-lgrass_segment
-lgrass_vect
-lm
-lz
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)
Hamish
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
was: [GRASS-dev] porting r.in.wms to python
wrt: angle between grid north and true north
> Hamish wrote:
> > does anyone know of a libgis function that will return
> > the current projection+coordinate's convergence angle WRT true north?
> > A method to find that
Helena:
> there is word Bohemia in the upper right (with the Lion symbol) and
> even Hungaria in upper left but the image and the title is too fuzzy
> to read.
Hamish:
> ah, now I see big letters on the UL-LR diagonal that spells "SILESIA",
Helena:
> Maybe there is
Helena Mitasova wrote:
Hamish:
> > I am looking to document the heritage of the GUI startup splash
> > screen.
> >
> > Anybody know? The "Polonia" in the bottom left indicates Poland,
> > but as it came from Radim I thought perhaps the area is part
&
Hi,
I am looking to document the heritage of the GUI startup splash screen.
Anybody know? The "Polonia" in the bottom left indicates Poland, but as
it came from Radim I thought perhaps the area is part of Czech now, or...?
thanks,
Hamish
___
> #340: d.labels doesn't place labels exactly on
> coordinate point in label file.
> --+-
> Reporter: wolf | Owner: hamish
> Type: enhancement | Status: assigned
[moved to grass-dev]
Wolf:
> I'm still waiting for Hamish to check a patch for d.labels to allows
> precision placement that v.label.sa. So far he has been to busy to check
> it. *shrug*
The issue is not with the patch itself -- I have full confidence in Wolf's
coding. R
at is sampling noise? what constitutes the spike vs
bump threshold?
just an idea,
Hamish
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
grass-de
> Does grass on windows have problems with spaces in the
> mapset or location path?
The GIS database directory path (C:\$HOME\grassdata\) may contain spaces.
mapset and location names may not. (nor may map names)
(problematic for [EMAIL PROTECTED], r.proj/g.list mapset= options, etc.)
Markus Neteler wrote:
> would it be possible to add a threshold parameter to r.series?
don't know,
> In our case, we want to consider only pixels above a
> certain value (>=).
>
> Not sure about the implementation: have two flags to define
> above/below?
more concise:
Michael wrote:
> The TclTk GUI is set to be abandoned in GRASS 7. It will continue to
> live in the GRASS 6 series.
last call for objections before the Tcl/Tk gis.m is removed from GRASS 7.
(trunk/gui/tcltk/)
Hamish
___
grass-dev mailing list
years old. It's not like arguing
to support Tcl/Tk 8.0.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
> > While running through this set of commands to resample from 30" to 2':
> > http://grass.osgeo.org/wiki/Blue_Marble#Processing
> >
> > I notice that the output of r.resamp.stats has its western-most raster
> > column set to all NULL. The
hout NULLs, and the target region is an exact multiple of the source region,
it doesn't seem to be an inherent exceeding-the-border
effect. The propagate nulls flag was not used.
Besides losing data, when you zoom to look at the pacific it makes an
ugly white line al
to create yourself
an OSGeo id and send the name to the grass-psc mailing list, along with a
note that you have read and agree to RFC2.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
user option) among modules would be
nice to ease the learning curves.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
I join Michael in this request:
http://article.gmane.org/gmane.comp.gis.grass.devel/23787
(in our case, it was looking at energy penguins expended to reach their nests)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
ons often "creative"
- inflexible
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ess a v.compare could simply run `diff` on the two folders in
$MAPSET/vector/ (with g.findfile adjusting for @otherMapset as needed)
thoughts?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
vector/v.segment/main.c
vector/v.label.sa/main.c
vector/v.what.rast/main.c
vector/v.to.db/update.c
vector/v.to.db/report.c
vector/v.kernel/main.c
vector/v.in.ascii/points.c
as the list is long and manual review is needed, if needed we can file
a trac ticket and tick them off o
k.nl/~dimitri/doxygen/docblocks.html#pythonblocks
"Since python looks more like Java than like C or C++, you should set
OPTMIZE_OUTPUT_JAVA to YES in the config file."
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
me backport this?
Glynn:
> >> Maybe.
> >>
> >> Unless there are modules which genuinely need to distinguish GRASS
> >> nulls from other NaNs,
Hamish:
> > It can help in tracking down bugs, e.g. see the BUGS section of the
> > r.in.xyz man page.
Markus:
>
looks more reasonable:
http://trac.osgeo.org/grass/changeset/25355
fwiw, %.8f should give about 1mm for lat/lon, which is beyond current
RTK GPS capability and what is meaningful for a lot of projection
math (as we are constantly reminded on the proj4 list).
while keeping i
e trained in using it (to some extent). And others
can gain transferable knowledge.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
are distinct- mathematical null vs. spatial null.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/* please improve */
}
it uses the 'if(a != a)' method.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
) returns garbage no harm is done and
G_percent() is skipped. It doesn't touch the processing aspect of the
module, just the cosmetic user message end of things.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osg
, so that the user
> could see what they were supposed to be clicking on.
> That's no longer applicable.
if needed the full d.vect step could become a flag in d.path.
> More generally, is there any intention to fix up gis.m with re
true north?
A method to find that with the `proj` program is given here:
http://grass.osgeo.org/wiki/Ps.map_scripts#Creating_a_fancy_North_Arrow
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/r.support.sh was partially needed because
1) non-interactive version did not in the past support all interactive
functionality, and
2) interactive version weirdly exits prematurely when called directly
from Tcl/Tk.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
iption makes that counter-intuitive).
> Optionally remove value= and/or qcolumn=.
Replacing qcolumn= with expression= sounds good to me. It's more to the
point.
At which point value= becomes a little redundant, but it helps to avoid
a some minor 'quote' proofing when used from the shell.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
> > also have a look at the swig/python/examples/m.distance python script
> > for a fully non-interactive version.
Markus:
> Would it be possible to get bearing added to
> swig/python/examples/m.distance
> ?
>
> The m.cogo module assumes a cartesian coor
-implicit-function-declaration" ./configure ...
for a long time without any problem.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
taining it feels a bit like a
game of whack-a-mole.
Perhaps there is some overlap with v.in.wfs as well? (currently relies on
lynx, which I guess is not commonly installed with MS-Windows..)
Hamish
___
grass-dev mailing list
grass-dev@lists.osge
massimo costantini:
> I need to create an empty vector file or delete all the feature in an
> existent vector file.
> How I can do this? the command Vect_open_new is non sufficient!
v.in.ascii -e
Hamish
___
grass-dev mailing list
on't see any highly suspicious changes to g.gisenv/main.c.
Was it some change in libgis then?
"unset PROMPT_COMMAND" fixes it of course.
what gives?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
shall we keep or remove r.resample in GRASS 7?
Its functionality is replaced by "r.resamp.interp method=nearest", or
if you wish to match old r.resample method exactly*: "r.mapcalc new=old".
[*] IIRC
?,
Hamish
___
grass-dev ma
n user-specified rules" and expect it
> to pop up a window into which they can enter rules? If they do,
> they're in for shock, as the GUI waits for r.colors,
> which is waiting for something to be fed to its stdin.
Hopefully the discover Michael's handywork in Raster-
[stating my peace then dropping this to focus on far more ghastly UI issues]
> Hamish wrote:
> > I've just added some logic in 6.x SVN to more nicely handle different
> > user interpretations of the commands. "accept sloppy input, create
> > tight output" a
er he can use `triangle' or not.
Unless the code is all GPL compatible I don't think we can host it on
the GRASS SVN or addons SVN. Perhaps at another OSGeo server or on
SourceForge? Personal websites are fine in the short term, but have a
habit of moving on after a few years and the code becomes lost.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ed effort to ensure that.
One huge exception might be the change of r.out.gdal.sh to r.out.gdal (C
version), WRT observing overall map vs. current region bounds, but I am
not sure of that, probably you know better than me if that is actually
the case and causes pain.
Hamish
__
ontract#guidelines
My attitude is that if it passes those tests, I/we can integrate
it into our project without much worry.
?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
users. Where's the gain in intentionally scuttling it early?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
t, there may be something important there.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
,
not changes to the code and available functionality.
If the problem is limited uptake, a solution could be a new / better
advertised reference example. e.g. a "g.swig" hello world module.
2c,
Hamish
___
grass-dev mailing
blio mirror works fine.
This has been happening for more than a month & is a bad look.
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
s and expand the *tmp struct you will see as
you step along that *p and *tmp just bounce around in an endless circle
between two memory valid addresses, so it never reaches NULL.
The x value for those two are 638631.01569480076 and 637951.01569479937
Hamish
br11_buf31.txt.gz
Description:
out them. A centroid's cat number (as thus DB
attributes) is inherited by the surrounding area.
> And again, please help with the busroute11 test, cause
> it's behaving weirdly.
right, will do.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
or even only r.spread)?
cd raster/wildfile/r.spread
svn up
make
#insert optional install step here
> How long does it take with the demomapset in demolocation (excuting the
> script firedemo.sh manually)?
forever.
the test fire simulation data
ious that
compatibility is broken and scripts using it may silently fail or
unexpectedly give a different result.
But I'll respect and take your word as for the author's original intentions.
;)
Hamish
___
grass-dev mailing
Glynn:
> Or we can make the C versions use basic REs for -r and add e.g.
> -e for extended REs.
I think it would be better to offer just one regex flag.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osg
ass-7.0.svn/etc/Init.sh: 27: source: not found
> /usr/local/grass-7.0.svn/etc/Init.sh: 142: create_tmp: not found
[...]
'source "$GISBASE/etc/functions.sh"' sets up create_tmp() et al. functions.
So if that fails they all fail.
Hamish
__
exactly match?
It's up to you.
see also http://trac.osgeo.org/grass/ticket/123
points exactly matching the southern boundary are ignored.
and the BUGS section at end of the help page.
It would be comforting to have the books exactly balance.
Hamish
emplate:Cmd
excelent. thanks Martin.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
00"E style
for cs2cs.
comments/ideas?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
es to Init.sh.]
don't forget to run $GISBASE/etc/clean_temp every now and then to clear
out left over files from processes that die or are terminated before they
get to their final cleanup stage. Considerable cruft can accumulate
during testing & debugging of modules.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
> > Is it as simple as replacing printf %d with %u ?? (seems to work)
Glynn:
> Yes.
ok, done in SVN r33163,4. I went with unsigned longs instead of floats for
the counts. This means 32bit users with datasets > 5 billion points will
get garbage counts in the summary message.
robably just a
superficial PR name change in 2009 for SP2, but who knows for sure?)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
d machine, LFS, nls, and in general
./configure feature report stuff, ...
?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ile. (or add aliases to the new names)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
re them 37,000 lines
> > C++ code: almost 30,000 lines
> >
> > very roughly, just `wc -l`.
Hamish:
> better to use sloccount:
> http://article.gmane.org/gmane.comp.gis.grass.devel/24729/
> (6 months ago)
> http://article.gmane.org/gmane.comp.gis.grass.devel/44
> C++ code: almost 30,000 lines
>
> very roughly, just `wc -l`.
better to use sloccount:
http://article.gmane.org/gmane.comp.gis.grass.devel/24729/ (6 months ago)
http://article.gmane.org/gmane.comp.gis.grass.devel/4498/ (4 yrs today)
Hamish
___
others).
use your best judgment.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
d changing that.
r.colors rules are used bit differently, so they may not fall into the
scope of this standardization round.
I assume vector modules which take SQL statements do not parse those
statements but pass them intact, in which case I would leave
Hi,
maybe it is a good time to revisit the idea of adding build date, SVN
checkout date, and/or SVN Revision (GIS_H_VERSION) to the output of
g.version.
Currently that doesn't specify x.y.svn better than to the year, which
is not as helpful as it could be.
H
areas A,B,... (Most of the
> times A,B,... will intersect each other)
can you reuse v.overlay code for that?
i.e. if you pass A and B into "v.overlay opt=or" do you get the
result you want? islands should be respected that way.
Hamish
Hamish:
> > no aliases cluttering things up please, lets just do the job right,
> > once. AFAIK we only guarantee the user interface is stable
> > within grass 6.x, not the library interface.
Markus:
> Are these G_OPTs externally used (GDAL, SWIG..)?
(R interface, QGIS, ..
liases cluttering things up please, lets just do the job right, once.
AFAIK we only guarantee the user interface is stable within grass 6.x, not the
library interface.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo
ine aliases) ?
+0 (devbr6)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
;s any point in
> cannibalising these as non-interactive programs which accept
> x/y screen coordinates as arguments.
r.what already provides a non-interactive d.what.rast, and
although I am not very familiar with it, v.what exists and
seems to work. So not much to do here.
Hamish
neutral so not a problem for the server-space reason,
but very much a problem for the user wants "core only" reason.
2c
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ter set is a GNU extension;
> other versions of sed need a literal tab character.]
see also
http://article.gmane.org/gmane.comp.gis.grass.devel/27382
http://article.gmane.org/gmane.comp.gis.grass.devel/27387
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
t updated the man page in SVN to make things clearer:
http://trac.osgeo.org/grass/changeset/32537
although I am not sure if the current way is as-intended or a bug.
intuitively I'd guess that 0 should be don't draw and 1 should be draw,
but alas..
devels see also the PostScript
Port 80
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ved it to gmath. Later, gmath
> got enriched with FFTW support and such.
>
> It should possibly go back to libgis (in GRASS 7).
or move FFTW stuff etc. into an "advanced_math" library.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ternative to r.buffer for large maps.
When I get back (in a couple of weeks) I'll give it a try to see how it does
with my v.surf.icw script (IDW interp but with distance term as (AFAIU)
r.grow.distance does it)
http://trac.osgeo.org/grass/browser/grass-addons/vector
Glynn:
> > > FWIW, I'm planning to remove ps.map from 7.x.
> > >
> > > Equivalent functionality will be available through d.*
> > > commands.
Hamish:
> > any reason other than redunancy?
Glynn:
> Partly redundancy, mainly to ensure that people comp
the only one who actually works on it). It doesn't touch anything
outside its directory and the code is a fairly small portion of the overall
tarball.
i.e., what is the cost of leaving it there for those who depend on it?
AFAICS the primary thing it lacks is a nice G
--overwrite comes and goes depending of if it is relevant
to the module.
re. the module list of flag from r.buffer --help: the vertical descriptions
of flags uses the short version (--q), but note that the top USAGE: line
has the long version. Both ways are listed there on
es we should include? currently for ISO sizes we
only define A0-A4.
link of interest: http://www.paperonweb.com/size.htm
regards,
Hamish
iso_sizes.m
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ng, perhaps it is time to retire the ban on $Id$. SVN gives us
unique rev numbers even among -addons, -web, branches, and trunk, so the prior
reasoning no longer applies.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn:
> I don't see a problem with explicitly passing the
> -text and -tcltk switches whenever you start GRASS.
> The default will then only matter if the user starts GRASS
> manually from a console.
note that using those switches at all will reset the
2007-02-17
v.in.ascii chokes there for obvious reasons.
Move over small welsh towns!
http://en.wikipedia.org/wiki/Taumatawhakatangihangakoauauotamateapokaiwhenuakitanatahu
[checkout the translation(s)]
Hamish
___
grass-dev mailing list
grass-dev@
ing in v.buffer yet.
oh sorry, nevermind, carry on I expect the trouble with it was particular
the old method and so it may be fine..
I look forward to trying out the new code!
regards,
Hamish
___
grass-dev mailing list
grass-
st for the new version?
(spearfish or NC test datasets, or OpenStreetMap extraction)
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
egion vect=region_box -p" and check that the new resolution is ok and that
rows x cols is no less than in the source region, slightly more if the
reprojection rotates the box significantly. and/or try the "-n" flag with
r.
needed.
> sample file can be downloaded from
> (GML) http://les-ejk.cz/tmp/pole2009.gml
> (SHP) http://les-ejk.cz/tmp/pole2009.tgz
"ERROR 503: Service Unavailable."
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn:
> Yeah, lat/lon could be a problem (r.info uses d:m:s while
> g.region uses decimal), as could fractional coordinates, due to
> precision issues.
so parse "g.region -p" instead of -g?
Hamish
___
grass-dev mai
rent task make it a new module. (see r.centroids)
if a large amount of code is shared, compile the two modules out of the same
directory, and share as much code in shared functions as possible. (see
r.univar)
Hamish
___
grass-dev mailing
culated
> by r.walk or r.cost).
AFAIR r.drain just blindly climbs to the next up/downhill D8 cell, in a loop,
until it can climb/drop no more. thus it is not "least" cost at all, just one
valid solution? (??)
Hamish
__
"
?
m.proj wants DMS in PROJ.4 style, i.e. 123d45'56"
a little sed magic can make that happen if needed.
use 'm.proj -d' if you want decimal output.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
g good use of G_debug() there. You can set the level to
"0" to always show the message when developing then adjust that to something
higher later on.
that's all,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
]
default_daysback
changeset_show_files would be very nice too.
and changeset_long_messages ...?
with a shorter daysback those more verbose modes wouldn't be as annoying..
comments?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
n "reseed" the second half of the calculation from an arbitrary point
without having to rerun the first.
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
r young and lightly tested.
If GRASS does not include FFMPEG it just means you need your own encoder to
create the movies from the series of frame images instead of it happening
automatically.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
sually you will have to call it a final time after the for loop to get the
"100% done" and newline to be printed. This depends on how you write your i++
for loop of course, but typically if you don't the number stalls a 99% w
1301 - 1400 of 1773 matches
Mail list logo
