Pular para o conteúdo

Discussing the future of Cantor

Hello devs! Happy new year!

It is common to use the new year date to start new projects or give new directions for old ones. The last one is the case for Cantor.

Since when I got the maintainer status for Cantor, I was working to improve the community around the software. Because the great plugins systems of Qt, it is easy to write new backends for Cantor, and in fact in last years Cantor reached the number of 11 backends.

If in a hand it is a nice thing because Cantor can run different mathematical engines, in other hand it is very common developers create backends, release them with Cantor upstream, and forget this piece of software after some months. The consequence of this is a lot of unsolved bugs in Bugzilla, unexpected behaviours of some backends, and more.

For instance, R backend is broken from some years right now (thanks Rishabh it was fixed during his GSoC/KDE Edu Sprint 2017 but not released yet). Sage backend breaks for each new release of Sage.

Different backends use different technologies. Scilab and Octave backends use QProcess + Standard Streams; Python 2 uses Python/C API; Python 3, R, and Julia use D-Bus.

In addition to these, remember each programming language used as mathematical engine for Cantor has their respective release schedule and it is very common new versions break the way as backends are implemented.

So, yes, the mainternhip of Cantor is a hell.

In order to remedy it I invited developers to be co-maintainer of these respective backends, but it does not have the effect I was suposed to. I implemented a way to present the versions of programming languages supported in the backend but it does not work well too.

So, my main work in Cantor during these years was try to solve bugs of backends I don’t use and, sometimes, I don’t know how they work, while new features were impossible to be planned and implemented.

If we give a look to Jupyter, the main software for notebook-based mathematical computation, it is possible to see this software supports several programming languages. But, in fact, this support is provide by the community – Jupyter focus effort in Python support only (named the ipython kernel) and in new features for Jupyter itself.

So, I would like to hear the KDE and Cantor community about the future of Cantor. My proposal is split the code of the others backends and put them as third-party plugins, maintained by their respective community. Only the Python 3 backend would be “officially” maintaned and delivered in KDE Applications bundle.

This way I could focus in provide new features and I could to say “well, this bug with X backend must be reported to the X backend community because they are accountable for this piece of software”.

So, what do you think about?

10 comentários em “Discussing the future of Cantor”

  1. This is an admirable project and with full respect, it hasn’t really been workable as you mention, so now what is its purpose in the face of the jupyter project especially now jupyterlab is coming to take the place of ides more developed than cantor?Would the efforts be better suited to somehow integrating jupyter into kde workspace and maybe into labplot also like cantor is now

  2. We as KDE community should not release broken Software
    i.e. Cant0r backends not working properly.
    Therefore your proposal makes sense.
    You mentioned Python 3 backend would be maintained,
    what about Kalgebra released by KDE?
    You should discuss this on the kde-edu mailinglist.

  3. Hello Filipe,

    I think your proposal makes sense ! 🙂
    In short, just maintaining the Python 3 stuff would be a great achievement giving that, I suppose, you would code it in your spare time.

    IMHO, most Kde softwares are too ambitious and, as soon as they become big as number of lines of code, because of that, they become usually buggy.
    In the end, most of the time, their developers stop maintaining them because it would take a huge of time to continue doing so.
    When they continue coding it takes a huge amount of time to see some results (e.g. Kexi3 port to Qt5) giving they do this, generally, on their free, very limited time, as a hobby.
    On top of this, needless to say, fixing bugs is usually time-consuming and not very interesting to attract new coders (young people often prefer to code new features instead of fixing bugs…).

    Krita, for instance, is an exception to this trend, because it has a huge community and their developers are paid, through donations, to do so…
    Consequently, they have much more time to fix bugs.

    To recap, in my view, just concentrate your efforts on Python is likely to be the best solution 🙂

    My best regards from Italy and THANKS a lot for our work on Cantor !

    Silvio Grosso

    1. Hello Silvio, thank you a lot for your appreciation of my work with Cantor. In fact, because it is really easy to write new backends, several developers created them. The problem is, after some time, these developers go out of Cantor development and the backends continue in the software but with unsolved bugs.

      Maybe putting these backends as third-party plugins can be a solution to this problem.

      Thank you again and cheers!

  4. Just wanted to chime in and say that I really appreciate the work that has gone into Cantor, and what you propose makes a lot of sense. I think python3 is a pretty good choice for the default backend. Good luck!

  5. Hello everyone,

    If Cantor is going to improve its support for Python 3, a really cool feature for Cantor, IMO, would be reading .ods files.
    In short, the files saved with LibreOffice, in particular, through its “Calc” application.

    From what I have read on Kde Planet, LibreOffice 6, the upcoming new version, is going to be much better integretad on Kde than before.
    Besides, Calligra, the Office Kde implementation, is not maintained any more: I am referring here to Sheets, in particular. Only Kexi, for the database stuff, is somewhat still updated.

    There is a useful thread on the Pandas mailing list:

    I am not a programmer but I suppose it would be *very* time-consuming to implement this option (not through some just hacks, I mean).

    Since thies feature (ods reading) is not fully supported by Jupyter currently, it might allow Cantor to differentiate itself from its “competitor” as regards the Python tools available on the market right now.

    Just my 2 cents, of course 🙂

  6. Hello everyone,

    I’m a new user of Sagemath and I was looking for a frontend. The two main options I found were Spyder and Cantor. I’ve faced the bug problems you talk about in Cantor, but I think it has a space not covered by Spyder, Jupyter or Cocalc, since the first one is centered on numerical computations and the others are browser-based.

    I agree with Silvio: read ‘.ods’ files could be an amazing feature! For engineering tasks it could be really much appreciated.

    Thanks to all the Cantor community for your work!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *