Liebe CoMa's

ihr kennt bereits aus dem letzten Semester die Abfrage eures (aktuellen?) 
Punkte-Standes aus dem Unix-Pool.
Diesen Service können wir ab sofort auch wieder bieten.
Dazu müsst ihr wieder nur im Unix-Pool mit eurem CoMa-Account eingeloggt sein 
und dann den Befehl

~co2-001/show_status

ausführen. 

Viel Spaß

Andreas

Liebe CoMa-Studenten,

es gibt jetzt die 2. Programmieraufgabe auf der Homepage.
Es geht noch um ein paar kleinere Klassen, die ihr schreiben 
sollt, alles Vorbereitung zur 3. Programmieraufgabe. 
Genaueres steht auf der Homepage.

Wichtig ist, dass ihr zuerst die aktuellste Version unserer 
Packages installiert. Löscht dazu alles, was in den packages- und
class-Verzeichnissen unterhalb von ccc und comaawt steht.
Kopiert euch die Dateien dann neu von uns und übersetzt sie.

Das vorherige Löschen ist hierbei wirklich wichtig, da sonst noch
etwas alter Müll übrigbleibt, der beim Compilieren zu Problemen
führen kann. Passt aber auf, dass ihr keine selbstgeschriebenen 
*.java-Dateien mit löscht. (Die haben deshalb nichts in unserem 
package-Verzeichnis zu suchen!)

Wenn ihr unter Linux (z.B. Unix-Pool) im Probleme habt, die Pakete 
von uns zu compilieren, dann hilft vielleicht folgendes:

Kopiert das Makefile von uns:
> cp ~co2-001/Makefile ~/
und compiliert die packages so:
> cd ~/
> make cleanccclib
> make all
Das sollte gehen.
Ihr solltet jetzt euren selbstgeschriebenen Code neu compilieren,
falls ihr ihn auch in das classes-Verzeichnis kompiliert habt.

Die ContainerApplication sollte jetzt auch nicht mehr zu gross sein,
sondern eine angenehme Größe haben. Sobald wir herausfinden, wie 
wir Java überreden können, sie in Bildschirmgröße auszugeben, gibt 
es nochmal ein kleines Update, bis dahin diese Zwischen-Lösung.
Falls ihr eine andere Standard-Größe wüscht, sucht ihr in der Datei
packages/comaawt/ContainerApplication.java
die Zeile
setSize(800,600);
und passt die Werte an.

So, das war's erst mal von mir.

Schönes Wochenende
Andreas

Liebe CoMa-Studenten,

ein Nachtrag zur ContainerApplication. 

Ab jetzt sollte sie Standardmäßig den Bildschirm fast komplett 
ausfüllen (modulo Window-Manager bei Unix-artigen Systemen). 
Unter einigen Windows-Versionen tritt sie jetzt im Vollbild-Modus 
in Erscheinung ( - denke ich ;-) )

Was eben über das setSize gesagt wurde -- vergesst es!

Damit verabschieden wir uns recht herzlich von allen Rechnern, 
auf denen JDK 1.3.x oder älter installiert ist, denn volle
Bildschirmgröße geht erst ab JDK 1.4. Vielen Dank an die 
Java-Entwickler!!!

Damit scheiden insbesondere die so liebgewonnenen AIX-Rechner im 
oberen Teil des Unix-Pools (c81 - ...) als CoMa-Rechner aus!!!
Sagt das bitte bei der Anmeldung im Unix-Pool an! 
Falls es euch dann doch an die alten Schnecken verschlägt, geht bitte 
mittels 
ssh c32 -l tadm 
in eurem Arbeits-xterm auf eine der Linux-Kisten!!!

Wer noch eine alte JDK-Version auf seinem Rechner hat:
Fragt mal rum, wer noch eine CoMa-CD vom ersten Semester zu Hause hat.
Ich habe leider nur noch eine, die verleihe.
Für alte Mac-Systeme (vor MacOS X) sehe ich allerdings schwarz...

So, das war's jetzt von mir für heute.

Bis bald und nochmals schönes Wochenende
Andreas

Liebe CoMa's,

es gibt noch einmal eine Verbesserung an der ContainerApplication.
Ab sofort werden zwei übliche Fehler von der Application
direkt erkannt. Bisher wurden nur kryptische Exceptions der Application
ausgegeben, die nicht auf die Ursache schliessen lassen. 

Falls ihr die verbesserte Fehler-Hilfe nutzen wollt, kopiert bitte 
nochmals die aktuellste Version der Application.

Dann noch einen schönen Abend. Bis morgen zur RechnerBetreuung.

Andreas

Liebe CoMa's,

auch auf die Gefahr hin, dass ich nerve... ;-)

Richtig geraten: Es gibt neues in der ContainerApplication.

Falls die Application mit eurer Klasse nicht starten will, so gebt bitte die Option "-d 1" an.
Dies erzeugt einige Debug-Ausgaben auf der Console, die vielleicht dabei helfen, den Fehler
zu lokalisieren.
Ist die Application schon gestartet, aber es tauchen irgendwelche "Abstürze" auf, so sieht man 
nun vielleicht ebenfalls mehr. 

Ihr könnt nach dem Programmstart auch im Menü Debugging->Debug output->DebugFrame
ein Fenster erzeugen, in das alle weiteren Debugausgaben geschrieben werden. Hier werden 
Exceptions in einer gekürzten, übersichtlicheren Form ausgegeben. 
Die "grosse" Exception-Ausgabe kann man im Übrigen jetzt auch in diesem Menü ein-/ausschalten.
Das entschricht dem setzen (oder nicht) der Option -e.

Genauere Debug-Ausgaben werden sicherlich im Laufe der Zeit folgen, je nachdem, welche Fehler
so gesucht werden müssen... ;-)

==============
|| WICHTIG: ||
==============

Damit ihr euch das ewige neu kopieren etc. spart bzw. vereinfacht, befolgt bitte folgende Schritte:

1. Jeder selbstgeschriebene Code muss in einem Verzeichnis 
	~/programme/programmX/
   oder so ähnlich stehen. Verschiebt eure eigenen Java-Dateien, falls noch nicht geschehen.

2. Löscht DANACH das gesamte Verzeichnis ~/packages und seine Unterverzeichnisse:
	rm -rf ~/packages

3. Kopiert euch von uns das Makefile:
	cp ~co2-001/Makefile ~/

4. Führt  folgenden aufruf aus:
	make cleanccclib ccclib

Immer wenn es von uns etwas neues gibt, braucht ihr nun nur noch 
	make ccclib
ausführen, und schon habt ihr die aktuellen .class-Dateien.

Wer zu Hause arbeitet und trotzdem auf dem aktuellsten Stand bleiben will, muss allerdings weiterhin 
die aktuellsten Dateien herunterladen.

 
So, dann macht's mal gut.

Andreas

P.S.: das vierte Übungsblatt ist seit heute mittag online. Gestern hab ich's nicht geschafft 
      (wegen 7 Std. Rechnerbetreuung...)

Liebe CoMa's,

ihr habt Schwierigkeiten, in eurem RootPathIterator euren eigenen Stack zu verwenden? 
Kein Wunder, ich hab da etwas kleines nicht bedacht....

Hier zwei Lösungsmöglichkeiten:

1. Ihr schreibt in die Stack-Klasse und alle von ihr verwendeten eigenen Klassen
   (Liste, ListNode, ListIterator) folgende erste Zeile:
	package mycoma;

   Nun übersetzt ihr all diese Dateien mittels
	java -d ~/classes MyStack.java MyList.java MyListNode.java MyListIterator.java

   Im RootPathIterator schreibt ihr nun noch
	import mycoma.*;

   Jetzt sollte es gehen...

2. Ihr verwendet doch (ausnahmsweise) den java.util.Stack.

Ach so, wenn ihr eure Iteratorn testen wollt, dann tut es einfach mal mit dem Aufruf:

	java comaawt.ContainerApplication ccc.bintree.RandomTree -i RootPathIterator 
	     BTLeafIterator BTPreorderIterator -d 1
	     
Gruß
Andreas

Liebe Studenten,

falls euer Huffman-Algorithmus nicht so will, wie er soll, ist es ganz hilfreich,
sich mal den Baum ausdrucken zu lassen. Dazu braucht man eine geeignete 
toString()-Methode.  

Hier ist eine Möglichkeit (entnommen aus der ContainerApplication):

public String toString(){
    StringBuffer s = new StringBuffer();
    s=s.append("Inorder:\n-------\n");
    try{
	for (ConstForwardIterator it=getConstIterator();
	     !it.isAtEnd();
	     it.increment()){
	    for (int i=0;i<getDepth(it); i++)
		s=s.append("|    ");
	    s = s.append(it.getData()==null? "null":it.toString());
	    s = s.append("\n");
	}
    }
    catch (RuntimeException e){
	e.printStackTrace();
    }
    
    return s.toString();
}


Baut sie einfach in eure Baum-Klasse ein.

Viele Grüße

Andreas

Hallo allerseits...

fuer alle, die schon an der 4. Programmieraufgabe feilen und darauf gekommen
sind, dass man Objekte nicht mit < und <= etc. vergleichen kann, wurden im
Aufgabentext noch ein paar Hinweise aufgenommen. In Kurzform: Der Suchbaum
sollte einen Comparator bekommen, mit dem man die gespeicherten Daten
vergleichen kann. Die (etwas) ausfuehrlichere Variante findet sich natuerlich
auf der homepage.

Viele Gruesse, Spass und Erfolg...

Axel.

Hallo nochmal...

noch ein paar Hinweise zur 4.Programmieraufgabe, die vielleicht von allgemeinem
Interesse sein koennten:

Ergaenzend zur Dokumentation des Interfaces Checkable sollte gesagt werden,
dass die Methode checkInvariant() bei Verletzung der Invarianten auf jeden Fall
eine InvariantViolatedException werfen sollte, und zwar in Verbindung mit einer
aussagekraeftigen(!) Meldung; der Vorteil ist vor allem, dass man dann genauer
nachvollziehen kann, bei welchem Test etwas nicht stimmte.

Zur Verwendung der CheckPolicy schaut Euch das Beispiel zur Dokumentation des 
Interfaces an -- insbesondere wie die methode checkInvariant() dort aufgerufen
wird. Ausser bei der Erstellung von Iteratoren macht es vor allem auch Sinn, am
Ende des Object-Array-Konstruktors von ConstBinTree die Invariante zu checken,
sowie natuerlich nach dem Einfuegen und Loeschen im SearchTree.

Viele Gruesse,

Axel.

Liebe CoMa's,

es ist mal wieder so weit: es gibt eine gaaaanz neue Version der ContainerApplication!!!

Allerdings handelt es sich um eine noch nicht bis ins kleinste getestete Entwickler-Version,
die zwar eventuell noch ein paar Fehler enthält, aber dennoch viel einfacher zu bedienen ist
(nach meiner Meinung).

Da es noch keine endgültigeVersion ist, findet sich die neue Application in einem neuen 
Package mit dem Namen comaawtdev. Der Programmaufruf hat die selben Optionen wie bisher.

Um die neue Application zu benutzen müsst ihr in eurem Wurzelverzeichnis einmal 

make ccclib 

ausführen und die Application dann mit 

java comaawtdev.ContainerApplication ..........

starten. Was sofort auffällt, ist, dass die Auswahl der meisten Klassen nun im 
"Settings"-Menu erfolgt und das Plugin-Panel verschwunden ist. Plugins werden nun in einem 
eigenen Menü gestartet.
Im File-Menü gibt es unter anderem die Möglichkeit neue Container zu erzeugen.

Ich wäre euch dankbar, wenn ihr ab sofort die neue ContainerApplication verwenden würdet.
Bitte meldet mir aber sämtliches merkwürdiges Verhalten, also insbesondere:

- Wann werden welche Exceptions aus der Application geworfen, an denen ihr keine Schuld habt?
- Welche Fehler in Euren eigenen Klassen führen zu welchem Verhalten der Application?
- Welche Fehlermeldungen gibt die Application, obwohl ihr gar nichts bzw. etwas ganz 
  anderes Falsch gemacht habt? 
- etc.


Ach ja, ihr könnt zwar alle bisher bekannten Plugins weiter verwenden, aber für alle 
Pile-Klassen (Stack, Queue, PriorityQueue, ...) gibt es ein neues, besseres Plugin:
comaawtdev.PileManipulation (statt ccc.util.PileManipulation)

Vielen Dank für Eure Mithilfe

Andreas

Hallo...

eine Fehler auf dem 7. Uebungsblatt, auf den ich gerade aufmerksam gemacht
wurde: in Aufgabe 36.b) (iii) muss es natuerlich heissen: "fuer alle schwarzen
Knoten z"! In den weiteren Teilen kann (und muss) man natuerlich die Ergebnisse
der vorherigen Teilalgorithmen verwenden -- so z.B. in Teil c) den Knoten y,
den man in Teil b) gefunden hat.

Zur Rot-Schwarz-Baum-Programmieraufgabe: Da fuer Rot-Schwarz-Baeume
Doppelrotationen nicht explizit benoetigt werden, muessen sie auch nicht
unbedingt mit implementiert werden. Wer das trotzdem machen moechte: eine
Doppelrotation nach links am Knoten x ist einfach die Ausfuehrung einer
Rechtsrotation am Knoten x.right, gefolgt von einer Linksrotation am Knoten x;
entsprechend symmetrisch funktioniert die Doppelrotation nach rechts.

Viel Erfolg...

Axel.

Hallo CoMa's,

die Folien aus Martino's Hashing-Übung vom Dienstag sind jetzt auf der
CoMa-Homepage.

Schönen Abend

Andreas