Hi Toby,
Excellent work ! great !
Concerning version numbering, I would tend to think that PyViennaCL should
indeed be rebuilt/repackaged at least every minor release, so that it can
benefit performance improvements in the core. On the other hand, following
the same versioning convention as ViennaCL could be imho misleading for the
userbase, since ViennaCL guarantees API stability throughout a version
number, while PyViennaCL may not integrate all the functionalities on the
API.
I would suggest starting PyViennaCL at 1.0, and increase the minor version
like you want, and synchronizing the version number with ViennaCL on each
major release (PyViennaCL 2.0 ...)
Do you want me to test your tarball right now on my system, or wait a bit
for you to polish the code further?
Philippe
2013/9/23 Toby St Clere Smithe <m...@tsmithe.net>
> Hi all,
>
> So, GSoC 2013 is drawing to a close. I've got a tarball produced by
> `make dist-src` on my branch that will build and install PyViennaCL for
> Python 2 and Python 3 (depending on how you configure it, with Python 3
> as default for now). It will also build (but not install, because it's
> redundant) HTML documentation, and run tests if necessary:
>
> ➜ build git:(pyviennacl) ✗ time optirun ctest --output-on-failure
> Test project /home/toby/src/viennacl/pyviennacl-dev/build
> Start 1: blas3_prod_py
> 1/5 Test #1: blas3_prod_py .................... Passed 104.93 sec
> Start 2: blas3_solve_py
> 2/5 Test #2: blas3_solve_py ................... Passed 4.43 sec
> Start 3: scalar_operations_py
> 3/5 Test #3: scalar_operations_py ............. Passed 0.21 sec
> Start 4: vector_operations_py
> 4/5 Test #4: vector_operations_py ............. Passed 0.59 sec
> Start 5: matrix_operations_py
> 5/5 Test #5: matrix_operations_py ............. Passed 5.34 sec
>
> 100% tests passed, 0 tests failed out of 5
>
> Total Test time (real) = 115.52 sec
> optirun ctest --output-on-failure 101.18s user 11.80s system 96% cpu
> 1:56.59 total
>
>
> That's the output on my GeForce 610m system, on battery power. Now,
> there are a couple of quirks remaining with the vector tests (such that
> I had to disable the inner product test because NumPy doesn't seem to be
> precise enough as I've written it, and because using slice and range on
> vectors seems to produce a weird result for the scaled add test), but
> the crucial stuff passes fine.
>
> The tarball is versioned as 1.4.998-py, because I want to clean some
> final things up before I call it a release (at version 1.5.0), but
> obviously I want something tangible to submit for the end of
> GSoC. Here's my list of things for the first release:
>
> + Fix vector_operations test
> + Add __all__ and __version__, so that docs are prettier
> + Fix sphinx warnings
> + Decide on version scheme
> (useful to have a separate version number for the extension
> only, to keep track of features added and bugs fixed given a
> different schedule and different demands)
> [perhaps: ViennaCLVersion.PyViennaCLVersion, eg, 1.5.0.1]
> + Auto-determine Python / Boost-Python version
> + Debian package
>
> Most of those are pretty straightforward (maybe excepting the
> range/slice issue on the vector test), which I'll report more formally
> on in a couple of days. The important things for me, for the first
> release, are sorting out the automatic determination of the Python
> version etc, and the PyViennaCL versioning scheme.
>
> Oh, and I coded up and added tests for the elementwise exponentiation,
> and added support for (u)int and (u)long integer types. char and short
> seem more problematic, but I don't mind about those. When the outer
> product for vectors becomes available in the scheduler, I can easily add
> that, too. For now, it's still just computed the old way.
>
> So, for submission, I don't know what's best or correct. Is there
> somewhere I should upload this tarball? As for build dependencies, they
> are as before, just with the addition of "sphinx" for Python
> documentation. On Ubuntu, it's in the package, `python-sphinx`.
>
> The tarball is called, `ViennaCL-1.4.998-py-src.tar.gz`.
>
> Finally, the build process is RAM intensive right now. An item on my
> roadmap for my second release (after I've got the basic first 1.5.0
> release out) is splitting up the C++ source so that it requires less
> than four gigabytes of memory. Which it does at the moment, with g++ 4.8
> and Boost 1.53 on my system.
>
>
> Best,
>
> Toby
>
>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> ViennaCL-devel mailing list
> ViennaCL-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
