Gpc-de

gpc-de@gnu.de

110 discussions

Zwei Fragen zu LongInt und eine zu String
by Roland Goretzki 24 May '10

24 May '10

Hallo, liebe Leute, 1. Ab welcher Größe muß man eine Zahl als LongInt deklarieren? 2. Wenn ich den Wert von GetMicroSecondTime in einer String-Variablen speichere, ist es dann richtig und sauber, diese String-Variable mit einer Länge von 16 zu deklarieren, weil GetMicroSecondTime für die nächsten über 270 Jahre 16-stellig bleibt? 3. Wie wichtig ist es üerhaupt, die Länge einer String-Variablen möglichst genau anzugeben? In dem speziellen Fall von 2. zumindestens denke ich, daß eine mögliche Fehlerquelle auszuschlossen wird, wenn ich z.B. mit ReadStr diese Variable wieder zu LongInt machen möchte. Danke und Fröhliche Grüße Roland

2 3

StrReadInt
by Roland Goretzki 18 May '10

18 May '10

Hallo, liebe Leute, vor einigen Jahren hatte ich einmal das Problem, Zahlen in Strings zu verwandeln, die Lösung, die mir hier von der Liste nahegelegt wurde, lag in Integer2String. Nun habe ich das umgekehrte Problem, und bevor ich hier unnötig die Liste in Anspruch nehmen wollte, habe ich mich erst einmal auf die Suche gemacht im Verzeichnis "units". Dort fand ich in der unit "stringutils.pas" folgende Funktion: function StrReadInt (const s: String; var i: Integer; var Dest: Integer): Boolean; attribute (ignorable); Das ist sicher genau das, was ich brauche, aber ich verstehe es offenbar nicht, diese Funktion korrekt aufzurufen. Versucht habe ich folgendes: StrReadInt (Leistungs_Zahl [3], Leistung [1]); Wobei "Leistungs_Zahl [3]" das Element aus einem String-Array ist und "Leistung [1]" das Element aus einem Integer-Array. Dabei beschwert er sich über zu wenig (3) Argumente. Ich wollte das String-Element als Integer-Zahl dem 1. Element des Arrays "Leistung" zuweisen. Bei dem Versuch, ein drittes Argument einzufügen (weil ich nicht weiß, was ich da wo eingeben soll, habe ich einfach als hilflosen Versuch noch ein weiteres "Leistung [1]" eingefügt, siehe unten), meckert er zwar überhaupt nicht mehr, aber die Zuweisung findet offensichtlich auch nicht statt. StrReadInt (Leistungs_Zahl [3], Leistung [1], Leistung [1]); Kann mir da bitte jemand einen Tip geben? Danke und Fröhliche Grüße Roland

2 9

Stoppuhr
by Roland Goretzki 07 May '10

07 May '10

Hallo, liebe Leute, ich möchte in ein Programm eine Stoppuhr einbauen, möglichst auch mit Sekundenbruchteilen. Gibt es da schon fertige Prozeduren und/oder Funktionen in irgendwelchen units, oder hat jemand ein paar Tips, wie ich mir so etwas relativ leicht selbst basteln kann? Danke im Voraus für evtl. Antworten! Fröhliche Grüße Roland

3 11

Zeichensalat
by egbert＠seibertz.de 19 Feb '10

19 Feb '10

Moin, Adrian, moin Frank, vielen Dank für Eure Gedanken zu meinem Zeichensatzproblem. Wie es nun letztlich löse weiß ich noch nicht ... Jedenfalls werde ich Eure Anregungen aufnehmen ... Herzlichst Egbert

1 0

Re: Zeichensalat
by Frank Heckenbach 18 Feb '10

18 Feb '10

Adriaan van Os wrote: > egbert(a)seibertz.de wrote: > > Moin Pascaller, > > > > im Rahmen von systemweiten Zeichensatzumstellungen (von > > latin1 auf utf8) funktionieren nun erwartungsgemäß einige > > Pascalprogramme nicht mehr. Teilweise weil Dateinamen > > nicht mehr verstanden werden und teilweise weil Eingaben > > nicht mehr verstanden werden. Oder die Nutzer die Ausgaben > > nur noch erraten können ... > > > > Sehr ärgerlich an utf8 ist, daß durch die variable > > Zeichenlänge der Programmieraufwand für die Erkennung > > überproportional ansteigt. Möglicher Weise wäre utf16 > > (USC2) deutlich einfacher im Aufwand ... > > Nach meiner Meinung ist UTF-16 wohl die slechteste Wahl, weil auch UTF-16 eine Kodierung ist mit > variabeler Länge (<http://en.wikipedia.org/wiki/Utf-16>), obwohl Sie oft nicht als Solches > behandelt wird, was dann wiederum zu Fehlern führt ! Das stimmt, also dann besser gleich UTF-32, das ist wirklich eine 1:1-Codierung, und entspricht auch "wchar_t" (wide char) in C/C++. egbert(a)seibertz.de schrieb: > Nun zur den Fragen: > > A hat jemand vielleicht schon eine (gut funktionierende) > Codeumsetzung von zB utf8 nach latin1 (und umgekehrt) > (besser (zukunftsicherer) wäre nach utf16 oder utf32) > geschrieben die man allen (!) Aus- und Eingabeoperationen > voransetzen kann (also nicht eine Funktion, die bei jedem > Schreiben oder Lesen im Programm explizit aufgerufen > werden muß)? > Gff: Wie aktiviert man das? Ich habe nichts in fertiger Form. Mein Ansatz wäre: - UTF-8 <-> UTF-32, also die Codierung der Zeichensequenzen (reine Rechnerei, unabhängig von der Bedeutung der Zeichen) - UTF-32 <-> Latin1 ist dann trivial, da Latin1 per Definition eine Teilmenge (0 .. 255) von UTF-32 ist, d.h. man muss nur überlegen, was man mit höheren Zeichen macht (wegwerfen, Fehler oder teilweise umsetzen). Interessant könnte auch Latin9 sein, das sich von Latin1 nur in ein paar Zeichen (v.a. Euro-Zeichen) unterscheidet. Diese muss man dann allerdings von Hand umsetzen (z.B. Euro: $20ac in Unicode, $a4 in Latin9). Das beides würde ich als eigenständige Funktionen schreiben, die man immer mal wieder brauchen kann. - Um die Funktionen automatisch in Ein-/Ausgabe einzubinden, gibt es jedenfalls für Textdateien eine GPC-spezifische Lösung, nämlich AssignTFDD ("Text File Device Driver"). Das ist etwas low-level, man muss mit Funktionszeigern und Buffern hantieren. Als Beispiel s. z.B. AssignDos in dosunix.pas (das ist für automatische CR/LF-Umwandlungen zwischen Dos- und Unix-Textdateien). Prinzipiell könnte man so auch UTF-Umwandlung implementieren. > B gibt es eine einfache Möglichkeit dem GPC zu sagen, daß > strings nun nicht mehr aus Feldern von char zu 8bit, > sondern aus char zu 16bit bestehen? Wobei ich nicht alles > händisch umschreiben möchte (Das Problem betrifft eben > sehr viele Programme, die mit deutschsprachigen Wörtern > umgehen können müssen ...). Zurzeit leider nicht, alle String-Operationen sind fest auf 8-Bit-"Char" eingestellt. Im Zuge von größeren Änderungen in GPC könnte man das irgendwann unterstützen, aber nicht auf die Schnelle. Ich habe mir in letzter Zeit ein paar Gedanken über mögliche größere GPC-Änderungen in der Zukunft gemacht (die weit über Unicode hinausgehen), und werde vermutlich in ein paar Wochen in der englischen Liste etwas dazu schreiben. Aber wie gesagt, für eine kurzfristige Lösung ist das nicht interessant. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Zeichensalat
by egbert＠seibertz.de 17 Feb '10

17 Feb '10

Moin Pascaller, im Rahmen von systemweiten Zeichensatzumstellungen (von latin1 auf utf8) funktionieren nun erwartungsgemäß einige Pascalprogramme nicht mehr. Teilweise weil Dateinamen nicht mehr verstanden werden und teilweise weil Eingaben nicht mehr verstanden werden. Oder die Nutzer die Ausgaben nur noch erraten können ... Sehr ärgerlich an utf8 ist, daß durch die variable Zeichenlänge der Programmieraufwand für die Erkennung überproportional ansteigt. Möglicher Weise wäre utf16 (USC2) deutlich einfacher im Aufwand ... Nun zur den Fragen: A hat jemand vielleicht schon eine (gut funktionierende) Codeumsetzung von zB utf8 nach latin1 (und umgekehrt) (besser (zukunftsicherer) wäre nach utf16 oder utf32) geschrieben die man allen (!) Aus- und Eingabeoperationen voransetzen kann (also nicht eine Funktion, die bei jedem Schreiben oder Lesen im Programm explizit aufgerufen werden muß)? Gff: Wie aktiviert man das? B gibt es eine einfache Möglichkeit dem GPC zu sagen, daß strings nun nicht mehr aus Feldern von char zu 8bit, sondern aus char zu 16bit bestehen? Wobei ich nicht alles händisch umschreiben möchte (Das Problem betrifft eben sehr viele Programme, die mit deutschsprachigen Wörtern umgehen können müssen ...). Neben den einfachen Ein-/Ausgabefuktionen betrifft das Problem natürlich Strukturen wie :=Wort[10] oder CASE OF ... Wie erwähnt würde mir utf16 erstmal am besten gefallen. Dank im Voraus! Grüße EGBERT

1 0

Veralteter Kern
by Egbert Seibertz 04 Jul '08

04 Jul '08

Liebe Pascaller, ich hab' ein kleines CGI in PASCAL geschrieben und der gpc hat's mir übersetzt: # P -static Weisel_Zucht.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgpc.a(rts.o): In function `_p_CGetPwEnt': /usr/src/tarfiles/DL/gcc/gcc-3.3.4/gcc/p/rts/rts.c:2563: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking von diesen Warnungen gibt's noch mehr ... local läuft das Programm und macht was es soll ... hier läuft: 2.6.23.14-e3 #1 PREEMPT vom Februar # ldd $(which WZ) linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb7eae000) libc.so.6 => /lib/libc.so.6 (0xb7d66000) /lib/ld-linux.so.2 (0xb7ef5000) auf dem http-Sever läuft: 2.4.22-e17 #3 SMP von vor fünf Jahren ... da sagt mir der Rechner: # WZ FATAL: kernel too old Speicherzugriffsfehler es gibt: /lib/libm.so.6 /lib/libc.so.6 /lib/ld-linux.so.2 linux-gate ist wohl ein dummy, ihn gibt es weder lokal noch remote ... Wie bekomme ich das Programm doch noch auf dem anderen System zum Laufen (ohne das ferne System zu erneuern)? Jeder Hinweis ist mir sehr willkommen! Grüße Egbert

2 4

Warum geht es nicht mit einer Variablen?
by Roland Goretzki 06 Mar '07

06 Mar '07

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

4 8

WikiBook-Projekt: Gnu-Pascal in Beispielen
by Eike Lange 24 Nov '05

24 Nov '05

Hallo zusammen! Das ursprünglich von mir geschriebene Buch über GNU-Pascal liegt jetzt als Wikibook auf http://de.wikibooks.org/wiki/GNU-Pascal_in_Beispielen. Es wird nun noch leichter, Fehler auszumerzen, dafür schwerer, eine druckbare Version zu erhalten. Insgesamt denke ich, dass die Vorteile einer Online-ausgabe überwiegen. Eike

1 0

SQLite3 Unit
by Eike Lange 25 Oct '05

25 Oct '05

Hi Leute! SQLite3 (http://www.sqlite.org/) ist eine Datenbankengine in einer einzelnen Datei, also ohne den Client/Server-Kram, den andere Datenbanksysteme so anbieten. SQLite3 ist klein, wendig und ausserdem gibt es ein GNU-Pascal Interface für sie ;-) Die SQLite3-Unit kann unter http://www.gnu-pascal.de/contrib/eike/sqlite3-gpc-20051025.tar.gz besichtigt werden. Eike

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Gpc-de