PHP introduced DTrace support with PHP 5.3, enabling probing points in the PHP executable that can be used to simplify probing of PHP applications without having to the PHP implementation details. We enabled probes on function calls, file compilation, exceptions and errors. But this has always been limited to the operating systems that support DTrace. With the popularity of DTrace, Systemap programmers decided to add a DTrace compatibility layer that allows to use DTrace probes as Systemtap probing points as well.

With my recent commit to the PHP 5.5 branch, we allow DTrace probes to be build on Linux, so people can use Systemtap to probe those userland probes.

$ git clone git://github.com/php/php-src php-src
$ cd php-src
$ git checkout PHP-5.5

$ ./buildconf --force
$ ./configure --disable-all --enable-dtrace
$ make

$ stap -l 'process.provider("php").mark("*")' -c 'sapi/cli/php -i'
process("sapi/cli/php").provider("php").mark("compile__file__entry")
process("sapi/cli/php").provider("php").mark("compile__file__return")
process("sapi/cli/php").provider("php").mark("error")
process("sapi/cli/php").provider("php").mark("exception__caught")
process("sapi/cli/php").provider("php").mark("exception__thrown")
process("sapi/cli/php").provider("php").mark("execute__entry")
process("sapi/cli/php").provider("php").mark("execute__return")
process("sapi/cli/php").provider("php").mark("function__entry")
process("sapi/cli/php").provider("php").mark("function__return")
process("sapi/cli/php").provider("php").mark("request__shutdown")
process("sapi/cli/php").provider("php").mark("request__startup")

$ cat request.stp
global callcount;
probe process.provider("php").mark("function-entry") {
    callcount[user_string($arg1)] += 1;
}
probe end {
    printf("count : function\n");
    foreach (name in callcount) {
        printf("%5d : %s\n", callcount[name], name);
    }
}

$ sudo stap -c 'sapi/cli/php test.php' request.stp
count : function
  100 : foo
  101 : bar

So that’s all. You can use systemtap now to probe your PHP. Hope you come up with some useful scripts. Share them!

The current state of bookmarks

Bookmark semantics

A start

$ hg clone http://selenic.com/hg hg
destination directory: hg
requesting all changes
adding changesets
adding manifests
adding file changes
added 17684 changesets with 34643 changes to 2168 files
updating to branch default
996 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg bookmark upstream
$ hg bookmark
 * upstream                  17683:6d7db5794e8c

$ hg bookmark topic/bm-warn-ambiguous
$ hg bookmark
 * topic/bm-warn-ambiguous   17683:6d7db5794e8c
   upstream                  17683:6d7db5794e8c

$ vim mercurial/bookmarks.py
$ hg commit -m'bookmarks: warn if bookmark name is ambiguous'
$ hg bookmark
 * topic/bm-warn-ambiguous   17684:d018b3fda542
   upstream                  17683:6d7db5794e8c

Using existing bookmarks

$ hg update upstream
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg bookmark
   topic/bm-warn-ambiguous   17684:d018b3fda542
 * upstream                  17683:6d7db5794e8c
$ hg log -r upstream
changeset:   17683:6d7db5794e8c
bookmark:    upstream
parent:      17681:a41fd730f230
parent:      17682:829919ef894a
user:        Matt Mackall 
date:        Sat Sep 29 12:28:52 2012 -0500
summary:     merge with stable

$ hg bookmark -m  topic/bm-warn-ambiguous t/warn-ambiguous
$ hg bookmark
   t/warn-ambiguous          17684:d018b3fda542
 * upstream                  17683:6d7db5794e8c

$ hg bookmark -d t/warn-ambiguous
$ hg bookmark
 * upstream                  17683:6d7db5794e8c
$ hg bookmark -r 17684 t/warn-ambiguous
$ hg bookmark
   t/warn-ambiguous          17684:d018b3fda542
 * upstream                  17683:6d7db5794e8c

Merging

$ hg bookmark
  t/warn-ambiguous          17684:d018b3fda542
* upstream                  17685:861d6aeee6aa
$ hg merge t/warn-ambiguous
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m'Merge'
$ hg bookmark
   t/warn-ambiguous          17684:d018b3fda542
 * upstream                  17686:c6b62c2e15fc

Bookmarks and revsets

$ hg log -r 'bookmark()'
changeset:   17683:6d7db5794e8c
bookmark:    upstream
parent:      17681:a41fd730f230
parent:      17682:829919ef894a
user:        Matt Mackall 
date:        Sat Sep 29 12:28:52 2012 -0500
summary:     merge with stable

changeset:   17684:d018b3fda542
bookmark:    t/warn-ambiguous
tag:         tip
user:        David Soria Parra 
date:        Tue Oct 02 03:07:05 2012 +0200
summary:     bookmarks: warn if bookmake name is ambiguous

MQ and bookmarks

$ hg update t/warn-ambiguous
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qimport -r tip
$ hg bookmark
 * t/warn-ambiguous          17684:d018b3fda542
   upstream                  17683:6d7db5794e8c
$ vim mercurial/bookmarks
$ hg qrefresh
$ hg bookmark
 * t/warn-ambiguous          17684:a5bbed225a3f
   upstream                  17683:6d7db5794e8c

$ hg qnew tests
$ vim tests/test-bookmarks.t
$ hg qrefresh

Naming conventions and alias

[alias]
bm = bookmark

Conclusion

Bookmarks changed a lot of the last years and most of Mercurials code base is bookmark aware. With the change to qrefresh, it’s going to be good enough for my workflows. Whats your bookmark story? Also Steve Losh wrote an excellent article about the different ways of branching in Mercurial (it has pictures, wwoooo). He also wrote an excellent article about MQ. He wrote a lot of interesting stuff at all, visit his page.

ps: without flattrs, comments or anything like that, there is probably not going to be a part III

The Mercurial project aims to support Python 2.4 to Python 2.7. It does not support Python 3. Why? Python 3 is a drastic change. Unicode is the default string type, classes removed, etc. The impact of the changes are similar to the change from PHP 4 to PHP 5. Most software projects have adopted these language changes, but for projects that need to support LTS operating systems like RHEL or Solaris 9/10, it can be become an issue. You could drop Python 2.X support and tell existing users of your software to look for something else – a no-go for a version control system. You could simply not support Python 3 at someday, but Python 2.7 already reached it’s EOL. It’s just a matter time until distribution stop shipping Python 2.X. LTS operating systems might still not have Python 3 and rely on Python 2. Writing software that needs to be backwards-compatbile for 8 years can be a problem.

The source of the problem

Why is this a not an issue for Java or C, but for Python, PHP and Ruby? Java and C compile to bytecode that is guaranteed to be stable. C compiles to machinecode. A processor architecture won’t change anymore. If it’s a x86 processor, it will support x86 machinecode. It won’t change with the next software update. If your code needs to support old C code that modern compilers don’t understand anymore, use an old one. Java is similar in that regard. The JVM runtime has a defined set of instructions, which won’t be changed anymore. It doesnt matter which Java compiler you use, in the end it will produce bytecode that will run on any JVM. Sure you still might have problems supporting multiple versions of a library, but at least the JVM will always run your compiled code.

Python and PHP compile to bytecode as well, similar Java. There is, however, one exception: They do it in memory and the VM to interprete the bytecode is bundled with the compiler. This is were the backwards compatibility problem comes in play. You cannot run Python bytecode compiled on Python 3 with a Python 2 interpreter. You cannot compile with PHP 5 and run it on PHP 4. Either the interpreter simply fails to your old code, or your VM implementation is not guaranteed to be stable. That means in Python and PHP the underlying machine that you compile might change with the next update. Let’s compare this to the x86 world. Your next software update might change the x86 instruction set? You would have to recompile all your C code and maybe some of the old C code cannot be compiled with modern C compilers and old C compilers might not be able to get compiled on the new instruction set. Sounds painful, particularly if you really care about backwards-compatibility.

Sidenote

I think that Python, PHP and others did an architectual mistake. They bundled the VM and runtime with the compiler. Thus your language version defines your runtime and the underlying machinecode. If you write a new language, write down a minimum instruction set that you will always support and separate your VM from your compiler. Always support that instruction set. This can lead to interesting problems. The implementation of Java Generics is a good example. Nobody thought about generics when defining the insturctions set. Therefore the bytecode was not designed to retain information about the generic type. Thats why the Java compiler needs to check the generic type information and than transform it, so that the resulting bytecode is compatible with old JVM versions. This is known as type erasure. Python and PHP developer would probably just introduce new bytecodes, not caring about BC. (Well PHP devs would just pretend that PHP is a web language and web projects shouldn’t care about BC at all ;)).

Conclusion
If you seriously care about backward-compatibility for LTS systems that are 8 years old, choose a language which separates the VM from the compiler. Languages like Java (probably C#) do this. Java developer won’t define behavior that requires a new opcode. PHP and Python are wonderful programming languages, but personally I am not sure if it is wise to write something like a VCS in such a language.

Long story short: Language choice matters for BC. If you write your own language, please separate your VM from your compiler. Better (as johannes pointed out) compile to an existing VM like JVM, CLR or LLVM

The problem: If I plug in my Realforce, I want to have the CAPS remapped to CTRL. If I plug in my Happy Hacking, it should stay the way it is!
Solution: Xorg Udev Matching

So in recent Xorg versions you can use udev matchings to select the options for a particular keyboard. On my Fedora 16, I added the following file:

$ vim /etc/xorg.conf.d/01-realforce.conf
Section "InputClass"                                                                                             
  Identifier	"Realforce"                                          
  MatchProduct 	"Realforce 103U"
  Option	"XkbLayout"	"us,de"                                              
  Option	"XkbOptions"	"grp:menu_toggle,ctrl:swapcaps"
EndSection

Done. If I plug in my Realforce I have the ctrl and caps key swapped!

Bonus: As the win key on my HHK is right of the alt key I better switch ALT and WIN on my Realforce, too:

Option "XkbOptions" "grp:menu_toggle,ctrl:swapcaps,altwin:swap_lalt_lwin"

Which is just fine for smaller repositories but can take a long time on large repositories with a lot of large files in that directory.
The faster way is to manipulate only the index:

git filter-branch --index-filter 'git ls-files -- DIRECTORY | xargs git update-index --remove' --tag-name-filter cat --prune-empty -f -- --all;


• git ls-files will give you a list of files in the DIRECTORY
• git update-index will remove those files from the index
• And the tag filter is there to include tags
• –prune-empty tells filter-branch to ignore empty commits.

Done.

So my 2 cents:

What really makes people contribute:

1. A nice and encouraging community
2. Respect the work of others
3. Don’t take everything for granted

What doesn’t encourage people:

1. Continous rants about how to do things or not
2. Telling people what they do is totally wrong
3. Not contribute yourself

Open Source Projects are community driven. There is a place for discussion, but note that Open Source Communities are open, so people will come in and start ranting about things. If you are serious about a certain problem and want to solve it, contribute! If you want things to change, contribute! If you want to have your opinion heard, contribute! But do not try to squeeze argumentations in 140 characters and think everyone will follow you, just because it’s you.

Personally I’m getting tired of this, making me either not to contribute anymore (and you guys are stuck with SVN :)) or just ignore people.

In emacs use M-x slime-connect to connect to swank.

user> (use 'clojure.test)
nil
user> (use :reload 'geocommit.test.services) (run-test 'geocommit.test.services)
{:type :summary, :test 3, :pass 9, :fail 0, :error 0}

This blogpost gives you an example how to use geocommit and the geocommit.com services. I’ll show how to use geocommits in your Git or mercurial project. How to make github and bitbucket more beautiful with our Chrome and Firefox extensions and how to get a fancy map of your geocommits.

What is geocommit

First of all, geocommit is a text format to attach geolocation data to version control system commits. The geocommit website has detailed information about the geocommit format.
Second, geocommit is a service to store and analyse your geocommit data. We offer a set of tools and a webservice to make geocommit cool. The Git implementation git geo runs on Mac OS X and Linux. The Mercurial implementation hg-geo runs only under Linux. Mac OS support is under way.

Git & Geocommit

To start with geocommit, install git geo:

$ pip install geocommit

Go to a project directory and enable geocommit support:

$ cd myproject.git
$ git geo setup
geocommit setup
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-rewrite
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-merge
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-commit

This will enable geocommit support in your project. If you commit something with git commit, git geo will try to get your current location and add a geocommit. If no WiFi connection is enabled, no geocommit will be created.

Check your geocommits:

$ git log --show-notes='geocommit'
commit 5a34e6ebc8cb5c2a394ca26505c1d375095161c4
Merge: 25cf72d 828af6e
Author: David Soria Parra 
Date:   Tue Jan 4 14:00:55 2011 +0100

    Merge branch 'master' of https://github.com/jezdez/geocommit

Notes (geocommit):
    geocommit (1.0)
    lat: 48.1211828
    long: 11.4853565
    hacc: 39.0
    src: nmg

Let’s push our geocommits to github:

$ git geo push

git geo push accepts the same options as git push. It pulls geocommits first, merges them and then pushes geocommits and the given branch to the remote repository.
That’s everything you need. Easy, isn’t it? So let’s see how to enable geocommits on Mercurial and then talk about the Chrome and Firefox extensions.

Mercurial & geocommit

You can add support for geocommits to Mercurial by installing the hg-geo extension. Clone the extension and enable it in your hgrc:

$ hg clone http://bitbucket.org/segv/hg-geo
$ echo "[extensions]\ngeo=/path/to/hg-geo/geo.py"
$ hg help geo

The extension will add an additional line to every commit that you do.

$ hg commit
$ hg log -v
changeset:   9:236a0f4c3d2e
tag:         tip
user:        David Soria Parra 
date:        Sun Jan 02 03:01:04 2011 +0100
files:       .hgtags
description:
Added tag v1.0.0 for changeset 3079e3ff3083

geocommit(1.0): lat 48.1211306, long 11.4853251, hacc 30.0, src nmg;

Now push your geocommits to bitbucket.

$ hg push

bitbucket.org and github.com

We can push geocommits easily now. But how to use them? We can install the Firefox or Chrome extension. This will display a map next to your commit!

Firefox
To install the geocommit extension for Firefox you need Greasemonkey. Greasemonkey is a well know and supported extension that enables user scripts to safely modify the displayed website.

Install Greasemonkey from userscripts.org. You can then browse bitbucket.org or github.com and see a map of your geocommit:

Chrome
On Chrome install the plugin from
chrome.google.com

Post Hook

We offer a post hook that you can use with github.com and bitbucket.org. Your commits will be tracked by gecommit.com and we will create a global and a project specific map as well as provide further analytics as soon as possible.

github.com
To install the hook go to th eadmin section of your repository and select Service Hooks.

Add http://hook.geocommit.com/api/github as a POST service hook.

on bitbucket.org
Go to the admin seciton of your repository and select Services

Add http://hook.geocommit.com/api/bitbucket as a POST service hook

Thats about it. Browse www.geocommit.com/full.html to checkout your commits on our map.

Questions?!
Enjoy!