Re: Class library translation to Python

Hi Scott

It may be worth considering PyPy for this project?
>

I do care about compatibility with PyPy using plain Python, performance is
drastically better, except, maybe, if code compiles functions within the
clock's scheduling calls, it does in some places though I removed some, it
may get jittered, code still needs some tuning.

I believe it's possible to do a green thread implementation in PyPy that is
> a much closer match to how SuperCollider Routines/Threads work (though I
> think you'll be stuck doing the lowest level scheduling bits in C++
> regardless).
>

I'm not doing a low level implementation, at least not in the near future.
Also I don't think it is completely necessary or even at all for many use
cases.


> Also, the PyPy garbage collector is a better candidate for
> timing-sensitive use cases like patterns than the regular Python GC.
> Supposedly the max pause times are in the low hundreds of milliseconds -
> not fantastic, but okay enough to run the normal pattern use-cases. I think
> the GC is much more configurable, so there may be ways to optimized this
> for SC as well.
>

I've read around that now it has an incremental garbage collector (GCs are
interchangeable). I guess (because I don't have the required knowledge
about it) that it will strongly depend on the language side memory load and
that the common use of SC is not as hard as a web server with thousands of
requests. CPython is quite steady if there is not much memory usage, also
the GC can be disabled, I've tested that, no difference besides memory
growth. Also clocks are implemented with logical time as in sclang (should
be the same if I didn't mess up), and sending bundles with logical time and
the default server latency (100ms) shouldn't be a problem.

The issue with splitting things is compatibility with other libraries in
different platforms and it gets harder to maintain. My only goal for now is
having the library working properly and being as clean and consistent as
possible. More advanced things can be done later by anyone who wants it.


> PyPy is build on RPython - a JIT compilation / language-building tool? -
> which people have used to implement versions of e.g. Ruby and Smalltalk. It
> would be possible - (with a lot of work :) ) - to use RPython to interpret
> SuperCollider source directly, and call back and forth between Python and
> SuperCollider code. In my mind, RPython or Graalvm are probably the two
> most likely paths we have of rescuing the SuperCollider language from being
> unmaintained in the long-long term.
>

Yeah, that was the cause of many of my complaints in the past, is really
not easy work to do and may be impossible without changing too much and
that would bring other problems. I don't know, don't feel it is possible to
change sclang without changing SuperCollider, there is so much legacy that
would be affected.