Beiträge von ComSubVie

    vermutlich kennt das schon der eine oder andere, aber egal. gesteuert wird mit j und k.

    naja, mit deinem SQL ist das ein wenig komplizierter. aber wenn du die teams einfach als array aufbaust $team[0] = array(name1,name2), $team[1]=array(name1,name3), ...
    dann kannst du deine matches auch so wie oben aufbauen (team: 0/1, 0/2, 0/3, .. 0/b, 1/2, 1/3, ... 1/n, ... n-1/n), und dabei überprüfst du noch, ob eh kein spieler in beiden teams drin ist (team[i][0] != team[j][0], team[i][1] != team[j][0], team[i][0] != team[j][1], team[i][1] != team[j][1]), und wenn das der fall ist einfach in die liste einfügen

    im prinzip nicht so schlecht. die doppelten kriegst du weg, wenn du die schleifen so designst:
    1 -> 2
    1 -> 3
    ..
    1 -> n
    2 -> 3
    2 -> 4
    ..
    2 -> n

    (d.h. der startindex vom zweiten spieler immer größer ist, als jener vom ersten)

    als code z.b.:

    Code
    for ( $i = 0; $i < $anzahl; $i++ ) {
      for ( $j = $i+1; $j < $anzahl; $j++ ) {
        $team = array( $namen[$i], $namen[$j] );
      }
    }

    Bau dir zuerst mal eine Liste mit den Teams auf (das sind 2 verschachtelte Schleifen, also trivial).
    Bau dir dann einfach aus der Teamliste den Spielplan auf - das sind auch wieder nur 2 verschachtelte Schleifen, wobei du halt darauf aufpassen musst, das ein spieler zur gleichen Zeit nur in einem Team spielen darf. Nicht trivial, aber leicht.

    Was ist daran jetzt so schwierig?

    am einfachsten direkt in jenes skript reinschreiben, welches die karten initialisiert (zB sowas wie /etc/init.d/network*). aber bevor du das skript änderst, schau ob das nicht eh eine config lädt, wo man das konfigurieren kann. in debian kann man das mit pre-up-scripts in der /etc/network/interfaces elegant lösen (SuSE hab ich auch laaaaaaang nicht mehr verwendet. dann erst kürzlich wieder angegriffen, für untauglich befunden und wieder weggeschmissen).

    ich warte eh schon lange auf die "neu: video-ipods", "neue imacs", "aperture", ... - threads :D

    aber interessant zu sehen, das es auch leute gibt, die nicht schon wochenlang gebannt darauf warten, was his steveness bei pressekonferenzen neues zu verkünden hat (und da dann nicht gleich sofort die live-weblogs lesen müssen).

    naja, das b-tree-problem wird sich vermutlich durch neuformatierung lösen lassen. und ob man bei kaputten b-trees auf die vorhandenen daten noch zugreifen kann, wage ich eigentlich zu bezweifeln. aber dafür gibts ja backups (wobei ich zugeben muss, das ich vor dem update kein aktuelles backup gemacht habe) ;)

    bei mir ging das update übrigens problemlos, nicht der geringste mucks, nichts. allerdings habe ich davor auch immer brav alle updates geladen (ich aktualisiere aber auch mein debian/sid täglich *g*).

    Naja, das kommt darauf an was du tun willst. Wenn du on-chip-debugging betreiben willst, dann wirst du um einen komplexen JTAG-programmer nicht herumkommen, wobei ich da bezweifel das diese unter OS X funktionieren. Wenn du den AVR nur programmieren willst, so wirst du unter *NIX-Systemen vermutlich den uisp verwenden, eventuell den avrdude (ich selber verwende den uisp).

    Als Hardware kannst du eigentlich alles mit ein wenig eingebauter Intelligenz verwenden, also z.b. die offiziellen STK200 bzw. STK500 Starterkits+Programmer von Atmel, oder einen AVRISP. Die kostengünstigste Version ist vermutlich der AVR910 (das ist genau genommen eine Application Note, die einen AVR zur Übersetzung von RS232 auf ISP verwendet, und daher auch mit USB-Adaptern funktioniert).

    Ich selber verwende momentan ein STK500 unter OS X, sowie einen eigenen RS232-Programmer, der allerdings die Schnittstelle vergewaltigt und daher nur mit einem echten RS232 funktioniert (das halt auf meinem Linux-Desktop - dafür sehr billig, weil nur Kabel).

    für DD kannst du vorher ein bisschen mit hdparm optimieren. DMA an (incl. PIO-mode), (E)IDE 32-bit I/O an, dann müsste es flotter gehen. sonst eventuell die platte an einen anderen controller hängen, als single-master anhängen, etc.

    Ich konnte mich mit dem VisualBasic irgendwie nie anfreunden, auch wenn es zugegebenermaßen für schnell zusammengeklickte GUIs recht brauchbar ist - allerdings habe ich noch keinen einzigen (Visual)Basic-Code gesehen, der auch nur annähernd rudimentäre Merkmale von Wiederverwendbarkeit zeigt.

    Der VisualStudie GUI-Designer war allerdings auch in früheren Versionen recht brauchbar (ich muss zugeben, ich habe VS.net noch nicht verwendet), und in Verbindung mit den MFC konnte man durchaus recht schnell brauchbare GUI-Programme erstellen. Wobei seit ich Apple-User bin hab ich mich nicht mehr ernsthaft damit beschäftigt.

    Wobei gerade im GUI-Bereich wäre es schon schön zu wissen, was eure favorisierten C(++)-Bindings sind, schließlich will man ja auch mit C plattformunabhängig bleiben - mit QT hab ich mich jedoch nie anfreunden können, und GTK ist zwar schön, aber mehr C als C++ (oder hat sich das inzwischen geändert?).

    Java ist für gewisse Aufgaben durchaus eine recht brauchbare Sprache - vor allem wenn es um GUIs geht, aber auch die Netzprogrammierung damit ist ein bisschen einfacher als Socket-Programmierung in C, aber ich mag Java trotzdem nicht. Das ist aber wohl mehr eine religiöse Überzeugung.

    hal: Das mit C++ kann ich nicht nachvollziehen. Ok, ein KDE kompiliert ewig, aber das liegt glaub ich nicht wirklich an der Sprache selber (wobei ich um KDE einen weiten Bogen mache), wenn du allerdings Metaprogrammierung mit C++ betreibst, so ist das durchaus klar und verständlich das der Compiler eine gewisse Zeit beansprucht (siehe z.B. CodeGuru: C++ Math and Fun).

    Das gleiche Argument hör ich für VisualBasic auch immer ;)

    Seinerzeit: BASIC, Logo
    Damals: Pascal, als es zu langsam wurde mit Assembler (x86) optimiert
    Früher: C, C++ sowie verschiedene Assemblerdialekte (x86, 8051, PIC, C167, ...)
    Heute: C, C++, Java (igitt), Perl, PHP
    Demnächst: Python (soll ja nicht so übel sein)

    Als IDE verwende ich fast immer vi(m), wobei ich mich momentan auch mit Eclipse beschäftige(n muss).