Development, Network, Security, Ideas & Opinions
I am currently playing around with using Play Framework on cygwin. I noticed that Typesafe Activator, which has replaced the play command in recent Play versions, ruins the mintty terminal of cygwin: you won’t see any echo of your keystrokes after activator returns.
A simple solution is to blindly type stty sane into the terminal, which will reset it. Another way is, to wrap the activator in a special cygwin-activator bash script:
#!/bin/bash
activator $@
R=$?
stty sane
exit $R
Based on a recent question on stackoverflow I found the power of git aliases and want so share one I invented for answering the question and after that I found very useful in everyday git use:
git config --global alias.add-commit '!git add -A && git commit'
After this, you can simply check in all new, modified, and deleted files with a simple
git add-commit -m 'My commit message'
I have aliased this command also to git ac in order to save further on typing. I never thought that this combination could be that useful, but actually I think it really is. Thanks to the questioner for bringing the idea up.
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 -text -diff
*.jpg -text -diff
*.png -text -diff
In the file you set attributes to a path (or a pattern), or unset them (with the minus sign). The text attribute is the attribute which tells that end-of-line normalization should be applied to a file. If you unset it, Git won’t mess with the line endings in the file and consider it binary.
More details can be found on the gitattributes man page.
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
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:
Voilla, that’s all. git-svn should work again.
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.
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):
[youtube vIFCV2spKtg]
(via jfo’s coding and slashdot)
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”.
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.
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.
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.