[pypy-svn] r26419 - pypy/extradoc/soc-2006
auc at codespeak.net
auc at codespeak.net
Thu Apr 27 10:33:45 CEST 2006
Author: auc
Date: Thu Apr 27 10:33:43 2006
New Revision: 26419
Modified:
pypy/extradoc/soc-2006/wp09_10_ideas.txt
Log:
minor adjustment
Modified: pypy/extradoc/soc-2006/wp09_10_ideas.txt
==============================================================================
--- pypy/extradoc/soc-2006/wp09_10_ideas.txt (original)
+++ pypy/extradoc/soc-2006/wp09_10_ideas.txt Thu Apr 27 10:33:43 2006
@@ -12,17 +12,16 @@
with possibly subotpimal runtime performance but no external
dependency,
-* wrapping Gecode : first finish the c-wrapper around Gecode, then use
- rctypes to provide interpreter access to low-level Gecode
- functionality, and finally integrate it into the existing
- interpreter-level constraint solver.
+* wrapping Gecode : first finish the c-wrapper around Gecode (unless
+ the wrapper for C++ becomes available), then use rctypes to provide
+ interpreter access to low-level Gecode functionality, and finally
+ integrate it into the existing interpreter-level constraint solver.
Rctypes is what PyPy offers, mimicking python ctypes, to interface the
-interpreter with C code. The machinery is still very young and the
-advancement of the project might be hindered by defects or
-incompleteness of rctypes. The point is that, even if the actual
-wrapping of gecode is incomplete, the effort to build it at least
-should yield a better rctypes.
+interpreter with C code. The machinery is still young and the
+advancement of the project might be hindered by bugs of rctypes. The
+point is that, even if the actual wrapping of gecode is incomplete,
+the effort to build it at least should yield a better rctypes.
One modest, reasonable target could be running the simple
send-more-money problem with very few actual search steps due to the
More information about the Pypy-commit
mailing list