spinnt Java oder EprogIO oder mein PC?

    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

    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 inputfile ;) das 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 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.

    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.



    Quote

    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é!

    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 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

    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 sein

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

    Quote from derbrain


    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...

    ich 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 :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.

    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 :D

    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

    In summo apud illos honore geometria fuit, itaque nihil mathematicis inlustrius. -- Cicero, Tusculanae disputationes.

    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:


    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 :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.



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


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

    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