Hello everyone !
I've a little problem. I want to open an ASCII-file in one of my programs
and then edit it. Of course, I did this with TP under MS-DOS, but I don't
have any plan how this works in Linux ?!
Does anyone know what to do ? I just downloaded the bpcompat-packet but
the files don't compile under Linux. (I'm trying to get some of the units into
a Linux-version)
So if someone has a good idea, please help !
Thanks a lot,
Chris
e-mail > chris(a)bockermann.ping.de
…
[View More]____________________________________
(subject "send pgp-key" for pgp-key)
[View Less]
Peter:
>> OK, though (no corruption). The problem does occur with version 5.12, or
^^^^
not
>> with PKunzip. Moreover, the timestamp problem only affects certain files
>Perhaps that's because I zipped these files under Linux with `zip' rather
>than under DOS with `pkzip'. I will have a look at that.
>
Sorry, as you can see, I forgot a "not" before unzip version 5.12 and
…
[View More]pkunzip. These programs work (with the correct timestamp), whereas later
versions of unzip do not, including the currect version, 5.31.
Jesper
[View Less]
Peter:
>> With the 971001 version, I still get the "incompatible pointer type" that
was
>> supposed to be fixed (minor problem, of course),
>
>Strange. I have tried this new GPC on all the test programs I had received
>from you, and everything went through. Could you please send me a fresh
>program that triggers the error?
>
I am sorry for posting INCORRECT information to you and the list. The
"incompatible pointers" problem has indeed been fixed (thanks) in the …
[View More]new
version.
However, in the midst of my confusion about the broken GPC library (and the
timestamp problem which led me to believe for a while that I had downloaded
an old version), I simply failed to notice that I was actually using
incompatible pointers (abusing Pascal and treating it as C), so the warnings
were perfectly in order for that program! The program in my original bug
report compiled OK under the new beta (DJGPP). Thus, now the feature works,
but the bug has been fixed.
Jesper Lund
[View Less]
On Mon, 6 Oct 1997 00:27:19 +0200, Frank Heckenbach wrote:
>
>Bernhard Tschirren wrote:
[...]
>> Var
>> I : Integer;
>> Begin
>> Case I Of
>> 1: WriteLn('One');
>> 2: WriteLn('Two');
>> Else WriteLn('Big');
>>
>> WriteLn('BUG!');
>> End;
>> End.
>
> SP and EP (AFAIK) don't use "else" but
>"otherwise" in a "case" statement, so they don't apply here.
Actually SP doesn'…
[View More]t have an else/otherwise/default/whatever you want to
call it technique for case statements. EP does have an 'otherwise'
feature and my reading of 10206:6.9.3.5 is that like BP's "else" usage,
"otherwise" doesn't require a begin/end for statement sequences either.
Or can someone tell if I am reading it wrong? (Note especially, the
first example)
>(If GPC behaves wrong with "otherwise", that's another thing, I don't know.)
Ironically, gpc doesn't compile it with an "otherwise" in there (at
least with 970714) -- which *would* be a bug (IMO), but I don't think
that is at all what the original poster was getting at.
-Kevin
--
Kevin A. Foss --- kfoss(a)mint.net
--
[View Less]
According to The African Chief:
> I understand that RHIDE was written
> in C/C++, with a port of Turbo Vision to DJGPP. If this is correct,
It is. Borland doesn't allow free distribution of C-TV, but everybody
is allowed to download it directly from Borland. Unfortunately, this
does *not* hold for Pascal-TV, AFAIK. :-(
> is there
> a GPC port of Turbo Vision, or is one being worked on? Can the C version
> somehow be used with GPC?
Certainly it can, but one must re-write …
[View More]each method of each object to
call a C++ method with a rather cryptic AsmName. It will be much easier
to port the Pascal TV to GPC. Having that, we can distribute a `diff',
so all owners of Borland's TV can patch their source to work with GPC.
While I am not an expert on this, I don't think that this violates
Borland's copyright.
*And* it will be easy to port the whole thing to Linux because we can
"steal" the system-dependent stuff from C-TV for Linux. :-)
> Is there a GUI library that is suitable for use
> with GPC?
I am working on one. Planned completion: End of 1996. Estimated
completion: Well ... ??? :-(
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005]
maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]
[View Less]
According to Bernhard Tschirren:
>
> Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous
> 'CASE' bug. Have a go at compiling the sample program below:
>
>
> Var
> I : Integer;
> Begin
> Case I Of
> 1: WriteLn('One');
> 2: WriteLn('Two');
> Else WriteLn('Big');
>
> WriteLn('BUG!');
> End;
> End.
Yes, it writes "Big BUG!" to the screen - at least if I assign a
value not in [ …
[View More]1, 2 ] to I. What's wrong about that?
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [970125]
[View Less]
Bernhard Tschirren wrote:
> Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous
> 'CASE' bug. Have a go at compiling the sample program below:
>
>
> Var
> I : Integer;
> Begin
> Case I Of
> 1: WriteLn('One');
> 2: WriteLn('Two');
> Else WriteLn('Big');
>
> WriteLn('BUG!');
> End;
> End.
>
>
> Now how did that bug get there :) Cya L8r
What bug, please? According to BP, the …
[View More]"else" of a case doesn't require
"begin" and "end" for multiple statements, and that's how GPC behaves.
I think it is OK, since the "else" part is always terminated by the
"case"'s "end", so it's clear how far the else extends, even without
another "begin" and "end". SP and EP (AFAIK) don't use "else" but
"otherwise" in a "case" statement, so they don't apply here.
(If GPC behaves wrong with "otherwise", that's another thing, I don't know.)
Or do you mean anything different? (I was guessing the above from your
indentation since you didn't state the problem.)
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
http://home.pages.de/~fjf/links.htm
[View Less]
Hi, everybody!
(* The dial-in connections to the Uni Essen work again;
you can expect your mail to me answered soon ... *)
I updated the GNU Pascal WWW home site a little and included
links to Lluis' HTML version of the mailing list archives
and to Frank's To-Do list. Please check whether everything
there is correct and/or you like it. (-:
Yours,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~…
[View More]peter.gerwinski/ [971005]
maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]
[View Less]
Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous
'CASE' bug. Have a go at compiling the sample program below:
Var
I : Integer;
Begin
Case I Of
1: WriteLn('One');
2: WriteLn('Two');
Else WriteLn('Big');
WriteLn('BUG!');
End;
End.
Now how did that bug get there :) Cya L8r
________________________ e-mail: bernie(a)icenet.com.au
| _) | | ptschirrenb(a)cc.curtin.edu.au
|___)ernhard |_|…
[View More]schirren tschirre(a)cs.curtin.edu.au
www: www.geocities.com/CollegePark/Quad/8070/
[View Less]
The new GPC BETA (971001) for DJGPP has fixed a lot of bugs. Great work!!
Unfortunately, I found a new bug which only affects badly written programs
(So why did I find it ?!?!? :). 'GOTO' used in a unit crashes the compiler
with a SIGSEGV. Take a look at the code below:
Unit
Goto_U;
Interface
Implementation
Procedure BugProcedure;
Label
BugLabel;
Begin
{$M BEFORE}
Goto BugLabel;
{$M AFTER}
BugLabel:
End;
End.
Cya L8r
…
[View More]________________________ e-mail: bernie(a)icenet.com.au
| _) | | ptschirrenb(a)cc.curtin.edu.au
|___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au
www: www.geocities.com/CollegePark/Quad/8070/
[View Less]