[Frage] spinnt Java oder EprogIO oder mein PC? [Archive]

derbrain

31-05-2004, 22:01

da schreib ich so schöne input-files zum testen meines programms, und auf einmal hängt das ding nur noch. während die meisten files problemlos gelesen werden, fängt bei einigen der prozessor an auf hochtouren zu laufen und nix passiert. irgendwann kommt dann die meldung, dass der speicher voll ist.
ich hab mein programm also ausgeben lassen, was es grad macht, und siehe da, bei readFloat() gehts nicht weiter. hab versucht die zahl, bei der er hängt, zu ersetzen - nix. wenn ich aber HINTEN noch eine zahl anhänge, also eigentlich zu viele eingaben, gehts. aber auch nicht immer. das ist mir jetzt schon bei zwei inputfiles passiert, ich seh aber keinen zusammenhang zwischen denen. nach nem neustart hats geklappt. und manchmal klappts auch nach einigem rumklauben im file. einfach so, auf einmal. weiß nicht ob es überhaupt am rumklauben liegt...
also ich blick da absolut nicht durch. hat jemand eine idee worans liegen könnte???

also, falls sich irgendwer wundert wieso ich das jetzt schreib wo ich doch schon abgegeben hab (siehe nächter thread): von gestern abend, als ich angefangen hab das zu schreiben bis heute vor 10 minuten hat das internet bei mir nicht funktioniert. weiß der henker wieso. jedenfalls hat das testen schlussendlich geklappt, aber ich hab ja eh schon geschrieben dass das auf einmal aufhört http://hades.gothic.at/iforum/images/smilies/rolleyes.gif also irgendwas muss da doch faul sein

michi204

01-06-2004, 01:54

da schreib ich so schöne input-files zum testen meines programms, und auf einmal hängt das ding nur noch. während die meisten files problemlos gelesen werden, fängt bei einigen der prozessor an auf hochtouren zu laufen und nix passiert. irgendwann kommt dann die meldung, dass der speicher voll ist.
ich hab mein programm also ausgeben lassen, was es grad macht, und siehe da, bei readFloat() gehts nicht weiter. hab versucht die zahl, bei der er hängt, zu ersetzen - nix. wenn ich aber HINTEN noch eine zahl anhänge, also eigentlich zu viele eingaben, gehts. aber auch nicht immer. das ist mir jetzt schon bei zwei inputfiles passiert, ich seh aber keinen zusammenhang zwischen denen. nach nem neustart hats geklappt. und manchmal klappts auch nach einigem rumklauben im file. einfach so, auf einmal. weiß nicht ob es überhaupt am rumklauben liegt...
also ich blick da absolut nicht durch. hat jemand eine idee worans liegen könnte???
check mal die zeilenumbrüche in deinem inputfile ;) das hat bei mir damals manchmal probleme verursacht.

hth, lg michi

Filz

01-06-2004, 04:34

check mal die zeilenumbrüche in deinem inputfile ;) das hat bei mir damals manchmal probleme verursacht.

hth, lg michi

würde ich auch vorschlagen - am Ende von jedem Input-File ein(ig)e neue Zeile(n), und es sollte immer funktionieren.

Die Eprog-Read-Funktionen lesen immer so lange ein, bis ein Leerzeichen oder eine neue Zeile kommt. Wenn dein Input-File direkt mit einer Zahl aufhört, bleibt er dann klarerweise in der Funktion stecken.

rck

01-06-2004, 16:00

da schreib ich so schöne input-files zum testen meines programms, und auf einmal hängt das ding nur noch. während die meisten files problemlos gelesen werden, fängt bei einigen der prozessor an auf hochtouren zu laufen und nix passiert.

Wie die Kollegen schon angemerkt haben: Die EPROG-Klassen haben einen Bug. Statt "End of Input" als gültiges Wortende anzuerkennen (was eigentlich so üblich ist), will die EPROG-Klasse "mehr" haben. Eben zB eine weitere Zahl. Oder einen Zeilenumbruch.

Deshalb habe ich bei manchen Programmen auf die EPROG-Klassen gepfiffen (bei Real-Zahlen zugegebenermaßen... gewagt) und mir das ganze selber geschrieben. Siehe auch Hauptroutine des Einheitenberechners (http://www.kiesler.at/article~view~41~page_num~2.html).

irgendwann kommt dann die meldung, dass der speicher voll ist.

Das war bei mir noch nie! Wie geduldigt bist Du da, wie lange wartest Du darauf? :-)

Kannst Du ein "minimales Beispiel" geben, welches man dann vielleicht (gegebenenfalls anonym) der Übungsleitung zuschicken kann? Ich denke, dass noch einige über den Bug stolpern werden und das nicht im Sinne des erfinders sein kann... // René!

michi204

01-06-2004, 16:12

Wie die Kollegen schon angemerkt haben: Die EPROG-Klassen haben einen Bug. Statt "End of Input" als gültiges Wortende anzuerkennen (was eigentlich so üblich ist), will die EPROG-Klasse "mehr" haben. Eben zB eine weitere Zahl. Oder einen Zeilenumbruch.!
Welches ASCII-Zeichen ist denn End-of-Input? Also ich habe schon von EOF und EOL gehört, aber noch nie von EOI :D Nein im Ernst: Ich nehme an, du meinst EOF oder? Wenn dem so ist, dann ist es nicht unbedingt ein Bug - die Eprog-Klassen wurden hauptsächlich für die direkte Eingabe konzipiert, und nicht für ein Lesen aus einer Datei. Und auf der Tastatur geben die wenigsten Leute ein EOF ein.

LG Michi

derbrain

01-06-2004, 16:19

hm, ich hab jetzt mal bei den funktionierenden input-files den letzten zeilenvorschub weggelassen, und siehe da: selber fehler. liegt also höchstwahrscheinlich wirklich an den zeilenvorschüben.
was mich wundert ist nur, dass der prozessor gefordert wird. sollte beim warten auf eine eingabe doch im leerlauf sein http://hades.gothic.at/iforum/images/smilies/confused.gif
und das mit dem speicherüberlauf ist auch seltsam. das war eigentlich keine absicht so lange zu warten, hab meistens vorher abgebrochen. nur einmal hab ich mich auf die suche nach dem fehler gemacht während das programm noch lief, und als ich das fenster wieder aufgemacht hab: -> ERROREZ http://hades.gothic.at/iforum/images/smilies/shinner.gif
übrigens arbeite ich unter linux (hab ich das schon gesagt?), kann sein dass es sich unter windows anders verhält.
jedenfalls ist das problem jetzt gelöst und ich habe abgegeben :-)

noch eine bemerkung zum beispiel: hat jemand mal das beispiel "Dreieck (http://eprog.sourceforge.net/eprog/3077/Dreieck.html)" bekommen? dagegen ist das neue beispiel aus der 4. runde ("virus (http://eprog.sourceforge.net/eprog/4114/virus.html)") ein spaziergang...
versucht mal:
1. alle möglichen fälle zu finden und
2. funktionierende testcases auszuarbeiten... http://hades.gothic.at/iforum/images/smilies/shinner.gif

michi204

01-06-2004, 17:04

hm, ich hab jetzt mal bei den funktionierenden input-files den letzten zeilenvorschub weggelassen, und siehe da: selber fehler. liegt also höchstwahrscheinlich wirklich an den zeilenvorschüben.
was mich wundert ist nur, dass der prozessor gefordert wird. sollte beim warten auf eine eingabe doch im leerlauf sein http://hades.gothic.at/iforum/images/smilies/confused.gif
busy waiting nennt man so etwas... wundert mich natürlich ein wenig, dass java bzw. EprogIO das verwendet..

noch eine bemerkung zum beispiel: hat jemand mal das beispiel "Dreieck (http://eprog.sourceforge.net/eprog/3077/Dreieck.html)" bekommen? dagegen ist das neue beispiel aus der 4. runde ("virus (http://eprog.sourceforge.net/eprog/4114/virus.html)") ein spaziergang...
versucht mal:
1. alle möglichen fälle zu finden und
2. funktionierende testcases auszuarbeiten... http://hades.gothic.at/iforum/images/smilies/shinner.gifich hatte irgendwas mit dreiecken.. war nicht gerade mein lieblingsbeispiel :)

lg michi

rck

05-06-2004, 15:30

Welches ASCII-Zeichen ist denn End-of-Input?

Ja gar keines :-) Das ist ja genau der Punkt :D

EOF (ASCII 26?), EOL (\n, \r\n, \r) und dergleichen haben ja alle ihre ASCII-Codes. End-of-Input wiederum glänzt durch Abwesenheit... Und nachdem man Abwesenheit scheinbar nicht so leicht checken kann, hängt dann die EPROG-Klasse.

Zumindest meine Theorie.

In C zB könnte man das ganze mit feof() checken, genau. Andererseits sollte es wurscht sein, ob Eingaben von der Tastatur oder von einer Datei kommen.

rck

05-06-2004, 15:33

busy waiting nennt man so etwas... wundert mich natürlich ein wenig, dass java bzw. EprogIO das verwendet..

Mich täte ja der Sourcecode zur eprog.jar interessieren :-)

michi204

05-06-2004, 18:48

Mich täte ja der Sourcecode zur eprog.jar interessieren :-)
wem geht es da nicht so? ;) aber den werden sie besser hüten als den von windows schätze ich mal.. sonst findet noch wer ein paar exploits.. eigentlich verwerflich, diese security by obscurity... ich bin dafür, den gesamten eprog.jar und eprog-bewertungssystem-sourcecode unter die gpl zu stellen :D

lg michi

nonamenobody

05-06-2004, 19:17

Ich habe irgendwann früher einmal eine per jad dekompilierte Variante der EprogIO gesehen. Was ich mich erinnern kann, war es aber nicht sooo spektakulär.

lg
Philipp

Filz

05-06-2004, 20:32

aber den werden sie besser hüten als den von windows schätze ich mal.. sonst findet noch wer ein paar exploits..

Exploits finden - da wirst du dir ziemlich schwer tun - Die Funktionen in Eprog sind ungefähr so spektakulär:

public static void println(String s)
{
System.out.println(s);
}

public static void printFixedln(double d)
{
DecimalFormat decimalformat = new DecimalFormat("#0.000");
DecimalFormatSymbols decimalformatsymbols = decimalformat.getDecimalFormatSymbols();
decimalformatsymbols.setDecimalSeparator('.');
decimalformat.setDecimalFormatSymbols(decimalforma tsymbols);
System.out.println(decimalformat.format(d));
}

Und das Bewertungssystem funktioniert auch ziemlich ähnlich wie:

java X <input1.in >ueberpruef1.out
und dann einem Dateivergleich mit dem richtigen Ergebnis ... :)

michi204

05-06-2004, 20:38

@filz: war ja nicht ganz ernst gemeint mein posting... :p

und exploits resultieren oft aus den einfachsten codestücken... wenn es auch bei java-programmen nicht so leicht sein wird...

lg michi

rck

05-06-2004, 20:59

ich bin dafür, den gesamten eprog.jar und eprog-bewertungssystem-sourcecode unter die gpl zu stellen :D

Guter Plan :-)

Wobei, das Bewertungsystem, und da schließe ich mich filz an, wird wirklich nicht mehr sein, als ein paar Redirects. Wieso wohl wäre es sonst so pingelig, was zB Groß/Kleinschreibung bei Fehlermeldungen, Zeilenumbrüche etc. angeht?

Blöd halt, dass damit genau die Kollegen frustriert werden, die gerade mit dem Programmieren anfangen und eigentlich eher eine ordentliche Portion Motivation und Erfolgserlebnisse gebrauchen könnten!

Die Eprog.jar hingegen könnte möglicherweise von den Argus-Augen diverser Kollegen, und da möchte ich mich einschließen, profitieren.

rck

05-06-2004, 21:00

Ich habe irgendwann früher einmal eine per jad dekompilierte Variante der EprogIO gesehen.

Kannst Du das irgendwo auftreiben? Vielleicht zahlt es sich ja aus, dann einen Artikel darüber zu schreiben. Bezüglich Pitfalls, etc...

Filz

06-06-2004, 14:04

Kannst Du das irgendwo auftreiben? Vielleicht zahlt es sich ja aus, dann einen Artikel darüber zu schreiben. Bezüglich Pitfalls, etc...
selbermachen geht immer schneller :)

http://kpdus.tripod.com/jad.html#download

rck

06-06-2004, 14:41

selbermachen geht immer schneller :)

http://kpdus.tripod.com/jad.html#download

Das Ding ist ja mördergeil! Verbindlichsten Dank :-)

rck

06-06-2004, 14:43

public static boolean readBoolean()
throws EprogException
{
boolean flag = true;
try
{
flag = readByte() == 0;
}
catch(NumberFormatException numberformatexception)
{
throw new EprogException("Wrong Datatype: Not a Byte");
}
return flag;
}

...offensichtlich darf man nur Booleans übergeben, die auch Bytes sind. Naja.

Also, ich glaube, ich werde da einen Artikel zusammenstellen *ggg*

rck

08-06-2004, 16:09

Also, ich glaube, ich werde da einen Artikel zusammenstellen *ggg*

Habe einen Artikel zusammengestellt (http://www.kiesler.at/article53.html), finde aber nix. Könnts ihr euch das ganze ansehen und eventuelle Ungereimtheiten im Kommentarbereich des Artikels anmerken? Danke // René!

derbrain

10-06-2004, 03:08

Habe einen Artikel zusammengestellt (http://www.kiesler.at/article53.html), finde aber nix. ich schon! *stolzbin*
hab readWord jetzt mal zu einem alleinstehenden (das arme... http://hades.gothic.at/iforum/images/smilies/devil.gif) programm abgeändert und ein paar ausgaben reingetan. und siehe da: bei EOF (oder "End of Input" oder wie auch immer...") liefert println (c) ein fragezeichen!
natürlich steht in c nicht wirklich ein Fragezeichen, das wird nur von println so gemacht. EOF ist nämlich in unicode nicht definiert!!! Ein einfaches Character.isDefined (c) löst das problem! (routine beenden, wenn nicht defined)
wahrscheinlich haben die gehofft, undefinierte zeichen werfen eh eine exception. das aber nicht, sonst wär ja jedesmal abbruch mit fehlermeldung!
übrigens: habs jetzt auch mit input-files der ersten runden probiert, natürlich das selbe problem. allerdings reicht schon ein leerzeichen nachher, man braucht gar keinen zeilenumbruch!
mal schaun was die sagen wenn wir ihnen die lösung präsentieren http://hades.gothic.at/iforum/images/smilies/biggrin.gif

derbrain

15-06-2004, 01:44

@ rck: hast du verbindungen zu den eprog-leuten? hat dus ihnen schon gesagt?

derbrain

17-06-2004, 21:05

hab dem reiter mal ein mail geschrieben. im anhang sollte die verbesserte version von readWord stehn (ist eine methode innerhalbs einer testklasse mit hauptprogramm, die von der EprogIO abgeleitet ist). das .txt hinten sollte gelöscht werden, hab ich angefügt weil das forum kein .java mag http://hades.gothic.at/iforum/images/smilies/rolleyes.gif
zwar steht \uFFFF in unicode für ein undefiniertes zeichen, mit dem man strings abschließen KANN. möglicherweise tun das die meisten (alle?) editoren aber nicht. vielleicht gibts auch mehrere solcher zeichen. der vergleich jedes einzelnen characters mit \uFFFF, wie es im original-readword gemacht wird, funktioniert jedenfalls nicht.
stattdessen kann man aber die Methode Character.isDefined(char c) anwenden und darauf die abfrage aufbauen. http://hades.gothic.at/iforum/images/smilies/thumb.gif

jeuneS2

17-06-2004, 22:04

\uFFFF, besser gesagt -1, wird bei zeichenorientiertem Lesen üblicherweise für EOF verwendet (vgl. getchar() in C) und wird von der lesenden Methode selbst generiert, steht also nicht in der Datei selbst.

Dass readWord() entgegen der eigenen Dokumentation nicht darauf reagiert, ist eine andere Sache und auch der Grund warum noch ein Zeichen nach dem letzten Wort in der Inputdatei stehen muss. Es wäre meiner Meinung nach sinnvoller gewesen, eben diese Tatsache zu bereinigen, als gewisse Zeichen schon im Input zu filtern, weil eine solche Vorgehensweise ein Programm nicht unbedingt "gutmütiger" macht (wer jemals Umlaute in einen 7-Bit Lexer gefüttert hat, weiß wovon ich rede ;) ).