Wednesday, December 24, 2014

Swift ... not yet

The programming language Swift -- announced at WWDC 2014 by Apple -- looks fine at first sight.

BUT: The standard library is very sparse. The reference documentation of the swift standard library is only about 50 pages, most things are missing.

So you have to fall back to the the Objective C runtime, in order to get something done. The automatic binding is fine, but there is so much friction between the layers, that all the fine parts of swift -- safety, expressiveness, automatic memory handling -- are covered in the end.

Apple has still a long way to go in order to implement a standard environment, which is safe and fun to use.

For instance
My personal verdict: If you are not an expert in the peculiarities of Apple Objective C Runtime you have no chance to use swift productively right now. So there is no point in using it.

Thursday, July 10, 2014

Maven/Ivy considered harmful (1)

Consider the repositories http://central.maven.org/maven2/org/mortbay/jetty/jetty/6.1.26/ and http://repository.jboss.org/nexus/content/groups/public/org/mortbay/jetty/jetty/6.1.26/
Both do contain a jetty-6.1.26.pom with very different contents.
Somehow the pig compile job can pick up the pom from jboss repository and using it on maven central, yielding to this weird message when compiling bigtop:

[ivy:resolve] 
[ivy:resolve] :: problems summary ::
[ivy:resolve] :::: WARNINGS
[ivy:resolve]   [FAILED     ] org.mortbay.jetty#jetty;6.1.26!jetty.zip:  (0ms)
[ivy:resolve]  ==== fs: tried
[ivy:resolve]    XXXXXXXXX/.m2/repository/org/mortbay/jetty/jetty/6.1.26/jetty-6.1.26.zip
[ivy:resolve]  ==== maven2: tried
[ivy:resolve]    http://repo2.maven.org/maven2/org/mortbay/jetty/jetty/6.1.26/jetty-6.1.26.zip
[ivy:resolve]  ==== jboss-maven2: tried
[ivy:resolve]    http://repository.jboss.com/nexus/content/groups/public/org/mortbay/jetty/jetty/6.1.26/jetty-6.1.26.zip
[ivy:resolve]  ==== apache-snapshots: tried
[ivy:resolve]    http://repository.apache.org/content/groups/snapshots-group/org/mortbay/jetty/jetty/6.1.26/jetty-6.1.26.zip
[ivy:resolve]   ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:resolve]   ::              FAILED DOWNLOADS            ::
[ivy:resolve]   :: ^ see resolution messages for details  ^ ::
[ivy:resolve]   ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:resolve]   :: org.mortbay.jetty#jetty;6.1.26!jetty.zip
[ivy:resolve]   ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:resolve] 
I am not the only one see here for instance: Pig posting Have to look into it why http://repository.jboss.org/nexus/content/groups/public/ is used at all for resolving dependencies.

Saturday, May 31, 2014

Recompile a debian package (valgrind) from testing to stable (wheezy)

Valgrind 3.7 as supplied Debian does not support the avx2 instructions the gcc 4.7 from debian supports if one uses gcc -march=native -mtune=native on a more-or-less recent processor.
01af@debian:~/bench1$ valgrind ./bench1
==26780== Memcheck, a memory error detector
==26780== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==26780== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26780== Command: ./bench1
==26780== 
vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0xEF 0xC0 0x66 0xF 0x1F 0x44
==26780== valgrind: Unrecognised instruction at address 0x40156e.
==26780==    at 0x40156E: main (memblock.cc:120)
==26780== Your program just tried to execute an instruction that Valgrind
==26780== did not recognise.  There are two possible reasons for this.
==26780== 1. Your program has a bug and erroneously jumped to a non-code
==26780==    location.  If you are running Memcheck and you just saw a
==26780==    warning about a bad jump, it's probably your program's fault.
==26780== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26780==    i.e. it's Valgrind's fault.  If you think this is the case or
==26780==    you are not sure, please let us know and we'll try to fix it.
==26780== Either way, Valgrind will now raise a SIGILL signal which will
==26780== probably kill your program.
==26780== 
==26780== Process terminating with default action of signal 4 (SIGILL)
==26780==  Illegal opcode at address 0x40156E
==26780==    at 0x40156E: main (memblock.cc:120)
Since current valgrind 4.9 does support these instructions, I asked myself how to I upgrade this peculiar package.
Using an instructions how to rebuild a debian package, one needs to install the build tools
apt-get install build-essential fakeroot dpkg-dev
Since valgrind is supported by debian testing one can get source from https://packages.debian.org/source/jessie/valgrind. i.e.
git clone git://anonscm.debian.org/collab-maint/valgrind.git
Start build dpkg-buildpackage -rfakeroot -b. And add the missing dependencies to the systems. Start again until all dependencies are fulfilled
Afterwards the freshly packages are in ... Use
dpkg -i valgrind_3.9.0-5_amd64.deb valgrind-dbg_3.9.0-5_amd64.deb
to upgrade the package. And it works now as expected.



Friday, May 30, 2014

How to use perf in vmware

The amazing Linux perf performance tool does not work as expected in a vmware guest:

A simple perf record command shows no output when displayed with perf report.

A workaround would be to use a non-hardware related event type for sampling with the command line switch -e.

But there is a much better solution (at least in vmware fusion 6): Enable virtualisation of performance counters:

The switch is the one with "Anwendungen mit Code-Profil".

Gnome 3 fallback mode

Was wondering why the gnome shell in Debian 7 seems to be always in fallback mode when started in a vmware guest. The ~/.xsession-errors file states
gnome-session-is-accelerated: No hardware 3D support.
But that is not strictly true, since 3D Acceleration is enabled in vmware, and Debian has a Linux 3.2 kernel and Mesa 8.0 Support. Output from glxinfo:
...
direct rendering: Yes
...
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x209)
OpenGL version string: 2.1 Mesa 8.0.5
The command /usr/lib/gnome-session/gnome-session-check-accelerated-helper is the one displaying the message in the .xession-errors file. Using strace reveals the file /usr/share/gnome-session/hardware-compatibility:
##
## This file contains a list of blacklist/whitelist regular expressions for
## renderer strings.
##
## The regular expressions are case-insensitive POSIX Extended Regular
## Expressions. See regex(7) for details.
##
## Syntax:
##  - Comment lines start with '#'
##  - Lines starting with '+' are whitelisting.
##  - Lines starting with '-' are blacklisting.
##  - Lines not starting with '#', '+', '-' are ignored.
##

# Intel 830-865
-Intel\(R\) 8[[:digit:]]{2,2}[^[:digit:]]

# Pre-R300 radeon
-Mesa DRI R[12]00[^[:digit:]]
-Mesa DRI R[12]00$

# Old Mesa software GL renderer
-software rasterizer

# Gallium has softpipe and llvmpipe
-softpipe
-llvmpipe
Commenting out these last two lines enables the "normal" gnome shell. After enabling the non-fallback mode I enabled fallback mode again quickly: It is unusable since the screen shows flickering and artifacts. Another useless information generated...