Capi’s Corner

If you are using Git on Windows and follow my advise on how to get past the problem with the “suspicious patch lines”, you might run into problems if you are using Encapsulated PostScript (.eps) files in your repository.

PostScript files are almost plain-text files, and if you set core.autocrlf and core.safecrlf, they might cause problems with the EPS binary encoded parts, as they might be detected as text-files and therefore remove any CRLF and replace it with single LF, which can mess up the whole image.

To force Git to consider a file binary which it would consider as text-file otherwise, the easiest way is to add a .gitattributes file to the directory containing the file or to any parent directory. In my case, I normally add a .gitattributes file in the root of the repository, containing

*.eps -crlf
*.jpg -crlf
*.png -crlf

In the file you set attributes to a path (or a pattern), or unset them (with the minus sign).  The crlf attribute is the attribute which tells if a file is affected by the core.autocrlf options. If you unset it, Git won’t mess with the line endings in the file.

More details can be found on the gitattributes man page.

computer, development development, eps, git, troubleshooting

This is my cheat sheet for the settings I use for my git-repositories (list to be edited continuously):

Global settings:

git config –global user.name Martin Carpella
git config –global user.email xxx@yyy.invalid
git config –global color.ui auto

Per-repository settings:

git config core.autocrlf true
git config core.safecrlf true

Per-repository .gitignore for Visual Studio/C# projects:

bin
obj
*.user
*.suo
Thumbs.db

computer, development development, git

Git’s nice Subversion (SVN) integration is one of the reasons I switched to using it within our company for my own revision control besides our official repository. Unfortunately, upgrading cygwin broke my system once again:

$ git svn dcommit
6 [main] perl 4760 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\lib\perl5\site_perl\5.8\cygwin\auto\SVN\_Core\_ Core.dll to same address as parent(0x260000) != 0x990000 84 [main] perl 3224 fork: child 4760 - died waiting for dll loading, errno 11 panic: MUTEX_LOCK (45) [util.c:2331] at /usr/bin/git-svn line 787. panic: MUTEX_LOCK (45) [op.c:352].

The reason behind this behavior is a huge difference in the way processes and threads and libraries are created/handled on Windows and Linux. git-svn relies on perl within cygwin and several perl libraries that use the same base-address for libraries internally. Of course, no two libraries can be loaded to the same base-address at the same time.

Long explanation, short way to fix the problem:

1. Quit all cygwin processes
2. Start ash (<cygroot>\bin\ash.exe)
3. Execute /usr/bin/rebaseall

Voilla, that’s all. git-svn should work again.

development, software cygwin, git, subversion, troubleshooting

Strings are immutable. If you want to modify a sequence of characters, use StringBuilder. At least, that’s whats officially said. But in the framework there is at least one method that does modify a string:

TextRenderer.MeasureText() with ModifyString and EndEllipses will modify your string to match the ellipsed text if ellipsing happens. You can look at this VB# example on codeproject using TextRenderer.MeasureText() for trimming text on how it is used.

The string seems to be modified directly in native code by DrawTextEx from user32.dll. Additionally to the scary fact that strings are not immutable, the length of the string is not updated, regardless if the resulting string is shorter!

For instance if you have a string “aaaaaaa” which will be truncated to “aa...“, the Length property will still return 7 for the shortened string. The debugger shows that the string will in fact be “aa…\0a” after the operation. So maybe it might be right that the string is still 7 characters long but most outputting functionality like Console.Out.WriteLine() gets confused sometimes and stops any further output to the debugger or console under certain conditions.

A very quick investigation of the System.Drawing assembly using Lutz Roeder’s fabulous .NET Reflector showed that at least there should be no memory corruption in case “WW” would get ellipsed to “W...“, as DrawTextEx takes the length of the buffer and should result only in “W.“.

Summing up, I find the corruption of an immutable string by an official Microsoft API very troubling.

computer, development, security .net, bug, c#, development, security

Krispin made me aware of a very cool new technique for resizing images: content-aware image resizing. Based on an energy-function path of an image are removed when shrinking or are duplicated and interpolated when growing the image in a non-uniform way.

This technique can also be used to remove objects from a given image. There is a nice demo video available on YouTube (it’s the same as in jfo’s coding blog, where Krispin originally found the information):

(via jfo’s coding and slashdot)

computer, development algorithm, development, graphics, image-processing, science, video

What I really love about Git is the fact that it nicely integrates with existing Subversion repositories. At our company, we are using Subversion as our SCM, but I personally like Git more and I want to use it as a side tool for more flexible branching, merging, and for checking in versions I wouldn’t check in the shared repository.

Git is supplied with git-svn, which can import an existing SVN repository and also commit back to it. Under cygwin, you need to perform two additional steps for getting git-svn to work, otherwise it is likely to fail with “failed to include Error.pm”.

• subversion-perl (install via cygwin’s setup.exe)
• Error.pm

You need to download Error.pm from CPAN. You have to save it to <cygwin-dir>\lib\perl5\Error.pm

Voila! git-svn should work now.

development, software git, subversion, troubleshooting, windows

I am currently thinking a lot about the OpenMoko project. Unfortunately OpenMoko at the moment provides hardware which is limited to GPRS, Bluetooth, and/or USB 1.0 for connectivity. In autumn there should be the next generation which should include a WLAN (and maybe even UMTS?) support. It will be called Neo 1973 – GTA02.

Together with Austrian-based one “H.U.I. Starter” rate (250MB @ UMTS, reduction to 56kBit/s above, 10€/month) this would be a nice package. However, if I could have UMTS, well, that would be better. Personally, WLAN is even more important for me, I could use it in the office or in my home, where I have WLAN access available and fall back to GPRS while being “on the road”.

For me this means: standby for autumn, because I can’t afford to invest US-$300 now and another US-$450 in a couple of month. Still, I am really, really interested in OpenMoko (and normally I wouldn’t invest that amount of money into a hobby of mine). Which means, I am standing by and waiting for news from the OpenMoko community…

In the meantime, if you understand German, you could listen to this very interesting Chaosradio Express Podcast.

On YouTube there are some very interesting videos about the Neo 1973.

development, hardware, software hardware, linux, mobile, openmoko, software

If you are using Git under Windows using cygwin, and you got through the initial problems, you will soon realize that Git likes to fail with “You have some suspicious patch lines” when committing.

The cause for this problem is the carriage-return/line-feed problem of Git under Windows/cygwin: The patches contain a trailing line-feed if you edited them with a Windows editor and not strictly inside cygwin. This will trigger the pre-commit hook to fail on patches where the last line of a file has been changed.

To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:

if (/\s$/) {
bad_line("trailing whitespace", $_);
}

Now committing should work.

development, software git, troubleshooting, windows

In a previous article I already mentioned Direct Web Remoting (DWR), the best AJAX-library I encountered up to now. I just had the time to re-discover it, as I sought something to get back to my Java skills. This library really keeps one promise: it really starts making fun to develop web-applications with AJAX. A short summary: DWR provides a very easy means for calling server-side methods which are hosted in a Java Servlet Container like Tomcat or Jetty. It masks the communication effort by providing client-side abstraction to the method calls of exported Java methods, so remote calls look local to the developer.

The new version 2.0 (release-candidate) introduces a new concept, which they call “reverse AJAX“. Reverse AJAX allows the server to asynchronously send data to its clients. It works by either polling, persistent connection or additional information on your next AJAX call. It means, that the server at any time can push data to the client, without the client’s request. In “persistent connection” this works almost “real-time”, while polling takes at least a poll-interval to notice the new information and additionally increases load on the server.

This feature allows highly interactive applications where new information can be published right away, in best case without noticeable delay. Developing a simple chat-application becomes the matter of just a few lines of server-side code.

For an example of what you can easily do now, look at this example (fake) stock ticker, which updates the data on the client without the client being required to poll for changes. Also note the simple, yet cool, inclusion of script.aculo.us effects during the update. (Hint: you need to move the mouse over the table for the application to start.)

The downside is, the feature is still in an early stage of development, it still has some problems. On my Gentoo Linux box, I can reproducibly increase my CPU load to 100% by duplicating a tab with an open persistent connection in Opera. In Firefox, duplicating the tab leads to normal AJAX calls to no longer function with about 50% chance. If Firefox enters this mode, it will queue up XMLHttpRequest causing a “normal” call to be queued behind the persistent call which will be kept open for around 60 seconds if no data is pushed from the server or even longer, if there is data. This of course makes it almost unusable at the moment, unless you can be sure, users won’t hit your site twice within the same session and/or are not using tab-duplication.

I’m really looking forward to this feature becoming stable, this is so cool and you can do so much awesome stuff with it. Thanks to all developers for their great work!

development

In an earlier article I made a mistake. I told that Microsoft Vista x64 will only work with signed drivers and assumed (wrongly) that this means every driver has to go through the WHQL program for getting a signature of Microsoft’s driver quality program, which would be a quite costly process.

I now discovered an older (German) blog-article by Daniel Melanchton, in which he points out that only a digital signature with a certificate from a trusted CA is required. It seems that it is not required to go through the WHQL process, you just need a certificate. The trusted CAs seem to comprise most root authorities also accepted by Internet Explorer by default, so driver developers are not dependent on Microsoft for getting a signature.

While this still might be a problem for some established Open Source drivers, it is still an affordable and in my opinion useful approach, as digital signatures at least in most ways make the originator of a software known. Of course, this does not tell anything about the quality of the software nor if it is benign or malware. Microsoft’s approach seems to be that without force hardly any publisher will sign their drivers. Unfortunately, they might be true…

Update 2007-02-21: It seems that I still missed one point. The “Secure Media Path” depends on a valid Microsoft signature. Without this signature, drivers are supposed to disable the “Secure Media Path”, so that high-quality (e.g. HDTV, Dolby 7.1) multimedia content is rendered to lower quality.

development