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 also irgendwas muss da doch faul sein

spinnt Java oder EprogIO oder mein PC?
-
-
-
Quote from derbrain
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 inputfiledas hat bei mir damals manchmal probleme verursacht.
hth, lg michi -
Quote from michi204
check mal die zeilenumbrüche in deinem inputfile
das hat bei mir damals manchmal probleme verursacht.
hth, lg michiwü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.
-
Quote from derbrain
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.
Quoteirgendwann 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é!
-
Quote from rck
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 EOINein 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 -
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
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
ü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" bekommen? dagegen ist das neue beispiel aus der 4. runde ("virus") ein spaziergang...
versucht mal:
1. alle möglichen fälle zu finden und
2. funktionierende testcases auszuarbeiten... -
Quote from derbrain
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 seinbusy waiting nennt man so etwas... wundert mich natürlich ein wenig, dass java bzw. EprogIO das verwendet..
Quote from derbrainich hatte irgendwas mit dreiecken.. war nicht gerade mein lieblingsbeispiel
lg michi -
Quote from michi204
Welches ASCII-Zeichen ist denn End-of-Input?
Ja gar keines
Das ist ja genau der Punkt
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.
-
-
Quote from rck
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
lg michi -
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 -
Quote from michi204
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:
Code- 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(decimalformatsymbols);
- 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 ... -
-
Quote from michi204
ich bin dafür, den gesamten eprog.jar und eprog-bewertungssystem-sourcecode unter die gpl zu stellen
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.
-
-
Quote from rck
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 -
Quote from Filz
Das Ding ist ja mördergeil! Verbindlichsten Dank
-
Code
...offensichtlich darf man nur Booleans übergeben, die auch Bytes sind. Naja.
Also, ich glaube, ich werde da einen Artikel zusammenstellen *ggg*
-
Quote from rck
Also, ich glaube, ich werde da einen Artikel zusammenstellen *ggg*
Habe einen Artikel zusammengestellt, finde aber nix. Könnts ihr euch das ganze ansehen und eventuelle Ungereimtheiten im Kommentarbereich des Artikels anmerken? Danke // René!
-
Quote from rck
Habe einen Artikel zusammengestellt, finde aber nix.
ich schon! *stolzbin*
hab readWord jetzt mal zu einem alleinstehenden (das arme...) 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