[GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

martinl · June 3, 2014, 6:55am

Reminder for all Windows users, please note that winGRASS 7.1 no.>981
will be broken (calling python script from python script issue - eg.
wxGUI Extension manager) again.

2014-06-03 7:24 GMT+02:00 <svn_grass@osgeo.org>:

Author: glynn
Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014)
New Revision: 60679

Modified:
grass/trunk/lib/python/script/core.py
Log:
Remove Popen() "magic" on Windows; it creates more problems than it solves

Modified: grass/trunk/lib/python/script/core.py

--- grass/trunk/lib/python/script/core.py 2014-06-03 03:51:54 UTC (rev 60678)
+++ grass/trunk/lib/python/script/core.py 2014-06-03 05:24:32 UTC (rev 60679)
@@ -41,28 +41,8 @@

class Popen(subprocess.Popen):
+ pass

- def __init__(self, args, bufsize=0, executable=None,
- stdin=None, stdout=None, stderr=None,
- preexec_fn=None, close_fds=False, shell=None,
- cwd=None, env=None, universal_newlines=False,
- startupinfo=None, creationflags=0):
-
- if shell == None:
- shell = (sys.platform == "win32")
- if sys.platform == "win32":
- # get full path including file extension for scripts
- fcmd = get_real_command(args[0])
- if fcmd.endswith('.py'):
- args[0] = fcmd
- args.insert(0, sys.executable)
-
- subprocess.Popen.__init__(self, args, bufsize, executable,
- stdin, stdout, stderr,
- preexec_fn, close_fds, shell,
- cwd, env, universal_newlines,
- startupinfo, creationflags)
-
PIPE = subprocess.PIPE
STDOUT = subprocess.STDOUT

_______________________________________________
grass-commit mailing list
grass-commit@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

Pietro2 · June 3, 2014, 7:10am

Hi Glynn,

On Tue, Jun 3, 2014 at 8:55 AM, Martin Landa <landa.martin@gmail.com> wrote:

Reminder for all Windows users, please note that winGRASS 7.1 no.>981
will be broken (calling python script from python script issue - eg.
wxGUI Extension manager) again.

2014-06-03 7:24 GMT+02:00 <svn_grass@osgeo.org>:

Author: glynn
Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014)
New Revision: 60679

Modified:
grass/trunk/lib/python/script/core.py
Log:
Remove Popen() "magic" on Windows; it creates more problems than it solves

Please, could you explain which problems creates?

martinl · June 4, 2014, 3:25pm

2014-06-03 9:10 GMT+02:00 Pietro <peter.zamb@gmail.com>:

Remove Popen() "magic" on Windows; it creates more problems than it solves

Please, could you explain which problems creates?

I am waiting for reasonable/acceptable explanation for long time, I do
not assume that it will ever come. Anyway, dear all, this commit
completely broke the whole winGRASS 7.1 which even doesn't start

  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 981, in gisenv
    s = read_command("g.gisenv", flags='n')
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 400, in read_command
    ps = pipe_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 375, in pipe_command
    return start_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 334, in start_command
    return Popen(args, **popts)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 711, in __init__
    errread, errwrite)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 948, in _execute_chil
d
    startupinfo)
WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor
Error in GUI startup. If necessary, please report this error to the GRASS develo
pers.
Switching to text mode now.

Hit RETURN to continue...

Happily we have 7.0 which still includes this "magic" (in other words
GRASS starts and works). Martin

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

hellik · June 4, 2014, 5:07pm

Martin Landa wrote

2014-06-03 9:10 GMT+02:00 Pietro <

peter.zamb@

>:

Remove Popen() "magic" on Windows; it creates more problems than it
solves

Please, could you explain which problems creates?

I am waiting for reasonable/acceptable explanation for long time, I do
not assume that it will ever come. Anyway, dear all, this commit
completely broke the whole winGRASS 7.1 which even doesn't start

  File
"C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 981, in gisenv
    s = read_command("g.gisenv", flags='n')
  File
"C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 400, in read_command
    ps = pipe_command(*args, **kwargs)
  File
"C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 375, in pipe_command
    return start_command(*args, **kwargs)
  File
"C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 334, in start_command
    return Popen(args, **popts)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 711, in
__init__
    errread, errwrite)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 948, in
_execute_chil
d
    startupinfo)
WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor
Error in GUI startup. If necessary, please report this error to the GRASS
develo
pers.
Switching to text mode now.

Hit RETURN to continue...

Happily we have 7.0 which still includes this "magic" (in other words
GRASS starts and works). Martin

--

I don't understand this uneeded break of winGRASS 7.1.

anyway, I've intensely tested this "magic" quite a lot in the last 2 months
in different win-boxes (vista, 7, 8) with a bunch of different python
scripts. no problem so far.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5144069.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

Glynn_Clements1 · June 4, 2014, 5:56pm

Pietro wrote:

> Reminder for all Windows users, please note that winGRASS 7.1 no.>981
> will be broken (calling python script from python script issue - eg.
> wxGUI Extension manager) again.
>
> 2014-06-03 7:24 GMT+02:00 <svn_grass@osgeo.org>:
>> Author: glynn
>> Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014)
>> New Revision: 60679
>>
>> Modified:
>> grass/trunk/lib/python/script/core.py
>> Log:
>> Remove Popen() "magic" on Windows; it creates more problems than it solves

Please, could you explain which problems creates?

The shell doesn't simply pass its arguments to the program being
executed; it may interpret them (e.g. performing redirection in the
presence of |, < or > characters). For a specific example of why this
is a problem, see ticket #2314.

http://trac.osgeo.org/grass/ticket/2314

The quoting performed by the subprocess module (specifically, the
list2cmdline() function) doesn't take this into account (i.e. it
doesn't perform any additional quoting when shell=True).

So either:

1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That
has the same issues as using shell=True, but at least it only applies
in the case where we're executing a script.

2. If we know that the "program" is a script, the interpreter can be
specified explicitly (i.e. "python path/to/script.py"). This keeps the
shell out of the picture.

--
Glynn Clements <glynn@gclements.plus.com>

neteler · June 4, 2014, 8:35pm

On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
...

So either:

1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That
has the same issues as using shell=True, but at least it only applies
in the case where we're executing a script.

... this would follow the apparently working method in GRASS 6.
Maybe worth a try also in GRASS 7 at this point.

2. If we know that the "program" is a script, the interpreter can be
specified explicitly (i.e. "python path/to/script.py"). This keeps the
shell out of the picture.

... how much effort is the latter? Check file type and path to file?

Markus

martinl · June 4, 2014, 8:48pm

2014-06-04 22:35 GMT+02:00 Markus Neteler <neteler@osgeo.org>:

2. If we know that the "program" is a script, the interpreter can be
specified explicitly (i.e. "python path/to/script.py"). This keeps the
shell out of the picture.

... how much effort is the latter? Check file type and path to file?

this check has been removed from thunk [1].

...
fcmd = get_real_command(args[0])
if fcmd.endswith('.py'):
....

Martin

[1] http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

mlennert · June 5, 2014, 3:36pm

On 04/06/14 22:35, Markus Neteler wrote:

On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
...

So either:

1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That
has the same issues as using shell=True, but at least it only applies
in the case where we're executing a script.

... this would follow the apparently working method in GRASS 6.
Maybe worth a try also in GRASS 7 at this point.

I had the feeling that this was the "consensus" (or at least with lack of clear dissension) we had reached:

http://lists.osgeo.org/pipermail/grass-dev/2014-April/068519.html

Moritz

martinl · June 5, 2014, 7:14pm

Hi,

2014-06-05 17:36 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

... this would follow the apparently working method in GRASS 6.
Maybe worth a try also in GRASS 7 at this point.

I had the feeling that this was the "consensus" (or at least with lack of
clear dissension) we had reached:

"consensus" is somehow courageous to say, bearing in mind that Glynn
simply reverts any other solution regardless that it breaks the whole
GRASS on Windows (try to install 7.1, completely useless, even no
answer, break is just OK). Well, someone need to implement it, even
some of us are not probably happy about that, we need to take care
about user scripts and so on. It's somehow funny, because 7.0 simply
works (same was for 7.1 some days ago).

Martin

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

mlennert · June 6, 2014, 6:50am

On 05/06/14 21:14, Martin Landa wrote:

Hi,

2014-06-05 17:36 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

... this would follow the apparently working method in GRASS 6.
Maybe worth a try also in GRASS 7 at this point.

I had the feeling that this was the "consensus" (or at least with lack of
clear dissension) we had reached:

"consensus" is somehow courageous to say, bearing in mind that Glynn
simply reverts any other solution regardless that it breaks the whole
GRASS on Windows (try to install 7.1, completely useless, even no
answer, break is just OK). Well, someone need to implement it, even
some of us are not probably happy about that, we need to take care
about user scripts and so on. It's somehow funny, because 7.0 simply
works (same was for 7.1 some days ago).

Have you looked at the reason for Glynn's revert ? Do you have a better suggestion to solve the problem at hand ?

Moritz

Glynn_Clements1 · June 6, 2014, 6:52am

Markus Neteler wrote:

> 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That
> has the same issues as using shell=True, but at least it only applies
> in the case where we're executing a script.

... this would follow the apparently working method in GRASS 6.
Maybe worth a try also in GRASS 7 at this point.

> 2. If we know that the "program" is a script, the interpreter can be
> specified explicitly (i.e. "python path/to/script.py"). This keeps the
> shell out of the picture.

... how much effort is the latter? Check file type and path to file?

No. The latter involves the caller knowing that it's invoking a script
and explcitly invoking it via the interpreter.

Attempting to determine this within the library is problematic, as we
would need to mimic the mechanisms which the platform uses for
invoking scripts. E.g.

* If the "program" argument isn't a full path, we need to scan %PATH%
for it.

* If it lacks an extension, we also need to scan %PATHEXT%.

* There's also the question of whether such treatment should be
applied for any script, or just those which are part of GRASS.

Using batch files has the advantage that we can just execute the
command without worrying about any of this.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn_Clements1 · June 6, 2014, 7:08am

Martin Landa wrote:

>> ... this would follow the apparently working method in GRASS 6.
>> Maybe worth a try also in GRASS 7 at this point.
>
>
> I had the feeling that this was the "consensus" (or at least with lack of
> clear dissension) we had reached:

"consensus" is somehow courageous to say, bearing in mind that Glynn
simply reverts any other solution regardless that it breaks the whole
GRASS on Windows

The reason I do this is because GRASS has a long history of dealing
with bugs using ugly hacks, which typically introduce
equal-but-opposite bugs. This then means that any attempt to fix the
underlying bug breaks everything. It also results in incomplete fixes,
which are then "fixed" further by adding yet more code, with each
iteration getting progressively uglier due to interactions with
earlier layers.

If something doesn't actually work, I'd rather everyone be aware of
that and try to find an actual solution, rather than just papering
over the cracks and pretending that the issue has been solved.

E.g. if run_command() has problems with using a vertical bar character
in an argument, modifying specific cases to avoid using a vertical bar
doesn't fix the actual problem.

Removing the shell from the equation fixes the actual problem (and
possibly other problems related to the shell, e.g. ANSI-vs-OEM
codepage issues). Escaping arguments should fix that specific problem
(but not others), provided that we can accurately determine the
shell's rules (Good Luck With That; the bash manual runs to ~82 pages;
I've never seen anything like that for cmd.exe).

--
Glynn Clements <glynn@gclements.plus.com>

annakrat · June 6, 2014, 1:49pm

On Fri, Jun 6, 2014 at 3:08 AM, Glynn Clements <glynn@gclements.plus.com>
wrote:

Martin Landa wrote:

> >> ... this would follow the apparently working method in GRASS 6.
> >> Maybe worth a try also in GRASS 7 at this point.
> >
> >
> > I had the feeling that this was the "consensus" (or at least with lack
of
> > clear dissension) we had reached:
>
> "consensus" is somehow courageous to say, bearing in mind that Glynn
> simply reverts any other solution regardless that it breaks the whole
> GRASS on Windows

The reason I do this is because GRASS has a long history of dealing
with bugs using ugly hacks, which typically introduce
equal-but-opposite bugs. This then means that any attempt to fix the
underlying bug breaks everything. It also results in incomplete fixes,
which are then "fixed" further by adding yet more code, with each
iteration getting progressively uglier due to interactions with
earlier layers.

Yes, that's very true, there is lot of such examples in the GUI. Therefore
Vaclav and I did some refactoring there but I would like to point out that
during the refactoring the GUI was still *working*.

If something doesn't actually work, I'd rather everyone be aware of
that and try to find an actual solution, rather than just papering
over the cracks and pretending that the issue has been solved.

I think we all know about the issue and removing the ugly code from SVN
doesn't solve anything, especially when there is no one who is willing to
solve it soon.

E.g. if run_command() has problems with using a vertical bar character
in an argument, modifying specific cases to avoid using a vertical bar
doesn't fix the actual problem.

Removing the shell from the equation fixes the actual problem (and

and breaks the rest so I wouldn't say it fixes anything. I understand you
want to keep the code clean without any workarounds but you didn't
implement better solution.

I would suggest to remove the link to GRASS 71 on GRASS website unless
someone is going to fix this soon.

Anna

possibly other problems related to the shell, e.g. ANSI-vs-OEM

codepage issues). Escaping arguments should fix that specific problem
(but not others), provided that we can accurately determine the
shell's rules (Good Luck With That; the bash manual runs to ~82 pages;
I've never seen anything like that for cmd.exe).

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

martinl · June 7, 2014, 2:24pm

Hi,

2014-06-06 15:49 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:

[...]

I would suggest to remove the link to GRASS 71 on GRASS website unless
someone is going to fix this soon.

I have commented out 7.1 [1,2]. I do not believe than someone will fix
it soon. The person who introduced the complete break [3] simply
doesn't care.

Martin

[1] http://grass.osgeo.org/download/software/ms-windows/
[2] http://trac.osgeo.org/osgeo4w/wiki/PackageListing#GRASSGIS
[3] http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

Glynn_Clements1 · June 7, 2014, 4:28pm

Martin Landa wrote:

> I would suggest to remove the link to GRASS 71 on GRASS website unless
> someone is going to fix this soon.

I have commented out 7.1 [1,2]. I do not believe than someone will fix
it soon.

Even if they don't, everything except scripts should still work. There
are plenty of projects where daily snapshots are far less reliable,
and where that's considered normal.

On Unix, you'd expect developers to just build from source. But on
Windows, getting a development environment set up is a lot more
effort, so having access to binaries is still useful for developers.

But you're the one hosting them (or not), so it's your call.

The person who introduced the complete break [3] simply doesn't
care.

No, that's not true. However, my Windows system is still rather
inadequate as a development platform (it does now have the base
MinGW/MSys installation, but not the libraries required to build
GRASS).

It doesn't absolutely *have* to be me who fixes it. I don't even use
Windows as a development platform for my own purposes. If Windows
script execution never gets implemented, that won't be because a
specific person doesn't care, but because nobody cares.

The changes required to Script.make and/or ScriptRules.make to create
batch files aren't exactly rocket science, but testing them would be
much easier for someone who has a Windows system which can actually
build GRASS.

--
Glynn Clements <glynn@gclements.plus.com>

hellik · June 7, 2014, 5:29pm

On Unix, you'd expect developers to just build from source. But on
Windows, getting a development environment set up is a lot more
effort, so having access to binaries is still useful for developers.

[...]

However, my Windows system is still rather
inadequate as a development platform (it does now have the base
MinGW/MSys installation, but not the libraries required to build
GRASS).

in OSGeo4W [1] there is included a ready-to-use GRASS build environment with
all dependencies [2].

all winGRASS-binaries (OSGeo4W, standalone installers) are based upon this
OSGeo4W build environment.

[1] http://trac.osgeo.org/osgeo4w/
[2] http://trac.osgeo.org/grass/wiki/CompileOnWindows

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5144586.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

martinl · June 8, 2014, 9:50am

2014-06-07 18:28 GMT+02:00 Glynn Clements <glynn@gclements.plus.com>:

[...]

Right, anyway it's not the first time you broken Windows builds
without any attempt to fix (or even attempt to understand what you
broke - it requires that you at least install GRASS on your Windows
machine). The last example which I can mention is the problem with
calling python script from python script. I was forced to locally
patch winGRASS 7 for several months to make it working (it was used by
many of us in our lessons). From this perspective you simply don't
care..., you just revert without proposing any other working solution.

On Unix, you'd expect developers to just build from source. But on
Windows, getting a development environment set up is a lot more
effort, so having access to binaries is still useful for developers.

Right, that was the main reason why I put quite a lot of energy and my
time to create environment for producing daily builds for Windows. And
you can guess, I am not Windows user. Why I spent my time on that
including fixing some Windows-related bugs? The main reason is that
GRASS project needs good support on Windows. I would prefer to spend
my time on other more interesting issues, as you can probably guess.

But you're the one hosting them (or not), so it's your call.

Right, and try to guess why? Because nobody wanted to do that, so I
did. Don't ask me to do more for Windows, and please don't break GRASS
on this platform regularly as you are doing. It's simply not my call!

The person who introduced the complete break [3] simply doesn't
care.

No, that's not true. However, my Windows system is still rather
inadequate as a development platform (it does now have the base
MinGW/MSys installation, but not the libraries required to build
GRASS).

Feel free to invest your time to make it better, just reverting or
blocking is not the way. If you are not able to find such time, please
tell us and don't continue reverting our attempts to make it working.

It doesn't absolutely *have* to be me who fixes it. I don't even use
Windows as a development platform for my own purposes. If Windows

Huh, I know probably only one GRASS developer here who uses Windows
regularly, other people use GNU/Linux. From this perspective we
haven't had any daily builds on Windows, because nobody would set it
up.

The changes required to Script.make and/or ScriptRules.make to create
batch files aren't exactly rocket science, but testing them would be
much easier for someone who has a Windows system which can actually
build GRASS.

Cool, if you are reverting other attempts you could probably find some
time to implement it even it's not "exactly rocket science". The
discussion about this topic has probably tens of e-mails with
guessable result. You were proposed bat-files at the beginning, no
consensus, no other way. Never ending "discussions" with no result.

Martin

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

Glynn_Clements1 · June 9, 2014, 9:01am

Martin Landa wrote:

Cool, if you are reverting other attempts you could probably find some
time to implement it even it's not "exactly rocket science". The
discussion about this topic has probably tens of e-mails with
guessable result. You were proposed bat-files at the beginning, no
consensus, no other way. Never ending "discussions" with no result.

Are you referring to this thread, or the "Handling of Python scripts
on MS Windows" thread from the last couple of months.

The latter concluded (in spite of my initial resistance) that we would
probably need to use batch files to deal with the fact that we can't
rely upon the .py extension being associated with the correct
interpreter.

If scripts are invoked via batch files, there's no point in setting
shell=True, as batch files don't need it, and it would result in the
shell's argument-parsing being applied a second time.

The bottom line is that batch files need to be generated, they aren't
being generated yet, and intermediate stop-gap measures (i.e.
shell=True) don't actually get us any closer to the end result (they
just give that impression, provided that you aren't paying too much
attention).

--
Glynn Clements <glynn@gclements.plus.com>

martinl · July 1, 2014, 12:00pm

2014-06-09 11:01 GMT+02:00 Glynn Clements <glynn@gclements.plus.com>:

beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...

Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 31,
in <module>
    from core import globalvar
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py", li
ne 29, in <module>
    from core.debug import Debug
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 6
6, in <module>
    Debug = DebugMsg()
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 3
7, in __init__
    self.SetLevel()
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 4
2, in SetLevel
    self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 998, in gisenv
    s = read_command("g.gisenv", flags='n')
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 400, in read_command
    ps = pipe_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 375, in pipe_command
    return start_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 334, in start_command
    return Popen(args, **popts)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 711, in __init__
    errread, errwrite)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 948, in _execute_chil
d
    startupinfo)

Martin

[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

lucadelu · July 1, 2014, 1:05pm

On 1 July 2014 14:00, Martin Landa <landa.martin@gmail.com> wrote:

2014-06-09 11:01 GMT+02:00 Glynn Clements <glynn@gclements.plus.com>:

beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...

Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 31,
in <module>
    from core import globalvar
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py", li
ne 29, in <module>
    from core.debug import Debug
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 6
6, in <module>
    Debug = DebugMsg()
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 3
7, in __init__
    self.SetLevel()
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py", line 4
2, in SetLevel
    self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 998, in gisenv
    s = read_command("g.gisenv", flags='n')
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 400, in read_command
    ps = pipe_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 375, in pipe_command
    return start_command(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", l
ine 334, in start_command
    return Popen(args, **popts)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 711, in __init__
    errread, errwrite)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 948, in _execute_chil
d
    startupinfo)

I just upload to a friend and it has the same problem

Martin

[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org