Pular para o conteúdo

LaKademy results – starting development of Python backend to Cantor

LaKademy is over and I will report about the event in several themed posts. This is about I developed during the Latin American meeting of KDE developers. More posts in LaKademy tag.

In this year I submitted a proposal to Google Summer of Code to develop a Python backend for scientific programming in Cantor. In the last year, I developed a Scilab backend. Unfortunately my proposal was not accepted.

But that’s okay, life goes on. This does not discourage me to begin the project.

During the LaKademy, I put as a goal to make communication between Cantor and Python. My first idea was to make a fork of Sage backend, which is also a technology based in Python. But in the evaluation phase of proposal for Google Summer of Code, the Cantor main developer, Alex Rieder, suggested to me take a look in Python/C API.

I began studying this API and other resources on the web (like this one, based on Elmer). I realized that send Python commands from C/C++ code would be easy, however, capture the output of the Python interpreter would be the real challenge. All this communication could be simple if Python would use standard streams by default, which would allow to use kprocess. Scilab didn’t support, but I implemented this support and it allowed the use of kprocess approach. However, in Python I could not do that – or would be harder to do it.

After searches in internet and some studies, I implemented a Python class that redirects messages from the Python interpreter, both conventional outputs and error messages, to a variable that can later be retrieved in a string type by Python/C API. Voilà!

Using this recovered variable, I can say that the core of Python backend for Cantor is working and ready to implement more features. Let see some screenshots:

Computation of a simple counter in Python

Cantor + Python + matplotlib in a external plot

Python error message in Cantor

From this implemented part, the new features that will be added: append plot figure in Cantor workspace, syntax highlighting, auto-complete pre-defined functions, and more. I intend to support in particular for libraries numpy, scipy and matplotlib, which when added to Python make it an interesting tool for scientific programming, like others we have in the free world as GNU Octave, Scilab, Maxima, Sage.

The code is avaiable in python-backend branch of Cantor repository. But remember: it is a experimental version, and the main fatures will be develop yet. Only communication between C++ <-> Python, the core of application, is working for now.

Watch this blog (or follow python-backend tag) for more informations about this project. 😉

15 comentários em “LaKademy results – starting development of Python backend to Cantor”

    1. Thanks a lot @Eugeni! 🙂

      This is my contribution to KDE community, free software/open source movements, and Sao Carlos city too. 😉 😀

      Abraços,

  1. Great work! As the person who original proposed this project for GSOC, it is really nice to see it happening.

    A few thoughts/suggestions:

    How are you planning to implement the matplotlib plot handling? One thing I think would be nice in general was if there was a generic matplotlib figure pyqt4/pyside qwidget integrated into the upstream matplotlib release. The matplotlib PyQt4/Pyside backends could then be windows embedding this widget, with the buttons connected via proper slots in the widget, and perhaps even Qt signals for mouse handling. Getting this in before the next release, which could happen any day now, would make it possible to then use it with the next KDE SC release.

    I would also consider including sympy, which is the primary symbolic manipulation/computer algebra python module. Although I don’t personally use it, sympy is more in line with the other cantor backends, so supporting it is probably important for a full maxima/octave/sage alternative.

    Finally, are you thinking at all about python 3? I know both numpy and scipy support python 3, and matplotlib and sympy will both support it in the next release (both happening any time now). With Linux distros seeming eager to switch, I would at least keep it in mind.

    1. Hi @TheBlackCat,

      I didn’t understand. Did you submit a proposal to Python backend for Cantor in this GSoC too?

      The idea about matplotlib using a qwidget is really interesting. But in my contribution I will develop like others backends: load a matplotlib figure in Cantor workspace. I will talk with others Cantor developers about this suggestions. Maybe, implement this for the others backends too. But I think that your idea is cool.

      I think that sympy is interesting for have a specific sympy backend, but I need to know more about this library.

      About the Python backend compatibility, actually it was tested only in Python 2.7. I will do tests with Python 3 series soon.

      Thanks for your feedbacks, you are welcome!

      1. @Filipe Saraiva,
        No, I was the one who suggested it be included in the list of GSOC project ideas.

        As for widgets, I think matplotlib has an advantage that it already has a Qt-based backend, so getting a working widget might not be as difficult as for other backends that are not already Qt-based. So the solution used for other backends might not be the optimal one for matplotlib.

  2. Putz. Obviamente eu não entendi nada do post, pq eu não li =x É inglês eh parace ser direcionado para um público bem específico. Mas e essa logomarca do LaKademy? Suponho que esse seja um evento… O caso é que a alguns anos atrás eu pensei em participar de um concurso de logomarcas e fiz que tinha um conceito beeeem parecido ahisuhsauhs

    1. Opa @Laris, bem-vinda!

      Aqui tem o mesmo texto em português – http://blog.filipesaraiva.info/?p=769 😉 Ainda é direcionado para um público técnico específico, mas dá pra entender uma coisa ou outra, hehehe.

      Você trabalhou com um conceito parecido com o da logomarca? Depois manda pra mim, para que eu possa dar uma olhada e tal.

      Fique a vontade para descobrir o blog.

  3. Hello there!

    You mentioned doing auto-completion and syntax highlighting for the builtin python functions… this will be easy enough for the standard library builtins, but more difficult for stuff like numpy, scipy, or matplotlib. I’m working on something similar (python language support for KDevelop) so I thought we could maybe share some code (or more likely, only ideas) about how to do that best (how to get the data about what completion-items to offer, and how to keep it up-to-date with the project’s API).
    I’m well aware that this surely isn’t your top-priority for now, but in case you want to do it one day, I’d be happy if you wrote me an email so we can share our thoughts about that stuff.

    Sounds like a cool project otherwise, I’m excited about how this is going to continue!

    Cheers,
    Sven

    1. Hi @Sven Brauch,

      I thought in implement auto-complete and syntax highlighting using xml files processing, like Scilab backend and Sage backend for Cantor. What do you think?

      It is conventional way of implement these features in Cantor backends.

      Cheers,

      1. @Filipe Saraiva, XML is not a format I could use, but the problem is not so much the format the data is stored in, but where to get that data from. The online docs? Introspection? All not so great…
        Do you have an idea already? In case it would be necessary to, for example, parse the online docs, that’s something we should (and could) share for sure (regardless of the format the data is stored in at the end).

        Greetings,
        Sven

  4. Pingback: LaKademy, Hierarchical Edge Bundles, and KDevelop « Live Blue

  5. Pingback: Google Summer of Code 2013: Cantor + Python at Filipe Saraiva's blog

  6. Pingback: Python backend for Cantor – Syntax Highlighting, Tab Complete, and Interactive Mode at Filipe Saraiva's blog

  7. Pingback: My LaKademy 2016 at Filipe Saraiva's blog

  8. Pingback: Meu Lakademy 2016 at Filipe Saraiva's blog

Deixe um comentário

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