Showing posts with label kawigiedit. Show all posts
Showing posts with label kawigiedit. Show all posts

Thursday, September 12, 2013

KawgiEdit-pfa with c++ code cleaner and Greed

I released a new update to my unofficial version of KawigiEdit. Among other minor things, I added ahmed_aly's unused code cleaner. He made a custom version of KawigiEdit a long ago that would clean some unused code in c++. When browsing codes in the TopCoder arena, I noticed that there are many coders using his version of KawigiEdit, but since he coded it a while ago, it is missing some of the new features KE has. I merged the two forks together so that coders interested in both the code cleaner and the new features are able to use them. Anyway, the code cleaner is disabled by default (I, for example wouldn't use it, I *love* to make codes full of comments visible to anyone). But it can be enabled in the c++ options.

Get it at the Forum thread

Fun anecdote: This might be the last version of KawigiEdit I release. Yesterday, after making these updates, I thought to myself ("Why are you bothering with this? No one uses it") so I decided to go to the SRM 590 division summary and read codes. Everyone is using some FileEdit variation. Many people are using an old KawigiEdit version (Including some VERY OLD ones). A couple are using the KawigiEdit version with ahmed_aly's code cleaner. Another couple are using fushar's plugin. I did find one submission that uses KawigiEdit-pf though :) Great. (Although since KawigiEdit-pf allows you to remove the Powered by line, maybe some people are using it and just remove it).

Well, I am mostly making these KawigiEdit updates for myself. So it doesn't matter if it doesn't have many users. However, I was noticing that KawigiEdit was giving me some issues in becoming what I wanted it to become. Or rather, I want it to become something that it is not good at. The option to completely disabling loading of code saved in TopCoder is one example.

When reading the codes, I noticed around 5 or so submissions that used "Greed 1.5", that was curious because, unlike the other plugins, I never heard of this one and it wasn't announced in the forums. I was curious and googled. And it is very promising. Actually, Greed turns out to be close to my ideal plugin. Because you can customize even the tester code. I have been having some nice results with it although currently have an issue with long long. I might have more to say more about this plugin and post some tutorials once I decide if it can really do all that I need.

Tuesday, August 06, 2013

KawigiEdit 2.3.0

Yep, it seems like I am sliding the maintainer slippery slope.

The major changes in this version of KawigiEdit were caused because I wanted to try the idea of using an external editor to code TopCoder stuff. KawigiEdit is good as an editor - definitely much better than the vanilla editor. But jEdit has a lot of features. Let us face it, the "Code Editor" problem is a problem that has already been solved and a minor project like KawigiEdit can't compete with other editors in that area.

So , move to FileEdit / moj, etc ? Not really. The thing is that although KawigiEdit can't beat external editors, the TopCoder integration is something that KawigiEdit does wonderfully. As an editorial writer / problem setter that really, really likes c++, I need a plugin that works with Java, c++ and python. Language support is definitely a deal-breaker. Having to install and use multiple plugins - one for each language would be quite terrible.

Kawigi is great at generating tester code. The resulting file compiles and run. The tester code is removed before you send it to TC. And that includes all 5 languages. Not only that, but you can easily edit/add the test cases it uses. And temporarily disable some without deleting them.

Another super ultra convenience is that it saves independent files for anything you code in topcoder. I have a giantic directory full of old solutions I can use for reference. I actually have this directory synced with a private dropbox folder, just in case my computer explodes during a SRM, I can take my laptop and keep on working...

So, the point is that nothing really beats KawigiEdit as a plugin for vexorian's use. So I tried to give it a try as a bridge between topcoder and jEdit . It worked ok (And I even managed to add a jEdit macro that calls my separate terminal window tester just like KawigiEdit did). But I found some issues. There is specially too much cluelessness as to what is the editor doing. Is it using your code or its own? Why isn't it loading your code? Etc. Overall I had to make many additions, including a log window. The log window is also very useful when I am editing KawigiEdit, I can use it to show debugging messages :). I fixed some other things related to syncing with an external editor.

So, there it is. If you want to try it out, go to its topcoder forums thread.

As usual, my personal mod for KawigiEdit has been updated too. Refer to the old blog post to find it. Actually, it has been changed. Now it dose not have the compile tab. Only the output tab. Any exit code error in running compile/run commands will be reported there.

Wednesday, July 31, 2013

KawigiEdit update 2.2.1

So, yesterday I released a new version of KawigiEdit that enables you to temporarily disable some test cases for better debugging.

Today I was using KawigiEdit to finish my code for SRM 586's div1 1000 (Editorial will be ready soon). Being able to disable test cases was very useful, but I discovered a bug with it. I fixed it and since I am apparently a strong believer in release soon, update often. I am making a minor revision. Version 2.2.1.

As usual my KawigiEdit mod has been updated too

Tuesday, July 30, 2013

KawigiEdit update 2.2.0

It appears that I cannot help myself. I told to myself (Since you are updating KawigiEdit anyway, why not add the stuff you have always wanted it to have?). And there we go...

This update is cool mainly because you can now temporarily disable test cases. This can be very useful during a match when there are 7 cases. One test case is wrong. But debugging the test case is difficult because the other 6 cases cause you trouble. I took this idea from watching Petr's screencast for SRM 550. He uses CHelper, which I am sure is a great plugin, but it is only for Java coders.

KawigiEdit unofficial updates thread: http://apps.topcoder.com/forums/?module=Thread&threadID=794920&start=0&mc=8#1759241

Also the KawigiEdit-pfx mod (The plugin I actually use) has been updated too: http://vexorian.blogspot.com/2013/07/my-topcoder-coding-setup.html

Sunday, July 28, 2013

New version of KawigiEdit-pf

I was having some fun writing SRM 586's editorial. Since I am now allowed to use python code I was giving it a try. Could make some very short looking stuff. However, I eventually noticed that my code for div2 250 was not actually working in TopCoder's servers - Giving a runtime error about tuples not having the remove attribute. They were working fine locally. My first reaction was to assume that TopCoder's python version was old. So I tried to instal python 2.6 instead of my local 2.7... Still the same error.

Eventually I figured, ffao's python implementation was making KawigiEdit generate "array" function arguments as lists [a,b,c,d] . But TopCoder's server sends them as tuples (a,b,c,d). So I had to make a new release for KawigiEdit-pf.

KawigiEdit-pf forum thread.

Of course, in reality I first updated my KawigiEdit mod. The KawigiEdit-pfx version in that post has been updated too.

Thursday, July 25, 2013

My TopCoder coding setup (update 4)

Update (Aug 6-th, 2013): New KawigiEdit-pf version. Now 2.3.0. Synced KawigiEdit-pfx with it. Some tweaks.

Update: Updated KawigiEdit-pfx to version 2.1.9.1 (Incorporates changes from normal KawigiEdit. Also it renames the Outside mode window so that it begins with the word "Outside ", updated gnometerm.sh accordingly.

Around a year ago, I had a big , big, enormous problem. I was supposed to be writing blogs for the TopCoder Open, and I had absolutely no idea what to talk about (Speaking of which, whatever happened to this year's TCO blogs?) . So I improvised. I decided to rush a post about arena setups. It is not easy to bring everything to work in the optimal way for you. Back then someone asked if I would release my modified version of KawigiEdit. Although I said I was going to release it, it took me this long to do it.

Why I modified KawigiEdit

KawigiEdit is a great Arena plugin, and everyone just starting in Topcoder should begin with this one. That's the reason I chose it. However, there were some issues with it. Back when I was starting to use TopCoder plugins, the version of KawigiEdit was not very updated and there was an issue with problem method signatures that returned double, TopCoder rules admit an absolute or relative error of up to 1e-9. The old KawigiEdit, however, compared doubles without taking care of this. So whenever you tried to solve one of those problems in KawigiEdit, it was likely that you would have KE tell you the results are wrong, even though they are not - they are really within the accepted range. With Kawigi not around to update the plugin, I had no choice but to add the comparison stuff myself.

Eventually, this issue got fixed by pivanof, but I started slipping downwards the slippery slope of editing KawigiEdit. Overtime things got crazy. It all started when I wanted to add separator lines between the output of example cases. I use print statements to debug issues with my problems and when a test case gets full of output, it is hard to find the test case in the normal KawigiEdit output format.

I added these big lines =========================== to the output. But I had a new problem. The lines were good at separating example cases because they were very visible. Perhaps too visible. They were starting to distract me. I needed these lines to of a color that didn't contrast as much as the background. But adding color to the KawigiEdit output was looking very problematic.

It occurred me that I could use ANS color codes in the kawigi edit output . But then I would have to make the output appear in a terminal window instead of KawigiEdit's output tab... I had mixed feelings, but then I noticed "If I make output appear in terminal, I will also have the benefit of being able to read output and my code at the same time!" unlike the usual KawigiEdit experience... Then I noticed another good benefit. Closing the terminal window would forcefully kill the tester program. Killing programs was something that KawigiEdit was having issues with until a recent update.

The problem was how to move the output to a terminal window...

The gnometerm script

It was not easy to do it. But with the help of a lot of tweaking and a program called wmctrl. I was able to make a program that would run any command inside a terminal window. There were many requirements. The terminal window will be always on top, so that you can type on a larger window without it going missing. After the command finishes execution, the terminal shouldn't close. The active window should still be the coding window. Also, we don't want terminal windows to pile up, it is best if the program closes the previous one. But only this kind of terminal windows... you wouldn't want other terminal windows to go away...

This program is adapted to work with gnome-terminal, the default terminal application in Ubuntu. I am not sure how possible or not it is to make it work in other terminal applications.

#!/bin/bash

# Run command in terminal window
# (c) Victor Hugo Soliz Kuncar under the Zlib/libpng license

# Terminal geometry. Read gnome-terminal manual for more info
# Basically, this is what makes sure the terminal spawns at the left side of the
# screen
GEOMETRY="--geometry=75x50-0-100"
# Terminal profile, I have a profile called KE
PROFILE="--window-with-profile=KE"
# you can leave both options empty...

TITLE='** TopCoder **'
# The window title for the terminal window. It is *not* merely aesthetic.
# It should be something unique that you are sure won't be shared by a window
# you don't want to be closed automatically whenever this command is called

#===============================================================================
if [ "$1" = "_act" ]; then
wmctrl -r "$TITLE" -b add,above
# == Activate window command: ==

# The idea is to activate the code window after the terminal window is created
# so that you can still code on it even after the output terminal appears.

# If the editor is undocked, the code window is called Outside KawigiEdit...:
wmctrl -a 'Outside KawigiEdit'
# Else it will be the normal competition arena window:
if [ $? = 1 ]; then
wmctrl -a 'TopCoder Competition Arena - Coding Phase'
fi

# why twice? Because once seems to fail 1/20 of the times...
sleep 0.1
wmctrl -r "$TITLE" -b add,above
exit 0
fi

if [ "$1" = "_monitor" ]; then
# == Monitor command: ==
# In this mode,
# - Call the activate command as another process so that there are no
# delays before calling the compiler.
#
$0 _act &
# - Run the command (provided to ./gnometerm as arguments)
${@:2}
# ${@:2} means "all arguments except first one"
read aok
# read aox makes the bash program wait until someone presses enter.
exit 0
fi

# With a tool called wmctrl, close the window with title 'Topcoder Test cases!' so that
# only one of those windows exists at once:
wmctrl -c "$TITLE"

# Run the terminal: The terminal will run this script in monitor mode...
gnome-terminal $GEOMETRY $PROFILE --title="$TITLE" -x $0 _monitor $@ 2> /dev/null & disown
# 2> /dev/null is just so output doesn't go to KawigiEdit's tab...
# & disown so that killing this script doesn't kill ther terminal.
exit 0;

Modded KawigiEdit

Anyway, by using this gnometerm.sh script and placing it in KawigiEdit's work folder (and setting it as executable). I am able to put things like ./gnometerm.sh python $PROBLEM$.py instead of just python $PROBLEM$.py and the execution will appear in the terminal. There are various issues with vanilla KawigiEdit and this approach.

It is convenient to have both compile messages and output appear in the terminal window. A bit of a problem is that KawigiEdit will automatically switch to the compile and output tabs whenever you run tests.

I had to change that. In fact, I removed the output tab altogether. I would remove Compile, but some of the least used languages still use it. Instead, the compile tab is only switched to automatically when there were "compile errors". Errors in the compile command. For my Java, c++ and Python setup, I use a single command to compile and run (I do not use the compile option in KawigiEdit and instead place an "echo" in the field ). The commands do various things. Specially my c++ command is not content with just compiling the program and running it. It also runs it in valgrind... and recolors the compiler messages :)

Anyway, the important thing is that I have a KawigiEdit mod. It has various "features" / things done different to the KawigiEdit I released before:

  • The test case output is very different. Besides of the ======== separators I mentioned, green and red ANSI color codes are used. Also, it has less clutter as it doesn't show your answer to a test case unless it was wrong. It also uses simply +, x and T (all colored) to say if a test case is correct, wrong or failed the time out. Because of the ANSI color codes, you need to use a trick similar to the gnometerm script to run the commands if you want to use this KawigiEdit mod.
  • The languages tab in settings is split in tabs, instead of having all settings in a single tab.
  • When you click the run tests button, the "Compile" tab will not be automatically selected. Unless the compile command you assigned has an exit code different to 0.
  • There is no output tab. If the run command you use has any console output, it will be added to the compile tab.
  • Instead of inserting "Powered by ... !" in your code it inserts a message that just says the editor version.
  • It doesn't say "you are a stud!" anymore. It says "Seems Ok (... Is It?)". I was never a fan of the stud thing.
  • The version is KawigiEdit-pfx 2.1.9. p stands for pavinof, f for ffao and x because it is my mod :).
  • Obviously , it supports python, just like KawigiEdit-pf.
  • So I would guess it is Linux-specific? Even gnome-specific

So if you are still interested, here is the jar: It has source code too: http://dl.dropboxusercontent.com/u/95690732/KawigiEdit/pfx/2.3.0/KawigiEdit.jar

Run script examples

Like I mentioned, I compile and run in a single command (which is called by gnometerm.sh). Here are some mild examples:

./gnometerm.sh python $PROBLEM$.py. It is easy for python :)

The following script works for Java, and adds a memory limit (Pass in class name as argument, if the script is called runjava.sh call it like: ./gnometerm.sh ./runjava.sh $PROBLEM$):

#!/bin/bash
echo "compiling..."
javac $1.java
if [ $? = 0 ];
then
java -Xmx64m $1
fi

In which I tweak KawigiEdit

I made an unofficial KawigiEdit release. It is all about python support.

Participating in TopCoder without a plugin that would generate a tester (with appropriate problem method signatures) Can get very tedious. Although the admins have finally added python support, it needs plugin support as well if we want it to work*

I want python to be popular in TopCoder, for many reasons. The main one being that it is a free language without attachment to unreliable corporations like Oracle or Microsoft. It is a very open language. It is also dynamic, something that is novel in TC. I know too that python is usually among the third most popular languages in the google code jam. I like the idea of being able to use python in editorials, it should be fun depending on the problem. There are people who claim python is a good beginner language. To be honest I don't think so. I think that the worst thing that could happen to a beginner is to deal with more run-time errors than compiler errors. But because of how the claim that python is good for beginners motivates people to talk to beginners about python, there ARE a lot of programmers that know python much better than C++.

The next Saturday will be the first TopCoder SRM that will officially support python. (SRM 585 was supposed to be it, but there were issues). Ever since the new compilers were announced I was trying very hard to make python work in KawigiEdit. For context, Kawigi was a very notable member and problem setter of the TopCoder community back aeons ago when I first joined. He made KawigiEdit which is probably the best plugin for those who are starting up in the arena. It supports all the TopCoder SRM languages, and it is very configurable. Although I think more advanced coders probably want something that uses an external editor. I knew for a while that Kawigi designed the plugin very well and flexible, so I was trying to implement python support. And failing. It was not until ffao made his own release that I finally discovered what I was missing.

The crux of the matter is that ffao's changes needed a bit of minor tweaks and I made them. Updated KawigiEdit.jar. There is more information in the forum thread.

I did my best to test that the python support is working in various problems. (Things like double return values, arrays of double, string comparisons). And it seems to work fine. But I don't take responsibility for any issues you might find during a match. Sorry:).

It is amazing how little (relatively speaking) work we needed to make KawigiEdit able to use python. Kawigi is a great software designer even in such a minor project as KawigiEdit. It is no surprise that you would later hear of him working for a couple of tech giants...

Am I going to maintain KawigiEdit now? The answer is no officially. I have not asked permission to pivanof yet to make new releases and those things. I also think that for the most part (except for the python support) KawigiEdit is not lacking in features and is working Ok. So there is no rush to pick a new mantainer. There is also the small issue that I actually use a KawigiEdit mod (which I will be releasing in a later blog post), so I don't really use the upstream version of the plugin. I think it is better to leave the possibility of someone else with more time and interest in improving the plugin to become the mantainer.

* In reality, it seems that the performance difference between python (at least the version in TC's servers) and Java is too grand and it may be impossible to make a passing submission in certain problems.