The Accidental Rubyist

invalid byte sequence in UTF-8

Archive for the ‘ruby’ Category

rbcurse no longer maintained

leave a comment »

Due to serious family issues, I will no longer be able to maintain rbcurse or other gems.

They may be taken over, or used as-is. I will continue to receive emails or comments left on this site, and will answer as soon as i can.

Sorry for the inconvenience. I will try to create a proper tutorial for rbcurse-core as a github project since I am unable to update the rubyforge tutorial due to a “Permission denied (publickey,gssapi-keyex,gssapi-with-mic)”. However, the best way of getting started is to see the examples in the examples folder of the project.

Written by totalrecall

March 15, 2014 at 2:21 pm

Posted in ruby

The Future of rbcurse (ruby ncurses)

with 14 comments

A year back I had split rbcurse into rbcurse-core and extras and experimental. Of late, I have been working on a widget called *textpad* to replace textview. It uses pads (which i earlier abhored and avoided) and this really simplifies the logic. I have also used the same textpad as a list, so that now obviates having a separate list class (unless I need to do multiple selection).
I have tested textpad as a textview and a list and a popup in a gem called cygnus. It is the ncurses version of the cetus gem which uses the terminal (I actually use cetus, cygnus is mostly to test out textpad).

I am also working on a replacement for tabular_widget using the same textpad. It extends textpad and only adds a minimal amount of code, but allows most of what tabular_widget allowed, while making it easier to override the rendering. I will release it after using it a little more in my current project. That mostly leaves replacing tree with a pad version.

However, my issue then is how to release these. I could replace the old widgets, but that won’t be backward compatible, and I have made things simpler, so i cannot be totally backward compatible. I could add these to the current project and request people to move over to these new widgets. I could release these as a separate gem….

My next goal after that is to seriously trim down the base. That is form and widget, and also Window, utils etc. This will definitely break everything and require a new gem. There is a lot of stuff that makes the base complex but may never be used. There is also code that really needs a rewrite such as Button and Menu.

Written by totalrecall

April 10, 2013 at 5:22 pm

Posted in ruby

indenting zsh files in vim

leave a comment »

Currently, if you start a function with the function keyword, the function body is not indented. The following line (added the last OR condition) will result in functions being indented.

elseif line =~ ‘^\s*\<\k\+\>\s*()\s*{‘ || line =~ ‘^\s*{‘ || line =~ ‘^\s*function ‘

Not sure whom to contact to get this fixed, or else each update will result in the change being overwritten.

Written by totalrecall

January 13, 2013 at 5:20 pm

Posted in ruby

rbcurse-extras 0.0.0 released

with 9 comments

Finally managed to release rbcurse-extras initial version with a small tweak to vimsplit. I also did some work on Actions for widgets so using ":" or "M-:" could pop up a menu for the current widget. Applications can add to this. This led to upgrades in rbcurse-core, so i’ve released rbcurse-core-0.0.3 with those changes.

I’ve tested out only editable lists and tables (the old programs) in rbcurse-extras, not everything.

The previous version of rbcurse (0.0.2), allows the user to see key-bindings for the current widget/control by pressing "M-?" or "?". It allows user to edit a textbox in vim or EDITOR and also "save as" using the ":"/"M-:" menu. It also introduced History to Field (optional at present), so you need to extend the Field object. History can be popped up using "M-h". I’ve used this in the shell-output dialog.

I’ve done some changes to ncurses settings (cbreak and half-delay) as i found that pressing C-c repeatedly quickly was crashing the app (see earlier posts), Hope this holds up in all cases.

Written by totalrecall

January 5, 2012 at 1:35 pm

Posted in ncurses, rbcurse, ruby

TIL: ncurses cbreak and halfdelay

leave a comment »

I accidentally typed C-c quickly in a sample of rbcurse and found that the program crashed giving an error somewhere deep in logger. I repeated this in various programs, the line giving the error would be random. I tried various versions of ruby, wondered whether this had started happening after upgrading to Lion, or perhaps a bug in ffi-ncurses, or something with iTerm2, or maybe xterm-256color.

(I might add, that when i do a wgetch or getch in my app, there is "rescue Interrupt" clause to take care of this situation.)

After many hours, I finally found that if I press C-c slowly one after the other, my app takes it, but in quick succession, the 3rd or 4th causes the program to abort. After further research, i came down to the following:

1. using cbreak in ncurses causes successive Control-C’s to be taken as interrupts.
2. Using half-delay also puts ncurses back into cbreak mode.

I was using half-delay so that some complex key codes can be handled, and this includes using ESC in place of ALT/META. So pressing ESC followed by ‘w’ in quick succession is taken as ALT-w and not 2 key strokes.

Currently my working solution has been to comment off cbreak, and to use nodelay in place of halfdelay. It seems to be working as of now. No idea whether there is some key under some terminal that may fail. I have tested this out under many different TERMs and stuff. I hope this doesn’t make the application hog CPU.

Update: I cannot set nodelay in startup as this means that wherever in the application I might do a getch, it will be non-blocking and I will not get the key I am expecting. I found this while typing “gg” in a textview. So I have used a wtimeout and set it to 1000 for the meantime. Switching off nodelay by itself does not work for me since in my app, when the window gets an ESC it waits for the next character or ERR to see if its an Esc-alphabet.

Written by totalrecall

December 20, 2011 at 12:03 pm

Posted in ruby

Major restructuring in rbcurse 1.5.0

with 2 comments

I’ve just finished a massive operation of splitting rbcurse into 3 gems. rbcurse-core contains the core infrastructure and basic widgets. These should allow for most ncurses applications. I intend to focus on keeping this as well tested and stable, and backward-compatible as possible. I’ll also work on simplifying the code of core as much as possible. The earliest widgets have also made it into core since a lot of users are using them. Thus, menu and textarea have made it, even though the editable textarea will never be very stable, and its better to use Vim to edit bodies of text. Core does have some new work which is quite experimental but i hope to have it as an integral part of rbcurse and to stabilize soon.

I’ve moved some more complex widgets to rbcurse-extras. These are widgets you should require less often. I’ve moved Table to extras, the simple. non-editable version will be in core. Similarly, the editable version of listbox is in extras, but the readonly version will be in core.

Stuff that is usable but experimental, and not thoroughly tested is in rbcurse-experimental. Essentially, I really am leaving it to users to improve. Some of it could move to extras if it proves useful.

Henceforth, rbcurse will be a meta-gem that installs the other three. You may install only core and develop with that. The directory structures have also changed appreciably. I did this in order to make the movement into 3 separate repositories a bit easier.

BTW, the first part of this operation was separating code into code, extras and experimental directories. Then adjusting the ‘requires’ in each file. Shell and perl (pie) made this quite easy. The second part was to create separate repos. After reading many posts on stackoverflow, I managed to get that done. I hope the history of each file is correct.

I did all this in the 1.5.0 branch, not master, so pushing this to master was another small job. Again found some articles and help on SO. Then to create separate gems for thm repos and tie them together. Someone pointed me to rspec and I’ve used their model.

I still have all the examples lying in the old repo. These still need to be changed so they can run only using core or extras. Most of them use features from all or two gems. I still have to change the names of some widgets that have moved from core to extras or vice-versa (listbox and table), and replace messagebox and tabbedpane with the simpler rewrites. This should take me several days, esp rewriting the examples. I intend standardizing the core widgets in 1.5. I’ve dome work on stacks and flows for placing widgets which needs to be tested further and integrated fully. I’ve done work on color-formatting of text which needs to be integrated and the API firmed up.

1.5.x should mainly be simplifying and cleaning up stuff, removing cruft. Very few feature additions.

Written by totalrecall

November 17, 2011 at 11:58 pm

Posted in ruby

colorizing bash output on terminal (non-curses)

leave a comment »

I’ve found that my ruby command-line scripts (gems) that put information into sqlite tables and then report from there, take time to load. If not loaded for an hour, the command can take as much as 8-10 seconds to load. I’ve tried faster-rubygems but that has made no difference (I am on 1.9.2 on OSX Lion).

The load time is okay, when i wish to add some info, but when I keep checking, its not acceptable. However, my earlier bash scripts that do similar reporting (and addition) respond instantly. Now i am not going back to writing stuff in bash, since the syntax keeps befuddling me after all these years. However, it takes only a few minutes to report data from sqlite, and get instant responses. You can also throw in 256 colors to get a neat presentable output. Here are some things that can help you.

This is the meat of the script. Define a temporary input and output file

echo ".mode column" > $file
echo "select id, title, priority, status from mytable where status != 'closed' order by priority , id;" >> $file
sqlite3 bugzy.sqlite < $file >> $out

Now your output is in the outfile. You can less or most the file.

If you want to color the rows here are some options.
colorize is a neat program that allows you to define regexes that work on a line basis and color the entire line. There’s a switch for "only color the pattern not entire line", but you can’t have both. So I stuck with the default.

cat <<ZZZ > colorize.cfg
/ cancel/ black
/ closed / black
/ started / blue on_yellow
/ P1 / reverse
/ P2 / bold white on_blue
/ P3 / yellow
/ P4 / magenta
/ P5 / bold blue
ZZZ
colorize --config=./colorize.cfg $out | less

So here I create a config file for colorize to use. It does the rest. Notice it has attribute, background and foreground, although it often does not work if you give both attribute and other options. Also, it does not seem to support 256 colors.

If you are willing to write a few lines of sed, you can add a variety of other colors or backgrounds rather than the garish 8 or 16. I like shades of grey.

I’ve put the basic color codes into a file that can be sourced. I’ve added some for the gray scale also. You need 256 color support in your Terminal (OSX’s Terminal has it, so does iTerm2). gnu-screen will have to be recompiled with 256 (see previous post).

I found a function that lets you get any color.

 function EXT_COLOR () { echo -ne "33[38;5;$1m"; }

You can use it as "$(EXT_COLOR 128) hello". Or use backticks.

Now use these combinations in sed (warning: blog has eaten up slashes and maybe more).

text=$(sed "
  s/(.* started .*)/${BLUE}${ON_WHITE}1${DEFAULT}/g;

  s/(.* canceled .*)/${BLACK}1${DEFAULT}/g;
  s/(.*P1.*)/${BLACK}${ON_YELLOW}1${DEFAULT}/g;

  s/(.*P2.*)/${YELLOW}${ON_GRAY236}1${DEFAULT}/g;
  s/(.*P3.*)/${CYAN}${ON_GRAY235}1${DEFAULT}/g;

  s/(.*P4.*)/${GREEN}${ON_GRAY234}1${DEFAULT}/g;
  s/(.*P5.*)/${BLUE}1${DEFAULT}/g;

  " $out)
echo  "$text" | less

There, you have instant display of data from an sqlite3 table. No ruby load times.
There's also a project called ansi-color on google-code, however, you would use that if you are generating the output. Let me know if you come across any project that allows for using 256 colors in bash in a cleaner way.

Also, let me know if you know how to get rubygems to load faster. I am sure if wrote the above program as a stand-alone ruby program it would respond immediately.

Here's a sample screenshot output, it's still garish and yucky, but i did it at 2am. Will improve the colors soon.

Written by totalrecall

November 14, 2011 at 1:06 pm

Posted in ruby