ctn-waterloo / ctn_benchmarks Goto Github PK

The following SpiNNaker changes should allow reverting some of the commits to this repo:

Clearly those PRs need reviewing first ;)

Because development activity seems to be slightly increasing here (#8, #9), I was wondering what the plans for the future are, especially with respect to PR #7. As #7 is a major rewrite of central parts it seems that it might be wasted effort to implement a lot of new features on the current master branch if the intend is to transition to that approach. It certainly adds complexity, but also increases the flexibility.

I will use #7 as part of my projects for sure and it would be nice to be able to link to it and pip install it easily (which is problematic if it lives in this branch). So if there is no intend to get this merged into ctn_benchmarks, I might go ahead and transition the code from the PR to its own repository.

Another point is that I think that #4 should be resolved earlier than later. The larger the user-base, the more problematic such fundamental changes as renaming the package will get.

In benchmark.py a ValueException is raised when 0 parameters are specified and when the same parameter is added twice to the list of defaults.

ValueException isn't a valid Python exception, so if any of the two cases above happen it ends up with:
NameError: global name 'ValueException' is not defined

Maybe ValueError, KeyError or TypeError would be more appropriate? I can submit a PR for this (if you let me :)

The repository is named ctn_benchmarks (plural), but you import ctn_benchmark (singular).

I had a case where one of the stored parameters was text which Python did not manage to evaluate as an object it recognizes:
_context = <pyopencl.Context at 0x319aaa0 on <pyopencl.Device 'GeForce GTX 970' on 'NVIDIA CUDA' at 0x251dc60>>

this ended up not loading the data (returning [] from Data object) and it took some time to figure it out. I raised the issue because:
a) cases such as these should also be handled somehow
b) it would be useful if an Exception would not continue quietly in this case, even a small warning would be very useful