Re: Python 3.x progress

On Wed, Jan 8, 2014 at 11:07 AM, Andy Robinson <[email protected]> wrote:
>
> Dinu, thanks for this.  It's probably "too late" since the code is now
> working 100% on both Python 2.7 and Python 3.3
>
> I should have announced this at the weekend, but we have also removed
> the temporary dependency on pyRXP which we introduced during the port.
>   All pararaphs are now parsed by html.parser.HTMLParser in the
> standard library, with xmllib gone forever.
>
> This week and next are rather crazy with year-end reporting projects
> for clients, but in the second half of the month we will switch this
> to default somehow, create the 'whant's new' page, create alpha
> releases and start updating the docs.  For now, if anyone wants to
> pull and update to the py33 branch, we would welcome feedback.
>
> - Andy

Hi Andy,

Is this expected to work on Mac OS X yet? Or, does it require a
specific revision of Python 3.3 - as I'm running into some problems:

Mac OS X, using hg from Mercurial-2.8.2-py2.7-macosx10.9.zip
and Apple Xcode from App Store, using a self compiled Python
version 3.3.0 under $HOME/bin,

$ hg clone ssh://[email protected]/rptlab/reportlab
$ cd reportlab
$ hg checkout py33
$ hg log -b py33 | head
changeset:   3972:b5870c0f3eb4
branch:      py33
tag:         tip
user:        robin
date:        Wed Jan 08 17:56:06 2014 +0000
summary:     patches from Matthias Klose

$ python3 setup.py build
...
$ python3 setup.py test
...
error: invalid command 'test'

Hmm. Pressing on,

$ python3 -c "import reportlab; print(reportlab.__file__);
print(reportlab.__version__)"
/Users/peterjc/lib/python3.3/site-packages/reportlab/__init__.py
 $Id$

Actually installing it,

$ python3 setup.py install
$ cd
$ python3 -c "import reportlab; print(reportlab.__file__);
print(reportlab.__version__)"
/Users/peterjc/lib/python3.3/site-packages/reportlab/__init__.py
 $Id$

So far so good, although there are some unicode related glitches
causing failures in the Biopython unit tests using ReportLab, which
I will look into (they may be problems on the Biopython side).

However, there is a problem trying to use Python interactively:

$ python3
Python 3.3.0 (default, Sep 29 2012, 19:41:44)
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import reportlab
>>> reportlab.__version__
Segmentation fault: 11


Weird. Also,

$ python3
Python 3.3.0 (default, Sep 29 2012, 19:41:44)
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import reportlab
>>> import sys
Segmentation fault: 11

Clearly something is badly amiss. There are some potentially
important warnings from the compilation step, including type
conversion (ssize_t, integers and longs), plus:

/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-parset1.c:604:28:
warning: for loop has empty body [-Wempty-body]
        for (i = 0; i < size; i++);
                                  ^
/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-parset1.c:604:28:
note: put the semicolon on a separate line to silence this warning

That looks like a real bug in the debug function print_string, possible
fix at end of email.

More worrying - perhaps (header problem?):

/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-namecontext.c:100:9:
warning: implicitly declaring library function 'strlen' with
      type 'unsigned long (const char *)'
  len = strlen (s);
        ^
/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-namecontext.c:100:9:
note: please include the header <string.h> or explicitly
      provide a declaration for 'strlen'
/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-namecontext.c:102:3:
warning: implicitly declaring library function 'memcpy' with
      type 'void *(void *, const void *, unsigned long)'
  memcpy (new, s, len);
  ^
/Users/peterjc/repositories/reportlab/src/rl_addons/renderPM/gt1/gt1-namecontext.c:102:3:
note: please include the header <string.h> or explicitly
      provide a declaration for 'memcpy'


This is odd, since it should be included via
src/rl_addons/renderPM/gt1/gt1-misc.h

#ifdef macintosh
#include <string.h> /* for memcpy() */
#endif

However, manually adding the include does not alter the
segmentation fault.

Any thoughts? Do you want the full build output?

Regards,

Peter

--

Trivial proposed fix to the print_string function,

$ hg diff src/rl_addons/renderPM/gt1/gt1-parset1.c
diff -r b5870c0f3eb4 src/rl_addons/renderPM/gt1/gt1-parset1.c
--- a/src/rl_addons/renderPM/gt1/gt1-parset1.c Wed Jan 08 17:56:06 2014 +0000
+++ b/src/rl_addons/renderPM/gt1/gt1-parset1.c Thu Jan 09 11:22:44 2014 +0000
@@ -601,7 +601,7 @@
  start = str->start;
  size = str->size;

- for (i = 0; i < size; i++);
+ for (i = 0; i < size; i++)
  printf ("%c", start[i]);
 }