Überraschend.

Das der so vollständig ist, hätte ich nicht erwartet. Aber in der Tat, ICU-Regexe in ihrer ganzen Pracht. Völlig ohne eine neue externe Dependency.

Laut der Dokumentation sollte das sogar in 10.4 schon funktionieren - mit dem einen Caveat, dass multiline Support dort wohl von Hand eingeschaltet werden muss (via (?m))

Sowas wird da möglich:

if ([@"aaa" matchesRegex:@"a{3}"])
    NSLog(@"gotcha");

// other examples
[@"argh fnord argh" matchesRegex:@".*\\bfnord\\b.*"];
[@"aaa" matchesRegex:@"\\w{3}"];

Und das mit extrem wenig Aufwand:

@interface NSString (SimpleRegexMatching)
- (BOOL) matchesRegex:(NSString *)aRegex;
@end

@implementation NSString (SimpleRegexMatching)
- (BOOL) matchesRegex:(NSString *)aRegex;
{
    id predicate = [NSPredicate predicateWithFormat:@"self matches %@", aRegex];
    return [predicate evaluateWithObject:self];
}
@end

Ich bin beeindruckt.

[source:/open-source/SimpleRegexSupport/trunk/RegexTest.m Code hier]

... eigentlich einfach zu verstehen.

Zum weglegen. :)

Gerne auch Freihaus...

Extra 3 hat es mal wieder genagelt.

:-)

Braucht man manchmal für Bindings. Gleichzeitig will ich aber nicht überall die namen meiner Variablen als Strings hinterlegen - schon alleine damit ich beim Refactorn auch alle Namen erwische.

Also den Macro-Prozessor zur Rettung:

#define NSStringize(aVariableName) @#aVariableName

::

macht aus einer beliebigen expression einen String @:: und das @ davor macht aus einem constanten c-string einen ObjC-NSString.

Und das problem ist gelöst. :)

Mit ein bisschen Hilfe von meinen Freunden...

Heute hab ich mal wieder die aktuelle Version von Bazaar (1.7.1) ausprobiert. Soweit ganz schnuckelig. Sogar der SVN Checkout von [svn://svn.adiumx.com/adium/trunk Adium] hat hervorragend geklappt.

Ich muss sagen, beeindruckend.

Nur mit dem Plugin bzrtools hatte ich Schwierigkeiten, denn die darin enthaltene shell (ein geiles feature) zu benutzen brachte bzr reproduzierbar zum Absturz. :-(

Stellt sich mit hilfe von #bazaar und nach einigen Detours über den Python Debugger (nice!) und dtruss (nice!) heraus dass es an der libreadline liegt.

Die hat sich nämlich geändert und erwartet inzwischen am Anfang eines History-Files als allererste Zeile diesen eintrag: _HiStOrYV2.

Na toll. Und ansonsten stürzt das Programm einfach ab. Also wer sich das ausgedacht hat, der gehört aber auch echt erschossen. Wenigstens die Fehlermeldung hätte vernünftig sein können. Grumpf.

Heute hatten wir wieder ein schönes Beispiel für Usability unter Windows. Zuerst das Setting. Eine Bekannte hatte auf einem USB-Stick Fotos mitgebracht und diese sollten auf einem Windows-Vista Notebook dann angeschaut werden.

Das ganze wäre dann fast daran gescheitert, dass auf dem USB-Stick ein Trojaner drauf war und sich Windows nach Entdeckung und Beseitigung des Virus (durch irgend ein Third-Party-Programm) standhaft geweigert hat den Stick im Explorer anzuzeigen. Je nachdem in welchem der USB-Stecker man den Stick einsteckte erkannte Windows nicht mal das überhaupt ein USB-Stick eingesteckt war. Aber ich lenke ab, denn das Problem konnte ich mit etwas Windows-Shell dann doch lösen.

Zum Thema: Nachdem der Ordner mit den Bildern im Explorer aufgemacht wurde, ging es nach einem Doppelklick auf das erste Bild los - der Bildbetrachter ging auf und die Slideshow ging los.

Und das ist das Thema: Unter Windows öffnet der Bildbetrachter Bilder anders als sonst Programme Dateien öffnen - implizit wird dort nämlich der ganze Ordner geöffnet, damit man leicht eine Slideshow mit den Bildern starten kann.

Und das hat doch immerhin so gut funktioniert, dass die Slideshows doch zusammen kamen.

Das bringt aber die Abstrakte Frage mit, was passiert wenn solche "Ausnahmen" immer mehr werden. Verstehen die Anwender dann trotzdem noch das allgemeine Prinzip was dahinter liegt? Sind sie in der Lage zu abstrahieren und das Verhalten an anderen Stellen vorherzusagen?

Ich sehe ein Problem darin, dass Computer für die meisten Menschen "magisch" sind - man lernt nur die magische Formel, die zu einem konkreten Ziel führt. Dass hinter den 30 Formeln die man mit der Zeit lernt ein Prinzip steht geht dann nur allzu oft verloren.

Zurück zum Beispiel: Am Mac ist es so, dass man, wenn man eine Datei öffnet, dann auch nur diese Datei aufgeht. Und das ist auch so wenn man ein Bild öffnet. Unter Windows ist das anders, denn man öffnet im Bildbetrachter (wehe wenn die Zuordnung verloren geht, weil man ein Bildbearbeitungsprogramm installiert hat) der von sich aus schon die nächsten Bilder kennt und es einem leicht macht eine Slideshow zu starten.

Was ist Besser? Im Beispiel waren relative Laien in der Lage eine Slideshow zu starten - das ist ein Plus. Hätten sie das auch auf einem Mac geschafft?

Wann ist es Besser so eine Ausnahme vom regulären Benutzungs-Konzept zu machen und wann nicht? Für mich ist die Grenze völlig unklar - nur dass es irgendwann den Punkt gibt, wo zu viele Ausnahmen selbst zum Problem werden.

... without needing to care which constructor to use this time to get it right.

Well, I was offended by this just long enough, so I sat down and wrote a macro that allows this:

//  Use like this:
    id dict = [NSDictionary dictionary];
    NSNumber *ten = NMMakeNumber(10.0f);
    [dict setObject:ten forKey:@"numberOfFingers"];
    [dict setObject:NMMakeNumber(23) forKey:@"fnord"];
    [dict setObject:NMMakeNumber(YES) forKey:@"wantFries"];

I'ts almost the way Autoboxing works in Java or C#.

This quite eases the pain of creating NSNumbers correctly for me, because it means I don't have to repeat the type of what I am working with quite as often.

Pretty DRY. :)

[source:/open-source/NSNumberCreator/trunk Here's the code to a NSNumber category and a makro that makes this happen.]

... fürs Anschnallen!

Super. :)

Mein Vorschlag für diese Diskussion

... ist schwer.

Glücklicherweise wurde der Prozess endlich offen gelegt!