This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks

I stumbled over Mercurial in August 2007. Back then I had already
used Git for 6 months, but wanted
to try out different distributed version control systems (DVCS).
I soon began to like Mercurial’s approach because of its simple and
intuitive interface and its clean codebase. While playing around
with Mercurial for a few weeks I was content with its concepts.
There was one feature missing
that I really like in Git: git-like branches.

Unlike in Mercurial or in any other version control system, branches in
Git are simply lightweight markers pointing to a commit. Every ancestor of
the commit is considered part of the branch. Back then, this sounded odd to me. Later I realized it was a really good tool to create small local branches. You can create a small branch
for a feature, merge it into your mainline, and remove the branch
without anyone knowing you ever had a branch called
‘stupid-little-feature‘. To make a long story short: It’s a good
idea to have a similar concept in Mercurial, but none existed back in 2008.

In June 2008 I started developing Mercurial References providing lightweight branches similar to those available in Git. Although the initial work was appreciated by the community, it was rejected
in favor of a concept more natural to Mercurial. Matt Mackall, the author of
Mercurial proposed Mercurial Bookmarks.

Bookmarks

The concept of bookmarks is easy:
You can bookmark a commit with a unique name. So it’s similar to
a tag, with one exception, a bookmark advanced when you commit.
(Like real bookmarks when you go to the next page).

I wrote an initial version of Mercurial Bookmarks in August, that
was finally accepted in October. This improved git like workflows
in Mercurial but still the implementation was far away from what I
wanted. By adding the notion of a so called “current bookmark”, it
got better. Still bookmarks had one major drawback in comparison
to git style branches. They were local only. There was no way to
push or pull bookmarks.

Pushable bookmarks

This was the status for the past two years. I tried to make bookmarks
pushable during this time. A proposal by me how extensions in general
can exchange arbitrary information over the wire was rejected in
early 2009 because it was too unrestrictive for the protocol. A new
concept, so called ‘pushkey concept’ was developed in 2009. This
was discussed and accepted during the Mercurial Sprint in Paris,
January 2010.

Matt Mackall, who now gets sponsored to work on Mercurial,
worked on the initial implementationof pushkey and
pushable bookmarks. And finally after two years of ongoing complains
by people about local-only bookmarks, Mercurial 1.6 will have
pushable bookmarks and introduces a great new concept to exchange
metadata information between repositories.

The next blogpost will show you how to use bookmarks.

To use the php-trunk portsfile. Just extract the tarball into a directory and…

$ tar xzvf php-trunk-port.tar.gz
$ cd php-trunk-port
$ echo "file://`pwd`" > /opt/local/etc/macports/sources.conf
$ echo "file://`pwd`" >> /opt/local/etc/macports/sources.conf
$ port install php-trunk


And the best thing about the port: It compiles PHP with dtrace support :).

Please note the Portfile is very simple and is not tested with the additional modules provided by macports. So use it at your own risk and enhance it.

DOWNLOAD

UPDATE: as philip noted, it should be >> instead of >.

To compile PHP with DTrace, on Solaris or Mac OS do:

  $ svn co http://svn.php.net/repository/php/php-src/trunk php
  $ cd php
  $ ./buildconf --force
  $ ./configure --enable-dtrace
  $ make

To check if your PHP has DTraces probes enabled, you can check the phpinfo() using

 $ php -i | grep DTrace

or use DTrace directly>

 $ sudo dtrace -ln 'php*:::' -c 'php -m'

88836    php4614               php               dtrace_compile_file compile-file-entry
88837    php4614               php               dtrace_compile_file compile-file-return
88838    php4614               php                        zend_error error
88839    php4614               php  ZEND_CATCH_SPEC_CONST_CV_HANDLER exception-caught
88840    php4614               php     zend_throw_exception_internal exception-thrown
88841    php4614               php           dtrace_execute_internal execute-entry
88842    php4614               php                    dtrace_execute execute-entry
88843    php4614               php           dtrace_execute_internal execute-return
88844    php4614               php                    dtrace_execute execute-return
88845    php4614               php                    dtrace_execute function-entry
88846    php4614               php                    dtrace_execute function-return
88847    php4614               php              php_request_shutdown request-shutdown
88848    php4614               php               php_request_startup request-startup

Have fun with DTrace in PHP.

A few examples will follow in the next days.

In the following post I’ll show a brief example on how to create a login page with Compojure 0.3.2 running on Clojure 1.1.0.

What is Clojure?

Clojure is a Lisp dialect. So it’s a programming language based on the principles of Lisp. The interesting part about Clojure is that it runs on the Java Virtual Machine. As a developer you can therefore use the bright variety of Java written libraries in your code without touching one line of Java. Use the power of Java libraries together with the power of Lisp.

What is Compojure?

Compojure is a web framework for Clojure. It handles incoming request, offers an easy way to create servlets and provides basic functionality for HTML templates. The current stable version 0.3.2. Compojure is a young project and things change fast there, so be aware that a 0.3.2 application might not run on 0.4.

What is a session?

Basically it’s a per-user store managed by the server. For example a server backend can store the credentials of a user that it received in a request in this store making it possible to identify the user again when he or she does a second request. Usually this functionality is achieved by a library or by the interpreter itself (for example in PHP) and is implemented by storing the session data either in memory or on disk together with a unique identifier that is then stored in a cookie at the users computer. So when the user comes back, the cookie is read and the identifier is used to find the data for the user.

The application

A basic example

Before we work with a session, let’s create a simple webpage that displays hello world for us.

The example is straight forward. We define a set of routes. In our example the route is “/*”, so it matches everything. The route then takes a function as a second argument. In our case we use the templating mechanism of Compojure and create a simple HTML response with the (html) macro.

We then start the server using the (run-server) macro and binding our routes to a specified mountpoint. I won’t go into details about servlets but usually it is sufficient if you have a servlet running on the mountpoint “/*” and then a set of routes.

To run the server you can use a small script like this one:

#!/bin/sh
CLASSPATH=.:~/dev/clojure/compojure.jar:~/dev/clojure/clojure.jar
java -cp $CLASSPATH clojure.lang.Script net/experimentalworks/clojure/serve.clj


Adding sessions

Before we can start adding sessions we have to be aware that Compojure has a mechanism called decorating. So you can decorate a set or routes with what Compojure calls a middleware. We will think of it as a way to enable advanced mechanism. To add the session mechanism to a set of routes use the (decorate) macro as shown in the following code:

Note the that we define a session decoration. At the moment sessions only support in-memory storage (which by the way should be usually the way you want to manage sessions). The :memory keyword here is to tell Compojure to store it’s sessions in memory. Although you can omit the keyword, I prefer writing it down so people can easily figure out how our session is stored.

Creating a login

Let’s create a login. We will first add a new route called /login/:user. This will tell Compojure that the last part of the query string is a parameter and it should extract it. We can then access the value using (:user params). We use the (session-assoc) function to associate our username with the session-key :loggedin. Here is what the code looks like:

You can then “login” to your site using http://localhost:8080/login/test and you Compojure will recognize you again if you go back to http://localhost:8080/

Logout

To logout, we clear the key itself. Let’s a have a look directly into the code. We use the (session-dissoc) function to drop the key (it seems that clear-session is broken in my Compojure checkout for whatever reasons..need to debug *debug*).

Use http://localhost:8080/logout to get rid of your session.

Conclusion

The basic idea behind Compojure sessions is simple and I hope you were able to grasp the idea a little bit. What can be annoying and what I didn’t show you is that you might run into problems within the actual implementation, although the basic stuff should work fine. Once you figured out the basics you can read and write sessions withing seconds and the code becomes clean and beautiful. Feel free to comment on this article if you like the post, it’s the only measurement for me that I can use to make sure I’m not writing stupid stuff.

• Dutch PHP Conference 2010
• Interntational PHP Conference

The talk will give a very brief overview how Git works, and will then give a more detailed insight in how Git handles commits, files, etc so that people get a very good understanding about the concepts that are needed to fully understand tools like git rebase, git reflog and git svn. The aim is to provide them will all necessary information and a few examples to get lost commits back, rebase their branches and design more complex git workflows in the future without needing to search the web or ask a guru.

A second talk will be more focused on beginners and developers coming from subversion. This talk will be part of a series of talks the german telekom is organizing. I’ll also give an extended version of this as an in-house workshop at a Munich based company.

So for me it seems that after five years, DVCS is mature enough to get into companies and that we can expect a bright variety of companies to adopt new tools and workflows. Let’s see what’s coming…

For sure I still offer Git and Mercurial trainings, so feel free to contact me (dsp ~at~ php ~dot~ net)

probably shameless self promotion

compile it

(set! *compile-path* "build")
(compile 'net.experimentalworks.clojure.outdegree)

Ah yeah and hsv2rgb transformation:

As I wanted to have nice a build system for my PHP subversion checkout, I used this need as a project to start coding Scala. So what do I exactly need? I want to build multiple versions of PHP from the same branch without checking out the code twice. I also want to configure these builds somewhere without always typing in the parameter list or so. For further versions I want to be able to configure these in a file that can easily be distributed to other machines.

I set down and wrote a parser for a configuration file that can configured build targets which is then build by
the program. The configuration file I used is specialized for this purpose, which is why I didn’t used something like ant or so. The result is called bauaffe-3.0.0a1.jar.

I’ll just show a few things done in the project, but mainly focus on what the nice script can do. Further blog posts will be about the actual implementation.

The configuration looks like this

$ cat ~/.buildmaker
begin default configuration
    define source "/Users/dsp/dev/c/php-src"
    define build "/Users/dsp/dev/c/php-src/build"
    define defaults as
        with "iconv=/opt/local"
    build trunk as
        "php60" using defaults
        "php60-debug" using defaults
            enable "debug"
    build branch "PHP_5_3" as
        "php53" using defaults
            environment PHP_AUTOCONF="autoconf213"
        "php53-debug" using defaults
            enable "debug"
            environment PHP_AUTOCONF="autoconf213"

.
Proper indention is not necessary (as e.g in python).

Did I mention that the actual parser is 170 lines of code with usual indention and formatting?

Configuration
The configuration file is searched in ~/.buildmaker, or if ~/.builmaker doesn’t exists, buildmaker.conf in the current directory. How do you configure the tool? First of all you can specify a configuration. It is usually called “default”. It is not yet supported to name it differently, although the parser is able to parse it. In further versions multiple configurations per file are allowed.

Variables
Variables are set using the define syntax. At the moment you can set the build and source variable as well the defaults variable, which is usually a block of statements that can be used in the branch configurations.

Branches
A branch is configured using the build syntax. You first have to specify which branch to build. Every branch can then configured to have build target with a given set of options. Branch options are:

• with string: Builds the target with the given extension
• enable string: Builds the target with the given extension
• environment string=string: Builds the target with environment variable

. You can specify using defaults which will cause the runner to use the options specified in the defaults define.

At the moment the parser will not do a good job in notifying you what you are allowed to do and what not, although pure parse error will be emitted. You can also not set any other variable than the described once.

Building
Calling

$ java -jar bauaffe-3.0.0a1.jar list
TARGET                         LAST BUILD
php60                          None
php60-debug                    None
php53                          Sat Jan 09 16:55:12 CET 2010
php53-debug                    Sat Jan 09 16:59:37 CET 2010

gives you a list of parsed targets and their last build date. You can build a target using

$ java -jar bauaffe-3.0.0a1.jar 

or build all using

$ java -jar bauaffe-3.0.0a1.jar all

Please notice that the current version requires that you now what you are doing. You might miss some error messages or find them not useful. I’ll change this before the first release, if I’ll do a final version of it. I hope you like the little tool.

Download It!

Scala (pronounced /ˈskɑːlə, ˈskeɪlə/) is a multi-paradigm programming language designed to integrate features of object-oriented programming and functional programming.[1] The name Scala stands for “scalable language”, signifying that it is designed to grow with the demands of its users.

The happening will take place at Waldwirtschaft (http://www.waldwirtschaft.de)
beer garden, at any weather. We will meet at 19:00 o’clock – open end.

Catering will be provided and as a special delicacy you may enjoy a suckling pig!…hopefully vegetarian food. If you like to join the event please register at PHPUG-Munich Wiki (http://phpugmunich.org/dokuwiki/php_release_party) and follow it for updates. Alternatively you may register at Facebook
(http://www.facebook.com/event.php?eid=115203467104) as well and follow
this for updates.

For any questions please visit IRC channel: #phprp on irc.uni-erlangen.de.

The PHP 5.3. BBQ release party is sponsored by:
– Microsoft
– Mayflower GmbH
– Swoodoo AG
– Zend Technologies GmbH

Supporters for the PHP 5.3 BBQ release party are:
– Sun Microsystems
- PHPUG.de

result ZEND_ADD_OPCODE()
{
   return add_function(get_op1(), get_op2());
}

Voila, that’s the problem. On SPARC get_op1() is executed before get_op2(), while it’s the other way round on x86. As get_opX() detects if a variable exists, the error messages appear in reversed oder. I did a little bit research (thank you SunCC Team for your answer!) and it turned out, that C99 doesn’t define the way function calls in parameter lists are executed. Therefore, every system and compiler is free to use it’s own ordering mechanism. My current plan: Write a compiler that does this by random(). The fix is trivial:

result ZEND_ADD_OPCODE()
{
  op2 = get_op2();
  return add_function(get_op1(), op2);
}

. It’s a lovely curiosity.