headers
Hamish | 1 Aug 2004 08:53
X-Face
Picon
Favicon

Re: [GRASSLIST:3781] minor update to tcltkgrass for GRASS 5.7

> > d.barscale's GUI isn't rendering properly. When you open
> > it, the bcolor= and at= descriptors are missing, and the following 
> > error is displayed on the console:
> >
> > extra characters after close-quote
> > bad window path name ".pw.f0.frame.optwin.fra.frame.lab1"
> > invalid command name "0,0"
> > bad window path name ".pw.f0.frame.optwin.fra.frame.lab3"
> >
> > It is choking on the " character in bcolor=; if I change the module
> > to use ' instead, it works.. this will break d.text.freetype as
> > well.
> >
> > Similarly, at= breaks when it sees [], that happens in d.text too.
> >
> > It would be nice if the parser be a bit more robust to handle "[].

Ok, I think I fixed this one.

solution: in grass51/lib/gis/parser.c, replace

 ... -text \"$description\" ...
with
 ... -text {$description} ...

this text is in a sprintf() statement & the string goes into a command 
which is eventually fed through:

echo "$command" | wish &
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hamish | 1 Aug 2004 09:32
X-Face
Picon
Favicon

Re: Re: [GRASSLIST:3781] minor update to tcltkgrass for GRASS 5.7

> for the archives:
> To debug the tcl code, I had to add a line to parser.c just before
> system(cmd);
> 
> sprintf(stdout, "%s\n", cmd);
>   [perhaps this should be a if(DEBUG=3) command?]

ummm; yeah... it's already in there.
g.gisenv set="DEBUG=1"

> then run
> 
> GRASS:~> d.text.freetype > dtf_tcl.txt
> 
> then edit 'dtf_tcl.txt'  to remove the "| wish &" from the end.
..
> then 'wish < dtf_tcl.txt'  to test it.
> 
> 
> It was easiest to fiddle with dtf.tcl until it was right and then go 
> back and fix parser.c to provide what was needed.
> 
> 
> 
> References:
> "Is white space significant in Tcl"  http://wiki.tcl.tk/981
> "Tcl quoting hell"  http://wiki.tcl.tk/1726
> "1 minute intro to tcl"  http://www.pconline.com/~erc/tcl.htm
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glynn Clements | 1 Aug 2004 12:21
Favicon

Re: Re: [GRASSLIST:3781] minor update to tcltkgrass for GRASS 5.7


Hamish wrote:

> this text is in a sprintf() statement & the string goes into a command 
> which is eventually fed through:
> 
> echo "$command" | wish &

That's the real bug; the rest are just symptoms.

The way that G_gui() currently works is absolutely crazy. For two main
reasons:

1. The actual text in parser.c is first being interpreted according to
the syntax of C string literals, then the result is being interpreted
according to the syntax of /bin/sh (due to the use of system()), then
that gets interpreted according to the syntax of "echo" (at least
that's only an issue for backslashes), then the ultimate result is
finally interpreted as Tcl code.

2. It ends up calling system() with a potentially massive argument (it
allocates 100Kb). Many Unices have a limit to the length of the
command line, and it's typically less than 100Kb; 4Kb is typical.

If you're planning on doing more work on this, you could probably save
yourself (and anyone else who works on it) some work by:

1. Eliminating the use of the shell and "echo", by using popen()
instead of system(). Then, whatever you write to the FILE* is sent
directly to wish's stdin, without any processing. Apart from avoiding
(Continue reading)

Permalink | Reply | 1 comment |
headers
Request Tracker | 2 Aug 2004 00:52
Picon
Favicon

[bug #2564] (grass) interp_float needs siteslib in extralibs

this bug's URL: http://intevation.de/rt/webrt?serial_num=2564
-------------------------------------------------------------------------

Subject: interp_float needs siteslib in extralibs

Platform: other
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: cvs20040724

Somewhere between 7-10 cvs snapshot and 7-24 cvs the lib/rst/interp_float/makefile changed.  It 
needs $(SITESLIB) (I put it after $(VECTLIB)) in the EXTRA_LIBS.  Otherwise interp_float fails to build 
because it can't find G_site_put.

-------------------------------------------- Managed by Request Tracker
Permalink | Reply | 3 comments |
headers
William K | 2 Aug 2004 01:05
Favicon

cuserid alternative?

I checked the Mac OS X UNIX porting list archives and found a 
suggestion to use getlogin() instead of cuserid (at least for the case 
of passing a null pointer to cuserid).  Any thoughts?  I tried it by 
changing dbmi_base/whoami.c to use that instead of cuserid - compiles 
OK.

Is db_whoami() even used anywhere?  I didn't see it used in any of the 
source.  Without it being used anywhere, I can't really say if 
replacing cuserid() with getlogin() works (it's beyond my C knowledge 
to say if it should work).

FYI, this is my new whoami.c (let me know if anything is wrong with it):

#include <unistd.h>

/*!
  \fn
  \brief
  \return
  \param
*/
char *
db_whoami()
{
     char *getlogin();

     return getlogin();
}

-----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Glynn Clements | 2 Aug 2004 04:19
Favicon

Re: cuserid alternative?


William K wrote:

> I checked the Mac OS X UNIX porting list archives and found a 
> suggestion to use getlogin() instead of cuserid (at least for the case 
> of passing a null pointer to cuserid).  Any thoughts?  I tried it by 
> changing dbmi_base/whoami.c to use that instead of cuserid - compiles 
> OK.
> 
> Is db_whoami() even used anywhere?  I didn't see it used in any of the 
> source.  Without it being used anywhere, I can't really say if 
> replacing cuserid() with getlogin() works (it's beyond my C knowledge 
> to say if it should work).

cuserid() returns the username corresponding to the effective UID of
the calling process, while getlogin returns the username corresponding
to the utmp entry for the TTY associated with descriptor 0 (standard
input).

They may not produce the same result, e.g. if the user has switched
UIDs with su. Also, getlogin() will fail if stdin doesn't refer to a
TTY, or if no utmp entry exists for the TTY (this is quite common for
xterms and similar).

In all probability, db_whoami() (and, for that matter, G_whoami())
should be using getenv("LOGNAME") rather than either cuserid() or
getlogin().

> FYI, this is my new whoami.c (let me know if anything is wrong with it):
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
William K | 2 Aug 2004 05:31
Favicon

Re: cuserid alternative?

> In all probability, db_whoami() (and, for that matter, G_whoami())
> should be using getenv("LOGNAME") rather than either cuserid() or
> getlogin().
>
So, could this be changed in the source?  Didn't think to search for 
'whoami' (doh!), just db_whoami.  Hmm, looks like G_whoami() uses 
getlogin().  So, is there any point to db_whoami?

>> FYI, this is my new whoami.c (let me know if anything is wrong with 
>> it):
>>
>> char *
>> db_whoami()
>> {
>>      char *getlogin();
>
> Don't provide your own prototypes for library functions; include the
> appropriate header instead.
>
Yep, my lack of C skill shows here.  Just mimicking the cuserid version 
of db_whoami.

-----
William Kyngesburye <kyngchaos <at> charter.net>
http://webpages.charter.net/kyngchaos/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Neteler | 2 Aug 2004 10:08
Picon

Re: Re: [GRASSLIST:3781] minor update to tcltkgrass for GRASS 5.7

On Sun, Aug 01, 2004 at 06:53:16PM +1200, Hamish wrote:
> > > d.barscale's GUI isn't rendering properly. When you open
> > > it, the bcolor= and at= descriptors are missing, and the following 
> > > error is displayed on the console:
> > >
> > > extra characters after close-quote
> > > bad window path name ".pw.f0.frame.optwin.fra.frame.lab1"
> > > invalid command name "0,0"
> > > bad window path name ".pw.f0.frame.optwin.fra.frame.lab3"
> > >
> > > It is choking on the " character in bcolor=; if I change the module
> > > to use ' instead, it works.. this will break d.text.freetype as
> > > well.
> > >
> > > Similarly, at= breaks when it sees [], that happens in d.text too.
> > >
> > > It would be nice if the parser be a bit more robust to handle "[].
> 
> 
> Ok, I think I fixed this one.
> 
> 
> solution: in grass51/lib/gis/parser.c, replace
> 
>  ... -text \"$description\" ...
> with
>  ... -text {$description} ...
> 

Thanks a lot! This was a long-standing problem...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hamish | 2 Aug 2004 12:18
X-Face
Picon
Favicon

Re: Re: [GRASSLIST:4019] d.zoom in lat/lon?

> > > > I'm noticing when using d.zoom in a lat/lon location that the
> > > > resolution is not preserved, and I need to run 'g.region
> > > > res=$ORIG_RES -a' to fix it afterwards.
> > > > Is this a bug or a feature?
> > > 
> > Markus:
> > > To me it looks like a bug 

A few d.zoom bugs really, (mostly) fixed now.

> > Bug #1:
> > 
> > Right then. Increasing the significant digits on the round_to()
> > rounding calculation in set.c seems to have fixed it for resolutions
> > up to 0:00:00.0001 (3mm)
> > 
> > The "13" below is arbitrarily large, it was just an easy value to 
> > insert in vi. ;)

[but later tests showed anything less than 13 didn't fix the problem]

I didn't like that approach, so in the end I left that as it was and did
some checking & resetting just before the call to G_adjust_Cell_head()
rather than rewrite the entire program. This fixes zoom+unzoom or -f pan
circumnavigations too.

> > > (at least it's annoying because when zooming on continental scale
> > > you often get an error that you left the max latitude etc).
> >
> > Bug #2:
(Continue reading)

Permalink | Reply | 0 comments |
headers
guest user via RT | 2 Aug 2004 13:06
Picon
Favicon

[bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser

this bug's URL: http://intevation.de/rt/webrt?serial_num=2488

Request number 2488 was commented on by 'guest' (guest user). 
Responding to this message will send mail to the requestor.
			
			Request Tracker
			rt <at> intevation.de

--------------------------------------------------------------
Cc: grass5 <at> grass.itc.it

adding  printf("argc=%d\n", argc);  to G_parser() highlights the problem

e.g. 5.7's auto-gen Tcl makes:
button .run -text "Run" -command {
 ...
    set cmd "| $cmd 2> <at>  stdout"
    catch {open $cmd r} msg
 ...
}

so:
 set cmd {d.text.freetype text="abc 123" path=font.ttf}
gives argc=4 in G_parser

argv[0] is 'd.text.freetype'
argv[1] is 'text="abc'
argv[2] is '123"'
argv[3] is 'path=font.ttf'
(Continue reading)

Permalink | Reply | 10 comments |

Gmane