GSoC: Weekly Blog


There’s a lot I did in the last 2 weeks and since I did not update the blog last week, this post is going to include last 2 week’s progress.

Before I begin with what I did, here’s a quick review of what I was working on and what had been done.

I started porting Cantor’s Qalculate backend to QProcess and during the first week I worked on establishing connection with Qalculate, for which we use qalc and some amount of time was spent parsing the output returned by qalc


Qalculate backend as of now uses libqalcuate API for computing the result. To successfully eliminate the direct use of API all the commands should make use qalc, but since qalc does not support all the functions of Qalculate, I had to segerate the parts depending on API from qalc. For instance, qalc does not support plotting graphs.

The version of qalc that we are using supports almost all the major functionalities of Qalculate but there are a few things for which we still depend on the API directly

I will quickly describe what depends on what

* help command
* plotting
* syntax highlighter
* tab completion

* basic calculations: addition, subtraction etc
* all the math functions provided by Qalculate: sqrt(), binomial(), integrate() etc
* saving variables

Segregating part was easy. The other important thing I did was to form a queue based system for the commands that are required to be processed by qalc


Queue based system

The two important components of this system are:

1. Expression Queue :- contains the expressions to be processed
2. Command Queue:- contains commands of the expression being processed.

* The basic idea behind this system is , we compute only one expression at a time, mean while if we get more expressions from user, we store them in the queue and process them once the current expression being processed is complete.

* Another important point is , since an expression can contain multiple commands, we store all the commands for an expression in command queue and just like we process one expression at a time, we are going to process one command at a time. i.e we are going to give QProcess only one command at a time, this makes the output returned by QProcess less messy and hence it’s easier to parse

* Example: Expression1 = (10+12, sqrt(12)) : this expression has multiple commands. The command queue for the same will have two commands.

expression queue                                               command queue

[ expression 1 ] ——————————————-> [ 10+12 ], [ sqrt(12) ]

[ expression 2] ——————————————-> [ help plot ]


We solve all the commands of expression1 , parse the output and then move on to expression2 and this goes on till the time expression queue is empty


Apart from this I worked on Variable model of Qalculate. Qalc provides a lot of variations of save command. Different commands available are:

Not every command mentioned below has been implemented but the important ones have been.

1. save(value, variable, category, title): Implemented

This function is available through the qalc interface and allows the user to define new variables or override the existing variables with the given value.

2. save/store variable : Implemented
This command allows the user to save the current result in a variable with the specified name.

Current result is the last computed result. Using qalc we can access the last result using ‘ans’, ‘answer’ and a few more variables. definitions : Not implemented

Definitions include the user defined variables, functions, units .

4. save mode: Not implemented
mode is the configuration of the user which include things like ‘angle unit’, ‘multiplication sign’ etc.


With this most of the important functionalities have been ported to qalc but there are still a few things for which we depend on the API directly. Hopefully, in the future with the newer version of qalc we will be able to remove the direct use of API from Cantor

Thanks and Happy hacking

GSoC – Weekly Blog

Hi, this is going to be a quick review of what I did last week

Just a little about how cantor works

Cantor is divided in two main parts:

Worksheets –  An interface that allows user to interact with available back ends. Each worksheet is associated with one back end

Back ends –  Back ends are implemented as plugins

The whole back end architecture is divided in several parts. I am going to discuss the ones on which I worked last week

* Back end – Stores static information about back ends, like name, version , what all features(syntax highlighting, tab completion etc) a back end supports

* Session – This is where a connection to back end is established and destroyed. To be specific, the method login() is used for initiating a connection  and logout() is used for ending the connection with back end

* Expression – Every command sent by the user is treated as an Expression . The class is also responsible for storing the result of the expression

Last week I successfully completed:
* Establishing connection with Qalculate back end
* Using streams for I/O
* Parsing the output returned by Qalculate


That’s it for this blog. If you have any questions/suggestions, please get in touch.


QProcess Or KProcess ?

1 month of GSoC is already over and the coding period has officially begun. Here’s a highlight of what I did and what I plan to do for this week

Most of the time of community bonding period was spent giving college exams. By the time my exams got over,  I only had a week left to make something useful of the community bonding period time.

The last week started with a discussion with my mentor , where we decided which API to use to port the back ends.  We had to  decide between QProcess and KProcess. Just a brief of what these APIs do:

QProcess is used to start external programs and to communicate with them. The communication between QProcess and the external program happens through channels. The three standard channels used for communication are
Standard output(stdout): supplies regular console output
Standard error(stderr): supplies the errors that are printed by the process
Standard input(stdin): provides input to the process

KProcess is no different from QProcess. It inherits QProcess and extends it by by some extra and useful functionality

Since a few of the back ends of cantor were already using KProcess, we had to decide whether we actually need KProcess or whether QProcess will suffice our needs. The best  way to  decide this  was to port a back end which makes use of KProcess to QProcess.

Port of Scilab to QProcess

The port process was pretty simple and did not take more than an hour to port and test. The test was performed  on various inputs including plot commands.
You can have a look at the commit that actually does the port
Since Everything worked fine, we decided to move forward with QProcess and use it for other back ends

Plan for this week

The very first back end I have decided to work on is Qalculate. Qalculate at the moment uses libqalculate library for all the calculations.
To get rid of libcalulate, we will be making use of qalc which is the command line interface for Qalculate
This week  I’ll be concentrating on setting up basic communication  between Cantor and  Qalculate using  qalc

Let the hacking begin!

GSoC 2017 with KDE


Hi! I am Rishabh. This post is going to be about what project I will be working on and how happy and excited I am about  spending the summers with KDE

First things first, I would like to thank the entire KDE community and especially my mentor  Filipe Saraiva for accepting my proposal and being kind and generous to me whenever I needed any help. I can’t stress on this enough but KDE is really a  very helpful community, especially to beginners who struggle at very basic steps.

So, this is the first time my proposal for GSoC got accepted . I am really happy and would like to make the most of this opportunity.

Project Details:

I will be working on  Cantor and will be mentored by Filipe Saraiva,  who is the maintainer of Cantor

Cantor is a KDE Application aimed to provide a nice Interface for doing Mathematics and Scientific Computing. It doesn’t implement its own Computation Logic, but instead is built around different Back ends.

The main aim of this project is to port all the back ends to make use of  standard streams for communication.

At the  moment, Cantor use different methods to communicate with the back ends. Some of them use C Api, some use D-Bus protocol and some have already been making use of Q/K process.

This project is important since this way Cantor will make use of a standard technology to implement back end and it will enable the use of Cantor in different operational systems.

If you want to know more about the project, kindly have a look at my  proposal . It lists out the current status and the implementation details.

That’s all for this post. I will keep posting the progress of my project from time to time.

Looking forward to have great summers