Aktueller Inhalt von Georg

Die Variable, die die Anzahl der Kugeln beinhaltet oder die Collection, die die Kugeln beinhaltet (je nachdem, wie du es implementiert hast) sollte volatile oder synchronized sein, ansonsten kann es passieren, dass die VM die Variable nie wieder liest, wenn sie von einem anderen Thread verändert...

Lass dir doch mal die URL in der zeigeBild nochmal auf der Standardausgabe ausgeben. Ich tippe mal, dass da irgendwas schiefläuft, wenn es ansonsten geht (url per Hand eingeben geht ja offenbar wie du sagst).

Vorher würde ich einen Kurs in XML machen. Variable Nummern oder was auch immer das sein soll als Element-Namen ist etwas sinnlos (und das Schema dazu würde ich ja gerne mal sehen :) . Wenn du dir das angeschaut hast sollte sich auch dein Stylesheet-Problem vereinfachen.

dei mbuffer-Aufruf sieht auch etwas falsch aus. mbuffer -L -m 1G -p 25 < /dev/st0 | tar -xzf - mbuffer hat auch eine Option "-i" mbuffer -L -m 1G -p 25 -i /dev/st0 | tar -xzf -

Für Ersetzungs-Kleinscheiß (= nicht die Hauptaufgabe eines Mörder-Programmes) sollte man einfach das nehmen, was das SDK einem anbietet und sich nicht groß Gedanken darüber machen, wie schnell das ist. Und wenn man Strings von 1GB Länge bearbeitet sollte man das auch nicht mit dem Typ String...

Strings sind bei Java konstant und lassen sich nicht ändern -> du musst dir also einen neuen String zusammenbauen z.B. String x = "AAABAAA" Du willst nun B durch C ersetzen: x = x.replaceFirst("B", "C"); musst es also sich selber zuweisen (oder noch einen weiteren String anlegen) Wenn du...

Deine Probleme entstehen wahrscheinlich deshalb, weil der Webserver die Dateien UTF-8-kodiert vermutet, sie aber Latin1-kodiert sind. Du könntest die Dateien umkonvertieren (iconv) nach UTF-8. Hast du denn ein Charset-Tag in den HTML-Dateien? Benutzt du xhtml? Das direkt dort zu machen...

Ja, du hast recht. Ich hatte deshalb auch 16-bit-Unicode geschrieben, da die oberen Zeichen nicht so häufig sind. In den unteren 16 bit sind soweit ich weiß z.B. die chinesischen Zeichen drin - und damit verbrauchen dort Dateien im UTF-16-Format weniger Speicher als im UTF-8-Format.

Nur mal so zur Info: Java und .Net glaub ich auch lesen Zeichen ein und speichern alle Zeichen intern als 2Byte-Wert. Damit decken sie die 16bit-Unicode-Zeichen ab. Beim Einlesen findet mehr oder weniger ein Mapping statt, was einem oder mehreren Byte (je nach Zeichensatz) einem...

Tja, ich benutze seit Jahren postgresql und kann das nur weiterempfehlen. Aber ansich finde ich es auch einen guten Schritt.

Gib mal eine Tabelle von Prozessen, die du so standardmäßig laufen hast (ps -auxf) Da sieht man vielleicht, was das sein könnte... Die CRON-Nachrichten sind nur die Ausgaben des cron-daemon, schau mal nach, ob du für andere Nutzer vielleicht was liegen hast unterhalb von /var/spool/cron .

Sicher, bin aber (eigentlich) kein C-Programmierer und ignoriere mal solche Feinheiten ;) Aber wie schon gesagt, am besten ist sowieso wenn man das in ne Funktion haut und die Größe als Parameter übergibt (man ersetze main(...) durch zeichneBaum(int size) oder so und rufe die aus der main auf.

Hier der Code (mit Baumstamm ;) ) #include <stdio.h> #include <stdlib.h> #define TREESIZE 10 main () { int zeile, spalte, leer, sterne; char leaf[TREESIZE * 2]; // Baum for (zeile = 0; zeile < TREESIZE; zeile++) { sprintf (leaf, "%%%ds/%%%ds\\\n", TREESIZE-zeile, ((zeile) *...

Ich habe mir den Spaß auch mal gemacht und es mit einer Schleife (nur die Zeilen-Schleife) hinbekommen, aber mit nem kleinen Trick ;) Code gibt es morgen. Btw: Probier mal die Anzahl Zeilen/Spalten in eine constante zu extrahieren, das ist sauberer (#define groesse 10) und dann size verwenden...

Nur mal so als Anstoß (gefüllter Baum, Spitze in Spalte 10): in Zeile 1, 9 Leerzeichen, dann Sternchen. für jede weitere Zeile, ein Leerzeichen weniger, zwei Sternchen mehr. Mit dem Ansatz solltest du die Schleifen mal durchgehen.