Re: [GRASS-dev] grass7 on mac OSX
William Kyngesburye wrote:
> I had to restore the -U __GNUC__. Without it, I get a lot of syntax
> errors in GRASS headers.
Right; that will be due to this:
#if !defined __GNUC__ || __GNUC__ < 2
#undef __attribute__
#define __attribute__(x)
#endif
If __GNUC__ is defined, the __attribute__ declarations will be
retained, which ctypesgen won't like. This will cause it to omit
wrappers for any function with an __attribute__ declaration; most of
these are __attribute__((format,...)), i.e. G_message() etc.
G_fatal_error() also has __attribute__((noreturn)).
> With, though I get that unknown architecture
> error in nviz.py. The ctypesgen authors seem to be aware of and patch
> OSX issues, but maybe they never tried it with system framework headers.
But does this prevent the generation of the wrapper?
> Besides that, both with and without __GNUC__, there is the escape error
> in nviz.py:
> ValueError: invalid \x escape in ".HFS+ Private Directory Data\xd"
Right; my proposed fix (r42484) should handle that.
> I found that string in /usr/include/hfs/hfs_format.h:
>
> #define HFSPLUS_DIR_METADATA_FOLDER ".HFS+ Private Directory Data\xd"
>
> Probably included somewhere in the trail from ApplicationServices.h.
> Looks like a single-digit escape, so I tried your re.sub above. It then
> makes it thru that ValueError, but then there are tons of syntax errors
> in system headers. One example:
>
> Error:
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:820:
> Syntax error at '{'
> Error:
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:821:
> Syntax error at '>='
>
> This is the code there:
>
> CF_INLINE Boolean CFStringIsSurrogateHighCharacter(UniChar character) {
> return ((character >= 0xD800UL) && (character <= 0xDBFFUL) ? true :
> false);
> }
>
> There are more similar CF_INLINE definitions earlier, but they are
> inside a #ifdef CF_INLINE.
But do these prevent the wrapper from being generated, or result in it
missing necessary definitions?
ctypesgen ignores errors from the preprocessor (it doesn't capture
stderr and doesn't care about the exit code). Errors only matter
insofar as they cause significant declarations to be omitted or
malformed.
The ValueError is different as that's an exception being raised within
ctypesgen itself; r42484 should deal with that.
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as nviz_tools: ImportError
Helmut Kudrnovsky wrote: > WARNING: Nviz extension (3D view mode) disabled. Reason: grass_datetime not > found. Does PATH include the %WINGISBASE%\lib directory? And does libgrass_datetime.dll exist in that directory? -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
On Jun 4, 2010, at 1:04 PM, Glynn Clements wrote:
>
> Barton Michael wrote:
>
>> Once you or others think there is a potential fix for GRASS for OSX,
>> I'm happy to give it a try.
>
> Can you try the latest version? It will still fail, but it should
> provide more information (specifically, the "invalid \x escape"
> exception should now report the string that it's trying to decode).
>
> ctypesgen ignores errors from the preprocessor, but errors within
> ctypesgen itself (e.g. the decoding error) tend to be fatal.
>
> FWIW, the code acknowledges that the decoding may not be quite right
> (it decodes string literals according to Python's syntax, which is
> modelled on C but may have subtle differences):
>
># Unescaping probably not perfect but close enough.
>value = value[1:-1].decode('string_escape')
>
> The Python language reference says of \x escapes:
>
> Unlike in Standard C, exactly two hex digits are required
>
> Assuming that's the issue, it should suffice to replace the above
> with:
>
> try:
> value = value[1:-1].decode('string_escape')
> except ValueError, e:
> value = re.sub(r'\\x([0-9a-fA-F])(?![0-9a-fA-F])',
> r'\x0\1',
> value[1:-1]).decode('string_escape')
>
I had to restore the -U __GNUC__. Without it, I get a lot of syntax errors in
GRASS headers. With, though I get that unknown architecture error in nviz.py.
The ctypesgen authors seem to be aware of and patch OSX issues, but maybe they
never tried it with system framework headers.
Besides that, both with and without __GNUC__, there is the escape error in
nviz.py:
Error: gcc -E:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/FixMath.h:93:6:
error: #error "Unknown architecture."
Traceback (most recent call last):
File "./ctypesgen.py", line 134, in
descriptions=ctypesgencore.parser.parse(options.headers,options)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/__init__.py",
line 21, in parse
parser.parse()
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py",
line 67, in parse
ctypesparser.CtypesParser.parse(self,f.name,None)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/cparser.py",
line 113, in parse
self.preprocessor_parser.parse(filename)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
line 195, in parse
token = self.lexer.token()
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
line 51, in token
result = lex.Lexer.token(self)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/lex.py",
line 297, in token
newtok = func(tok)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
line 237, in t_ANY_string_literal
t.value = StringLiteral(t.value)
File
"/Users/Shared/src/GRASS/svn/trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
line 63, in __new__
raise ValueError("invalid \\x escape in %s" % value)
ValueError: invalid \x escape in ".HFS+ Private Directory Data\xd"
I found that string in /usr/include/hfs/hfs_format.h:
#define HFSPLUS_DIR_METADATA_FOLDER ".HFS+ Private Directory Data\xd"
Probably included somewhere in the trail from ApplicationServices.h. Looks
like a single-digit escape, so I tried your re.sub above. It then makes it
thru that ValueError, but then there are tons of syntax errors in system
headers. One example:
Error:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:820:
Syntax error at '{'
Error:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:821:
Syntax error at '>='
This is the code there:
CF_INLINE Boolean CFStringIsSurrogateHighCharacter(UniChar character) {
return ((character >= 0xD800UL) && (character <= 0xDBFFUL) ? true : false);
}
There are more similar CF_INLINE definitions earlier, but they are inside a
#ifdef CF_INLINE.
-
William Kyngesburye
http://www.kyngchaos.com/
The equator is so long, it could encircle the earth completely once.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
Started compilation: Ven 4 Giu 2010 21:08:54 CEST
--
Errors in:
/Users/Shared/source/grass_trunk/lib/python/default
/Users/Shared/source/grass_trunk/gui/wxpython
/Users/Shared/source/grass_trunk/visualization/nviz
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Ven 4 Giu 2010 21:18:34 CEST
make: *** [default] Error 1
host-001:grass_trunk sasha$ cd
/Users/Shared/source/grass_trunk/lib/python/default
-bash: cd: /Users/Shared/source/grass_trunk/lib/python/default: No such file or
directory
host-001:grass_trunk sasha$
cd /Users/Shared/source/grass_trunk/lib/python
make
...
make[2]: `date.py' is up to date.
make[2]: `grass.py' is up to date.
make[2]: `raster.py' is up to date.
make[2]: `gmath.py' is up to date.
make[2]: `proj.py' is up to date.
make[2]: `imagery.py' is up to date.
make[2]: `vector.py' is up to date.
make[2]: `display.py' is up to date.
make[2]: `stats.py' is up to date.
make[2]: `dbmi.py' is up to date.
make[2]: `g3d.py' is up to date.
make[2]: `arraystats.py' is up to date.
make[2]: `cluster.py' is up to date.
make[2]: `trans.py' is up to date.
make[2]: `vedit.py' is up to date.
make[2]: `ogsf.py' is up to date.
GISRC=/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/demolocation/.grassrc70
GISBASE=/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0
PATH="/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/bin:$PATH"
PYTHONPATH="/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/etc/python:$PYTHONPATH"
DYLD_LIBRARY_PATH="/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/bin:/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/lib:/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/lib:/Users/Shared/source/tables-2.1.2/tables/"
LC_ALL=C ./ctypesgen.py
-I/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/include
-I/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/include
-lgrass_nviz
/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/include/grass/nviz.h
-o nviz.py
Status: Preprocessing
/var/folders/G7/G7KYb9O2GaGW2zFTZZP9nE+++TI/-Tmp-/tmps7WNie.h
Status: gcc -E -U __BLOCKS__ -dD
-I/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/include
-I/Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/include
"-Dinline=" "-D__inline__=" "-D__extension__=" "-D_Bool=uint8_t"
"-D__const=const" "-D__asm__(x)=" "-D__asm(x)=" "-DCTYPESGEN=1"
"-D__uint16_t=uint16_t" "-D__uint32_t=uint32_t" "-D__uint64_t=uint64_t"
/var/folders/G7/G7KYb9O2GaGW2zFTZZP9nE+++TI/-Tmp-/tmps7WNie.h
Traceback (most recent call last):
File "./ctypesgen.py", line 134, in
descriptions=ctypesgencore.parser.parse(options.headers,options)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/__init__.py",
line 21, in parse
parser.parse()
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py",
line 67, in parse
ctypesparser.CtypesParser.parse(self,f.name,None)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/cparser.py",
line 113, in parse
self.preprocessor_parser.parse(filename)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
line 197, in parse
token = self.lexer.token()
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
line 51, in token
result = lex.Lexer.token(self)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/lex.py",
line 297, in token
newtok = func(tok)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
line 237, in t_ANY_string_literal
t.value = StringLiteral(t.value)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
line 63, in __new__
raise ValueError("invalid \\x escape in %s" % value)
ValueError: invalid \x escape in ".HFS+ Private Directory Data\xd"
make[2]: *** [nviz.py] Error 1
make[1]: *** [default] Error 2
host-001:python sasha$
i tried to change in
grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py to :
class StringLiteral(str):
def __new__(cls, value):
assert value[0] == '"' and value[-1] == '"'
# Unescaping probably not perfect but close enough.
try:
value = value[1:-1].decode('string_escape')
except ValueError, e:
value = re.sub(r'\\x([0-9a-fA-F])(?![0-9a-fA-F])', r'\x0\1',
value[1:-1]).decode('string_escape')
return str.__new__(cls, value)
but print out a lot of syntax errors,
maybe i changed it wrong,
if usefull i can try to rebuild and attach the
Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as nviz_tools: ImportError
-Ursprüngliche Nachricht-
Von: Glynn Clements
Betreff: Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as
nviz_tools: ImportError
>Helmut Kudrnovsky wrote:
>
>> hi,
> >
> >>Ursprüngliche Nachricht-
> >V>on: Martin Landa
> >
> >>probably yes, I will do some testing in trunk (ctypes are currently
> >>available only in trunk).
> >
> >I've tested it with WinGRASS-7.0.SVN-r42451-1-Setup.exe (nightly build) and
> >the nc-sample-dataset.
> >
> >the 3d-view-tab is opened in the layer manager, but i get following error
> >message:
>
>> File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
> >mingw32/etc/gui/wxpython/gui_modules/wxnviz.py", line 43, in
> >__init__
> >G_gisinit("")
>> NameError: global name 'G_gisinit' is not defined
>
>This implies that the grass.lib.grass module wasn't built correctly.
I've build the WinGrass7-installer (r42482) for myself (WinVista32).
WinGrass7 is starting and working (beside the wxnviz), in the
windows-command-console I get following:
"Cleaning up temporary files...
Starting GRASS GIS...
WARNUNG: Attention!
WARNUNG: Locking is not supported on Windows!
__ ___ _____
/ / __ \/ | / ___/ ___/ / / _/ ___/
/ / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \
/ /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ /
\/_/ |_/_/ |_/// \/___///
Welcome to GRASS 7.0.svn (2010)
GRASS homepage: http://grass.osgeo.org
This version running through:shell (C:\Program
Files\GRASS-70-SVN\msys\bin\sh.exe)
Help is available with the command: g.manual -i
See the licence terms with: g.version -c
If required, restart the GUI with: g.gui wxpython
When ready to quit enter:exit
GRASS 7.0.svn>
WARNING: Vector digitizer is not available (No module named grass7_wxvdigit).
Note that the vector digitizer is currently not working under MS Windows
(hopefully this will be fixed soon). Please keep an eye out for updated
versions of GRASS.
WARNING: Nviz extension (3D view mode) disabled. Reason: grass_datetime not
found.
GRASS 7.0.svn>"
So the 3d-view-mode seems to be disabled, because grass_datetime isn't found.
The compilation log says, there are no errors:
"GRASS GIS compilation log
-
Started compilation: Fri Jun 4 16:31:13 GMT 2010
--
Errors in:
No errors detected.
--
Finished compilation: Fri Jun 4 17:36:14 GMT 2010"
best regards
Helmut
___
NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
http://produkte.web.de/go/02/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
Barton Michael wrote:
> Once you or others think there is a potential fix for GRASS for OSX,
> I'm happy to give it a try.
Can you try the latest version? It will still fail, but it should
provide more information (specifically, the "invalid \x escape"
exception should now report the string that it's trying to decode).
ctypesgen ignores errors from the preprocessor, but errors within
ctypesgen itself (e.g. the decoding error) tend to be fatal.
FWIW, the code acknowledges that the decoding may not be quite right
(it decodes string literals according to Python's syntax, which is
modelled on C but may have subtle differences):
# Unescaping probably not perfect but close enough.
value = value[1:-1].decode('string_escape')
The Python language reference says of \x escapes:
Unlike in Standard C, exactly two hex digits are required
Assuming that's the issue, it should suffice to replace the above
with:
try:
value = value[1:-1].decode('string_escape')
except ValueError, e:
value = re.sub(r'\\x([0-9a-fA-F])(?![0-9a-fA-F])',
r'\x0\1',
value[1:-1]).decode('string_escape')
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
Once you or others think there is a potential fix for GRASS for OSX, I'm happy
to give it a try.
MIchael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Jun 4, 2010, at 7:01 AM, Glynn Clements wrote:
>
> William Kyngesburye wrote:
>
i applied the patch and tried to rebuild (after make distclean)
File
"/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
line 60, in __new__
value = value[1:-1].decode('string_escape')
ValueError: invalid \x escape
>>>
>>> This looks like an issue with Apple's "C" headers being incompatible
>>> with anything other than Apple's version of gcc.
>>>
>>> I think that it's going to need someone with a Mac to investigate the
>>> issues and make the necessary changes to ctypesgen to either support
>>> Apple's "enhanced" C dialect, or to provide the necessary switches to
>>> disable the enhancements (if such switches exist).
>>
>> Apple's GCC is GCC. The preprocessor is custom. When I looked into
>> ctypesgen, it says it uses the preprocessor.
>
> It does (via "gcc -E").
>
>> Did you take a trunk snapshot of ctypesgen? When? I see a lot of
>> differences between the current ctypesgen trunk and the copy in GRASS
>> trunk. The last batch of changes was in March. And there is a OS X
>> 10.6-specific fix in there (adding -U __BLOCKS__ to the parse command).
>
> The version in GRASS is r72 (the version I have installed via Gentoo).
> Martin was having problems with the latest trunk version.
>
>> What I'm seeing so far is that there are errors in lib/python/ctypes
>> that are not showing up in the GRASS error log, so Michael and Massimo
>> might have missed them.
>
> An error building lib/python/ctypes is currently non-fatal, as it
> isn't used for anything except wxNVIZ.
>
>> Removing the -U __GNUC__ causes even more errors.
>
> So do we remove it or keep it? I can only guess that the #error's were
> being triggerd by __GNUC__ being undefined. Is there some other
> setting which will work?
>
>> Adding the -U
>> __BLOCKS__ bit that's in trunk removes a couple errors. Using ctypesgen
>> trunk does no more than adding the -U __BLOCKS__ bit.
>
> I'll add that.
>
>> Errors I'm getting (after adding the -U __BLOCKS__ change):
>>
>> - gprojects.h (from proj.py) can't find proj_api.h or ogr_srs_api.h -
>> their -I's are not in the ctypesgen preprocessor command
>>
>> - same for ogr and geos headers in vector.py and vedit.py
>
> Okay; I've added these.
>
>> - nviz.py: /usr/include/TargetConditionals.h:284:10: error: #error
>> TargetConditionals.h: unknown compiler
>> (probably included from needing AGL and Application Services headers
>> from the system)
>> this appears to be caused by undefining __GNUC__, but leaving __GNUC__
>> defined causes lots of syntax errors in system headers, which spill into
>> grass headers. I don't know how this can be fixed.
>
> The question is whether the errors are recoverable. I don't think
> we'll know that until we deal with the ValueError issue.
>
>> proj.py, vector.py and vedit.py still get created, though I don't know
>> if they work. nviz.py has a ValueError: invalid \x escape, and doesn't
>> get created
>
> Can you provide more details? It should be possible to modify
> ctypesgen to recover from this.
>
>> (make error, yet it doesn't get caught by the grass error
>> log).
>
> An error in the ctypes subdirectory should now be logged.
>
> --
> Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as nviz_tools: ImportError
Helmut Kudrnovsky wrote: > >This looks like a packaging issue. > > maybe any hints where (which files) to look for this path-issues in > order to fix this in the nsis-installer? The source file is lib/init/grass.py. This is installed to bin./grass70 (grass70.py on Windows) with some substitutions. It is also installed to dist./grass70.tmp, with most of the substitutions but with @GISBASE@ left as-is. Install.make installs dist./grass70.tmp to $(UNIX_BIN), with @GISBASE@ substituted by the actual install directory. I note the following in mswindows/GRASS-Installer.nsi: ;replace gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.svn" in grass70.py with $INSTDIR Push "$INSTDIR\grass70.py" ; file to modify Push 'gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.svn"' ; string that a line must begin with *WS Sensitive* Push 'gisbase = "$INSTDIR"' ; string to replace whole line with Call ReplaceLineStr -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as nviz_tools: ImportError
-Ursprüngliche Nachricht- Von: Glynn Clements Betreff: Re: [GRASS-dev] WinGrass65 + import gui_modules.nviz_tools as nviz_tools: ImportError [...] >This looks like a packaging issue. maybe any hints where (which files) to look for this path-issues in order to fix this in the nsis-installer? best regards Helmut ___ NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit! http://produkte.web.de/go/02/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
