binfalse

One of the people that are working with me on some crazy stuff always forgets to pull the newest revision of the repository before changing the content and so he has very often trouble with different versions when he decides to push his work to the master repository. His actual workaround is to check out the complete repository in a new directory and merge his changes by hand into this revision… Here is a little instruction to maximize his productivity and minimize the network traffic.

Lets assume we have a repository, created like this:

/tmp % git init --bare root

And we have one user, that clones this new repository and inits:

/tmp % git clone root slave1
/tmp % cd slave1
/tmp/slave1 (git)-[master] % echo "line1\\nline2" >> testfile
/tmp/slave1 (git)-[master] % cat testfile
line1
line2
/tmp/slave1 (git)-[master] % git add .
/tmp/slave1 (git)-[master] % git commit -m "init"
[master (root-commit) bc7e4da] init
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 testfile
/tmp/slave1 (git)-[master] % git push ../root master

So we have some content in our root repo. Another user (our bad guy) clones that repository too:

/tmp % git clone root slave2

So let a bit of time elapse, while user one is changing the root repository so that the testfile may look like this:

/tmp/slave1 (git)-[master] % cat testfile | sed 's/line1/&\\nline1a/' > testfile.tmp && mv testfile.tmp testfile
/tmp/slave1 (git)-[master] % cat testfile
line1
line1a
line2

And of course, the changer commits his changes:

/tmp/slave1 (git)-[master] % git commit -a -m "haha, root has changed..."
[master e18f637] haha, root has changed...
 1 files changed, 1 insertions(+), 0 deletions(-)
/tmp/slave1 (git)-[master] % git push ../root master
Counting objects: 5, done.
Writing objects: 100% (3/3), 265 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To ../root
   bc7e4da..a04d363  master -> master

Ok, nothing bad happened, but now our special friend decides to work:

/tmp/slave2 (git)-[master] % cat testfile | sed 's/line1/&\\nline1b/' > testfile.tmp && mv testfile.tmp testfile
/tmp/slave2 (git)-[master] % cat testfile
line1
line1b
line2
/tmp/slave2 (git)-[master] % git commit -a -m "oops, i am very stupid..."
[master d691ada] oops, i am very stupid...
 1 files changed, 1 insertions(+), 0 deletions(-)

What do you think will happen if he tries to push his changes to the master repo? Your right, nothing but a error:

/tmp/slave2 (git)-[master] % git push ../root master
To ../root
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '../root'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

Mmmh, so lets try to pull the root repo:

/tmp/slave2 (git)-[master] % git pull ../root master
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../root
 * branch            master     -> FETCH_HEAD
Auto-merging testfile
CONFLICT (content): Merge conflict in testfile
Automatic merge failed; fix conflicts and then commit the result.

Our friend would now check out the whole repository and insert his changes by hand, but whats the better solution? Merging the file! Git has a function called mergetool , you can merge the conflicts with a program of your choice. Some examples are vimdiff , xxdiff , emerge or also for GUI lovers kdiff3 . In this post I’ll use vimdiff :

/tmp/slave2 (git)-[master|merge] % git mergetool --tool=vimdiff testfile

Normal merge conflict for 'testfile':
  {local}: modified
  {remote}: modified
Hit return to start merge resolution tool (vimdiff): 
3 files to edit

So change the conflicting file(s), you will also see the changes made in root’s and in your local revision. If you’re done just save it and commit your merge:

/tmp/slave2 (git)-[master|merge] % git commit -m "merged"
[master 6be1482] merged

Great, now there is nothing that prevents you from pushing your changes to the root repository:

/tmp/slave2 (git)-[master] % git push ../root master
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 555 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
To ../root
   a04d363..6be1482  master -> master

I think this way of solving such conflicts maybe much more efficient than cloning the whole repository again and again and again ;)

One week passed since I got a package of Spots, this weekend I found some time to hack a little bit with this funny components.

First of all I programmed a tool that visualizes the Spots movement in an OpenGL frame that draws a virtual Spot. Nice for demonstrations, but nothing spectacular.

After that I developed a little mouse emulator, that translates Spot movement to mouse motions on the screen. Here the Spot isn’t doing anything intelligent, it only sends its tilt status every 25 ms as well as switch events to broadcast. Another Spot, working as basestation connected to my machine, is listening to this talking Spot and my host analyzes the received values. To move the mouse on the screen or to generate a click I use the Robot class of the Java AWT package. Long story short, a video may explain it more understandable (via YouTube):

I will continue with working on these libraries before I publish them in another post. So look forward to the release ;-)

The unstable release of Debian is of course tricky in a lot of cases, so there is also a little stumbling stone on your path of Java network programming. On every new system it annoys me.

Before I wrongful blame my preferred Debian release called Sid I have to acknowledge I don’t know whether this feature is also available in other releases… Here is a small program to test/reproduce:

import java.net.URL;
import java.io.BufferedReader;
import java.io.InputStreamReader;

public class WebReader
{
	public static void main (String[] args)
	throws Exception
	{
		BufferedReader reader = new BufferedReader(
			new InputStreamReader (new URL (args[0]).openStream ()));
		String line = reader.readLine ();
		
		while ((line = reader.readLine ()) != null)
			System.out.println (line);
	}
}

Compilation shouldn’t fail, but if you try to launch it you’ll get an exception like that:

Exception in thread "main" java.net.SocketException: Network is unreachable
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
        at java.net.Socket.connect(Socket.java:525)
        at java.net.Socket.connect(Socket.java:475)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
        at sun.net.www.http.HttpClient.New(HttpClient.java:306)
        at sun.net.www.http.HttpClient.New(HttpClient.java:323)
        at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860)
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801)
        at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1049)
        at java.net.URL.openStream(URL.java:1010)
        at WebReader.main(WebReader.java:10)

This is caused by one little line in /etc/sysctl.d/bindv6only.conf saying you want to explicitly bind via IPv6. But my connection (maybe yours too) communicates still over IPv4, so this method of networking of course fails. To change this behavior you have to choose between two solutions.

Solution 1: Permanent modification (needs to be root)

You can change this behavior for the whole system by editing the file /etc/sysctl.d/bindv6only.conf :

# original only IPv6
# net.ipv6.bindv6only = 1
net.ipv6.bindv6only = 0

After that just type invoke-rc.d procps restart in your terminal to let your changes take effect. Your next run should work fine.

Solution 2: Change it for this single example

If your are not allowed to change system settings, you can add -Djava.net.preferIPv4Stack=true to your execution command:

java -Djava.net.preferIPv4Stack=true  WebReader http://localhost
# instead of `java WebReader http://localhost`

This causes your actual runtime to connect the network via IPv4, no matter to system preferences. I hope this could save some time of developers like me ;-)

Just sitting around with Micha on a SunRay (maybe meanwhile OracleRay?). He is surfing through the web until his session seems to hang and he said:

Fuck FLASH!! Need the flash-trick...

I didn’t heard about that trick before, but now he told me that feature.

If Flash kills your SunRay session you have to type Ctrl+Alt+Moon , relogin and your session will revive. With running Flash!

As far as I know this happens very often when he is using his browser because unfortunately the whole web is contaminated with this fucking Flash… The Flash-Trick is very nice, but a flashblock plugin would be more user friendly!?

My boss wants to present some cool things in a lecture that can be done with SUN Spots. I'm selected to program these things and now I have three of them to play a little bit.

The installation was basically very easy, all you should know is that there is no chance for 64bit hosts and also Virtual Box guests don't work as expected, virtual machines lose the connection to the Spot very often... So I had to install a 32bit architecture on my host machine (btw. my decision was a Sidux Μόρος).

If a valid system is found, the rest is simple. Just download the SPOTManager from sunspotworld.com, that helps you installing the Sun SPOT Software Development Kit (SDK). If it is done connect a Sport via USB, open the SPOTManager and upgrade the Spot's software (it has to be the same version as installed on your host). All important management tasks can be done with this tool and it is possible to create virtual Spots.

Additionally to the SDK you'll get some demos installed, interesting and helpful to see how things work. In these directories ant is configured to do that crazy things that can be done with the managing tool. Here are some key targets:

ant info		# get some info about the spot (version, installed application and so on)
ant deploy		# build and install to spot
ant host-run	# build a host application and launch it
ant help		# show info about existing targets
# to configure a spot to run as base station OTA has to be disabled and basestation must be started
ant disableota startbasestation

A basestation is able to administrate other Spots, so you don't have to connect each to your machine.

Ok, how to do own stuff?
There are some Netbeans plugins that makes live easier, but I don't like that big IDE's that are very slow and bring a lot of overhead to your system. To create an IDE independent project that should run on a Spot you need an environment containing:

• File: ./resources/META-INF/MANIFEST.MF

  MIDlet-Name: NAME
  MIDlet-Version: 1.0.0
  MIDlet-Vendor: Sun Microsystems Inc
  MIDlet-1: App Description, ,your.package.MainClassName
  MicroEdition-Profile: IMP-1.0
  MicroEdition-Configuration: CLDC-1.1

• File: ./build.xml

  < ?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <project basedir="." default="deploy">
  <property file="${user.home}/.sunspot.properties"/>
      <import file="${sunspot.home}/build.xml"/>
  </project>

• Directory: ./src
  Here you can place your source files

And now you can just type `ant` and the project will be deployed to the Spot.
A project that should run on your host communicating with other spots through the basestation needs a different environment:

• File: ./build.xml

  < ?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <project basedir="." default="host-run">
  <property name="main.class" value="your.package.MainClassName"/>
  <property file="${user.home}/.sunspot.properties"/>
      <import file="${sunspot.home}/build.xml"/>
  </project>

• Directory: ./src
  Here you can place your source files

Ok, that's it for the moment. I'll report results.