Re: [Bf-committers] *** GMX Spamverdacht *** Re: Syntax error in export_3ds.py

2012-07-09 Thread CoDEmanX
My bad! Turned it back into utf8, hope it's ok now.

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=3602


Am 08.07.2012 15:55, schrieb IRIE Shinsuke:
> Hi CoDEmanX,
>
> r3595 causes another error:
>
> Traceback (most recent call last):
> File "/usr/lib/python3.2/runpy.py", line 160, in _run_module_as_main
>   "__main__", fname, loader, pkg_name)
> File "/usr/lib/python3.2/runpy.py", line 73, in _run_code
>   exec(code, run_globals)
> File "/usr/lib/python3.2/py_compile.py", line 187, in 
>   sys.exit(main())
> File "/usr/lib/python3.2/py_compile.py", line 169, in main
>   compile(filename, doraise=True)
> File "/usr/lib/python3.2/py_compile.py", line 116, in compile
>   codestring = f.read()
> File "/usr/lib/python3.2/codecs.py", line 300, in decode
>   (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 905: 
> invalid continuation byte
>
>
> export_3ds.py was accidentally saved with non UTF-8 character encoding.
>
> 12/07/08, CoDEmanX wrote:
>> Commited fix:
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=3595
>>
>> Should now work as expected.
>>
>> Thanks for reporting!
>>
>>
>> Am 08.07.2012 06:08, schrieb IRIE Shinsuke:
>>> Hi,
>>>
>>> When I was byte-compiling release/scripts/addons/ (r3577), I got a
>>> syntax error in io_scene_3ds/export_3ds.py as follows:
>>>
>>> File 
>>> "/usr/share/blender/2.63/scripts/addons/io_scene_3ds/export_3ds.py", line 
>>> 227
>>>   """
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>
>>>
>>>   ^
>>> SyntaxError: invalid syntax
>>>
>>>
>>> The triple-quotes """...""" are enclosed by the same style of
>>> triple-quotes:
>>>
>>> """
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>   __slots__ = ...
>>>
>>> """
>>>
>>> so the inside of the inner ones is not a string literal.
>>> Please use the different style of triple-quotes like below:
>>>
>>> '''
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>   __slots__ = ...
>>>
>>> '''
>>>
>>> Anyway, I think triple-quotes shouldn't be used to comment out
>>> multiple lines.
>>>
>>
>
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Change of MinGW64 compiler

2012-07-09 Thread Antony Riakiotakis
>
> About the issue with the crash,
>

This is the previous crash on render, not the one related to pthreads. The
new dll libraries are needed because of the new compiler build (code
compiled with it willl expect these dlls). It may be possible to ommit some
of these if all libraries are recompiled with
static-libgcc/static-libstcc++ but pthread will always be necessary I'm
afraid, and specific to the mingw64 build we are using :/. Same with
libgomp.dll (openmp related).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Change of MinGW64 compiler

2012-07-09 Thread Antony Riakiotakis
This is an issue with the buildbot, it will need to be updated with the new
compiler.

About the issue with the crash, it is related to image paths that are not
found. I did some research during the weekend without success. cmake builds
do -not- have this problem so I suspect it may be a lib order issue/missing
define or something similar. I will try to find some way to fix this
(probably through a lot of trial and error/recompiling libraries etc) but
given that I am in the middle of gsoc right now it may take a while :/ .
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Change of MinGW64 compiler

2012-07-09 Thread Caleb Joseph
Some debugging reveals that the crash is caused by the 
pthreadGC2-w64.dll library that is included with the buildbot builds. I 
have no idea how this library made its way into the build, it is not 
needed for building, nor part of MinGW-w64 or the Blender mingw64 
library repository. This is definitely an issue with the buildbot, not 
the compiler or Blender code base.

On 9/07/2012 7:54 PM, Constantin Rahn wrote:
> Hi,
>
> the current build bot mingw win64 r48748 crashes on startup. Confirmed
> by JesterKing on IRC.
> "jesterKing: 48700 already crashes on startup. I'm guessing it has to do
> with the dlls that are now used in mingw64 builds (gomp, gcc_s_sjlj,
> winpthread, stdc++-6)"
>
> Could this be a problem with your latest changes?
> Who could fix this? Blender Developers (maybe you) or is it a problem on
> the mingw side?
>
> Happy blending
> Conz
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Change of MinGW64 compiler

2012-07-09 Thread Constantin Rahn
Hi,

the current build bot mingw win64 r48748 crashes on startup. Confirmed 
by JesterKing on IRC.
"jesterKing: 48700 already crashes on startup. I'm guessing it has to do 
with the dlls that are now used in mingw64 builds (gomp, gcc_s_sjlj, 
winpthread, stdc++-6)"

Could this be a problem with your latest changes?
Who could fix this? Blender Developers (maybe you) or is it a problem on 
the mingw side?

Happy blending
Conz

Am 05.07.2012 03:39, schrieb Antony Riakiotakis:
> Hi,
>
> I am preparing a major update of libraries and a change of the supported
> compiler to resolve the crashes that occur with subsurf/multires when
> compiling with openmp. This one will be used:
>
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/release/x86_64-w64-mingw32-gcc-4.7.1-release-win64_rubenvb.7z/download
>
> Ruben's builds are the closest thing to "release" builds. Unfortunately it
> requires SSE 3 (pentium 4 prescott+) to run but, given that blender may
> take easily 2GB to link (== a recent pc) and that prescott is about 8 years
> old I think it's a safe change.
> This compiler should already work and subsurf rendering will not crash if
> compiled with openmp, however there may be some crashes on exit with
> openexr. I have already compiled openexr with this build and it works OK
> here. I will also update libpng and openimageio using the recompiled
> openexr.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers