I have completed the tab completion framework is now complete. It has been tested with a network updater built on MySQLdb library of python. Both static and network parts of updater mechanism are working.
Now the task will be to finish this module by rewriting this network update framework with boots query framework.
I now think that gsoc work is complete for me. Will now look for more open source work with drizzle.
Developments On Boots GSOC 2010
During the summer of 2010, I am participating in the Google Summer of Code. I got the opportunity to develop for the Drizzle shell Project: Boots.
Sunday, August 15, 2010
Monday, August 9, 2010
Tab completion module in boots
As the last part of gsoc project, I have created tab completion. I have written the framework for completion, but I still need to find a way of fetching db names, table names etc from server. This tab completion works with curses ui only.
The feature could be downloaded and tested from here https://code.launchpad.net/~ashishsharma/boots/curses-devel.
I have also created a separate branch for updating the documentation. I am writing python style docs for documentation of the project.
The feature could be downloaded and tested from here https://code.launchpad.net/~ashishsharma/boots/curses-devel.
I have also created a separate branch for updating the documentation. I am writing python style docs for documentation of the project.
Labels:
drizzle,
tab completion
Tuesday, July 13, 2010
Curses UI latest updates: Control Signals now supported
After working on it for over a month and a quarter, now the branch for curses ui is pretty mature. It is now supporting nearly all the command line editing commands and signals and is also providing syntax highlighting for sql.
The latest revision of the branch adds support for control signals. It also features some code refactoring and refinement.
The last hurdle that still remains in curses UI is the handling of SIGWINCH signal or the resizing of a terminal window. In my earlier posts I have described the difficulties that I am facing on this. Still I have to figure out a way to properly incorporate this functionality to curses UI.
UI is available for use at lp:~ashishsharma/boots/curses-devel .
Screenshot:
The latest revision of the branch adds support for control signals. It also features some code refactoring and refinement.
The last hurdle that still remains in curses UI is the handling of SIGWINCH signal or the resizing of a terminal window. In my earlier posts I have described the difficulties that I am facing on this. Still I have to figure out a way to properly incorporate this functionality to curses UI.
UI is available for use at lp:~ashishsharma/boots/curses-devel .
Screenshot:
Friday, July 2, 2010
Curses UI for Boots - Commented and Refactored.
After having the curses ui for boots nearly complete, I engaged in code restructuring, refactoring and comments insertion.
My main thrust was to make the code less messy, standards compliant and easier to review. I have uploaded the revision with latest of these at launchpad.
Code restructuring led to a nearly complete makeover of the code structure and files. Doc strings for functions have been inserted. I have also added some comment CODEXs(CODe EXplanations) to help explain working of larger code blocks.
The next step in the project will be to create a local cache of database server's objects. But before that lexers are to be added for lingos, other than 'sql', which are supported in boots and create the missing curses UI features.
Testing the UI more extensively will reveal bugs in the UI. So if anybody gets interested, then one can get the code from here and file bugs on launchpad or mail them to me.
My main thrust was to make the code less messy, standards compliant and easier to review. I have uploaded the revision with latest of these at launchpad.
Code restructuring led to a nearly complete makeover of the code structure and files. Doc strings for functions have been inserted. I have also added some comment CODEXs(CODe EXplanations) to help explain working of larger code blocks.
The next step in the project will be to create a local cache of database server's objects. But before that lexers are to be added for lingos, other than 'sql', which are supported in boots and create the missing curses UI features.
Testing the UI more extensively will reveal bugs in the UI. So if anybody gets interested, then one can get the code from here and file bugs on launchpad or mail them to me.
Monday, June 28, 2010
Boots Developments: Curses UI is nearing completion.
Curses UI for boots finally looks like its complete, although there is a feature missing( Explained in a previous post here).
In short I will state curses UI as a new face for the already great drizzle shell boots. This face is a bit colorful too with syntax highlighting in the commands. Although the syntax highlighting has to be refined and modified for a better look. But it is still good.
After sharing curses UI details, its now the time to share a bit of my experience with it.
At first when I started to code the UI in curses I felt that it is going to be an easy job. All I had to do was emulate terminal with help of curses. But as I started, difficulties started to unfold. First, there are not much on-line materials available for reference on python curses. Even tutorials on C/C++ curses have not been updated for long. Second, debugging is case of an error is difficult and consumes a lot of time. Messages generated by python related to the error are mostly lost on testing on a simple terminal. This made me finally use winpdb for the purpose of debugging. Finally now the curses ui is nearing completion and I hope of completing it quickly.
The ui is available for review and testing at the launchapad branch.
In short I will state curses UI as a new face for the already great drizzle shell boots. This face is a bit colorful too with syntax highlighting in the commands. Although the syntax highlighting has to be refined and modified for a better look. But it is still good.
After sharing curses UI details, its now the time to share a bit of my experience with it.
At first when I started to code the UI in curses I felt that it is going to be an easy job. All I had to do was emulate terminal with help of curses. But as I started, difficulties started to unfold. First, there are not much on-line materials available for reference on python curses. Even tutorials on C/C++ curses have not been updated for long. Second, debugging is case of an error is difficult and consumes a lot of time. Messages generated by python related to the error are mostly lost on testing on a simple terminal. This made me finally use winpdb for the purpose of debugging. Finally now the curses ui is nearing completion and I hope of completing it quickly.
The ui is available for review and testing at the launchapad branch.
Sunday, June 27, 2010
Handling terminal window resizing. A nightmare.
I am working on the boots curses ui for over a month now. While developing curses UI I was faced with the challenge of handling the scenario when a terminal window is resized.
My first approach was to look out for some references on line. I looked out and in all the resources that I found nothing more than this was written -- ''Handle the SIGWINCH signal'' . So I went on to handle it. I wrote the function to handle and tried it on. But to my bad luck, it didn't work properly. The problem was that whenever curses was asked to create a new window it always created of a size on which it was initialized in the first place.
I tried to de-initialize and reinitialize curses, but that too didn't work.
I then tried to dig out some IRC channels where I could find some help. For this purpose I tried to contact weechat developer who seem to have solved this problem quite well. But from there also I was not able to receive much help. They told me the same line that I had seen before.
So as a last resort I tried to dig out code which had SIGWINCH handling stuff in the source of weechat. I have not been successful at this right now.
So for right now I have stopped the work on this and have removed limited SIGWINCH handling capabilities from curses ui for boots.
I would like to add this capability in curses UI in near future.
My first approach was to look out for some references on line. I looked out and in all the resources that I found nothing more than this was written -- ''Handle the SIGWINCH signal'' . So I went on to handle it. I wrote the function to handle and tried it on. But to my bad luck, it didn't work properly. The problem was that whenever curses was asked to create a new window it always created of a size on which it was initialized in the first place.
I tried to de-initialize and reinitialize curses, but that too didn't work.
I then tried to dig out some IRC channels where I could find some help. For this purpose I tried to contact weechat developer who seem to have solved this problem quite well. But from there also I was not able to receive much help. They told me the same line that I had seen before.
So as a last resort I tried to dig out code which had SIGWINCH handling stuff in the source of weechat. I have not been successful at this right now.
So for right now I have stopped the work on this and have removed limited SIGWINCH handling capabilities from curses ui for boots.
I would like to add this capability in curses UI in near future.
Tuesday, May 25, 2010
Doubts on Curses UI.
In the development of curses ui, now I'm done with creating the basic classes needed and now have started developing the main input and output classes and functions.
At this point I am in a bit of confusion, I have to decide between two types of UI that are possible with curses UI.
One is to make a UI similar to a terminal, as a regular terminal .
Second one is to make UI similar to weechat, in which user input and output are separated from from each other.
See images attached for better understanding of my point.
Now according to my assessment, the terminal-like UI will be more complex as it is likely to have more parameters to take care of. As compared to terminal like UI the other weechat like UI must be easier to implement.
Please leave you thoughts as comments here.
At this point I am in a bit of confusion, I have to decide between two types of UI that are possible with curses UI.
One is to make a UI similar to a terminal, as a regular terminal .
Second one is to make UI similar to weechat, in which user input and output are separated from from each other.
See images attached for better understanding of my point.
Now according to my assessment, the terminal-like UI will be more complex as it is likely to have more parameters to take care of. As compared to terminal like UI the other weechat like UI must be easier to implement.
Please leave you thoughts as comments here.
Subscribe to:
Posts (Atom)


