diff options
| author | Stefan Behnel <stefan_ml@behnel.de> | 2016-06-12 09:17:37 +0200 |
|---|---|---|
| committer | Stefan Behnel <stefan_ml@behnel.de> | 2016-07-15 08:19:53 +0200 |
| commit | 61cf621658f91c52aaf810f82b0691c920f36122 (patch) | |
| tree | d31192e106dc8623d415c62ab6819680600e8a66 | |
| parent | 25de842f66930dafe1ce85b3e607826b4519af10 (diff) | |
| download | cython-61cf621658f91c52aaf810f82b0691c920f36122.tar.gz | |
adapt some line endings to standard Unix style
| -rw-r--r-- | Demos/callback/README.txt | 13 | ||||
| -rw-r--r-- | Demos/callback/cheesefinder.h | 3 | ||||
| -rw-r--r-- | Doc/About.html | 172 | ||||
| -rw-r--r-- | Doc/index.html | 75 | ||||
| -rw-r--r-- | Doc/primes.c | 143 | ||||
| -rw-r--r-- | Doc/s5/ui/default/print.css | 48 |
6 files changed, 425 insertions, 29 deletions
diff --git a/Demos/callback/README.txt b/Demos/callback/README.txt index fa3b871ce..8e8abdf29 100644 --- a/Demos/callback/README.txt +++ b/Demos/callback/README.txt @@ -1 +1,12 @@ -This example demonstrates how you can wrap a C API
that has a callback interface, so that you can
pass Python functions to it as callbacks.
The files cheesefinder.h and cheesefinder.c
represent the C library to be wrapped.
The file cheese.pyx is the Pyrex module
which wraps it.
The file run_cheese.py demonstrates how to
call the wrapper.
\ No newline at end of file +This example demonstrates how you can wrap a C API +that has a callback interface, so that you can +pass Python functions to it as callbacks. + +The files cheesefinder.h and cheesefinder.c +represent the C library to be wrapped. + +The file cheese.pyx is the Pyrex module +which wraps it. + +The file run_cheese.py demonstrates how to +call the wrapper. diff --git a/Demos/callback/cheesefinder.h b/Demos/callback/cheesefinder.h index 3c31bdc08..0524dee0c 100644 --- a/Demos/callback/cheesefinder.h +++ b/Demos/callback/cheesefinder.h @@ -1 +1,2 @@ -typedef void (*cheesefunc)(char *name, void *user_data);
void find_cheeses(cheesefunc user_func, void *user_data);
\ No newline at end of file +typedef void (*cheesefunc)(char *name, void *user_data); +void find_cheeses(cheesefunc user_func, void *user_data); diff --git a/Doc/About.html b/Doc/About.html index 37cfb2ecb..ff2ae3feb 100644 --- a/Doc/About.html +++ b/Doc/About.html @@ -1 +1,171 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]">
<title>About Cython</title>
</head>
<body>
<center>
<h1>
<hr width="100%">Cython</h1></center>
<center><i><font size=+1>A language for writing Python extension modules</font></i>
<hr width="100%"></center>
<h2>
What is Cython all about?</h2>
Cython is a language specially designed for writing Python extension modules.
It's designed to bridge the gap between the nice, high-level, easy-to-use
world of Python and the messy, low-level world of C.
<p>You may be wondering why anyone would want a special language for this.
Python is really easy to extend using C or C++, isn't it? Why not just
write your extension modules in one of those languages?
<p>Well, if you've ever written an extension module for Python, you'll
know that things are not as easy as all that. First of all, there is a
fair bit of boilerplate code to write before you can even get off the ground.
Then you're faced with the problem of converting between Python and C data
types. For the basic types such as numbers and strings this is not too
bad, but anything more elaborate and you're into picking Python objects
apart using the Python/C API calls, which requires you to be meticulous
about maintaining reference counts, checking for errors at every step and
cleaning up properly if anything goes wrong. Any mistakes and you have
a nasty crash that's very difficult to debug.
<p>Various tools have been developed to ease some of the burdens of producing
extension code, of which perhaps <a href="http://www.swig.org">SWIG</a>
is the best known. SWIG takes a definition file consisting of a mixture
of C code and specialised declarations, and produces an extension module.
It writes all the boilerplate for you, and in many cases you can use it
without knowing about the Python/C API. But you need to use API calls if
any substantial restructuring of the data is required between Python and
C.
<p>What's more, SWIG gives you no help at all if you want to create a new
built-in Python <i>type. </i>It will generate pure-Python classes which
wrap (in a slightly unsafe manner) pointers to C data structures, but creation
of true extension types is outside its scope.
<p>Another notable attempt at making it easier to extend Python is <a href="http://pyinline.sourceforge.net/">PyInline</a>
, inspired by a similar facility for Perl. PyInline lets you embed pieces
of C code in the midst of a Python file, and automatically extracts them
and compiles them into an extension. But it only converts the basic types
automatically, and as with SWIG, it doesn't address the creation
of new Python types.
<p>Cython aims to go far beyond what any of these previous tools provides.
Cython deals with the basic types just as easily as SWIG, but it also lets
you write code to convert between arbitrary Python data structures and
arbitrary C data structures, in a simple and natural way, without knowing
<i>anything</i> about the Python/C API. That's right -- <i>nothing at all</i>!
Nor do you have to worry about reference counting or error checking --
it's all taken care of automatically, behind the scenes, just as it is
in interpreted Python code. And what's more, Cython lets you define new
<i>built-in</i> Python types just as easily as you can define new classes
in Python.
<p>Sound too good to be true? Read on and find out how it's done.
<h2>
The Basics of Cython</h2>
The fundamental nature of Cython can be summed up as follows: <b>Cython is
Python with C data types</b>.
<p><i>Cython is Python:</i> Almost any piece of Python code is also valid
Cython code. (There are a few limitations, but this approximation will serve
for now.) The Cython compiler will convert it into C code which makes equivalent
calls to the Python/C API. In this respect, Cython is similar to the former
Python2C project (to which I would supply a reference except that it no
longer seems to exist).
<p><i>...with C data types.</i> But Cython is much more than that, because
parameters and variables can be declared to have C data types. Code which
manipulates Python values and C values can be freely intermixed, with conversions
occurring automatically wherever possible. Reference count maintenance
and error checking of Python operations is also automatic, and the full
power of Python's exception handling facilities, including the try-except
and try-finally statements, is available to you -- even in the midst of
manipulating C data.
<p>Here's a small example showing some of what can be done. It's a routine
for finding prime numbers. You tell it how many primes you want, and it
returns them as a Python list.
<blockquote><b><tt><font size=+1>primes.pyx</font></tt></b></blockquote>
<blockquote>
<pre> 1 def primes(int kmax):
2 cdef int n, k, i
3 cdef int p[1000]
4 result = []
5 if kmax > 1000:
6 kmax = 1000
7 k = 0
8 n = 2
9 while k < kmax:
10 i = 0
11 while i < k and n % p[i] <> 0:
12 i = i + 1
13 if i == k:
14 p[k] = n
15 k = k + 1
16 result.append(n)
17 n = n + 1
18 return result</pre>
</blockquote>
You'll see that it starts out just like a normal Python function definition,
except that the parameter <b>kmax</b> is declared to be of type <b>int</b>
. This means that the object passed will be converted to a C integer (or
a TypeError will be raised if it can't be).
<p>Lines 2 and 3 use the <b>cdef</b> statement to define some local C variables.
Line 4 creates a Python list which will be used to return the result. You'll
notice that this is done exactly the same way it would be in Python. Because
the variable <b>result</b> hasn't been given a type, it is assumed to hold
a Python object.
<p>Lines 7-9 set up for a loop which will test candidate numbers for primeness
until the required number of primes has been found. Lines 11-12, which
try dividing a candidate by all the primes found so far, are of particular
interest. Because no Python objects are referred to, the loop is translated
entirely into C code, and thus runs very fast.
<p>When a prime is found, lines 14-15 add it to the p array for fast access
by the testing loop, and line 16 adds it to the result list. Again, you'll
notice that line 16 looks very much like a Python statement, and in fact
it is, with the twist that the C parameter <b>n</b> is automatically converted
to a Python object before being passed to the <b>append</b> method. Finally,
at line 18, a normal Python <b>return</b> statement returns the result
list.
<p>Compiling primes.pyx with the Cython compiler produces an extension module
which we can try out in the interactive interpreter as follows:
<blockquote>
<pre>>>> import primes
>>> primes.primes(10)
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]
>>></pre>
</blockquote>
See, it works! And if you're curious about how much work Cython has saved
you, take a look at the <a href="primes.c">C code generated for this module</a>
.
<h2>
Language Details</h2>
For more about the Cython language, see the <a href="overview.html">Language
Overview</a> .
<h2>
Future Plans</h2>
Cython is not finished. Substantial tasks remaining include:
<ul>
<li>
Support for certain Python language features which are planned but not
yet implemented. See the <a href="overview.html#Limitations">Limitations</a>
section of the <a href="overview.html">Language Overview</a> for a current
list.</li>
</ul>
<ul>
<li>
C++ support. This could be a very big can of worms - careful thought required
before going there.</li>
</ul>
<ul>
<li>
Reading C/C++ header files directly would be very nice, but there are some
severe problems that I will have to find solutions for first, such as what
to do about preprocessor macros. My current thinking is to use a separate
tool to convert .h files into Cython declarations, possibly with some manual
intervention.</li>
</ul>
</body>
</html>
\ No newline at end of file +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]"> + <title>About Cython</title> +</head> +<body> + +<center> +<h1> + +<hr width="100%">Cython</h1></center> + +<center><i><font size=+1>A language for writing Python extension modules</font></i> +<hr width="100%"></center> + +<h2> +What is Cython all about?</h2> +Cython is a language specially designed for writing Python extension modules. +It's designed to bridge the gap between the nice, high-level, easy-to-use +world of Python and the messy, low-level world of C. +<p>You may be wondering why anyone would want a special language for this. +Python is really easy to extend using C or C++, isn't it? Why not just +write your extension modules in one of those languages? +<p>Well, if you've ever written an extension module for Python, you'll +know that things are not as easy as all that. First of all, there is a +fair bit of boilerplate code to write before you can even get off the ground. +Then you're faced with the problem of converting between Python and C data +types. For the basic types such as numbers and strings this is not too +bad, but anything more elaborate and you're into picking Python objects +apart using the Python/C API calls, which requires you to be meticulous +about maintaining reference counts, checking for errors at every step and +cleaning up properly if anything goes wrong. Any mistakes and you have +a nasty crash that's very difficult to debug. +<p>Various tools have been developed to ease some of the burdens of producing +extension code, of which perhaps <a href="http://www.swig.org">SWIG</a> +is the best known. SWIG takes a definition file consisting of a mixture +of C code and specialised declarations, and produces an extension module. +It writes all the boilerplate for you, and in many cases you can use it +without knowing about the Python/C API. But you need to use API calls if +any substantial restructuring of the data is required between Python and +C. +<p>What's more, SWIG gives you no help at all if you want to create a new +built-in Python <i>type. </i>It will generate pure-Python classes which +wrap (in a slightly unsafe manner) pointers to C data structures, but creation +of true extension types is outside its scope. +<p>Another notable attempt at making it easier to extend Python is <a href="http://pyinline.sourceforge.net/">PyInline</a> +, inspired by a similar facility for Perl. PyInline lets you embed pieces +of C code in the midst of a Python file, and automatically extracts them +and compiles them into an extension. But it only converts the basic types +automatically, and as with SWIG, it doesn't address the creation +of new Python types. +<p>Cython aims to go far beyond what any of these previous tools provides. +Cython deals with the basic types just as easily as SWIG, but it also lets +you write code to convert between arbitrary Python data structures and +arbitrary C data structures, in a simple and natural way, without knowing +<i>anything</i> about the Python/C API. That's right -- <i>nothing at all</i>! +Nor do you have to worry about reference counting or error checking -- +it's all taken care of automatically, behind the scenes, just as it is +in interpreted Python code. And what's more, Cython lets you define new +<i>built-in</i> Python types just as easily as you can define new classes +in Python. +<p>Sound too good to be true? Read on and find out how it's done. +<h2> +The Basics of Cython</h2> +The fundamental nature of Cython can be summed up as follows: <b>Cython is +Python with C data types</b>. +<p><i>Cython is Python:</i> Almost any piece of Python code is also valid +Cython code. (There are a few limitations, but this approximation will serve +for now.) The Cython compiler will convert it into C code which makes equivalent +calls to the Python/C API. In this respect, Cython is similar to the former +Python2C project (to which I would supply a reference except that it no +longer seems to exist). +<p><i>...with C data types.</i> But Cython is much more than that, because +parameters and variables can be declared to have C data types. Code which +manipulates Python values and C values can be freely intermixed, with conversions +occurring automatically wherever possible. Reference count maintenance +and error checking of Python operations is also automatic, and the full +power of Python's exception handling facilities, including the try-except +and try-finally statements, is available to you -- even in the midst of +manipulating C data. +<p>Here's a small example showing some of what can be done. It's a routine +for finding prime numbers. You tell it how many primes you want, and it +returns them as a Python list. +<blockquote><b><tt><font size=+1>primes.pyx</font></tt></b></blockquote> + +<blockquote> +<pre> 1 def primes(int kmax): + 2 cdef int n, k, i + 3 cdef int p[1000] + 4 result = [] + 5 if kmax > 1000: + 6 kmax = 1000 + 7 k = 0 + 8 n = 2 + 9 while k < kmax: +10 i = 0 +11 while i < k and n % p[i] <> 0: +12 i = i + 1 +13 if i == k: +14 p[k] = n +15 k = k + 1 +16 result.append(n) +17 n = n + 1 +18 return result</pre> +</blockquote> +You'll see that it starts out just like a normal Python function definition, +except that the parameter <b>kmax</b> is declared to be of type <b>int</b> +. This means that the object passed will be converted to a C integer (or +a TypeError will be raised if it can't be). +<p>Lines 2 and 3 use the <b>cdef</b> statement to define some local C variables. +Line 4 creates a Python list which will be used to return the result. You'll +notice that this is done exactly the same way it would be in Python. Because +the variable <b>result</b> hasn't been given a type, it is assumed to hold +a Python object. +<p>Lines 7-9 set up for a loop which will test candidate numbers for primeness +until the required number of primes has been found. Lines 11-12, which +try dividing a candidate by all the primes found so far, are of particular +interest. Because no Python objects are referred to, the loop is translated +entirely into C code, and thus runs very fast. +<p>When a prime is found, lines 14-15 add it to the p array for fast access +by the testing loop, and line 16 adds it to the result list. Again, you'll +notice that line 16 looks very much like a Python statement, and in fact +it is, with the twist that the C parameter <b>n</b> is automatically converted +to a Python object before being passed to the <b>append</b> method. Finally, +at line 18, a normal Python <b>return</b> statement returns the result +list. +<p>Compiling primes.pyx with the Cython compiler produces an extension module +which we can try out in the interactive interpreter as follows: +<blockquote> +<pre>>>> import primes +>>> primes.primes(10) +[2, 3, 5, 7, 11, 13, 17, 19, 23, 29] +>>></pre> +</blockquote> +See, it works! And if you're curious about how much work Cython has saved +you, take a look at the <a href="primes.c">C code generated for this module</a> +. +<h2> +Language Details</h2> +For more about the Cython language, see the <a href="overview.html">Language +Overview</a> . +<h2> +Future Plans</h2> +Cython is not finished. Substantial tasks remaining include: +<ul> +<li> +Support for certain Python language features which are planned but not +yet implemented. See the <a href="overview.html#Limitations">Limitations</a> +section of the <a href="overview.html">Language Overview</a> for a current +list.</li> +</ul> + +<ul> +<li> +C++ support. This could be a very big can of worms - careful thought required +before going there.</li> +</ul> + +<ul> +<li> +Reading C/C++ header files directly would be very nice, but there are some +severe problems that I will have to find solutions for first, such as what +to do about preprocessor macros. My current thinking is to use a separate +tool to convert .h files into Cython declarations, possibly with some manual +intervention.</li> +</ul> + +</body> +</html> diff --git a/Doc/index.html b/Doc/index.html index 635085d6c..7a7da62f8 100644 --- a/Doc/index.html +++ b/Doc/index.html @@ -1 +1,74 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]">
<title>Cython - Front Page</title>
</head>
<body>
<table CELLSPACING=0 CELLPADDING=10 WIDTH="500" >
<tr>
<td VALIGN=TOP BGCOLOR="#FF9218"><font face="Arial,Helvetica"><font size=+4>Cython</font></font></td>
<td ALIGN=RIGHT VALIGN=TOP WIDTH="200" BGCOLOR="#5DBACA"><font face="Arial,Helvetica"><font size=+1>A
smooth blend of the finest Python </font></font>
<br><font face="Arial,Helvetica"><font size=+1>with the unsurpassed power </font></font>
<br><font face="Arial,Helvetica"><font size=+1>of raw C.</font></font></td>
</tr>
</table>
<blockquote><font size=+1>Welcome to Cython, a language for writing Python
extension modules. Cython makes creating an extension module is almost as
easy as creating a Python module! To find out more, consult one of the
edifying documents below.</font></blockquote>
<h1>
<font face="Arial,Helvetica"><font size=+2>Documentation</font></font></h1>
<blockquote>
<h2>
<font face="Arial,Helvetica"><font size=+1><a href="About.html">About Cython</a></font></font></h2>
<blockquote><font size=+1>Read this to find out what Cython is all about
and what it can do for you.</font></blockquote>
<h2>
<font face="Arial,Helvetica"><font size=+1><a href="overview.html">Language
Overview</a></font></font></h2>
<blockquote><font size=+1>A description of all the features of the Cython
language. This is the closest thing to a reference manual in existence
yet.</font></blockquote>
<h2>
<font face="Arial,Helvetica"><font size=+1><a href="FAQ.html">FAQ</a></font></font></h2>
<blockquote><font size=+1>Want to know how to do something in Cython? Check
here first<font face="Arial,Helvetica">.</font></font></blockquote>
</blockquote>
<h1>
<font face="Arial,Helvetica"><font size=+2>Other Resources</font></font></h1>
<blockquote>
<h2>
<font face="Arial,Helvetica"><font size=+1><a href="http://www.cosc.canterbury.ac.nz/~greg/python/Cython/mpj17-pyrex-guide/">Michael's
Quick Guide to Cython</a></font></font></h2>
<blockquote><font size=+1>This tutorial-style presentation will take you
through the steps of creating some Cython modules to wrap existing C libraries.
Contributed by <a href="mailto:mpj17@cosc.canterbury.ac.nz">Michael JasonSmith</a>.</font></blockquote>
<h2>
<font face="Arial,Helvetica"><font size=+1><a href="mailto:greg@cosc.canterbury.ac.nz">Mail
to the Author</a></font></font></h2>
<blockquote><font size=+1>If you have a question that's not answered by
anything here, you're not sure about something, or you have a bug to report
or a suggestion to make, or anything at all to say about Cython, feel free
to email me:<font face="Arial,Helvetica"> </font><tt><a href="mailto:greg@cosc.canterbury.ac.nz">greg@cosc.canterbury.ac.nz</a></tt></font></blockquote>
</blockquote>
</body>
</html>
\ No newline at end of file +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]"> + <title>Cython - Front Page</title> +</head> +<body> + +<table CELLSPACING=0 CELLPADDING=10 WIDTH="500" > +<tr> +<td VALIGN=TOP BGCOLOR="#FF9218"><font face="Arial,Helvetica"><font size=+4>Cython</font></font></td> + +<td ALIGN=RIGHT VALIGN=TOP WIDTH="200" BGCOLOR="#5DBACA"><font face="Arial,Helvetica"><font size=+1>A +smooth blend of the finest Python </font></font> +<br><font face="Arial,Helvetica"><font size=+1>with the unsurpassed power </font></font> +<br><font face="Arial,Helvetica"><font size=+1>of raw C.</font></font></td> +</tr> +</table> + +<blockquote><font size=+1>Welcome to Cython, a language for writing Python +extension modules. Cython makes creating an extension module is almost as +easy as creating a Python module! To find out more, consult one of the +edifying documents below.</font></blockquote> + +<h1> +<font face="Arial,Helvetica"><font size=+2>Documentation</font></font></h1> + +<blockquote> +<h2> +<font face="Arial,Helvetica"><font size=+1><a href="About.html">About Cython</a></font></font></h2> + +<blockquote><font size=+1>Read this to find out what Cython is all about +and what it can do for you.</font></blockquote> + +<h2> +<font face="Arial,Helvetica"><font size=+1><a href="overview.html">Language +Overview</a></font></font></h2> + +<blockquote><font size=+1>A description of all the features of the Cython +language. This is the closest thing to a reference manual in existence +yet.</font></blockquote> + +<h2> +<font face="Arial,Helvetica"><font size=+1><a href="FAQ.html">FAQ</a></font></font></h2> + +<blockquote><font size=+1>Want to know how to do something in Cython? Check +here first<font face="Arial,Helvetica">.</font></font></blockquote> +</blockquote> + +<h1> +<font face="Arial,Helvetica"><font size=+2>Other Resources</font></font></h1> + +<blockquote> +<h2> +<font face="Arial,Helvetica"><font size=+1><a href="http://www.cosc.canterbury.ac.nz/~greg/python/Cython/mpj17-pyrex-guide/">Michael's +Quick Guide to Cython</a></font></font></h2> + +<blockquote><font size=+1>This tutorial-style presentation will take you +through the steps of creating some Cython modules to wrap existing C libraries. +Contributed by <a href="mailto:mpj17@cosc.canterbury.ac.nz">Michael JasonSmith</a>.</font></blockquote> + +<h2> +<font face="Arial,Helvetica"><font size=+1><a href="mailto:greg@cosc.canterbury.ac.nz">Mail +to the Author</a></font></font></h2> + +<blockquote><font size=+1>If you have a question that's not answered by +anything here, you're not sure about something, or you have a bug to report +or a suggestion to make, or anything at all to say about Cython, feel free +to email me:<font face="Arial,Helvetica"> </font><tt><a href="mailto:greg@cosc.canterbury.ac.nz">greg@cosc.canterbury.ac.nz</a></tt></font></blockquote> +</blockquote> + +</body> +</html> diff --git a/Doc/primes.c b/Doc/primes.c index 7af92f203..1fc9cf608 100644 --- a/Doc/primes.c +++ b/Doc/primes.c @@ -1 +1,142 @@ -#include "Python.h"
static PyObject *__Pyx_UnpackItem(PyObject *, int);
static int __Pyx_EndUnpack(PyObject *, int);
static int __Pyx_PrintItem(PyObject *);
static int __Pyx_PrintNewline(void);
static void __Pyx_ReRaise(void);
static void __Pyx_RaiseWithTraceback(PyObject *, PyObject *, PyObject *);
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list);
static PyObject *__Pyx_GetExcValue(void);
static PyObject *__Pyx_GetName(PyObject *dict, char *name);
static PyObject *__pyx_m;
static PyObject *__pyx_d;
static PyObject *__pyx_b;
PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args); /*proto*/
PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args) {
int __pyx_v_kmax;
int __pyx_v_n;
int __pyx_v_k;
int __pyx_v_i;
int (__pyx_v_p[1000]);
PyObject *__pyx_v_result;
PyObject *__pyx_r;
PyObject *__pyx_1 = 0;
int __pyx_2;
int __pyx_3;
int __pyx_4;
PyObject *__pyx_5 = 0;
PyObject *__pyx_6 = 0;
if (!PyArg_ParseTuple(__pyx_args, "i", &__pyx_v_kmax)) return 0;
__pyx_v_result = Py_None; Py_INCREF(__pyx_v_result);
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":2 */
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":3 */
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":4 */
__pyx_1 = PyList_New(0); if (!__pyx_1) goto __pyx_L1;
Py_DECREF(__pyx_v_result);
__pyx_v_result = __pyx_1;
__pyx_1 = 0;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":5 */
__pyx_2 = (__pyx_v_kmax > 1000);
if (__pyx_2) {
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":6 */
__pyx_v_kmax = 1000;
goto __pyx_L2;
}
__pyx_L2:;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":7 */
__pyx_v_k = 0;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":8 */
__pyx_v_n = 2;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":9 */
while (1) {
__pyx_L3:;
__pyx_2 = (__pyx_v_k < __pyx_v_kmax);
if (!__pyx_2) break;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":10 */
__pyx_v_i = 0;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":11 */
while (1) {
__pyx_L5:;
if (__pyx_3 = (__pyx_v_i < __pyx_v_k)) {
__pyx_3 = ((__pyx_v_n % (__pyx_v_p[__pyx_v_i])) != 0);
}
if (!__pyx_3) break;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":12 */
__pyx_v_i = (__pyx_v_i + 1);
}
__pyx_L6:;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":13 */
__pyx_4 = (__pyx_v_i == __pyx_v_k);
if (__pyx_4) {
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":14 */
(__pyx_v_p[__pyx_v_k]) = __pyx_v_n;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":15 */
__pyx_v_k = (__pyx_v_k + 1);
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":16 */
__pyx_1 = PyObject_GetAttrString(__pyx_v_result, "append"); if (!__pyx_1) goto __pyx_L1;
__pyx_5 = PyInt_FromLong(__pyx_v_n); if (!__pyx_5) goto __pyx_L1;
__pyx_6 = PyTuple_New(1); if (!__pyx_6) goto __pyx_L1;
PyTuple_SET_ITEM(__pyx_6, 0, __pyx_5);
__pyx_5 = 0;
__pyx_5 = PyObject_CallObject(__pyx_1, __pyx_6); if (!__pyx_5) goto __pyx_L1;
Py_DECREF(__pyx_6); __pyx_6 = 0;
Py_DECREF(__pyx_5); __pyx_5 = 0;
goto __pyx_L7;
}
__pyx_L7:;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":17 */
__pyx_v_n = (__pyx_v_n + 1);
}
__pyx_L4:;
/* "ProjectsA:Python:Pyrex:Demos:primes.pyx":18 */
Py_INCREF(__pyx_v_result);
__pyx_r = __pyx_v_result;
goto __pyx_L0;
__pyx_r = Py_None; Py_INCREF(__pyx_r);
goto __pyx_L0;
__pyx_L1:;
Py_XDECREF(__pyx_1);
Py_XDECREF(__pyx_5);
Py_XDECREF(__pyx_6);
__pyx_r = 0;
__pyx_L0:;
Py_DECREF(__pyx_v_result);
return __pyx_r;
}
static struct PyMethodDef __pyx_methods[] = {
{"primes", (PyCFunction)__pyx_f_primes, METH_VARARGS, 0},
{0, 0, 0, 0}
};
void initprimes(void); /*proto*/
void initprimes(void) {
__pyx_m = Py_InitModule4("primes", __pyx_methods, 0, 0, PYTHON_API_VERSION);
__pyx_d = PyModule_GetDict(__pyx_m);
__pyx_b = PyImport_AddModule("__builtin__");
PyDict_SetItemString(__pyx_d, "__builtins__", __pyx_b);
}
/* Runtime support code */
+#include "Python.h" + + +static PyObject *__Pyx_UnpackItem(PyObject *, int); +static int __Pyx_EndUnpack(PyObject *, int); +static int __Pyx_PrintItem(PyObject *); +static int __Pyx_PrintNewline(void); +static void __Pyx_ReRaise(void); +static void __Pyx_RaiseWithTraceback(PyObject *, PyObject *, PyObject *); +static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list); +static PyObject *__Pyx_GetExcValue(void); +static PyObject *__Pyx_GetName(PyObject *dict, char *name); + +static PyObject *__pyx_m; +static PyObject *__pyx_d; +static PyObject *__pyx_b; + + +PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args); /*proto*/ +PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args) { + int __pyx_v_kmax; + int __pyx_v_n; + int __pyx_v_k; + int __pyx_v_i; + int (__pyx_v_p[1000]); + PyObject *__pyx_v_result; + PyObject *__pyx_r; + PyObject *__pyx_1 = 0; + int __pyx_2; + int __pyx_3; + int __pyx_4; + PyObject *__pyx_5 = 0; + PyObject *__pyx_6 = 0; + if (!PyArg_ParseTuple(__pyx_args, "i", &__pyx_v_kmax)) return 0; + __pyx_v_result = Py_None; Py_INCREF(__pyx_v_result); + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":2 */ + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":3 */ + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":4 */ + __pyx_1 = PyList_New(0); if (!__pyx_1) goto __pyx_L1; + Py_DECREF(__pyx_v_result); + __pyx_v_result = __pyx_1; + __pyx_1 = 0; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":5 */ + __pyx_2 = (__pyx_v_kmax > 1000); + if (__pyx_2) { + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":6 */ + __pyx_v_kmax = 1000; + goto __pyx_L2; + } + __pyx_L2:; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":7 */ + __pyx_v_k = 0; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":8 */ + __pyx_v_n = 2; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":9 */ + while (1) { + __pyx_L3:; + __pyx_2 = (__pyx_v_k < __pyx_v_kmax); + if (!__pyx_2) break; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":10 */ + __pyx_v_i = 0; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":11 */ + while (1) { + __pyx_L5:; + if (__pyx_3 = (__pyx_v_i < __pyx_v_k)) { + __pyx_3 = ((__pyx_v_n % (__pyx_v_p[__pyx_v_i])) != 0); + } + if (!__pyx_3) break; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":12 */ + __pyx_v_i = (__pyx_v_i + 1); + } + __pyx_L6:; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":13 */ + __pyx_4 = (__pyx_v_i == __pyx_v_k); + if (__pyx_4) { + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":14 */ + (__pyx_v_p[__pyx_v_k]) = __pyx_v_n; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":15 */ + __pyx_v_k = (__pyx_v_k + 1); + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":16 */ + __pyx_1 = PyObject_GetAttrString(__pyx_v_result, "append"); if (!__pyx_1) goto __pyx_L1; + __pyx_5 = PyInt_FromLong(__pyx_v_n); if (!__pyx_5) goto __pyx_L1; + __pyx_6 = PyTuple_New(1); if (!__pyx_6) goto __pyx_L1; + PyTuple_SET_ITEM(__pyx_6, 0, __pyx_5); + __pyx_5 = 0; + __pyx_5 = PyObject_CallObject(__pyx_1, __pyx_6); if (!__pyx_5) goto __pyx_L1; + Py_DECREF(__pyx_6); __pyx_6 = 0; + Py_DECREF(__pyx_5); __pyx_5 = 0; + goto __pyx_L7; + } + __pyx_L7:; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":17 */ + __pyx_v_n = (__pyx_v_n + 1); + } + __pyx_L4:; + + /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":18 */ + Py_INCREF(__pyx_v_result); + __pyx_r = __pyx_v_result; + goto __pyx_L0; + + __pyx_r = Py_None; Py_INCREF(__pyx_r); + goto __pyx_L0; + __pyx_L1:; + Py_XDECREF(__pyx_1); + Py_XDECREF(__pyx_5); + Py_XDECREF(__pyx_6); + __pyx_r = 0; + __pyx_L0:; + Py_DECREF(__pyx_v_result); + return __pyx_r; +} + +static struct PyMethodDef __pyx_methods[] = { + {"primes", (PyCFunction)__pyx_f_primes, METH_VARARGS, 0}, + {0, 0, 0, 0} +}; + +void initprimes(void); /*proto*/ +void initprimes(void) { + __pyx_m = Py_InitModule4("primes", __pyx_methods, 0, 0, PYTHON_API_VERSION); + __pyx_d = PyModule_GetDict(__pyx_m); + __pyx_b = PyImport_AddModule("__builtin__"); + PyDict_SetItemString(__pyx_d, "__builtins__", __pyx_b); +} +/* Runtime support code */ diff --git a/Doc/s5/ui/default/print.css b/Doc/s5/ui/default/print.css index e52c441ba..4a3554ddd 100644 --- a/Doc/s5/ui/default/print.css +++ b/Doc/s5/ui/default/print.css @@ -1,24 +1,24 @@ -/* The following rule is necessary to have all slides appear in print! DO NOT REMOVE IT! */
-.slide, ul {page-break-inside: avoid; visibility: visible !important;}
-h1 {page-break-after: avoid;}
-
-body {font-size: 12pt; background: white;}
-* {color: black;}
-
-#slide0 h1 {font-size: 200%; border: none; margin: 0.5em 0 0.25em;}
-#slide0 h3 {margin: 0; padding: 0;}
-#slide0 h4 {margin: 0 0 0.5em; padding: 0;}
-#slide0 {margin-bottom: 3em;}
-
-h1 {border-top: 2pt solid gray; border-bottom: 1px dotted silver;}
-.extra {background: transparent !important;}
-div.extra, pre.extra, .example {font-size: 10pt; color: #333;}
-ul.extra a {font-weight: bold;}
-p.example {display: none;}
-
-#header {display: none;}
-#footer h1 {margin: 0; border-bottom: 1px solid; color: gray; font-style: italic;}
-#footer h2, #controls {display: none;}
-
-/* The following rule keeps the layout stuff out of print. Remove at your own risk! */
-.layout, .layout * {display: none !important;}
+/* The following rule is necessary to have all slides appear in print! DO NOT REMOVE IT! */ +.slide, ul {page-break-inside: avoid; visibility: visible !important;} +h1 {page-break-after: avoid;} + +body {font-size: 12pt; background: white;} +* {color: black;} + +#slide0 h1 {font-size: 200%; border: none; margin: 0.5em 0 0.25em;} +#slide0 h3 {margin: 0; padding: 0;} +#slide0 h4 {margin: 0 0 0.5em; padding: 0;} +#slide0 {margin-bottom: 3em;} + +h1 {border-top: 2pt solid gray; border-bottom: 1px dotted silver;} +.extra {background: transparent !important;} +div.extra, pre.extra, .example {font-size: 10pt; color: #333;} +ul.extra a {font-weight: bold;} +p.example {display: none;} + +#header {display: none;} +#footer h1 {margin: 0; border-bottom: 1px solid; color: gray; font-style: italic;} +#footer h2, #controls {display: none;} + +/* The following rule keeps the layout stuff out of print. Remove at your own risk! */ +.layout, .layout * {display: none !important;} |