R in Cantor: now with tab-completion

Good news, everyone. Cantor's R backend now has gained the same level of tab-completion as the original CLI R does, at least I want to believe in it. Turned out to be much easier than I originally thought as R comes with its own strong core tab-completion infrastructure, isolated from the interface code. So, even though it works, I'm not actually proud of the code and it has lots of stubs for those unlikely-to-happen situations. However those, who are using Cantor with R already are hereby welcomed to grab the r1132348 version of SoC-Cantor directory and play with it around for a while to make sure it works as intended in a regular workflow.

06:17 AM | Comments | Tags: kde, public, cantor, r

FCSS Day: Criticism

I am disappointed. To be fair, this time the days of our both faculties were less than unsuccessful. There were a handful of damn good reasons for this to happen, and thus everything was quite predictable. In my opinion, FCSS day was just a disaster, even probably worse than ours was. Summarizing the experience of both events, I can compose a list of what I personally consider to be the essence of failure and what should be avoided at all means when preparing a faculty day show:

• Newfags can't triforce — can't stress this enough. The auditory should be studied a priori and new students should not sit with square eyes wondering what the thing is all about. Of course, some jokes for the oldies are never bad, but this should only be carefully weighted, not to turn the event as a whole into a boredom-fest to youngsters. As a rule of the thumb, expect your public to be a second year student. They do know something about the recent history of university, but they totally will not understand your satire about the things having had place 5 years in the past. This equally applies to outsiders, which leads to the next point:
• Keep your style, but keep the humor within the range of understanding by a third person. Normally, we expect and welcome guests coming to our faculty days. That is a grave headache as usual, because we can't expect them to get our inside jokes with ease. It is exactly what happened today, as I ended up explaining most of FCSS day content to the husband of my colleague and my old friend who were occasionally present at the event. Professional specifics look cool, but to present them in an understandable fashion is indeed a skill to master.
• Famous people are not enough by themselves. Now, *cough*, let's just skip the plagiarism part with the driving school promoter, that will purely lie on their own conscience. It is critically incorrect to showcase a person just because of their fame. The person should be an organic part of the show, otherwise it looks like showing a trophy. This is even more the case when the popularity of the person in question is disputed.
• Parodying teachers does get old. All right, sometimes it's hilarious. However, some teachers are a well deep of humor by themselves and trying to mimic them all the time will backlash on you. A parody of a funny person risks to sound worse than the actual person would do in fact, and thus this gives no novelty in the best case scenario and a disappointment of public in the worst.
• Art, decorations and media should be shown properly. Some part of your audience will obviously have sight problems, tell statistics. Showing important information on a A4 sheets is nonsense. Not only the rear part of the hall will only see but colored papers, but the majority of the viewers will probably do as well, judging from simple mathematical assumptions. Everything to read should be shown on beamer, period. Unless it's written with meter-high letters of course. Also, speaking of beamer operation, there should never be operating system interface on the presentation screen. You're computer scientists, come on!
• Breaking the fourth wall should only be employed when the awesomeness of results justifies the intrusion. That's simply it. People dislike being engaged in action. You must be over 100% sure that the effects you are trying to achieve will overweight the discomfort of the auditory. Mosksalevsky tried to create an avant-guarde show last year and failed having done too much pressure on the viewer with too less output. Tonight it was even worse as that was not an artistic search, it was just weak.
• Organisation is the key. Despite everything, that is the aspect where we were seriously outmatched by our FCSS «rivals». Even the brightest idea will fade away if it's not properly rehearsed and planned. We had a very narrow window to prepare and thus, our show was largely undisciplined and spontaneous. Planning ahead ensures the success, while not doing so destroys every little hope of it.

Now, we'll start preparing for FNS day '11 right now already!

03:53 AM | Comments | Tags: naukma, fcss, criticism, public

Google Summer of Code project: R backend for Cantor improvements

This year I am taking part in the Google Summer of Code program. The project I am going to work on is the improvement of R language support in Cantor mathematical environment written by Alexander Rieder. The project includes both regular fixes aiming to bring the functionality of different Cantor's languages on par, and other more ambitious goals which revolve around upgrading Cantor itself which would allow to turn it into a serious and appealing working environment for R programmers. Following is the list of planned improvements:

• Syntax highlighting and tab-completion — the obvious commodity of many environments still lacks in Cantor for the R language. In the scope of the project it is planned to fully implement the syntax highlighting feature, highlighting of invalid code constructs, symbol completion from the working environment, available commands etc;
• Environment browser. The workplace in R is called an environment, which is composed of object the user has allocated. For the ease of the user a panel will be implemented which will display currently active environment, allowing the user to browse trough, annotate objects and drag them into the worksheet;
• Plotting assistant. The plots in R are much sophisticated, along with myriads of representation customizations and features. An assistant will be implemented which would ease the process of plotting for a new user(and sometimes for a lazy experienced one). It would help compose a plotting command, fine-tune an existing one and inspect the code being generated by assistant;
• CRAN integration into the package management system. A lot of Linux system repositories allow only indirect access to CRAN. They repackage CRAN's packages into a native format and publish them on their own repository. This scheme is not always convenient for both the user, which becomes limited in CRAN access, and repository maintainers, which are doing the «double work». Therefore, in the scope of the program an experimental support of CRAN in PackageKit is going to be implemented, thus allowing the user to access CRAN directly in their package manager;
• «Eyecandy» table representation. Currently, the tables in Cantor are drawn pretty much in the same way they are in console R interface — they are displayed pseudographically. Indeed, this is not the modern picture the end user expects of Cantor GUI. It is planned to replace table representations in Cantor with HTML-rendered ones, including CSS styling support. The table representation is among the most common operations in R workflow and this improvement is meant to be the first step in a series of other representation improvements outside of GSoC;

Moreover, there are plans for upgrading the architecture of worksheet representation in Cantor, which would allow to skip some of the technical limitations in the way worksheet run results are displayed. In particular, it would make possible to create interactive and standalone representation widgets such as tables with sorting and search support, extra-informative plots and much more others.

In my blog, I shall regularly report the progress achieved on this breathtaking project.

09:40 PM | Comments | Tags: public, google, kde, cantor, r