Hallo, liebe Leute,
im Anhang sende ich zwei kleine Pascal-Quelltexte, die sich im wesentlichen nur durch eine Prozedur unterscheiden, die der eine Quelltext nicht hat.
Es geht darum, aus einem Array von Dateinamen diese mit einem Zufallsgenerator zu referenzieren.
In dem Programm namens geht.pas funktioniert alles wie gewünscht, nur leider kann ich nicht weiter auf den zufälligen Dateinamen zugreifen, da er nicht als Variable gespeichert ist.
Deshalb habe ich in dem Programm namens gehtNicht.pas den Versuch gestartet, den zufälligen Dateinamen in einer Variablen festzuhalten.
Das funktioniert aber (wie der Programmname schon sagt) nicht richtig: Es werden nämlich völlig unkalkulierbar manchmal die Dateinamen vollständig zurückgegeben, aber manchmal werden am Ende einige Zeichen abgeschnitten.
Damit man das schneller erkennen kann, lassen beide Programme so viele Dateinamen ausgeben.
Kann mir da bitte jemand helfen?
Danke im Voraus und Fröhliche Grüße Roland
Roland Goretzki wrote:
Hallo, liebe Leute,
im Anhang sende ich zwei kleine Pascal-Quelltexte, die sich im wesentlichen nur durch eine Prozedur unterscheiden, die der eine Quelltext nicht hat.
Es geht darum, aus einem Array von Dateinamen diese mit einem Zufallsgenerator zu referenzieren.
In dem Programm namens geht.pas funktioniert alles wie gewünscht, nur leider kann ich nicht weiter auf den zufälligen Dateinamen zugreifen, da er nicht als Variable gespeichert ist.
Deshalb habe ich in dem Programm namens gehtNicht.pas den Versuch gestartet, den zufälligen Dateinamen in einer Variablen festzuhalten.
Das funktioniert aber (wie der Programmname schon sagt) nicht richtig: Es werden nämlich völlig unkalkulierbar manchmal die Dateinamen vollständig zurückgegeben, aber manchmal werden am Ende einige Zeichen abgeschnitten.
Damit man das schneller erkennen kann, lassen beide Programme so viele Dateinamen ausgeben.
Kann mir da bitte jemand helfen?
Sieht aus wie ein Fehler im Compiler.
[P17:~/gpc/testgpc] adriaan% gp geht.pas [P17:~/gpc/testgpc] adriaan% ./geht ../lesenoten/h.png ../lesenoten/e1.png ../lesenoten/c.png ../lesenoten/c.png ../lesenoten/a1.png ../lesenoten/g1.png ../lesenoten/h1.png ../lesenoten/l-c1.png ../lesenoten/f.png ../lesenoten/c2.png ../lesenoten/d1.png ../lesenoten/e1.png ../lesenoten/h1.png ../lesenoten/d1.png ../lesenoten/a.png ../lesenoten/d1.png ../lesenoten/d.png ../lesenoten/g.png ../lesenoten/c2.png ../lesenoten/l-c1.png
../lesenoten/e.png ../lesenoten/a.png ../lesenoten/l-c1.png ../lesenoten/a.png ../lesenoten/d.png ../lesenoten/e1.png ../lesenoten/e1.png ../lesenoten/h.png ../lesenoten/f.png ../lesenoten/d.png ../lesenoten/d.png ../lesenoten/f.png ../lesenoten/e.png ../lesenoten/e1.png ../lesenoten/g.png ../lesenoten/c2.png ../lesenoten/f1.png ../lesenoten/c.png ../lesenoten/h1.png ../lesenoten/e.png
../lesenoten/g.png ../lesenoten/l-c1.png ../lesenoten/a.png ../lesenoten/f.png ../lesenoten/d.png ../lesenoten/f.png ../lesenoten/a1.png ../lesenoten/h1.png ../lesenoten/c2.png ../lesenoten/r-c1.png ../lesenoten/a.png ../lesenoten/g.png ../lesenoten/a.png ../lesenoten/g1.png ../lesenoten/c.png ../lesenoten/g1.png ../lesenoten/h1.png ../lesenoten/h1.png ../lesenoten/a1.png ../lesenoten/a1.png [P17:~/gpc/testgpc] adriaan% gp gehtNicht.pas [P17:~/gpc/testgpc] adriaan% ./gehtNicht ../lesenoten/f.png ../lesenoten/l-c1.p ../lesenoten/r-c1. ../lesenoten/h.png ../lesenoten/e.png ../lesenoten/c2.pn ../lesenoten/f1.pn ../lesenoten/d.png ../lesenoten/h.png ../lesenoten/d.png ../lesenoten/h1.pn ../lesenoten/l-c1. ../lesenoten/d1.pn ../lesenoten/d.png ../lesenoten/f.png ../lesenoten/r-c1.
../lesenoten/f1.pn ../lesenoten/c2.pn ../lesenoten/e.png ../lesenoten/f.png ../lesenoten/f.png ../lesenoten/f.png ../lesenoten/d.png ../lesenoten/h1.png ../lesenoten/l-c1. ../lesenoten/h.png ../lesenoten/a.png ../lesenoten/e1.pn ../lesenoten/a.png ../lesenoten/a.png ../lesenoten/f1.pn ../lesenoten/r-c1.p
../lesenoten/h1.png ../lesenoten/f1.pn ../lesenoten/a.png ../lesenoten/h1.pn ../lesenoten/l-c1. ../lesenoten/d.png ../lesenoten/c.png ../lesenoten/d.png ../lesenoten/e.png ../lesenoten/c.png ../lesenoten/f.png ../lesenoten/c2.png ../lesenoten/c.png ../lesenoten/h1.png ../lesenoten/a1.png ../lesenoten/c.png
[P17:~/gpc/testgpc] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 --with-arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20051116, based on gcc-3.4.5
Met freundlichen Grüssen,
Adriaan van Os
Adriaan van Os dixit:
Roland Goretzki wrote:
Es geht darum, aus einem Array von Dateinamen diese mit einem Zufallsgenerator zu referenzieren.
Dann nimm bitte /dev/urandom… das gibts zumindest auf einer Handvoll mehr Systemen, und /dev/random ist oft für „wirklich wichtige Sachen“ reserviert.
Sieht aus wie ein Fehler im Compiler.
Okay, dann sag ich mal, daß ichs reproduzieren kann:
tg@odem:~ $ gpc -v Reading specs from /usr/lib/gcc/i386-ecce-mirbsd9/3.4.6/specs Configured with: Thread model: single gpc version 20060325, based on gcc-3.4.6 (propolice; gpc; MirOS 09A7)
Ist „nicht ganz vanilla“, aber der gpc-Teil drin ist schon was aktueller als Deiner, Adriaan, darum.
Gruß //mirabile
Hallo Liste, hallo Adrian und Thorsten,
zunächst erst einmal Danke für Eure Antworten! :)
Adriaan van Os dixit:
Roland Goretzki wrote:
Es geht darum, aus einem Array von Dateinamen diese mit einem Zufallsgenerator zu referenzieren.
Dann nimm bitte /dev/urandom??? das gibts zumindest auf einer Handvoll mehr Systemen, und /dev/random ist oft für ???wirklich wichtige Sachen??? reserviert.
Also, wenn das wirklich ein Fehler im Compiler ist, dürfte mir ja urandom auch nicht helfen, da die Fehlerquelle dann wahrscheinlich nicht mit der Wahl des Gerätes beseitigt wird.
Ich hab's trotzdem probiert, und es funktioniert auch mit urandom nicht (beim Programm gehtNicht).
Sieht aus wie ein Fehler im Compiler.
Wenn das so ist, dann sieht es so aus, als wenn ich ein Talent dafür hätte, mit geschlossenen Augen den Finger in nicht gekannte Wunden zu legen. ;-)
(Immerhin habe ich bis gestern - als eigentlicher Nichtprogrammierer - ca. anderthalb Jahre nicht mehr Pascal benutzt, und jetzt gleich sowas!)
Okay, dann sag ich mal, daß ichs reproduzieren kann:
tg@odem:~ $ gpc -v Reading specs from /usr/lib/gcc/i386-ecce-mirbsd9/3.4.6/specs Configured with: Thread model: single gpc version 20060325, based on gcc-3.4.6 (propolice; gpc; MirOS 09A7)
Meiner ist sogar noch älter: gpc version 20040516, based on gcc-3.3.5 (Debian 1:3.3.5-13)
Weiß vielleicht einer von Euch, weshalb es für debian sarge 3.1 kein neueres Paket gibt? (gibt es nämlich nicht, apt-get sagt immer, es sei schon das neueste ...)
Fröhliche Grüße Roland
Roland Goretzki dixit:
Also, wenn das wirklich ein Fehler im Compiler ist, dürfte mir ja urandom auch nicht helfen, da die Fehlerquelle dann wahrscheinlich nicht mit der Wahl des Gerätes beseitigt wird.
Ne, aber /dev/random gibts nicht überall bzw. hat andere Nutzung, während /dev/urandom auf wesentlich mehr Plattformen existiert oder emuliert wird.
Ich hab's trotzdem probiert, und es funktioniert auch mit urandom nicht (beim Programm gehtNicht).
Ja, schon klar.
Weiß vielleicht einer von Euch, weshalb es für debian sarge 3.1 kein neueres Paket gibt?
1. Debian oldstable. 'nuff said. 2. die letzte „volle“ gpc-Release liegt ewig lange zurück… wir benutzen Development-Versionen
Gruß //mirabile
Thorsten Glaser schrieb:
Roland Goretzki dixit:
Also, wenn das wirklich ein Fehler im Compiler ist, dürfte mir ja urandom auch nicht helfen, da die Fehlerquelle dann wahrscheinlich nicht mit der Wahl des GerÀtes beseitigt wird.
Ne, aber /dev/random gibts nicht überall bzw. hat andere Nutzung, während /dev/urandom auf wesentlich mehr Plattformen existiert oder emuliert wird.
Davon abgesehen, sind beide eigentlich nur nötig, wenn "hochqualitativer Zufall" benötigt wird, z.B. für Kryptographie. Für normale Anwendungsfälle (Spiele usw.; ich weiß natürlich nicht, ob das auf dein Programm zutrifft) reicht ein Pseudo-Zufallsgenerator (PRNG). Einen solchen hat GPC (wie die meisten Programmiersprachen) schon eingebaut, und man kann mit "Random (n)" eine ganzzahlige Zufallszahl von 0 bis n - 1 einschließlich erzeugen. In deinem Fall wäre (wenn sinnvoll) also "Random (NotenZahl) + 1" möglich.
Die Vorteile gegenüber /dev/[u]random sind u.a. einfacherer Code, höhere Portabilität (s.o.; GPC verwendet zwar /dev/urandom zur Initialisierung des PRNG wenn vorhanden, sonst aber auch andere Mechanismen, ohne dass sich der Programmierer darum kümmern muss; auch Portabilität zwischen Compilern, da z.B. auch BP und andere Random unterstützen) und schnellerer Code (zum einen muss nicht für jede Zufallszahl eine (Pseudo-)Datei gelesen werden, sondern eben nur einmal bei der ersten Verwendung, zum anderen gegenüber /dev/random, das u.a. auf externe zufällige Ereignisse wartet, um besten Zufall zu erzeugen, was daher eben nur verwendet werden sollte, wenn wirklich nötig, z.B. zur Schlüsselerzeugung).
Den Compiler-Bug muss ich mir mal anschauen ...
Frank
Hallo Liste, hallo Frank,
Du schriebst:
Davon abgesehen, sind beide eigentlich nur nötig, wenn "hochqualitativer Zufall" benötigt wird, z.B. für Kryptographie. Für normale Anwendungsfälle (Spiele usw.; ich weiß natürlich nicht, ob das auf dein Programm zutrifft) reicht ein Pseudo-Zufallsgenerator (PRNG). Einen solchen hat GPC (wie die meisten Programmiersprachen) schon eingebaut, und man kann mit "Random (n)" eine ganzzahlige Zufallszahl von 0 bis n - 1 einschließlich erzeugen. In deinem Fall wäre (wenn sinnvoll) also "Random (NotenZahl) + 1" möglich.
Danke, das werde ich vorläufig benutzen (hatte ich auch früher schon einmal, aber seit /dev/random völlig vergessen ...
Die Vorteile gegenüber /dev/[u]random sind u.a. einfacherer Code, höhere Portabilität (s.o.; GPC verwendet zwar /dev/urandom zur Initialisierung des PRNG wenn vorhanden, sonst aber auch andere Mechanismen, ohne dass sich der Programmierer darum kümmern muss; auch Portabilität zwischen Compilern, da z.B. auch BP und andere Random unterstützen) und schnellerer Code (zum einen muss nicht für jede Zufallszahl eine (Pseudo-)Datei gelesen werden, sondern eben nur einmal bei der ersten Verwendung, zum anderen gegenüber /dev/random, das u.a. auf externe zufällige Ereignisse wartet, um besten Zufall zu erzeugen, was daher eben nur verwendet werden sollte, wenn wirklich nötig, z.B. zur Schlüsselerzeugung).
Wie schon in der anderen E-Mail gesagt, Portabilität spielt in diesem Fall keine Rolle, schnellerer Code weiß ich noch nicht ...
Ein Spiel ist es nicht. Ich hatte nur gedacht, WENN ich schon Zufall benutze, dann so echt wie es überhaupt geht ...
Den Compiler-Bug muss ich mir mal anschauen ...
Dann war meine vielleicht nicht ganz sachgemäße Verwendung von /dev/random ja immerhin zu etwas gut! :-)
Danke und Fröhliche Grüße Roland
Hallo Liste, hallo Thorsten,
Du schriebst:
Also, wenn das wirklich ein Fehler im Compiler ist, dürfte mir ja urandom auch nicht helfen, da die Fehlerquelle dann wahrscheinlich nicht mit der Wahl des Gerätes beseitigt wird.
Ne, aber /dev/random gibts nicht überall bzw. hat andere Nutzung, während /dev/urandom auf wesentlich mehr Plattformen existiert oder emuliert wird.
Okay, hab' ich verstanden. Allerdings spielt die Portabilität bei meinem Programm diesmal überhaupt keine Rolle ...
Weiß vielleicht einer von Euch, weshalb es für debian sarge 3.1 kein neueres Paket gibt?
- Debian oldstable. 'nuff said.
Das verstehe ich nicht. (Wirklich nicht!)
- die letzte ???volle??? gpc-Release liegt ewig lange zurück??? wir benutzen Development-Versionen
Hab' ich vor längerer Zeit auch mal gemacht. Aber wie schon gesagt, ich programmiere nicht sehr häufig ...
Vielleicht werd' ich's aber demnächst doch wieder tun (dev benutzten).
Jedenfalls Danke noch mal!
Fröhliche Grüße Roland
Roland Goretzki schrieb:
Hallo Liste, hallo Thorsten,
Du schriebst:
Also, wenn das wirklich ein Fehler im Compiler ist, dürfte mir ja urandom auch nicht helfen, da die Fehlerquelle dann wahrscheinlich nicht mit der Wahl des Gerätes beseitigt wird.
Nein, es war ein Compiler-Fehler, der bewirkte, dass die linke Seite von String-Zuweisungen zweimal ausgewertet wurde, insbes. die Funktion zweimal aufgerufen wurde (einmal für die String-Länge, einmal für den String-Wert).
Wenn die Funktion beide Male den gleichen Wert liefert, fällt das nicht auf, aber Random-Funktionen (egal welcher Art) sollten dies i.a. nicht tun (na ja, fast immer ... http://xkcd.com/c221.html ;-).
Mit dem folgenden GPC-Patch müsste es gehen (für ältere GPC-Versionen so wie deine; für neuere s. meine Mail in der englischen Liste).
Allerdings spielt die Portabilität bei meinem Programm diesmal überhaupt keine Rolle ...
Diese Aussage hört man leider viel zu oft (zwar meistens in Bezug auf gewisse andere Systeme ...), s. auch:
http://gnu-pascal.org/gpc/Portability-hints.html#Portability%20hints
Frank
-
Adriaan van Os -
Frank Heckenbach -
Roland Goretzki -
Thorsten Glaser