This and py4cl2

[digikar99]

In reference to https://github.com/digikar99/py4cl2, how do we go about the upgradation - or do we keep things separate?

I hope to find time to backport some more of rest of the things worked on in the past few months - those ones should be non-breaking.

However, as far as I understand, argument imports and writing to stdout from separate threads could break a good amount of things with users using existing py4cl.

Do we still procede with deprecating the symbols and then push users to upgrade, or any other suggestions?

[bendudson]

You've made some really nice improvements, and put a lot of good work into pycl2. I haven't had a lot of time to work on this recently, unfortunately. I'm not sure what the best thing to do is, but I think my priorities are to:

1. Avoid duplicating or fragmenting effort; the community is already small enough
2. Avoid breaking people's code

The easiest way I can see to achieve this is to:

1. Focus effort on pushing forward py4cl2; I'm happy to contribute to that for future updates
2. Keep the current py4cl interface, but make it clear that this repo is in maintenance mode: I could add a notice pointing to py4cl2, and saying that I'll accept bug fixes and non-breaking minor updates into py4cl, but that people looking to help should base their work on py4cl2.
   Does that sound reasonable? It seems that you might have more time/motivation for maintaining this than I currently do.

[digikar99]

Okay with that; I'll get back some time this month. Also, zach suggested to use a different name - do we keep it as it is (py4cl2)?

[bendudson]

I think keeping it as py4cl2 would be good, as a major version change from py4cl.

[digikar99]

Currently on the list include:

• python-process-startup-error
• test and if required fix large numpy array transfer bug
• embedding py4cl.py into the lisp image: requires removing all the single-quotes in "py4cl.py"
• look into importing submodules and may be provide a continue-ignoring-errors option as in py4cl2

Another change is about preserving the array types between python (numpy) and common lisp - not sure if this can break people's code; I think no.

[digikar99]

Also, could you elaborate on async functions? I mean, one could simply use a separate thread, no?

[rpgoldman]

As far as I can tell, only Py4CL, and not Py4CL2, are installable with Quicklisp.

[digikar99]

Erm, both should be available in recent quicklisp dists. Did you try quickloading after (ql:update-dist "quicklisp")?

[rpgoldman]

@digikar99 Got it, thanks! Forgot to update.

[jcguu95]

I wonder what the current status is. Will we merge py4cl2 back into py4cl in near future?

[bendudson]

Hi @jcguu95 My understanding is that py4cl2 is unlikely to be merged back into py4cl:
py4cl2 is a major version that changes some of the API.
In the interests of stability py4cl is in "maintenance mode". I'm happy to merge bug fixes, but encourage anyone interested in contributing to please base their improvements on py4cl2.