mein iPhone führt nun Anwendungen im Hintergrund aus. Danke #iPhoneBackgrounder http://bit.ly/nmNM und #jailbreak
Author: Philipp
just rendered a movie with #gource (http://code.google.com/p/gource) about the svn history of a long time project :-)
just rendered a movie with #gource (http://code.google.com/p/gource) about the svn history of a long time project 🙂
tvnoir.de: Eva Briegel – Crazy: http://blip.fm/~r66qp via @addthis
tvnoir.de: Eva Briegel – Crazy: http://blip.fm/~r66qp via @addthis
merke: netcat heißt bei macport nc #goodtoknow
merke: netcat heißt bei macport nc #goodtoknow
ein Bekannter verkauft seinen alten WV Passat BJ 91. http://bit.ly/9Niwlr
ein Bekannter verkauft seinen alten WV Passat BJ 91. http://bit.ly/9Niwlr
creating JNI with Swig
I am currently playing around with JNI and Java due the colleagues question to make the connect features of jack-audio (http://jackaudio.org) accessible to java.
There is already a javalib (http://jjack.berlios.de) with some features, there seems still some needes ones missing.
So i started today to have a look into SWIG (http://swig.org).
“SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.”
After some hours of research i ended up with some facts:
To created yourself a Java binding to a given c/c++ Program or Library you need one or more Interface files (*.I) and swig file with all the necessary swig module descriptions.
There is an example on the swig homepage ( http://www.swig.org/Doc1.3/SWIGDocumentation.html#Introduction) to explain the workflow of SWIG.
There is a c file exmple.c:
/* File : example.c */ double My_variable = 3.0; /* Compute factorial of n */ int fact(int n) { if (n <= 1) return 1; else return n*fact(n-1); } /* Compute n mod m */ int my_mod(int n, int m) { return(n % m); }
The mapping example.i files looks as the following:
/* File : example.i */ %module example %{ /* Put headers and other declarations here */ extern double My_variable; extern int fact(int); extern int my_mod(int n, int m); %} extern double My_variable; extern int fact(int); extern int my_mod(int n, int m);
As you can see, the Interface file has a similar syntax with some additional meta information.
You can now create your JNI bindings:
swig -java example.i There are also flags for different other languages: -allegrocl - Generate ALLEGROCL wrappers -chicken - Generate CHICKEN wrappers -clisp - Generate CLISP wrappers -cffi - Generate CFFI wrappers -csharp - Generate C# wrappers -guile - Generate Guile wrappers -java - Generate Java wrappers -lua - Generate Lua wrappers -modula3 - Generate Modula 3 wrappers -mzscheme - Generate Mzscheme wrappers -ocaml - Generate Ocaml wrappers -octave - Generate Octave wrappers -perl - Generate Perl wrappers -php - Generate PHP wrappers -pike - Generate Pike wrappers -python - Generate Python wrappers -r - Generate R (aka GNU S) wrappers -ruby - Generate Ruby wrappers -sexp - Generate Lisp S-Expressions wrappers -tcl - Generate Tcl wrappers -uffi - Generate Common Lisp / UFFI wrappers -xml - Generate XML wrappers
As a result you get three new files:
- example.java
- exampleJNI.java
- example_wrap.c
The example_wrap.c can be used to compile the needed library file for your JNI access.
The two java Files are the basic JNI implementation:
class exampleJNI { public final static native void My_variable_set(double jarg1); public final static native double My_variable_get(); public final static native int fact(int jarg1); public final static native int my_mod(int jarg1, int jarg2); }
And a basic java example how to access these functions:
public class example { public static void setMy_variable(double value) { exampleJNI.My_variable_set(value); } public static double getMy_variable() { return exampleJNI.My_variable_get(); } public static int fact(int arg0) { return exampleJNI.fact(arg0); } public static int my_mod(int n, int m) { return exampleJNI.my_mod(n, m); } }
To get into working with SWIG i can advise the sources of the G4Java Project.
There is also a maven plugin to use SWIG from within your maven build: http://java.freehep.org/freehep-swig-plugin.
I am currently trying to create the necessary Interface files from the jack-audio sources to use them for a first run of SWIG. For python and tck you can use cmake to create these files.
Wiederherstellen eines MacOS Festplatten-Backups mit Hilfe von DD
Das Festplattendienstprogramm von MacOS bietet unter einer übersichtlichen Oberfläche ein umfangreiches Tool um mit Festplatten zu arbeiten.
Allerdings gibt es hier einige Probleme, welche oftmals einen Umweg über das Terminal benötigen.
Ich habe das Tool dazu benutzt um eine Festplatte aus einem neu erworbenen Netbook zu sichern, bevor ich mit verschiedenen Linux Distributionen spiele :-).
Das war notwendig, weil diese Festplatte eine Recovery-Partition enthält, von der man dann ggf. das Windows-System wiederherstellen kann.
Das Festplattendienstprogramm ermöglicht es sehr einfach, ein Image von einem kompletten Device (einer Festplatte) zu ziehen. Hierbei werden auch gleich nicht gefüllte Bereiche ausgespart, sodass von der 160 GB Platte ein knapp 8GB großes Image übrig bleibt. Bis zu diesem Zeitpunkt befand ich mich noch in dem Glauben, dass ich das Image zu einfach wieder zurückspielen könnte.
Achja: Für das Backup habe ich die 2,5″ SATA Platte ausgebaut und mit Hilfe eines USB-SATA Adapters meinem MacBook Pro zur Verfügung gestellt.
Die Struktur der Festplatte sieht wie folgt aus:
bash-3.2# diskutil list ... /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *160.0 GB disk1 1: Windows_NTFS System 85.9 GB disk1s1 2: DOS_FAT_32 69.6 GB disk1s2 3: 0xDE 4.5 GB disk1s4 ...
Dem unbedarften Leser scheint hier nichts besonderes aufzufallen, allerdings ist die letzte Partition vom Typ EISA-Konfiguration und kann von MacOS nicht gemountet werden. Interessanterweise ist es dem Festplattendienstprogramm aber möglich, die Partition mit in ein Gesamt-Image zu sichern, wenn man das komplette Device sichert. Dummerweise ist eine Wiederherstellung auf Device-Ebene nicht vorgesehen :-).
D.h. es ist möglich die Partition mit der (aktuellen) Windows Partition(NTFS), sowie eine weitere Partition mit Update-Daten(FAT32) wiederherzustellen, aber die eigentlich Revocery-Partition bleibt im Nirvana verschollen :-/. Weiterhin ist es hierzu notwendig, das sowohl Zielfestplatte, als auch Backup-Image die identische Partition-Struktur haben – d.h. legt ein Linux-Installer ein eigenes Partition-Schema an, so ist es nicht mehr so einfach möglich, das Backup wieder einzuspielen.
Was uns bei beiden Problemen hilft ist das Unix-Tool “dd”.
Als allererstes ist es wichtig, herauszufinden, wie die beiden Devicenamen lauten. Hierzu mounten wir das Backup-Image und schließen die Festplatte wieder an den Mac an.
Danach lassen wir uns die Disk-Device auflisten:
bash-3.2# diskutil list /dev/disk0 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *200.0 GB disk0 1: EFI 209.7 MB disk0s1 2: Apple_HFS Imotep HD 199.7 GB disk0s2 /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *160.0 GB disk1 1: DOS_FAT_32 DISK1S1 84.9 GB disk1s1 2: Linux_Swap 970.6 MB disk1s3 3: DOS_FAT_32 69.6 GB disk1s2 4: 0xDE 4.5 GB disk1s4 /dev/disk2 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *160.0 GB disk2 1: Windows_NTFS System 85.9 GB disk2s1 2: DOS_FAT_32 69.6 GB disk2s2 3: 0xDE 4.5 GB disk2s4
Unsere Quelle ist /dev/disk2, unser Ziel /dev/disk1. Als allererstes kopieren wir den MBR vom Image auf die Festplatte (hier ist auch die Partition-Tabelle gespeichert - man erspart sich das aufwendige Neu-Partitionieren). Der MBR befindet sich innerhalb der ersten 512k einer Festplatte.
bash-3.2# sudo dd if=/dev/disk2s1 of=/dev/disk1s1 bs=512 count=1
Nun sind wir in der Lage die beiden sichtbaren Partitionen über das Festplattendienstprogramm wiederherzustellen. Hierzu wählen wir unser Ziel an. Unter dem Tab "Wiederherstellen" ziehen wir einmal unsere Zielpartition in das Input-Feld "Ziel" und aus dem gemounteten Image die Quell-Partition in das Input-Feld "Quelle". Sollte das Programm eine Fehlermedung ausgeben, so ist es ggf. notwendig, die Partitionen erst zu deaktivieren (Partition anwählen und über die Toolbar oben deaktivieren). Nach einigen Minuten sollte das Backup eingespielt sein. Dies ist ein großer Vorteil gegenüber von "dd", weil dd die Daten sektorweise wiederherstellt (also auch Nullsektoren 1:1 überträgt), während das Festplattendienstprogramm nur die reinen Daten überträgt und Nullsektoren ausspart.
Was bleibt ist die letzte nicht-sichtbare Partition. Dies kopieren wir nun abermals per "dd". Um nicht kB-Weise zu kopieren wählen wir hier 512MB Slices:
dd if=/dev/disk2s4 of=/dev/disk1s4 bs=512m
Obwohl es nur knapp 5GB sind, nimmt der Kopiervorgang einiges an Zeit in Anspruch, sodass sich abschätzen lässt, wie zeitaufwendig ein Wiederherstellen der kompletten 160GB per "dd" wäre.
Mich hat diese Erkenntnis eine halbe Nacht gekostet :-). Vielleicht steht irgendjemand einmal vor dem gleichen Problem (z.B. sichern/wiederherstellen von reinen Linux Partitionen).
Testpost
This is a Test Post…
with some….
formating…
and
- bullets
- more
- more
- and
- more
At last…
an image:
Okay… next… a link
Done.
Praktika und die 20%
Für alle, die es mal immer wissen wollten, hatte ich vor einiger Zeit mal angefragt (letztendlich wurde die Frage bei http://www.wikia.com gestellt):
Sehr geehrter Herr H.,
hiermit kommen wir auf Ihre Email vom 18.02.09 zurück.
Ihre Frage, warum wir gerade Tiernahrung von unserer 20% Aktion ausschließen, ist durchaus berechtigt. Dies kommt dadurch zu Stande, dass es zum damaligen Zeitpunkt, als wir diese Aktion erstmals beworben haben, rechtliche Probleme bei der Rabattierung dieser Produkte gab. Diese wurden zwar zwischenzeitlich überwunden, tatsächlich verhält es sich jedoch so, dass sich unser Werbeslogan nunmehr genau mit diesem Wortlaut in den Köpfen unserer Kunden eingeprägt hat und mittlerweile zum Kult wurde, so dass wir diesen nach wie vor beibehalten.
Wir hoffen Ihnen mit dieser Erklärung die gewünschte Begründung geliefert zu haben und verbleiben
mit freundlichen Grüßen / best regards
i. A. T. K.
Marketing
Servicebuero
Praktiker Bau- und Heimwerkermärkte AG
Am Tannenwald 2
D-66459 Kirkel
Good to know 🙂.
system update :-/
Wer meine vergangenen Kurzbeiträge verfolgt hat, hat mitbekommen, dass ich mein System auf MacOS 10.6 aktualisiert habe.
Neben vielen Dingen die erstaunlich problemlos liefen, gibt es leider auch einige Probleme.
Manche davon ließen sich sehr einfach lösen:
- Die fehlenden Java Versionen 1.4 bis 1.5 lassen sich einfach durch das manuelle Kopieren aus einem Backup wieder herstellen
- Weiterhin gibt es einige Programme, die fehlerhaft, oder gar nicht liefen:
- Cyberduck lief gar nicht – da gibt es mittlerweile eine lauffähige, neue Version auf der Homepage
- BetterZip lief zwar, konnte aber keine tar.gz Files mehr lesen. Auch hier gibt es eine neue Version, siehe eine der letzten Posts
- Was für mich viel störender ist, ist das Nicht-Funktionieren des gpgMails Plugins von Stéphane Corthésy, da ich hin und wieder doch gerne verschlüsselte Emails verschicke. Das das Plugin von der aktuellen Version von Mail.app deaktiviert wird, hat wohl 2 Gründe:
- Wird das aktuelle Mail.app standardmäßig als 64bit-Anwendung ausgeführt. Das gpgMail Plugin ist allerdings nur als 32bit Version kompiliert.
- Hat sich mit der neuen Version wohl auch die (undokemntierte) API von Mail.app geändert.
Jeder der einmal versucht hat, eine API anhand von Message Calls und vorhandenen Headern zu reverse-engeneeren kann wohl nachvollziehen, wieso Stéphane für eine weitere Runde dieser Arbeit keine Zeit hat. Aber da das Plugin als Source vorliegt, liegt es ja nahe, sich der Sache selbst anzunehmen. Zwar sind meine Objective-C Kenntnisse bei weitem noch nicht so gut, wie ich es gerne hätte, allerdings ist das Plugin zwar sehr gut in Mail.app eingefügt, allerdings dient es ja nur als Client für libgpg. Zudem sind die Sourcen wirklich gut kommentiert worden, sodass die Stellen, an denen man Snow-Leopard spezifischen Code einfügen müsste, sehr schnell deutlich werden :-).
Stéphane hat hierzu in dem Projektforum von sourceforge ein paar Hinweise gegeben. So werden für eine erfolgreiche Kompilierung von gpgMail zuerst einmal universal-binary(UB) (oder nur 64bit) Versionen von gpg, libgpg-error, libgpgme und dem MacGPGME framework benötigt.
Mein erster Versuch mit gpg,libgpg und libgpg-error über macports zu Installieren und danach per hardlinks von /opt auf /usr zu linken, brachte mir zumindest eine kompilierte 64bit Version vom MacGPGME framework. Ein UB lässt sich nicht kompilieren, da ich scheinbar von den libs nur eine expliziete 64bit Version besitze (womöglich müsste ich die hardlinks auch im lib64 Verzeichnis erstellen).
Momentan bin ich dabei das MacGPGME framework in einer UB Version zu erstellen. Was mich ein wenig gewundert hat ist, dass gpgMail scheinbar Header Dateien verlangt, welche das MacGPGME framework gar nicht hergibt.
Es ist zumindest vermeldet worden, dass ein weiterer Entwickler sich der Sache angenommen hat, der zumindest mehr Ahnung zu haben scheint als ich :-). Vielleicht werde ich mich dann mal bei ihm melden, so ich denn nennenswerte Fortschritte erreichen kann. Ist zu hoffen, dass die API Änderungen von Mail.app nicht zu gravierend sind….