some Italian users notice that r.li modules are not active in GRASS
GIS 6.4.4 on windows, is this correct?
On the GRASS GIS 6.4.4 release announce there is "release include a
complete rewrite of the r.li suite"
some Italian users notice that r.li modules are not active in GRASS
GIS 6.4.4 on windows, is this correct?
On the GRASS GIS 6.4.4 release announce there is "release include a
complete rewrite of the r.li suite"
you are right, I would thought that author of r.li.* updates checked
also availability on Windows. I will try to check what is wrong with
the installer.
On 27 June 2014 16:11, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
Hi
you are right, I would thought that author of r.li.* updates checked
also availability on Windows. I will try to check what is wrong with
the installer.
you are right, I would thought that author of r.li.* updates checked
also availability on Windows. I will try to check what is wrong with
the installer.
r.li modules are not simply built on Windows [1]. Any idea why? Martin
On Fri, Jun 27, 2014 at 10:41 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi,
2014-06-27 16:36 GMT+02:00 Luca Delucchi <lucadeluge@gmail.com>:
>> you are right, I would thought that author of r.li.* updates checked
>> also availability on Windows. I will try to check what is wrong with
>> the installer.
r.li modules are not simply built on Windows [1]. Any idea why? Martin
I don't know but I hope that the authors discovered by svn blame know.
Anyway, blame is such a funny name for a command. Trac's annotate is boring.
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. I believe in the new
backported version of r.li those things are all removed now so it could
have the conditional removed from the Makefile and the modules tested
in a nightly WinGrass build. If it works I'd suggest a setup_6.4.4-2.exe
release be prepared with an altered Makefile. The source code isn't
touched so it wouldn't introduce any platform dependent behavior which
would need a new point release, instead it would only reduce platform
differences.
Luca:
I would thought that 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.
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. I believe in the new
r.li modules enabled in grass64 in r61153. Please test next build of
grass64-dev (no.13). Martin
> 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 next build of
grass64-dev (no.13).
Thanks. I am unable to test for the next weeks, but would appreciate if
someone else could try it.
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. I believe in the new
r.li modules enabled in grass64 in r61153. Please test next build of
grass64-dev (no.13). Martin
> 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 next build of
grass64-dev (no.13).
Thanks. I am unable to test for the next weeks, but would appreciate if
someone else could try it.
regards,
Hamish
_______________________________________________
grass-dev mailing list
couldn't execute "printenv": no such file or directory
while executing
"exec printenv HOME"
invoked from within
"set env(HOME)[exec printenv HOME]"
(file
"C:\OSGeo4W\apps/grass/grass-6.4.5svn/etc/r.li.setup/r.li.setup.main"
line 27)
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. I believe in the new
r.li modules enabled in grass64 in r61153. Please test next build of
grass64-dev (no.13). Martin
I am getting the same dialog on Linux when launching the module from
menu. When launching the module from wxGUI command line I am getting
different dialog (Tcl/Tk configuration tool). Martin
I am getting the same dialog on Linux when launching the module from
menu. When launching the module from wxGUI command line I am getting
different dialog (Tcl/Tk configuration tool). Martin
launching the module r.li.setup from wxGUI command line, an error message
pops up (already mentioned in this thread):
couldn't execute "printenv": no such file or directory
while executing
"exec printenv HOME"
invoked from within
"set env(HOME)[exec printenv HOME]"
(file
"C:\OSGeo4W\apps/grass/grass-6.4.5svn/etc/r.li.setup/r.li.setup.main"
line 27)
with r.li.setup --ui, the empty r.li.setup-wxgui pops up.
I am getting the same dialog on Linux when launching the module from
menu. When launching the module from wxGUI command line I am getting
different dialog (Tcl/Tk configuration tool). Martin
although the path to the conf file is given, it seems it's hard coded where
the r.li.*-module looks for the conf file (see doubling the path in the
error message)
manually creating the .r.li-folder where the module looks for and manually
putting there the conf file, the r.li.*-module is working:
I am getting the same dialog on Linux when launching the module from
menu. When launching the module from wxGUI command line I am getting
different dialog (Tcl/Tk configuration tool). Martin
although the path to the conf file is given, it seems it's hard coded where
the r.li.*-module looks for the conf file (see doubling the path in the
error message)
manually creating the .r.li-folder where the module looks for and manually
putting there the conf file, the r.li.*-module is working: