1. line breaks are counted to often. This is not always needed. However do not know how much it costs to go through the 4GB and count the breaks.

2. When moving backwards, it seems that the full buffer is parsed from begin to the current position. This could be done backwards.

Viq was intentended to be a project to add vim like interface to qemacs…

1. as about qt-wt integration: Considering that even well tuned browsers like the webkit based ones on embedded devices, would make sense to create a rendering engine for wt, that interacts with the Qt Declarative UI (QML). Such a combination would result in a very fast client and very fast server for deploying services on embedded devices

2. Implement WSqlQuery/WSqlModel etc family, as QSqlQuery/QSqlQueryModel . The Wt::Dbo family is nice, but they do not provide at the moment the integration with views.

3. The already proposed idea about using Qt Designer to design Wt widgets, might be a wrong direction. In my opinion a better solution would be to create a Wt application that would allow the construction of “empty” widgets, through a web application. The advantage of this approach is that contrary to Wt Designer, the widgets would render on the final web application as they render in the Wt. The product of this designer wt application would be a html template. Any .ui interface etc. would mean unnecessary overhead in the development cycle etc. etc.

http://github.com/apenwarr/git-subtree (git subtree)

http://apenwarr.ca/log/?m=201001#04 (backup with git)

What and Why? Just simply imagine a large project with hundreds of files, where you would have to do a huge huge huge huge refactoring that would affect more than 50% of files. (renaming for example). Opening each file is out of question. You could write some sed scripts to do the job. But why? Why you would not be able to open all the files in vi or you favourite editor, first do some analysis by searching for occurrences, then mass replace, etc, etc.

The aggregate filesystem should have some configuration file that would define what is aggregated by listing the files or defining rules (regular expressions for example, globing) about what kind of files to be included (for example all files under a directory). You would end up with a huge file that would be composed by all the files (in random order). End of files of each original file would be marked with a special line, I will call it pivot line. These pivot lines would unambiguously identify the end of file. Removing such a line would mean that the content would flow to the file that follows. The pivot line would also contain the full path of the original file.

When you open an aggregate file and start to read it the aggregate fs would open all the aggregated files (or eventually define other strategies). If you would read the file, the aggregate fs would read one by one all the aggregated files. When saving an aggregated file, the aggregate fs would save each part of the content to the original file indicated by the pivot line.

Such pivot line would also help to create commands inside your editor that would have eventually affect on the original file. For example open the original file.

Such a filesystem could be implemented both in kernel and userspace with fuse.

1. the working area. The working area can be on different machines, therefore I call these remotes as the machine name as well. It makes sense to have such remotes, as working on machine X, the Y will be a remote to X. So on each copy/mirror of the git repo, I will have a remote X, Y, Z…, where X,Y,Z… are the machine names I am working on. So far I am not sharing repos with other users on same machine. If that would be the case <machine>.<user> would probably make sense.

2. Git bare space. I call it simply “bare”. This is a remote for all other copies/mirrors that is somewhere on my local network. In my work-flow, I normally always pull/push here. I have some cron jobs, that do frequent pull push (if it is the case) with main repositories like github, or the projects origin.

3. Github and Gitorious.

4 Origin. I use this name for remote for projects that I do not keep a local copy/mirror bare repository. For these ones it really makes sense to think about the abstract remote pull/push.

***** old post follows ****

Under this name I will try to write a few articles about my design and experience in using git on top of clearcase in order to achive two things:

• make the enterprise happy by keeping the sources in a central repository
• make my work flow much easier by using the power of git and avoiding dead times when waiting for the slow clearcase to do operations like view setup, align with baseline, create branch, merge etc. The goal is to do all necessary development steps fast with git (including collaboration with other developers), and let the computer do the rest of required formalism against clearcase (checkout, “edit”, merge, etc)

At the enterprise where I would like to deploy this design, one of the first handicaps I faced is that the there is no place in the filesystem hierarchy before the clearcase vob, where I could place the .git folder, to map it over the cleracase views. One of the solutions came to my mind is to aske sysadmins to install the fuse module, but my request was refused for system security reasons.

Another alternative seemed to me was to run myself a virtual machine and mount there the vobs under a subfolder of a folder that contains .git. Running whatsoever virtual machine was not a choice do to my access limitations, so only UML could come in question. Uml would mean build a kernel, build a minimal filesystem with necessary tools, etc, etc.

Accidentally however I came across a simpler solution. And that is called virtual square umview. Virtual Square’s “main goal is to create an unified environment that allows virtual machines, systems and networks to communicate and interact”. Umview is a tool that is part of the project. It traps practically any system calls issued by any program that a user runs, and transform them as instructed. For example you can configure it to transform “read /mydiskspace/project.git/clearcase/vob1/module1/src/file1.c” into “read /clearcase/vob1/module1/src/file1.c”. That is to mount virtually “/mydiskspace/project.git/clearcase”  to “/clearcase” inside the virtual environment. Once having that in place you may create the mirroring .git repository in /mydiskspace/project.git. You will feed with source data from the virtually mounted /mydiskspace/project.git/clearcase/vob1/module1/src/file1.c.

How would you concretelly issue your commands? Here are they (see comments)

#>umview $SHELL #start a shell under the virtual environment

#>#you are now in the virtual environment but you have the “same” view

#>#until you start to “manipulate” it

#>um_add_service viewfs #load the module that handles virtual mounts

#>mount -t viewfs /clearcase/vob1/ /mydiskspace/project/git/clearcase

#>cd /mydiskspace/project.git

#>git init  #if this is the first git action

#>git add . #fill the repository with your files from the clearcase view

It is obvious that in the example above you are in the context of a view. You might be able to create wrapper commands around git, that will execute always in this “manipulated” environment view.

In following articles I will describe how I feed the git repo with history from clearcase. To start to work it is not strictly necessary to have the history. It is a nice convenience if you would want to access the history from git.

Note:

• It is mentioned on the umview website that the viewfs module is in early development phase, so it might be a bit buggy. If that does not work for you, try umfuse module
• The umview version that comes with Ubuntu Jaunty does not work well on my test machine, so I had to build one from the sources

As summary, the goal of mobifs (everything is filesystem) is to allow transparent (read/write) access to the tree structure of files that have such a tree structure under the form of traditional directory tree structure and to present the leaves in form of text, that can be edited without compromising the format expected by the original tools that handle these files.

The driving motivation behind is also to avoid to learn hundreds of command line parameters of hundreds of tools that access such files and to be able to access the data that hides behind with traditional viewers, editors or other tools.

For example an sqllite database file has such a directory structure. instead of issuing sql statements, one would be able to acces such a file like:

#>vi blogs.sqllite@sqllite/tables/blogs/rows/by/uniqueid/mobifs-eifs-story/content

in this example “blogs” is the table containing the blog entries, “by” means that I want to access data by column name, “mobifs-eifs-story” is the unique id of the blog entry, and “content” is the field containing the content.

if your blog database would be on a mysql database on a remote server, you would do sthg. similar:

#>vi blogs.db.id@mysql/tables/blogs/wors/by/uniqueid/mobifs-eifs-story/content

in this case blogs.db.id would contain necessary info how to access the database (server ip, db name, username, password)