[fpc-pascal] Linux : Using SDL with GTK2 ?
Hi, I'm desperately trying to build a application mixing GTK with SDL for *Linux*. I know that's not always recommended as it involves 2 listening loops but it should work. I found some *C* snippets/applications (eg making window hacks) but I'm unable to translate them into Pascal.My goal is to display Joystick events into a GTK2 window. Ideally I would like to use Jedi-SDL with GTK2. Of course either GTK2 or SDL used alone works fine.Does anyone have some example to achieve this ? Else do you think is it possible to use threads and listen from them to grab Joystick events and then update GTK GUI ?If yes does anyone have some example ? Else I'm ready to use anything else than Jedi-SDL as long as it can work with GTK (assembler ? C libraries ?...). Any suggestion ? Thanks for help.Tom Message sent using UebiMiau 2.7.8 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC + GTK2 : Using variable into a Widget name ?
Hi,
I use FPC with GTK2 and I have the following problem :
In a loop with I'd like to be able to use the indice (incremented integer)
on the name of widget to perform some actions.
Here is an example :
var
pFSImage01, pFSImage02, pFSImage03 : PGtkWidget;
...
For I:=1 to 3 do
begin
pFSImage0#I# := gtk_image_new_from_file('./mypix.jpg');
gtk_fixed_put(pGTKFIXED(pFSFixed), pGTKWIDGET(pFSImage0#I#) , 100*I,
20);
gtk_widget_show(pFSImage0#I#);
end;
So I'd like any #I# above are remplaced with the real I value. This would
considerably improve/reduce my code.
But I'm able to achieve this. Does anyone know ?
Thanks.
Tom
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Shared library with resources which contain bitmaps on Linux -- second try
> With version 2.3.1, you can try the new support for resources, > and it should work "out of the box". How can you obtain 2.3.1? I cannot find it in the repository... BR Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Shared library with resources which contain bitmaps on Linux -- second try
On Tue, 24 Jun 2008, Tom Carly wrote: > > With version 2.3.1, you can try the new support for resources, > > and it should work "out of the box". > > How can you obtain 2.3.1? I cannot find it in the repository... > You can get 2.3.1 only from subversion. I don't see it in the repository, the last release that is in there is 2_2_2. Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Strange Floating Point Exception problem
I have an application (for optimizing decisions in the dice game Yahtzee)
that uses Real and runs well with FPC on Mac OS X (PPC), but that
fails with a Floating Point Exception (FPE) under Windows (FPC 2.2.0).
What makes things complicated, is that the program has a GUI
through Lazarus, and that it is rather biggish, making it difficult
to isolate the problem.
The place where it complains is a simple statement
if x < 0.0 then
where x = -1 exactly. It happens inside a recursive function.
When I have the values of x printed (in bit form: sign, biased exponent,
fractional part), this is what I get:
Computing all choices for optimal Yahtzee strategy ...
OptExpectedScore(123456TFHSLYC;63-): x = 1 011
0
OptExpectedScore(_23456TFHSLYC;63-): x = 1 011
0
OptExpectedScore(__3456TFHSLYC;63-): x = 1 011
0
OptExpectedScore(___456TFHSLYC;63-): x = 1 011
0
OptExpectedScore(56TFHSLYC;63-): x = 1 011
0
OptExpectedScore(_6TFHSLYC;63-): x = 1 011
0
OptExpectedScore(__TFHSLYC;33-): x = 1 011
0
OptExpectedScore(___FHSLYC;33-): x = 1 011
0
This means that the if statement is passed 7 times without problem with
x = -1, and on the 8th pass, where x = -1 again, it bails out with an FPE.
How can I get more details about the exception?
What could be causing this?
When I use an ordinary write statement to print the value of x,
it also bombs out on the 8th pass.
Note that x is actually a field in a record stored in a high-dimensional
array that is dynamically allocated, accessed through a with statement.
Using various levels of optimization does not matter.
I am at a loss here,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Strange Floating Point Exception problem
On Sat, Aug 23, 2008 at 12:20:48AM +0200, Tom Verhoeff wrote: > I have an application (for optimizing decisions in the dice game Yahtzee) > that uses Real and runs well with FPC on Mac OS X (PPC), but that > fails with a Floating Point Exception (FPE) under Windows (FPC 2.2.0). I "played" around some more to resolve this problem. It now _seems_ to work, after suppressing all FPU exceptions through SetExceptionMask in unit Math. This is hardly satisfactory, since the place where the program got interrupted (viz. if x < 0) cannot cause an exception, as far as I can tell, since x is confirmed to equal -1 at that point. So, the program now runs (but might misbehave). I'll keep you posted. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Hudson and fpc
Hi, Does anyone of you have experience with integrating fpcunit test reporting in Hudson (or another continous integration server)? I can't find anything on the internet but I cannot believe that I would be the first one to try this. Is there maybe a simple change to one of the existing Hudson plugins to do this? Thanks in advance, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best method to uninstall fpc and lazarus
On Tue, Sep 02, 2008 at 10:08:36AM +0100, Jonas Maebe wrote: > > On 02 Sep 2008, at 09:05, Paul wrote: > >> I want to uninstall and reinstall fpc and lazurus. >> My current installation is useless. >> I found the steps on Wiki, but I used the docs on Wiki to install them >> and it totally went wrong. > > The uninstall steps on the wiki at > http://wiki.freepascal.org/OS_X_Programming_Tips#Uninstalling_Lazarus_and_Free_Pascal > > are correct. I just went over them and changed them so they are by > default for FPC 2.2.2. Make sure you also remove the .lazarus directory > in your home directory as described at the end. I guess most of your > problems are related to that one in fact. What about /etc/fpc.cfg? I don't see it mentioned in the uninstall. Is that location a legacy of older versions? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Speed difference between intel/ppc on intel Mac
I have an Intel-based MacBook Pro. Until recently, I still used a PowerPC version of FPC. PowerPC code on this machine runs through (invisible) emulation. However, I upgraded now to FPC 2.2.2 for Intel on mac. And to my surprise one of my time-consuming apps is twice slower, instead of faster. The PowerPC version took 95 minutes, the Intel version takes 195 minutes. This is on exactly the same machine, some OS. It could be a compiler options issue. But I tried to compile the Intel version for fastest code (no checking, etc.). Is there a way to see what options fpc actually uses (i.e. to find out which options are in effect, e.g. useful when both configuration file and command line options are being used)? The app does not use floating point operations. Anyone else have the same experience? Any suggestions? Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] License question; unit to view floating-point details
I have a created a unit FloatView to help you inspect in detail 32-bit
(Single) and 64-bit (Double) IEEE 754 floating-point values (in case
"every bit counts; note that when floating-point numbers are output in
decimal, some information is inevitably lost).
I would like to contribute this unit, and offer it for further integration
into FreePascal.
What would I need to do to release it under the same license as
other FreePascal libraries?
Would there be any interest in incorporating it?
Here are the supported operations (for Single; a similar set exists
for Double):
function SingleToStrBits ( const x: Single ): String;
{ returns string with bits for sign, biased exponent, and fraction }
function SingleToStrBinary ( const x: Single ): String;
{ returns string with binary scientific representation of x:
NaN, +/-Infinity, +/-B.B___Bd+/-E, where
'B' is a bit, 'd' stands for '*2^' and 'E' is the exponent in decimal }
function PowerOf2Single ( const x: Single; n: Integer ): Single;
{ returns x * 2 ^ n }
procedure FlipBitSingle ( var x: Single; i: BitIndexSingle );
{ flips bit i of x }
function SuccSingle ( const x: Single): Single;
{ returns successor of x }
function PredSingle ( const x: Single): Single;
{ returns predecessor of x }
Best regards,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] License question; unit to view floating-point details
On Sat, Sep 06, 2008 at 11:28:52PM +0200, Marco van de Voort wrote: > In our previous episode, Florian Klaempfl said: > > > Would there be any interest in incorporating it? > > > > If it's endian safe and if there are tests, I propose to incoperate it > > in math. > > The "Tostring" stuff should go into sysutils or strutils. There are also some constants and (conversion) types shared by the mathematical operations and ToString operations. Where would they go? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] License question; unit to view floating-point details
On Sat, Sep 06, 2008 at 09:31:02PM +0200, Florian Klaempfl wrote: >> >> What would I need to do to release it under the same license as >> other FreePascal libraries? > > Post the sources somewhere using the license header we use? I intend to do just that. I was considering the use of plain GPL, rather than LGPL. However, I wonder if that would interfere with the incorporation into FreePascal. Is it the case that all FPC libraries use (a variant of) LGPL? I am willing to use that license, but if GPL is an option, I would prefer that. >> Would there be any interest in incorporating it? > > If it's endian safe and if there are tests, I propose to incoperate it > in math. The old version initially was not, and the next version resolved that through conditional compilation. It used a set-of construct to access the bits of floating-point numbers. The current version is safe on most "reasonable" processors. Let me explain. I use 32-bit (Cardinal) and 64-bit (QWord) integers to access the bits of Single/Double values. The IEEE 754 standard format for floating-point numbers was specifically designed to allow the use of some integer operations on the representation to implement some floating-point operations, because this gives an opportunity to save on hardware. In particular, succ and pred on the floating-point number bit pattern _interpreted_as_integer_ will yield the next larger/smaller floating-point number. Therefore, I believe that my current implemenation is endian-safe on processors that exploit the IEEE 754 standard wisely. In particular, I tested it on Intel and PowerPC (which have opposite endianness; though PowerPC can switch endianness). The unit comes with a separate test driver. There are also some examples. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] License question; unit to view floating-point details
On Sun, Sep 07, 2008 at 07:53:06AM -0300, Felipe Monteiro de Carvalho wrote:
> I would suggest to put this routines in a new unit, to keep the
> existing base units small and clean.
How about naming them FloatUtils?
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] License question; unit to view floating-point details
On Sun, Sep 07, 2008 at 12:44:13PM +0200, Marco van de Voort wrote: > > > > > > Post the sources somewhere using the license header we use? I made the source available as a Contributed Unit using a modified LGPL. You can find a zip archive here: <http://www.win.tue.nl/~wstomv/software/float-view/> as well as individual files (float-view.zip and float-view-1_0.zip are links to the same file). For some reason, when I go there, it does not show the README.txt, but is is there: <http://www.win.tue.nl/~wstomv/software/float-view/README.txt> Feel free to incorporate it in the RTL. Best regards, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Install FPC/Lazarus for Win CE
On Wed, Sep 10, 2008 at 05:24:06PM +0200, Paul wrote: > > No, installed FPC/Lazarus on my iMac, but there are problems with it. > Appearantly, I'm not the only one, I've seen problems with it on the > mac-pascal list too. > On Mac OS X 10.5, I can't start Lazarus (OS-error : You can't start > lazzarus.app - it's not supported by this architecture) You probably tried the wrong lazarus.app (single z :-). I was misled there as well, or I had a wrong installation. Anyway, the lazarus.app that I found did not work. After throwing everything away, and reinstalling fpc, fpcsrc, lazarus, it did work. The Carbon version from www.hu.freepascal.org/lazarus installs lazarus into /usr/local/share/lazarus. In a Terminal window you can type open /usr/local/share/share/lazarus.app Once Lazarus runs, you can keep it in the Dock (click on its icon, and hold to see that option), and next time start it from there (you no longer need to open Terminal). Best regards, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Question: range checking for string indexing
Can someone confirm what range checking FreePascal does (if enabled) when indexing a string. I imagine shortstrings and ansistrings are handled differently, but cannot find this in the documentation. It looks like the following: String Type Range Checked for s[i] --- -- s: ShortString 0 <= i <= 255 s: AnsiString 1 <= i <= Length(s) I am surprised that for ShortString, the range is not also 1 <= i <= Length(s). IIRC Turbo Pascal only allowed you to access s[0] when range checking was off, and similarly for s[i] with i > Length(s). Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question: range checking for string indexing
On Wed, Oct 29, 2008 at 09:58:10PM +0100, Vinzent Höfler wrote: > Tom Verhoeff wrote: > >> I am surprised that for ShortString, the range is not >> also 1 <= i <= Length(s). >> >> IIRC Turbo Pascal only allowed you to access s[0] when range checking >> was off, and similarly for s[i] with i > Length(s). > > No. See transcript: That looks rather convincing. > Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland International However, IIRC there were some differences between Borland Pascal and Turbo Pascal (as it was named before they marketed it as Borland Pascal). But my memory may be confusing this with UCSD Pascal (Oh, those days :-). If find it more important that the rules are clear, than that a specific behavior is provided. Nevertheless, this means that AnsiStrings and ShortStrings are slightly more different than suggested in the documentation. AnsiString provide more protection with range checking (also implying that a program that works will with range checking and ShortStrings, might fail when using AnsiStrings, even though those are more flexible). In what way can this information be incorporated into the documentation? Where should it go? Can I generate a patch for that? Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] writing to shared memory
Hi, I have the example code working to write and read string to shared memory. I'd like to write and read other things than strings (integers, Booleans, ...) to the shared memory. For writing strings, you use strpcopy. Which functions can be used for other types? I was thinking of memcpy but that doesn't seem to exist under freepascal. Thx, Tom Carly ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] order of unit tests
On Sun, Dec 07, 2008 at 11:10:19AM +0100, Marc Santhoff wrote:
>
> How could I solve this problem in a better way?
By using SetUp and TearDown routines.
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, Mar 20, 2009 at 09:34:54AM +0200, Graeme Geldenhuys wrote: > > I know that to find the documentation for Free Pascal, I have to go to... > >http://www.freepascal.org/docs.var > > ...not the most intuitive URL. > Most users would try the following without browsing the website (most > other website work like this). > > http://www.freepascal.org/docs/ > http://docs.freepascal.org Personally, I just go to the relevant home page and expect a naviation link with anchor text Documentation. For FPC that exists (and works :-). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] sending signal to child process
Hi, I have a process A that starts another process B (with TProcess.Create). I introduced signal handling for SIGHUP, SIGTERM and SIGINT in process A and process B. The signal handling of process A triggers a call to "fpkill(processA.processid, SIGTERM)" (or "processA.Terminate(0)"). This code is executed when killing process A. The problem is that the signal handling code of process B is not executed when killing process A (although process B does get killed). If I launch process B separately and kill it, then the signal handling code of process B is executed. It seems that the signal that is sent from process A to process B is not the same as when you kill it via the command line. Does anyone have an idea how to solve this? Thanks! Best regards, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] sending signal to child process
Hi, I found that the problem is coming from the fact that I use process.Options := ProcessB.Options + [poUsePipes]; If I switch that off, process B does execute the signal handling code. Is this a bug or am I missing something? Thx, Tom -Original Message- From: fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Henry Vermaak Sent: maandag 30 maart 2009 16:37 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] sending signal to child process 2009/3/30 Tom Carly : > Hi, > > > > I have a process A that starts another process B (with TProcess.Create). > > I introduced signal handling for SIGHUP, SIGTERM and SIGINT in process A and > process B. > > The signal handling of process A triggers a call to > "fpkill(processA.processid, SIGTERM)" (or "processA.Terminate(0)"). do you mean processB.processid here? > > This code is executed when killing process A. > > The problem is that the signal handling code of process B is not executed > when killing process A (although process B does get killed). > > If I launch process B separately and kill it, then the signal handling code > of process B is executed. It seems that the signal that is sent from process > A to process B is not the same as when you kill it via the command line. are the permissions the same for the two processes? are you sending sigterm from the commandline, too? i've done something similar before, but using a different signal. that shouldn't matter, since sigterm can be blocked (unlike sigkill and sigstop). henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sparse matrix storage method
On Mon, Jun 08, 2009 at 03:28:50PM -0400, Alain Michaud wrote:
>
>would someone know of a procedure for solving a system of linear
> equations using a SPARSE MATRIX storage model.
>
> if one uses the usual: array [1..1;1..1] of "mostly_zeroes" then
> this is a really big waist of memory.
>
> I am thinking of using: Tlist instead, but I would not like to reinvent
> the wheel! I would apreciate if someone could give me a tip.
Alain,
I have attached a program (matrix.pas) to compare a full matrix against
a sparse matrix implementation (using singly linked lists with pointers)
for multiplication time. The surprising thing for me was that (back then
in 1995), the turnover point is at about 75% of nonzero (i.e. 25% zero)
elements (see mat-out.txt). This was actually a programming assignment
for our second-year students.
Note, however, that compring storage needs to be done carefully
because of the overhead in pointers and indexes.
The program is written in Turbo Pascal, but it should not be hard
to run it using FPC.
Best regards,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
Random Matrix2 a2:
. 0.08908 . 0.37243
.. 0.12135 .
.. 0.78422 .
. 0.19221 ..
Random Matrix1 a1 = a2:
0.0 0.08908 0.0 0.37243
0.0 0.0 0.12135 0.0
0.0 0.0 0.78422 0.0
0.0 0.19221 0.0 0.0
b1 = a1 * a1:
0.0 0.07159 0.01081 0.0
0.0 0.0 0.09516 0.0
0.0 0.0 0.61501 0.0
0.0 0.0 0.02332 0.0
b2 = a2 * a2:
. 0.07159 0.01081 .
.. 0.09516 .
.. 0.61501 .
.. 0.02332 .
Multiplication of random 100 x 100 Matrix1
% nonzero time in s
- -
0.00 3.30
20.00 3.63
40.00 4.29
60.00 5.49
80.00 7.19
100.00 9.39
Multiplication of random 100 x 100 Matrix2
% nonzero time in s
- -
0.00 0.00
20.00 0.71
40.00 2.31
60.00 4.45
80.00 7.58
100.00 11.26
Search turnover between 0.00% and 100.00%
Fraction = 50.00%, Mult2 takes 3.25s, Mult1 takes 4.83s
Turnover between 25.00% and 100.00%
Fraction = 62.50%, Mult2 takes 4.84s, Mult1 takes 5.71s
Turnover between 43.75% and 100.00%
Fraction = 71.88%, Mult2 takes 6.21s, Mult1 takes 6.48s
Turnover between 57.81% and 100.00%
Fraction = 78.91%, Mult2 takes 7.31s, Mult1 takes 7.14s
Turnover between 57.81% and 89.45%
Fraction = 73.63%, Mult2 takes 6.37s, Mult1 takes 6.59s
Turnover between 65.72% and 89.45%
Fraction = 77.59%, Mult2 takes 7.04s, Mult1 takes 6.92s
Turnover between 65.72% and 83.52%
Fraction = 74.62%, Mult2 takes 6.54s, Mult1 takes 6.70s
Turnover between 70.17% and 83.52%
Fraction = 76.85%, Mult2 takes 7.03s, Mult1 takes 6.92s
Turnover between 70.17% and 80.18%
Fraction = 75.18%, Mult2 takes 6.59s, Mult1 takes 6.70s
Turnover between 72.67% and 80.18%
Fraction = 76.43%, Mult2 takes 6.81s, Mult1 takes 6.81s
Turnover between 72.67% and 78.31%
Fraction = 75.49%, Mult2 takes 6.76s, Mult1 takes 6.81s
Turnover between 74.08% and 78.31%
program MatrixMultCompare;
{ Tom Verhoeff, Eindhoven University of Technology, Dept. of Math/CS,
October 1995, Version 2.0 }
{ Purpose: Compare two implementations of (sparse) matrix type, especially
w.r.t. multiplication time }
uses Timers;
type
EntryType = real;
const
Zero: EntryType = 0.0;
const
MaxN = 100; { SizeOf(EntryType) * sqr(MaxN) <= 64 KB, i.e. MaxN < 105 }
var
N: 0..MaxN;
type
Index = 0..MaxN-1; { intended 0..N-1 }
Vector1 = array [Index] of EntryType;
Matrix1 = array [Index] of Vector1;
Matrix1P = ^Matrix1; { too overcome Turbo Pascal size limitation }
Vector2 = ^Vector2Rec;
Vector2Rec = record
vix: Index; { N.B. it is not necessary to introduce upperbound here }
val: EntryType;
vnext: Vector2;
end;
{ Vector2.v == v --vnext-> nil /\ increasing in vix /\ val <> Zero }
{ [[v]].i = "if v --vnext-> w /\ w^.vix = i then w^.val else Zero"
for 0 <= i < N }
Matrix2 = ^Matrix2Rec;
Matrix2Rec = record
mix: Index;
vec: Vector2;
mnext: Matrix2;
end;
{ Matrix2.m == m --mnext-> nil /\ sorted on mix /\ vec <> nil }
{ [[v]].i = "if m --mnext-> p /\ p^.mix = i then [[p^.vec]]
else Zero-vector" for 0 <= i < N }
type
Fraction = real; { Fraction.a = 0 <= a <= 1 }
procedure WriteEntry(e: EntryType);
begin
write(e:9:5)
end; { W
[fpc-pascal] If an Assert fails in constructor, then destructor called (?)
While tracing a nasty bug (?), I discovered the hard way that when
an Assert is done in a constructor, and it fails, then the destructor
(Destroy) is automatically called.
However, because the constructor failed, the object did not satisfy the
class invariants.
So, the destructor needs to be pessimistic about the state.
Mine was not.
Since the Assert in the constructor is there to protect against
parameter values that do not statisfy the constructor's precondition,
there are no additional dynamic veriables and objects created, and
hence they need not be destroyed.
How can the destructor know that it is called in such a state?
Below is a simple example to illustrate the problem.
My destructor assumed that the class invariants hold, and it uses some
of the class methods to aid in tearing down the object. Except
that the object does not exist if the destructor gets called because
of the failed Assert in the constructor.
A painful lesson in Design By Contract...
Is there any place in the documentation, where one can find about
this implicit call of the destructor? Should it be added?
The program below writes
FAIL: Raised unexpected exception Access violation
which is raised in the destructor, after the EAssertionFailed excpetion
is raised in the constructor.
When uncommenting the if statement in the destructor, it writes:
OK: Raised EAssertionFailedTRing.Create pre failed: n = -1
(assert_in_constructor.pas, line 44)
In that case, one needs to rely on the fact that fields in a class get
initialized in a predefined way, e.g. pointers are set to nil.
Best regards,
Tom Verhoeff
--
program Assert_in_constructor;
{$Mode Delphi}
{$Assertions on}
uses
SysUtils, Classes;
type
PCell = ^ TCell;
TCell = record // singly linked list of integers
FData: Integer;
FNext: PCell;
end;
TRing = class ( TObject )
private
FList: PCell; // the elements in the ring
// Invariants:
// NonEmpty: FList <> nil;
// IsRing: repeated application of ^.FNext to FList leads to FList,
// i.e., the last cell points to the head cell
// Unique: all p^.FData for p: PCell appearing in FList are different
public
constructor Create ( n: Integer );
{ pre: 0 < n; post: ring consists of 0 through n-1 }
function IsSingleton: Boolean;
function Current: Integer;
procedure Step;
procedure RemoveSuccessor;
{ pre: not IsSingleton }
destructor Destroy; override;
end;
constructor TRing.Create ( n: Integer );
var
i: Integer;
q: PCell; // points to last cell, with FData = i-1
begin
inherited Create;
Assert ( 0 < n,
Format ( 'TRing.Create pre failed: n = %D', [ n ] ) );
New(FList);
q := FList;
q^.FData := 0;
i := 1;
while i <> n do begin
New ( q^.FNext );
q := q^.FNext;
q^.FData := i;
Inc ( i );
end;
q^.FNext := FList; // ring closed
end;
function TRing.IsSingleton: Boolean;
begin
Result := FList^.FNext = FList;
end;
function TRing.Current: Integer;
begin
Result := FList^.FData;
end;
procedure TRing.Step;
begin
FList := FList^.FNext;
end;
procedure TRing.RemoveSuccessor;
var
q: PCell; // cell to be removed
begin
q := FList^.FNext;
FList^.FNext := q^.FNext; // q unlinked
Dispose ( q );
end;
destructor TRing.Destroy;
begin
//if FList <> nil then
while not IsSingleton do RemoveSuccessor;
Dispose ( FList );
inherited Destroy;
end;
var
v: TRing;
begin
try
v := TRing.Create ( -1 );
writeln ( 'FAIL: Should have raised EAssertionFailed' );
except
on e : EAssertionFailed do begin
writeln ( 'OK: Raised EAssertionFailed' + e.Message )
end;
on e : Exception do begin
writeln ( 'FAIL: Raised unexpected exception ' + e.Message )
end
else
writeln ( 'FAIL: Raised an unrecognized exception' )
end; { try }
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] If an Assert fails in constructor, then destructor called (?)
On Tue, Jun 30, 2009 at 07:58:47PM +0100, Inoussa OUEDRAOGO wrote: > 2009/6/29 Tom Verhoeff : > > While tracing a nasty bug (?), I discovered the hard way that when > > an Assert is done in a constructor, and it fails, then the destructor > > (Destroy) is automatically called. > > Indeed, when an exception is raised in the constructor, be it an > "assert" exception or not, the destructor is called to allow the > developer to clean up the "in-construction" instance's members he has > already initialized. A colleague of mine pointed out that the Delphi 7 documentation for TObject.Create actually says so (see final Note): Constructs an object and initializes its data before the object is first used. Delphi syntax: constructor Create; Description Create constructs an object. The purpose, size, and behavior of objects differ greatly. The Create constructor defined by TObject allocates memory but does not initialize data. Descendant objects usually define a constructor that creates the particular kind of object and initializes its data. Note: If an exception escapes from a constructor, the object's destructor is called to clean up the failed instance. Zoiets zou ook in de TObject.Create (RTL) doc. van FreePascal passen (lees: thuishoren). > > of the class methods to aid in tearing down the object. Except > > that the object does not exist if the destructor gets called because > > of the failed Assert in the constructor. > > Wrong. The object _does exists_ : its memory has been allocated and > zeroed. With regard to the compiler/RTL, at the constructor entry > point, the instance is valid. Please remember that the compiler is not > aware of _your_ class invariants. My apologies; it exists "technically" but may be "invalid" (i.e. not a usable object, "semantically"). > Other important point : Object Pascal instance construction is not > done the same way as in C++ where the object is completely constructed > at the end of the constructor. In Object Pascal it is even valid to > call virtual methods in the constructor, that is possible because at > the constructor entry point the instance actual type is definitely > fixed. Thanks for the additional information. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] If an Assert fails in constructor, then destructor called (?)
On Wed, Jul 01, 2009 at 01:15:29PM +0200, Michael Van Canneyt wrote: > On Wed, 1 Jul 2009, Tom Verhoeff wrote: >> >> Zoiets zou ook in de TObject.Create (RTL) doc. van FreePascal passen >> (lees: thuishoren). > > For non-dutch speakers: It says that this kind of information should > be included in the FPC documentation. I will do so. But in my opinion, > it does not belong in the unit reference documentation, but in the language > documentation. My apologies for the Dutch part (I got interrupted when writing the message). The translation is OK :-) I have looked in the Language Reference Guide to see where it would be appropriate to include this information. Section 6.2 is about Class instantiation, using a constructor. I have no idea how the exception mechanism in constructors is actually implemented. Does it have anything to do with TObject, or is it completely independent of that? I did not find a discussion about the distinctions between the various kinds of methods (function, procedure, constructor, destructor). They are just named (syntactically) in 6.3.1 Classes > Methods > Declaration. In particular, the issue concerns both constructors as well as the destructor. For constructors it is important to realize what the consequences will be when they are interrupted with an exception. For destructors it is important to keep in mind what one may or may not assume when they are called. Best regards, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Profiller for Mac OS X
On Wed, Sep 02, 2009 at 06:20:17PM -0300, Felipe Monteiro de Carvalho wrote:
>
> Is anyone using a profiler in Mac OS X? I am trying to detect if there
> are memory leaks.
>
> gprof doesn't seam to work and valgrind doesn't seams usable from
> their readme, so I tryed "Sampler" from the Developers dir, but the
> application runs and after it nothing appears in the tables.
Why not just use unit heaptrc?
<http://www.freepascal.org/docs-html/rtl/heaptrc/>
Quoted from that page:
The HEAPTRC unit can be used to debug your memory
allocation/deallocation. It keeps track of the calls to
getmem/freemem, and, implicitly, of New/Dispose statements.
When the program exits, or when you request it explicitly. It
displays the total memory used, and then dumps a list of blocks
that were allocated but not freed. It also displays where the
memory was allocated.
If there are any inconsistencies, such as memory blocks being
allocated or freed twice, or a memory block that is released
but with wrong size, this will be displayed also.
The information that is stored/displayed can be customized using
some constants.
Works very well.
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero: EDivByZero and EZeroDivide
On Sat, Oct 17, 2009 at 01:57:28PM +0200, Bart wrote: > > Is there a reason why in fpc both floating point and integer division > by zero raise an EDivByZero exception? > > See: http://docwiki.embarcadero.com/VCL/en/SysUtils.EZeroDivide > > SysUtils.EZeroDivide exception is raised when an application attempts > to divide a floating-point value by zero. > Note: Integer divide-by-zero errors raise the SysUtils.EDivByZero exception. It would be nicer if one had the ability to make floating-point division by zero return an IEEE 754 plus/minus infinity, without raising an exception. This is e.g. useful when one needs to evaluate rational functions. Without such an infinity, you need to make a nasty case analysis, which furthermore depends on the rational function. A simple example is the situation where one needs to calculate the replacement resistor value R for parallel resistors having values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 + ... + 1/Rk). The formula gives a divide-by-zero if one of the resistors has value 0. But in that case, the replacement value R also equals 0. When allowing infinities, it just works out fine (infinity + x = infinity, 1/infty = 0). That is precisely why IEEE 754 has infinities. Also see <http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf> for other examples and further motivation. Unfortunately, many compilers still do not fully support the IEEE 754 floating-point standard. Best regards, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero: EDivByZero and EZeroDivide
On Sun, Oct 18, 2009 at 02:49:40PM -0200, Jorge Aldo G. de F. Junior wrote: > Wouldnt a NaN (Not a number) be more "matematically correct" result (I saw > that on an old book about i387) No, read Kahan's article that I pointed to. > Matematically division by zero is an "mathematical impossibility", so NaN > would be more logical There are situations (that occur e.g. in numerical approximations of mathematical models in physics) where division by zero is a well-defined infinity. For that reason, the IEEE 754 floating-point standard has distinct plus zero, minus zero, plus infinity, and minus infinity. There are precise (and useful) rules to calculate with these special numbers. They are not NaNs. Many processors fully support the IEEE 754 standard, but many compilers don't. Partial support of the standard in the compiler makes the standard much less useful. In our department, especially the numericists disliked (the old) Pascal because of the fixed array sizes and the lack of good support for floating-point arithmetic (i.e. IEEE 754 since 1985). I guess few (Free)Pascal users nowadays come from the numerical/scientific computing community. Another (longish) "must read" about floating-point: David Goldberg. "What Every Computer Scientist Should Know about Floating-Point Arithmetic". <http://www.validlab.com/goldberg/paper.ps> Note that IEEE Std 754 was revised in 2008, see e.g. <http://en.wikipedia.org/wiki/IEEE_754-2008> Best regards, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero: EDivByZero and EZeroDivide
On Mon, Oct 19, 2009 at 10:21:01AM +0200, Jonas Maebe wrote:
>
> On 18 Oct 2009, at 17:52, Tom Verhoeff wrote:
>
>> It would be nicer if one had the ability to make floating-point
>> division
>> by zero return an IEEE 754 plus/minus infinity, without raising an
>> exception.
>
> http://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
>
> Fully cross-platform, even.
How new is that?
It works 'partly'. Consider the program
program DivideByZero;
{ to see whether division by zero can result in Infinite values }
uses Math;
var one, zero, result: Double;
begin
SetExceptionMask ( [ exZeroDivide{, exPrecision} ] );
one := 1.0;
zero := 0.0;
result := one / zero;
writeln ( result ); { Expected output: +Inf }
result := one / result;
writeln ( result ); { Expected output: +0.0 }
end.
Outputs:
+Inf
An unhandled exception occurred at $60B0 :
EDivByZero : Division by zero
$60B0
$5850
$0001889B
In order to allow 1 / +Inf, you also need to mask exPrecision
(i.e. uncomment it from the set passed to SetExceptionMask).
I am surprised that division by an Infinity raises EDivByZero: Division by zero
Best regards,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero: EDivByZero and EZeroDivide
On Mon, Oct 19, 2009 at 02:57:10PM -0300, Gustavo Enrique Jimenez wrote: > 2009/10/18 Tom Verhoeff : > > A simple example is the situation where one needs to calculate > > the replacement resistor value R for parallel resistors having > > values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 + ... + 1/Rk). > > The formula gives a divide-by-zero if one of the resistors has value 0. > > But in that case, the replacement value R also equals 0. When allowing > > infinities, it just works out fine (infinity + x = infinity, 1/infty = 0). > > That is precisely why IEEE 754 has infinities. Also see > > > > <http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf> > > > > for other examples and further motivation. > > Mmm... the formula R = 1/(1/R1 + 1/R2 + ... + 1/Rk) is only valid if > none of Rn=0. > Programmers can and must take care of that situation. No, that is just the point. The "easy" formula is actually not not correct for zero resistors when adopting classical evaluation rules. However, it works out fine with infinities. Take the case of two resistors 1/(1/R1 + 1/R2) = R1 R2 / (R1 + R2) The left-hand side is continuous at R1=0 and at R2=0, but strictly speaking not defined in those points. The formula on the right is the same for R1, R2 not zero and it does not have a problem at R1=0 or R2=0 (unless R1=R2=0). For more than two resistors, rewriting as in the right-hand side is (practically) out of the question, but the same holds. Point is that for such rational functions, the use of infinities is well-defined and works well. Numericists want to evaluate the left-hand side, rather than doing a case analysis or rewriting it. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero: EDivByZero and EZeroDivide
On Mon, Oct 19, 2009 at 11:20:50PM +0100, Frank Peelo wrote: > Gustavo Enrique Jimenez wrote: >> 2009/10/18 Tom Verhoeff : >>> A simple example is the situation where one needs to calculate >>> the replacement resistor value R for parallel resistors having >>> values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 + ... + 1/Rk). >>> The formula gives a divide-by-zero if one of the resistors has value 0. >>> But in that case, the replacement value R also equals 0. When allowing >>> infinities, it just works out fine (infinity + x = infinity, 1/infty = 0). >>> That is precisely why IEEE 754 has infinities. Also see >>> >>><http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf> >>> >>> for other examples and further motivation. >> >> Mmm... the formula R = 1/(1/R1 + 1/R2 + ... + 1/Rk) is only valid if >> none of Rn=0. >> Programmers can and must take care of that situation. > > Agree: treating 1/0 as you would treat a finite number makes me feel > uncomfortable. See for instance > http://www.cocoa.uk.com/?p=63 One final comment here. The field of scientific computing, including numerical methods, is a specialism by itself, and there are many misunderstandings about it. Respected experts from this field (including William Kahan) have developed a floating-point standard and have been able to convince hardware builders to implement this standard in their (co)processors. Compiler writers would do well to trust those experts, especially if they do not understand them. So, yes 1/0 is not a finite number, but a (signed) infinity: 1/+0 = +Inf, 1/-0 = -Inf. Yes, there are two 0s among the floating-point numbers, and they are all well-behaved, and some operators work (1 + +Inf = +Inf), and others do not (+Inf + -Inf is undefined). With good reasons. Not everybody needs to be a floating-point expert, but compiler users that do know about this, would want to use the IEEE 754 standard, because it makes life so much simpler for them. That may be the reason why FORTRAN is still used in scientific computing (robust numerical libraries and good support in the compiler; but otherwise not a language I can like). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] mysql query
Hi, I'm using TMySQL50Connection and TSQLQuery to do a query on a mysql server. Is there a way that you can set a timeout on a query so that it also automatically kills the mysql process after the timeout and doesn't keep loading the mysql server? Thanks, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Remote FreePascal compile service, feedback requested
We (still) use FreePascal quite a bit in our first/second-year education, in particular, in , our Programming Education And Contest Hosting verification system. I was thinking of adding a remote FreePascal service along the following lines. You go to its web interface, browse for your source files (possibly a whole zip archive) on your local machine, enter command-line options, and let our server compile your stuff with a (selectable) version of fpc (under Linux), then you get back the results (possibly also in a zip archive). Mabye we can support cross compiles as well. Why do this? Because that way people can use/try FreePascal without installing anything. Furthermore, we plan to support several versions of FreePascal in parallel. That way, it may also be useful to the FreePascal community. E.g. when diagnosing a problem. Here are some questions: 1. Do you think this service would be useful? 2. Do you think the interface described above is good enough? Suggestions for refinements would be appreciated. 3. Are there any security risks that we may have overlooked? Of course, we will impose certain limitation to avoid resource hogging. But maybe there are ways to put together a malicious source file that makes the compiler misbehave ... 4. Whatever else comes to your mind ... Best regards, Tom Verhoeff -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Remote FreePascal compile service, feedback requested
On Mon, Dec 05, 2005 at 01:55:29PM +0100, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > > >Don't make all distributed units available, and forbid the use of some > >units. You don't want people opening an FTP socket and download 24G on > >your machine. > > I think it only compiles things, and does not execute them. Correct. It is compile only, without execution of the resulting binary. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Remote FreePascal compile service, feedback requested
On Mon, Dec 05, 2005 at 04:54:25PM +0100, Michael Van Canneyt wrote: > > I would also add the possibility to upload a zip file with some units. > Processing a single unit is not useful for evaluation, and having to > upload all units manually is tedious and error-prone. That is the intention (as indicated in my original message): > ... You go to its web interface, browse for your source files > (possibly a whole zip archive) on your local machine, enter command-line > options, ... Thanks for all the useful comments, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Remote FreePascal compile service, feedback requested
On Mon, Dec 05, 2005 at 10:03:58AM -0500, Tony Pelton wrote: > On 12/5/05, Tom Verhoeff <[EMAIL PROTECTED]> wrote: > > Why do this? Because that way people can use/try FreePascal without > > installing anything. > > installing really isn't too complicated currently. > > download a tarball, expand it, and run the compiler ? > > i can't imagine having to fiddle around with some webapp is going to > be any simpler than that. However, I wouldn't want to install the latest version from svn when I encounter a bug in the stable release. > > Furthermore, we plan to support several versions of FreePascal in > > parallel. That way, it may also be useful to the FreePascal community. > > E.g. when diagnosing a problem. > > i suspect anyone who is "diagnosing" anything to this detail is going > to want to have their versions/tools locally so that can see what is > going on. I was more thinking of being in need of getting some code running (by using a newer fpc version through the web), or confirming that your does/did compile properly with version x (on platform y). Of course, you don't need to use the remote service if you have your own solution. I would certainly encourage people to install their own local version of fpc (e.g. by having a download link on the web interface and a link to the install FAQ). The idea is that (a) it might lower the threshold for people new to fpc to give it a try; (b) to make some older/newer version of fpc easily accessible; (c) to make it easier to get started on cross compiling (though I suspect we will encounter some issues here, but I trust that these are solvable with help from the mailing lists). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
On Sat, Jan 21, 2006 at 07:07:39PM +0100, Olle Raab wrote: > 06-01-19 13.05, skrev Jonas Maebe följande: > > > > > On 19 jan 2006, at 11:51, L505 wrote: > > > >> From the FPC ReadLn sources I was under the impression that the Mac > >> used #13 for line > >> feeds and unix used #10 for line feeds, but I've heard that > >> sometimes certain unix > >> systems used #13. > > > > Mac OS 9 and below used #13. Mac OS X, with it's unix/bsd heritage, > > uses #10. > > But one should be aware of that a mac user, using Mac OS X might run classic > Mac OS programs, in the classic environmant, which produces #13 files. Even when you work in Mac OS X native, there are situations where you end up with #13 files. E.g. when using BBEdit and the default is set at Mac files, or when you use an (s)ftp connection with automatic text translation (depending on preference settings). I get bitten by this too often. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Floating-point number representation on various platforms
While writing a paper (several years ago) about the traps of using
floating-point numbers, I prepared a unit FloatView to "play" with
the internal representation according to the IEEE Std, including
to print it in various formats.
Initially, I made this work for the Linux/i386 platform only. Later,
I tweaked it for Mac OS X (different byte order). It supports only the
IEEE Std Single and Double format (not Extended).
I would like to make this unit available, but hesitate, because of
its platform dependence (and currently limited platform support).
Question 1: Is there an interest in such a unit?
Question 2: Any suggestions as to how to make it more platform independent,
or how to support multiple platforms in an easy way?
Looking forward to some feedback,
Tom Verhoeff
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating-point number representation on various platforms
On Sun, Feb 05, 2006 at 01:39:25PM +0100, Jonas Maebe wrote:
>
> On 05 Feb 2006, at 13:32, Tom Verhoeff wrote:
>
> >Question 2: Any suggestions as to how to make it more platform
> >independent,
> >or how to support multiple platforms in an easy way?
>
> The only differences are little/big endian. So if it works on PPC and
> I386, you have support for all platforms. Just use {$ifdef
> FPC_LITTLE_ENDIAN}
[This is about IEEE floating-point numbers]
Two further questions.
Which platforms use which endian? (Of course, I could just experiment,
or maybe even read the FPC source, but asking is simpler. :-)
When I looked at my code again, it seems to me that the change that I made
to support both PPC and I386 is not endian-related, but I may be wrong,
or it may be more complicated.
So, here are some pieces of the code, it uses a variant array to
access the bits of the IEEE floating-point numbers in Single and Double:
-
interface
const
SignIndexSingle =31; { position of sign bit in single format }
ExpSizeSingle = 8; { size of exponent field in single format }
MaxExpSingle= 255;
ExpBiasSingle = 127;
EminSingle = 1 - ExpBiasSingle;
EmaxSingle = MaxExpSingle - 1 - ExpBiasSingle;
FracSizeSingle =23; { size of fraction field in single format }
type
BitIndexSingle = 0 .. SignIndexSingle;
ConvertSingle = record
case Boolean of
False: ( d: Single )
; True : ( s: set of BitIndexSingle ) { i in s == bit i = 1 }
end;
procedure WriteBitsSingle ( const x: Single );
procedure WriteBinarySingle ( const x: Single );
function PowerOf2Single ( const x: Single; n: Integer ): Single;
const
SignIndexDouble =63; { position of sign bit in double format }
ExpSizeDouble =11; { size of exponent field in double format }
MaxExpDouble= 2047;
ExpBiasDouble = 1023;
EminDouble = 1 - ExpBiasDouble;
EmaxDouble = MaxExpSingle - 1 - ExpBiasDouble;
FracSizeDouble =52; { size of fraction field in double format }
type
BitIndexDouble = 0 .. SignIndexDouble;
ConvertDouble = record
case Boolean of
False: ( d: Double )
; True : ( s: set of BitIndexDouble ) { i in s == bit i = 1 }
end;
procedure WriteBitsDouble ( const x: Double );
procedure WriteBinaryDouble ( const x: Double );
procedure FlipBitDouble ( var x: Double; i: BitIndexDouble );
function PowerOf2Double ( const x: Double; n: Integer ): Double;
-
It turns out that my code for the Single type works on both PPC
and I386 without change. However for Double, I had to write e.g.
-
procedure WriteBitsDouble ( const x: Double );
var c: ConvertDouble; i, i_: BitIndexDouble;
begin
with c do begin
d := x
; for i := SignIndexDouble downto 0 do begin
{$IFDEF CPUPOWERPC}
i_ := (i + 32) mod 64
{$ENDIF}
{$IFDEF CPUI386}
i_ := i
{$ENDIF}
; if i_ in s then write ( '1' )
else write ( '0' )
; if i in [ SignIndexDouble, SignIndexDouble - ExpSizeDouble ] then
write ( ' ' )
end { for i }
end { with c }
end; { WriteBitsDouble }
-
That is, the lower and upper 32 bits (4 bytes) got swapped.
Maybe this is the case because both the 64-bit set and the Double
get allocated differently depending on endianess?
Can someone enlighten me?
Thanks,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating-point number representation on various platforms
On Sat, Feb 18, 2006 at 09:43:31AM +0100, Tom Verhoeff wrote: > > So, here are some pieces of the code, it uses a variant array to > access the bits of the IEEE floating-point numbers in Single and Double: That should be 'record' insteady of 'array', of course. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] When are used units recompiled?
In a programming course that I teach, some students are using Lazarus+FPC
instead of Delphi. I made available two precompiled units, that is, the
*.ppu and *.o files. However, when the students tried to compile their
programs using these units, the compiler complained that it could not
find the *.pas files. When compiling with -va (verbose all), it became
apparent that the compiler disliked something about the *.ppu files.
(Sorry, I didn't get the exact message from the students.)
Can someone explain to me under what circumstances FPC will (attempt to)
recompile a unit for which *.ppu and *.o are already available?
I couldn't find this in the documentation.
Versions: I used FPC 2.0.1 to compile the units; the students
used FPC 2.0.2 to compiler their programs.
Thanks,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (more details)
On Wed, Apr 05, 2006 at 01:27:04PM +0200, Jonas Maebe wrote: > > On 5 apr 2006, at 13:22, Tom Verhoeff wrote: > > >In a programming course that I teach, some students are using > >Lazarus+FPC > >instead of Delphi. I made available two precompiled units, that > >is, the > >*.ppu and *.o files. However, when the students tried to compile > >their > >programs using these units, the compiler complained that it could not > >find the *.pas files. When compiling with -va (verbose all), it > >became > >apparent that the compiler disliked something about the *.ppu files. > >(Sorry, I didn't get the exact message from the students.) > > Without the exact message it's hard to tell. Here are the relevant lines from -vaa (but -vu would have provided that as well): Unitsearch: Fig0.ppu Searching file Fig0.ppu... found PPU Loading Fig0.ppu (FIG0) PPU Name: Fig0.ppu (FIG0) PPU Source: Fig0.pas not found (FIG0) Recompiling Fig0, checksum changed for System The target OS is correct (I have made that mistake before, and the resulting error message is clear). The message "checksum changed for System" is not so clear. Now that I think of it (especially with System capitalized), it seems to imply that the compiled unit (Fig0.ppu) depends on the unit System, and when the unit System accessible by the compiler when finding Fig0.ppu differs from the checksum of the unit System used to compile Fig0.ppu, it triggers an automatic recompile of the unit begin loaded. It would certainly have helped me if the word "unit" was prepended to "System". Furthermore, the checksum did not "change" (there are two separate contexts; neither of which changed), but it differs from the one used to compile the unit being loaded. Thus, a better message might be: "checksum of current unit System differs from the one used to compile unit Fig0.ppu", or "unit Fig0.ppu was compiled with an incompatible System unit". > >Can someone explain to me under what circumstances FPC will > >(attempt to) > >recompile a unit for which *.ppu and *.o are already available? > >I couldn't find this in the documentation. Apparently, there is a dependency on the System unit, and incompatibility between System units can cause a recompile. Any other such dependencies? Is every separately compiled unit dependent on System? If not, under what circumstances will it depend on System? And on what other units? > There are lots of possible reasons. The main ones are > > 1) sources with the same name as those used in a unit are found, and > they are more recent than the ppu files This was not the case. > 2) incompatible ppu files because the internal structure changed and > the internal version number was increased Also this was not the case (the message would have been clearer). > Cause 1) can be solved by compiling using the -Ur switch. Good point. I will certainly do that in the future. > >Versions: I used FPC 2.0.1 to compile the units; the students > >used FPC 2.0.2 to compiler their programs. > > It's quite possible that your 2.0.1 uses a different ppu format than > the 2.0.2 release. That sounds rather vague. From my analysis above, it seems that updating your System unit will invalidate all (?) precompiled units (at least the ones that somehow "depend" on it). Or am I missing something here? Well, I did learn something. I hope it was useful for others as well. Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (wiki page added)
On Thu, Apr 06, 2006 at 08:18:28AM +0200, Peter Vreman wrote: > > Apparently, there is a dependency on the System unit, and incompatibility > > between System units can cause a recompile. Any other such dependencies? > > Is every separately compiled unit dependent on System? If not, under > > what circumstances will it depend on System? And on what other units? > > Units and programs always depend on System. It is the main unit where all > the basic types are defined. I have added a page titled "Releasing units without source code" to the FreePascal Wiki (look under FPC). I (once more) propose to improve the message when the compiler attempts to recompile a unit because of an incompatible System unit, i.e. the message "Recompiling ..., checksum changed for System": It would certainly have helped me if the word "unit" was prepended to "System". Furthermore, the checksum did not "change" (there are two separate contexts; neither of which changed), but it differs from the one used to compile the unit being loaded. Thus, a better message might be: "checksum of current unit System differs from the one used to compile unit Fig0.ppu", or "unit Fig0.ppu was compiled with an incompatible System unit". Note: The two contexts are: * the compiler installation of the provider of the compiled unit * the compiler installation of the user of the compiled unit Should I put this message-improvement request in the bug reporter? > > That sounds rather vague. From my analysis above, it seems that updating > > your System unit will invalidate all (?) precompiled units (at least > > the ones that somehow "depend" on it). Or am I missing something here? > > You are correct. That is the reason why it is recommended to use the > stable releases. This raises the concern that precompiled units become obsolete when the user of such a unit upgrades the compiler. The compiler apparently requires that the System unit of the precompiled unit and of the using program are IDENTICAL (which is enforced by the somewhat weaker check of comparing their checksums; but in practice that will have the same effect). Thus, there is NO "backward compatibility". I would hope that IF the newer System unit provides at least the services of (and possibly more/better services than) the System unit used for compiling the provided unit, THEN the "by-now-aged" precompiled unit can still be used without having its sources. In the current situation, the provider of a precompiled unit needs to publish *.ppu and *.o files for ALL 'relevant' System units (and Target OSs, of course). This makes it much less attractive to release units without source code. That may be understandable from an open-source perspective, but in teaching I find it useful or even necessary to provide units without source code. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (wiki page added)
On Thu, Apr 06, 2006 at 11:04:02PM +0200, Jonas Maebe wrote: > > On 6 apr 2006, at 22:59, Tom Verhoeff wrote: > > >This raises the concern that precompiled units become obsolete when > >the user of such a unit upgrades the compiler. The compiler > >apparently > >requires that the System unit of the precompiled unit and of the using > >program are IDENTICAL (which is enforced by the somewhat weaker check > >of comparing their checksums; but in practice that will have the same > >effect). > > The checksum is only calculated on the interface (i.e. all exported > symbols), it's not a generic binary checksum of the entire unit. OK. I didn't know that, and haven't found it in the documentation (or have I missed it?). I have updated the wiki page accordingly. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (wiki page added)
On Fri, Apr 07, 2006 at 10:24:59AM +0200, Peter Vreman wrote: > > There is nothing different compared with TP / Delphi. The internal PPU > format is made for speed and contains direct references from one PPU to > another PPU. Incompatible PPUs can therefor never be used together. I could not find any of this in the documentation, but I may have looked in the wrong places. Of course, I am not reading TP / Delphi doc when using FPC :-). > The release of closed source PPUs need to be done on a per stable release. > Just like with delphi and tp7. > > So please don't make a big issue out of this, the situation is still the > same as it was for the last 20+ years. Except that there were fewer releases/platforms to cope with, when using TP or Delphi. I just happened to be bitten by it in an unexpected way. If it is properly documented, then there is no issue. I have tried to remedy that by creating the wiki page on relasing units without source code. It could be helpful if an FPC developer checks that page: <http://www.freepascal.org/wiki/index.php/Releasing_units_without_source_code> It might be useful to include a bit in the User's Manual as well (updated Section 3.3 on Compiling a unit). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (wiki page added)
On Fri, Apr 07, 2006 at 01:25:52PM +0200, Michael Van Canneyt wrote: > > On Fri, 7 Apr 2006, Tom Verhoeff wrote: > > >I just happened to be bitten by it in an unexpected way. If it is > >properly documented, then there is no issue. I have tried to remedy > >that by creating the wiki page on relasing units without source code. > >It could be helpful if an FPC developer checks that page: > > > ><http://www.freepascal.org/wiki/index.php/Releasing_units_without_source_code> > >It might be useful to include a bit in the User's Manual as well > >(updated Section 3.3 on Compiling a unit). > > You note somewhere that: > > "(The User's Manual is not up to date on this topic, I believe. > If you know more details, e.g. from which version on this > changed, then please put it here.)" > > Can you tell me what you mean by this ? The current on-line User's Guide (HTML version), at the end of Section 3.3 (Compiling a unit), contains the paragraph: The compiler produces lowercase files, so your unit will be found, even if your source file has uppercase letters in it. Only when the compiler tries to recompile the unit, it will not find your source because of the uppercase letters. I don't believe this is any longer the case. But I don't know for what version of the compiler this stopped to be a necessity. At some version, the compiler started preserving the casing of the source file in the generated *.ppu and *.o files. It would be good to state explicitly in the User's Guide to what versions of the compiler the paragraph applies, and to add an explanation of what the situation is with newer versions. It wouldn't hurt to point in Section 3.3 to the compiler option -Ur. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When are used units recompiled? (wiki page added)
On Sun, Apr 09, 2006 at 10:58:09PM +0200, Giovanni Premuda wrote: > Tom Verhoeff ha scritto: > >This makes it much less attractive to release units without source > >code. That may be understandable from an open-source perspective, > >but in teaching I find it useful or even necessary to provide units > >without source code. > > > IN TEACHING? Why this shouting and bafflement? Here are two reasons: * In order to teach students to use services (=units) solely based on the contract (= specification), we withhold the implementation and only provide the compiled unit. That way the implementation cannot be consulted (=abused). * In some cases, the unit incorporates some "secrets", e.g. related to grading. Consider e.g. an assignment where one has to develop an algorithm for finding the median of an odd number of distinct integers by using only a binary comparison operator. To enforce the use of only binary comparisons, we don't give them the set directly, but rather give them a unit, which "hides" the actual integers and provides the comparison operator. Of course, this hidden set can be made inaccessible from the outside by putting it in the implementation part. In that case, it might seem harmless to give away the source code. However, there are more complications: e.g. where does the actual set come from? It is not built into the unit, but read from a file, or generated via a random generator with a seed read from a file. The data in the file is scrambled so that the students cannot simply read it and abuse that information. Unless you want to use sophisticated encryption techniques, it is easier to use a "proprietary" method and not give them the source code. In fact, the unit need not have a set of numbers to start with, but could construct a "worst case" scenario base on the actual sequence of operations carried out by the program (a so-called adversary). We don't want to give away the strategy of the adversary algorithm. > Btw. no sane commercial Delphi developer has ever considered using a > component without source code at least since Delphi 2.0. Look at the > offering of component vendors and you will see that they invariably > offer source code licenses. Most likely because the 'compatibility mechanism' is not very effective. Compatibility is one of the big problems in component-based development. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set format
On Tue, Nov 14, 2006 at 11:47:37AM +0100, Jonas Maebe wrote: > > I have a quick question: are there (m)any people here who store/load > sets to/from files? I do not mix sets and files, but I do mix sets and Single/Double in a record to decompose floating point numbers. However, I don't see a big problem in converting my unit to accommodate a different internal set representation. (It might even simplify matters for me.) > The reason is that we are considering to change the internal format > of sets in FPC on big endian machines. The reason is that this would > be necessary to allow byte-packing of sets (so that e.g. a set of > 0..63 would only occupy 1 byte as opposed to 4 like is currently the > case). An added advantage would be that this would make gdb (the > debugger used by Xcode) display sets correctly on PowerPC's and other > big endian machines. > > I'm afraid this may cause backward compatibility problems, but if not > too many people store sets in binary files, that fear is unfounded. I would think that in general the advantages you describe outweigh the disadvantages. For purposes of converting between one representation and the other, it might be nice to provide a means to declare "old"sets, which use the current representation, _alongside_ the new sets, which use the improved representation. Then it would be fairly straightforward to write a conversion program that reads in the old format and writes out the new format. Thanks for enquiring, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
On Tue, Feb 20, 2007 at 02:00:27PM +0100, Daniël Mantione wrote: > > Op Tue, 20 Feb 2007, schreef [EMAIL PROTECTED]: > > > In the ACM-ICPC International Collegiate Programming Contest dropped pascal > > for this year final competitions and for next year, the students are not > > allowed to use pascal as their programming language. Did you know this? What > > is your idea? Also, in TopCoder site, you can not develop your programs with > > Pascal while as I know, Pascal has all the properties that C++ or JAVA have. > > > > Any idea? Is there any technical problem with Pascal to be used in > > TopCoder's > > contest? > > I saw this coming for a few years. Free Pascal has most definately been > able to delay this for a few years, it was the de facto standard in > competitions in recent years. But the trend was there. When I > participated myself the amount of people using Pascal was in decline, > usually in the end it were two teams of 50 or so who used Pascal. I have been ICPC "Super Regional Director" for Europe for a number of years around the year 2000 (in 1999 we hosted the World Finals in Eindhoven). As a member of the ICPC Steering Committee I have always lobbied for Pascal. (But I must say that I have never been able to fully grasp the operation of this Steering Committee.) > Note that only the *requirement* to offer a Pascal environment has been > scrapped, organisers of contests can still provide it if they want. So, > please lobby at the contest organisation for a Pascal environment. This is very true. What is also very important, practically, is having Pascal supporters and experts on the "jury" (both of Regional Contests and the World Finals). > The only fix here is to strengthen our position in education. Most people > today participate in Java, which is silly as it puts you in a clear > disadvantage. ... Again, very true. But this will not be easy (discussion should continue in another thread)... > In short, Pascal still rocks in contests. One thing is very important: > a rock solid text mode IDE under both Windows and Linux. This makes a > difference in a contest. FPC has never been able to live up to the Turbo > Pascal level here. I'd say especially the IDE in Linux was only useable > for people knowledged with FPC to work around the limitations. Once again, a sore point, indeed. The IDE is an issue, especially for "beginners". Personally, I have been very happy to use vi(m) under contest conditions. > Perhaps we should ask Tom Verhoeff, he is very involved in the icpc's. Tom used to be very involved. I had to make a choice, and after the World Finals in 1999, I decided to focus on the International Olympiad in Informatics (IOI: for high school students). I am no longer in the ICPC Steering Committee, though I have been on the jury of the North-West European Regional Contest in 2005 and 2006. In the IOI, Pascal is still a "major" language. Demand comes especially from Central and Eastern Europe, and parts of Asia. The IOI has stayed away from Java, mainly for technical reasons, but this is creating more and more problems. Algorithms/programming education around the world seems to have fallen for Java, both for high school and for the bachelor level at university. Good, up-to-date, teaching material for Object Pascal is lacking. Oh, and before I forget: C++ has STL, and Java comes with numerous packages. These are very powerful tools in the hands of skilled programmers. FPC does have FCL, but (a) it is not well-known, (b) it is not sufficiently complete. To round this off: we are overhauling our CS curriculum, and fortunately there is a small core of Pascal supporters. Personally, I favor FPC/Lazarus, some others still believe in Delphi. Maybe we will produce some new Pascal material that could find wider usage. (Food for another thread.) To summarize the needs: * Tools: contest-friendly IDE; STL-like library * Teaching: Course material, tutorials (make Pascal a wanted language) * People: Supportive jury members It would be nice to have some (former) contestants contribute to FPC to make it a compelling contest language. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [fpc-devel] Submitted bug report on option order -Sa -Sg-
(Discussion switched from fpc-devel to fpc-pascal, because it might be of more general interest.) On Sat, Apr 14, 2007 at 06:56:12PM +0200, Jonas Maebe wrote: > > On 13 Apr 2007, at 17:38, Tom Verhoeff wrote: > > >The order -Sa -Sg- fails to generate assertion checking code, whereas > >this is generated for the order -Sg- -Sa. > > > >A separate test confirms this (mis)behavior (see bug report: Steps To > >Reproduce). > > > >Or am I missing the obvious, and is this really a feature and not a > >bug? > > -S- disables all the -S options, regardless of where the second - > appears (like -O- disables all -O options). This can indeed be > confusing, since e.g. -Cor- turns on overflow checking, but disables > range checking. This is indeed not consistent. Both cases work as > designed, but the design is obviously not optimal. Thanks for the explanation. I think I understand what you are saying. In the (on-line) User's Guide, I can't find anything about the use of a trailing - for options. Where is this documented? How would one disable just the goto statement, without affecting other -S options? By the way, the User's Guide states that goto statements are disabled by default. However, the reason we added the -Sg- (attempting to disable just goto statements) was because after upgrading, suddenly programs with goto were accepted (and we don't want that in our educational use of Pascal). Hence, we added the option. Could it be that the default configuration file also got changed by the update and now enables goto statements? (This would be confusing.) Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic array as return type of functions
On Wed, May 23, 2007 at 11:36:20AM +0300, Christos Chryssochoidis wrote: > > >>It *is* allowed. The only trick is that you have to declare a type for > >>your dynamic array, i.e. you have to write something like > > Yes, I have noticed that if you first wrap a dynamic array in a type > definition then you can declare a function returning such an array, > but it seemed to me as an unnecessary complication of things and as > an inconsistency in the language. However, the distinction between > dynamic and open arrays that D.Mantione says, explains this > complication. It is not a trick, but has to do with type compatibility issues (and history, I guess). If you have function f(...): SomeType; then the result of calling f needs to go somewhere. Either it "disappears" as an intermediate result in a larger expression, or you assign it to a variable (or such). In case it is a subexpression, the result of f acts as a parameter of an enclosing function or operator. while f(...) operator ... do ... if g( f(...) ) then ... v := f(...) The receiving parameter or variable needs to have a type "compatible" with SomeType. If SomeType is a type expression, then you cannot declare a parameter or variable of the same type by copying the type expression. In Pascal, var a: array [ Char ] of Integer; b: array [ Char ] of Integer; function g(p: array [ Char ] of Integer); function f(c: Char; i: Integer): array [ Char ] of Integer; does not (automatically) make a and b have the same type (in some cases automatic conversions etc. will give you some kind of compatibility). For that (partly historic) reason, parameter types and return types must be type names and not type expressions. Of course, there situations where you can argue that it works without using type names. E.g. if you return a record type, one way of using it would be to select a field: function f(...): record x, y: Integer end; if f(...).x = 0 then ... The "operation" of field selection works on arbitrary record types. Insisting on a type name seems unneeded. I.e. the typing of the "parameters" of . is not so strict; it occurs in a context record . fieldname_of_this_record_type The record is not a parameter of . in the usual sense. I haven't checked the FPC documentation on all this. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic array as return type of functions
On Wed, May 23, 2007 at 05:48:32PM +0300, Christos Chryssochoidis wrote: > > On 23 Μαϊ 2007, at 3:05 ΜΜ, Tom Verhoeff wrote: > > >It is not a trick, but has to do with type compatibility issues > >(and history, I guess). > > I see. If I understand well, Pascal uses some sort of declaration > equivalence for types. Correct. In general, it is costly (or even hard/impossible) for a compiler to determine equivalence of type _expressions_. Variables and parameters declared with the same type _name_ are (obviously) of the same type. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Search order for libraries, how to influence; using GMP
I am trying to use the GNU Multi-Precision (GMP) library with
FreePascal under Linux.
I have a Pascal interface for GMP (originally for Kylix; translated
from C header file).
The header file libgmp.pas and my using program testgmp.pas compile fine.
But linking fails. The message is
/usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for
/usr/lib/crti.o
/usr/bin/ld: cannot find /usr/lib/crti.o
This might be caused by the fact that I use a 64-bit machine with
a 32-bit version of FPC.
For that reason, I added the command-line option:
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32
Without this option, I get the message
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/crtbegin.o when searching for
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/crtbegin.o
/usr/bin/ld: cannot find /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/crtbegin.o
With the option, it does find the appropriate crtbegin.o.
Therefore, I also added the command-line option
-Fl/usr/lib32
But this does not help, since /usr/lib is searched first and there if
finds the incompatible (64-bit?) version of crti.o, and fails.
How can I force the linker to look in /usr/lib32 before /usr/lib ?
When inspecting link.res, it starts out
SEARCH_DIR(/lib/)
SEARCH_DIR(/usr/lib/)
SEARCH_DIR(/usr/X11R6/lib/)
SEARCH_DIR(/usr/lib32/)
SEARCH_DIR(/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32/)
SEARCH_DIR(/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/)
Apparently, the first three are forced 'out of nowhere', then there are
the two options from the command line, and then the one from /etc/fpc.cfg,
followed by a long list of directories named /usr/lib/fpc/* .
Where do the first three come from? Can those be (re)moved?
Thanks,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpcunit documentation?
I know FreePascal includes the fpcunit unit testing framework (the compiler knows where to find it), but I can't seem to find any documentation via the regular www.freepascal.org, or the fpc wiki, or on the lazarus site? Michael's fpcunit.pdf seems hidden. Google tells me it is here <http://www.freepascal.org/docs-html/fpcunit.pdf> but that directory does not list it. That is a pity. Can someone educate me (or update the site)? Is there any more up-to-date documentation. I know some people enhanced fpcunit after Michael's article from 9 October 2005. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcunit documentation?
On Wed, Jun 13, 2007 at 12:27:29AM +0200, Darius Blaszijk wrote:
> The link you gave below to the pdf seems to point to a valid file.
> Please recheck it.
It is there alright, but you cannot navigate to that file on
. You need to know the URL to find the file.
In fact, fpcunit is mentioned almost nowhere. Even googling does
not turn up a lot of relevant leads.
I think fpcunit is listed in (some earlier) release notes, when it
got integrated first in the FCL (1.9.x).
The FCL implementation got restructured (cf. the subversion repository
structure) after I wrote about FCL in the wiki.
If someone tells me the overall structure of the FCL, then I could
update the wiki somewhat more. How do I find out which units are there?
Looking at the svn repository, it is still not obvious to me.
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search order for libraries, how to influence; using GMP
On Tue, Jun 12, 2007 at 11:16:23PM +0200, Darius Blaszijk wrote:
> BTW: JediMath has a 100% pascal implementation for arbitrary length
> arithmatic. Checkout JmLargeFloat.
Thanks. But this does not seem to implement arbitrary-precision
integers and rationals (fractions). The GMP does.
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Metaware
Heh, if you are reading this then you may know what Metaware is?
I've a large(!) body of code written over the years under the Metaware
Professional Pascal compiler. This code is to be translated to run on
the fpc compiler.
I wonder if anyone out there has attempted such an endeavor and might
give me some suggestions, or even some warnings about what I should
watch out for? I have found that there are some functional differences
that Metaware has over fpc, one example is the yield() function which
returns the intermediate result of a function call. There are a few
other functional differences, these should be able to be (re)written out.
Another "interesting feature" is a #define statement which is very much
like a C macro:
#define ChMap(A,C) Vt220Map[A] := chr(c)
There are quite a bit of these '#defines' throughout this source. I'm
thinking that the fpc alias is not going to work very well here and that
I would have to recode these defines as functions / procedures?
I had considered building a pre-processor to reformat the input to
ppcx64 into a delphi style construction, but there are enough
significant differences in source file structure and declarations that
would make this a whole lot of work. Probably would also be a headache
to maintain such an animal as well (yacc?).
Here is a snippet of the first few lines of a pascal source:
== begin
export (libdos4);
{ Include MetaWare libraries }
pragma c_include('implement.pf');
pragma c_include('language.pf');
...
...
pragma c_include('dospriv.inc');
{ C routine package }
package FromC;
pragma calling_convention(language.C);
pragma routine_aliasing_convention(implement.global_aliasing_convention);
type
int = LongInt;
program libdos4_unit;
with
defstd4,
dospriv;
var
KeySaveChar: char;
function DosKeyCharHave:
boolean;
begin
return(FromC.rdchk(0) = 1);
end;
== snip =
Anyhow, any thoughts that someone may have would be greatly appreciated!
TIA,
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
On Mon, Jun 18, 2007 at 10:26:06AM -0400, Tom Walsh wrote: > Heh, if you are reading this then you may know what Metaware is? Unfortunately for you, I have no such experience; never heard of it. > Another "interesting feature" is a #define statement which is very much > like a C macro: > #define ChMap(A,C) Vt220Map[A] := chr(c) Would it be an option see if you can pull it through a C preprocessor to eliminate the #define constructs? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
Daniël Mantione wrote:
Wow... I doubt I would recognize that code as Pascal if I wasn't told it
was. Free Pascal implements the UCSD-Pascal derived dialects of the
language (Turbo Pascal, Delphi, Metrowerks Pascal).
Daniël
== begin
export (libdos4);
{ Include MetaWare libraries }
pragma c_include('implement.pf');
pragma c_include('language.pf');
...
...
pragma c_include('dospriv.inc');
Yes, I know. I learned the UCSD Pascal dialect while programming old
Apple ][ pascal. Heh, that was a while ago. This Metaware looks pretty
much like UCSD code in a lot of respects, but then they go into these
weird C-like extensions.
Fortunately, the developers are still very much active writing new code
against the Metaware compiler. You know how it is, just like Cobol,
once you get them hooked (swindled?), management will keep shoveling
money into it...
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
Mark Wood wrote: I have found that there are some functional differences that Metaware has over fpc, one example is the yield() function which returns the intermediate result of a function call. ? '?' indeed! I am fascinated! What does yield do exactly... presumably it returns a result from the function without closing down that instance of the function? Amazing concept. I am still trying to work out how that could be useful or even how it could be used (without breaking stuff upstream). This would be one example, a function which returns a value each time it is called. There are some scoping rules which dictate whether the yield'ed function will init or continue from the last yield point: == begin iterator LoopStep(Start, Stop, StepSize : StdInt) : StdInt; var i, Answer, NumLoops : StdInt; begin if StepSize = 0 then return; Answer := Start; NumLoops := ((Stop - Start) DIV StepSize) + 1; for i := 1 to NumLoops do begin Yield(Answer); Answer := Answer + StepSize; end; end; == snip = Not sure why they found this terribly useful, but I don't write financial code... TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
memsom wrote: '?' indeed! I am fascinated! What does yield do exactly... presumably it returns a result from the function without closing down that instance of the function? Amazing concept. I suspect - given the word "DOS" in some of the code, it allows a DOS event loop to continue in a single threaded co-operative multitasking environment. A bit like Application.ProcessMessages in Delphi or Application.DoEvents() in DotNet. You can probably do other things at the same time, but Yield says this to me (maybe my old Mac programming hat as the Toolbox has a similar API.) If so, it's probably a little redundant now and use of threads could get around the problem (or even using the Application object from Lazarus API to implement the "processmessages"/yield part?) Well, the programmers are referring to 'Dos' in the generic sense, this is definately on a unix box. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
Tom Walsh wrote:
Mark Wood wrote:
I have found that there are some functional differences that
Metaware has over
fpc, one example is the yield() function which returns the
intermediate result
of a function call.
?
'?' indeed! I am fascinated! What does yield do exactly... presumably
it returns a result from the function without closing down that
instance of the function? Amazing concept. I am still trying to work
out how that could be useful or even how it could be used (without
breaking stuff upstream).
This would be one example, a function which returns a value each time
it is called. There are some scoping rules which dictate whether the
yield'ed function will init or continue from the last yield point:
About three years ago, when this project was first proposed, I did find
a white-paper written by someone at Metaware which outlined the
internals of the yield(). Apparently, they construct a seperate stack
frame for a function containing a yield(). When it is first called via
the main entry point, it constructs the frame and fills the local vars.
Subsequent calls cause the function to be continued, rather than run
from the initial entry point. This is an example from the manual:
begin ==
Package Telephone_directories;
..
...
...
iterator AllEntriesInOrder (const aDirectory: Directory) :
(const NextName: string(10); const NextNumber: string(8));
var
I: 1..MaxSize;
begin
for I := 1 to aDirectory.Size do
with aDirectory.Entry[i] do
Yield(Name, Number);
end;
end;
{ this is a new program that uses the iterator }
...
...
...
with Telephone_Directories; { with seems to be something like the
'uses' clause }
var MyDirectory: Directory;
...
...
for aName, aNumber in AllEntriesInOrder(MyDirectory) do
writeln (aName, ' : ', aNumber);
...
...
snip ===
Oh, then there is the "cycle" statement which reads very much like the
continue statement we all know about
Odd shi^H^Htuff.
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interesting namespace question
Hi! New list member here...
> I saw an interesting bug on C++, and I was wondering how to solve this
> type of bug in Pascal:
This is easily resolved.
Try this version:
{$MODE OBJFPC}
program namespace_test;
function test : boolean;
begin
writeln('public function test called.');
result := true;
end;
type
TTest = class
function test : boolean;
end;
function TTest.test : boolean;
begin
writeln('method TTest.test called.');
result := test;
end;
var
c_test : TTest;
begin
c_test := TTest.create;
try
writeln (c_test.test); // calls the class method
writeln (namespace_test.test); // calls the public function
finally
c_test.free;
end;
end.
Tom
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Starting new threads
When you want to start a new thread, please create a new mail, instead of replying to a another message and changing the subject. The latter method messes up automatic threading in most email clients, because there are other email headers apart from the subject which indicate to which thread an email belongs (and this header is wrong if you reply). I assume that is directed at me. :) My apologies. I was attempting to respond to "Interesting namespace question", but I was not a member of the list yet, so I attempted to duplicate the subject. I should have known better. Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Starting new threads
By the way is NNTP forbidden? I would much rather use NNTP over a mailing list. Thanks, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
Luca Olivetti wrote: En/na Jonas Maebe ha escrit: On 14 jun 2007, at 19:04, Luca Olivetti wrote: No suggestions? Is there some special option (apart from -g) that I should specify to compile/link my program? No. But the garbage backtrace means that either your gdb cannot parse the signal handler frame, or that your program corrupted the call stack. Well, I'm starting to get desperate, I cannot debug where the sigsev occurs, I put a bazillion writeln and still I cannot see where the problem is. I can reproduce the sigsev at will, only I cannot see where it happens. I suspect it's one of the threads in the c library (linphonecore, http://www.linphone.org) I'm using (since in all of my threads I put writeln in the critical places, as well as in all the callbacks from said library), alas there's no sigsev when the same library is driven by the c console program that comes with it (linphonec). At one point I though the problem was in CheckSynchronize (since the last writeln before the sigsev was right before calling it), but it was just a timing coincidence (I was calling it with 1000, then when I tried with 0 I saw the sigsev right in the middle of a debugging printf in the library). Maybe it's not a good idea to mix c multithreaded libraries and pascal code? Any special unit I should use? (I already tried cmem and it made no difference). If I cannot solve it I think I'll have to write a small backend program in c that communicates with pascal either through stdin/stdout redirection or with a socket. Bye IIRC, it is 'gcc -c ' TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
Luca Olivetti wrote: En/na Jonas Maebe ha escrit: On 14 jun 2007, at 19:04, Luca Olivetti wrote: No suggestions? Is there some special option (apart from -g) that I should specify to compile/link my program? No. But the garbage backtrace means that either your gdb cannot parse the signal handler frame, or that your program corrupted the call stack. Well, I'm starting to get desperate, I cannot debug where the sigsev occurs, I put a bazillion writeln and still I cannot see where the problem is. I can reproduce the sigsev at will, only I cannot see where it happens. I suspect it's one of the threads in the c library (linphonecore, http://www.linphone.org) I'm using (since in all of my threads I put writeln in the critical places, as well as in all the callbacks from said library), alas there's no sigsev when the same library is driven by the c console program that comes with it (linphonec). At one point I though the problem was in CheckSynchronize (since the last writeln before the sigsev was right before calling it), but it was just a timing coincidence (I was calling it with 1000, then when I tried with 0 I saw the sigsev right in the middle of a debugging printf in the library). Maybe it's not a good idea to mix c multithreaded libraries and pascal code? Any special unit I should use? (I already tried cmem and it made no difference). If I cannot solve it I think I'll have to write a small backend program in c that communicates with pascal either through stdin/stdout redirection or with a socket. Bye Nope, it is 'gdb -c '. Sorry :-( TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How do I join the Lazarus list?
I cannot seem to find a way to join the mailing list. TIA, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Printers
Since you specify LPT1:, I assume you are using Windows. Obviously the
solution for Linux would be different than Windows. I am not quite sure
about FPC, but in Delphi you basically have two choices.
1) Capture the USB printer to an LPT port, then attempt assign(printer,
'LPTx:'); (not a good solution in my opinion).
2) Open the Windows printer in RAW mode. I've used this style of
printing to a Eltron USB thermal printer and it worked well. The
procedure below is quite similar to the one I used.
Please write back and let me know if this routine works.
(Begin Procedure -- From Delphi newsgroups)
uses WinSpool;
procedure WriteRawStringToPrinter(PrinterName: String; S: String);
var
Handle: THandle;
N: DWORD;
DocInfo1: TDocInfo1;
begin
if not OpenPrinter(PChar(PrinterName), Handle, nil) then
begin
ShowMessage('error ' + IntToStr(GetLastError));
Exit;
end;
with DocInfo1 do begin
pDocName := PChar('test doc');
pOutputFile := nil;
pDataType := 'RAW';
end;
StartDocPrinter(Handle, 1, @DocInfo1);
StartPagePrinter(Handle);
WritePrinter(Handle, PChar(S), Length(S), N);
EndPagePrinter(Handle);
EndDocPrinter(Handle);
ClosePrinter(Handle);
end;
(End Procedure)
Tom
Roberto Gonçalves Barreiro wrote:
I'm a delphi programmer.
I'm printing a report using:
assign(wPrinter,'Lpt1:')
and it goes ok in paralel priner.
I did assign(wPrinter,'USB001') and it did not work.
Do you know how to print in USB printers?
I thanks a lot if you can help me.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Printers
Disregard my prior post. It does not work unless the Windows Spooler API is converted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Printers
Disregard my prior post. It does not work unless the Windows Spooler API is converted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Printers
Disregard my prior post, it is Delphi specific. I did find this one. (http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/components/printers/samples/rawmode/unitmain.pas?root=lazarus&rev=10129&view=markup) procedure WritePrinter; var sTemp: String; Written: Integer; begin Written := 0; sTemp := 'Test String'; Printer.Title := Caption; Printer.RawMode := True; Printer.BeginDoc; Printer.Write(sTemp[1], Length(sTemp), Written); Printer.EndDoc; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Printers
Sorry for all of these replies, I think my ISP (webhost) is working on their mail servers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc make vs. gnu make
I am starting work on one fpc project and planning another. The current project will be for an x86 target, the planned project would be on ARM. I'm confused by the inclusion of a make utility within the fpc package. Is there a compelling reason NOT to use GNU make for the fpc projects? Is there any benefit to the fpc make? Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Need three things (follow-up on contracts)
On Sun, Aug 12, 2007 at 01:00:44AM -0500, JK Smith at Grid-Sky wrote:
> Three things needed in FPC:
>
> 2) Contract programming. We have to be able to show proof of correctness in
> code to prove the business value of FPC. This will be a major theme for the
> business side of software development in the future.
Actually, we (at Dept. Math/CS of TUE) have already contributed an
experimental branch to the repository for this. See branches/tue.
That project is in a stable state, ready to be merged (since January).
It is not finished (still a number of missing features).
I am to blame for the delay in taking follow-up actions; my apologies.
Documentation can be found at (in formann.zip, but also is also unzipped)
<http://www.win.tue.nl/~wstomv/software/formann/>
Basically, the current features are available (see user.pdf).
It is possible to insert assertions before, between or after
any statement, using {@ ...} syntax. These are (optionally)
compiled just like regular Assert()-statements. Furthermore,
pre- and postconditions of functions, procedures and methods
can be given. Class invariants are supported in a limited way.
Before loops the programmer can insert an invariant and a
variant function. Finally, there is support for propositions
and definitions, that act as abbreviations.
Missing are the abilities to use quantified expressions like
'for all', inheritance of class invariants, and giving pre- and
postconditions of procedures and functions in the unit header
instead of the unit implementation.
...
By default, formal annotation parsing is switched off. This
is to maintain backwards compatibility with programs that have
comments that start with [EMAIL PROTECTED] The FreePascal compiler
itself has
at least one place where a comment starts with [EMAIL PROTECTED]
To control the behavior of the compiler with respect to formal
annotation parsing, two options are made available: compiler
directives and command-line arguments.
The command-line argument -Sf switches formal annotation
parsing on.
The compiler directive {$FORMAL+} switches formal annotation
parsing on, {$FORMAL-} switches it off.
The directives take precedence.
(Please note that some formal annotation constructs make the
compiler generate run-time assertion checks. These are not
compiled into actual code if assert()-statement compilation is
switched off.)
If the argument -Aproofobl is given on the command-line, then
proof obligations for procedures and functions with pre- and
postconditions are generated (if feasible), as a LaTeX file.
(Two examples arincluded: naive.pdf, intelligent.pdf.)
The file programmer.pdf contains information for developers; it documents
how things have been implemented.
Maybe a developer can take a look, and we can discuss off-line whether
to merge this, and if so, how to proceed.
Best regards,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OT: Rename for Pascal
ik wrote: Hi, I wonder how can we make Pascal and FPC more attractive to people, and I believe in what Donal Knuth have said: "The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language." So I believe that if we will change the name, it might help. What do you think ? And what name will you prefer to see FPC as ? FWIW, I am in the early stages of a commercial development using Free Pascal and have to submit weekly progress reports. I cringe whenever I have to put the phrase "Free Pascal Compiler" in the report! This project is with a company that just spent 4+ million US dollars on a Java solution (client and server side) to replace all their old Pascal code, then, their clients told them they didn't like the Java solution, that they wanted to keep using the Pascal stuff! Not that the compiler is junky, but the word "Free" does have a negative connotation. Many business people still associate "free software" with that of being low-quality. Business people are used to paying thousands of dollars for any development software worthy of notice, the word "free" doesn't fit into their thinking. Using the word "free" while reporting, or talking to them, about the project is an oxymoron. I am not "free", I get a substantial hourly rate. If you renamed it to the "Open Source Pascal Compiler" it would be more accurate? Oh, and please, please change the name soon, ok? I have a lot more of these reports to write... Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OT: Rename for Pascal
Bisma Jayadi wrote: This project is with a company that just spent 4+ million USD on a Java solution (client and server side) to replace all their old Pascal code, then, their clients told them they didn't like the Java solution, that they wanted to keep using the Pascal stuff! Isn't Java also free? :-P The point is that the compiler is not "free", it is encumbered by a license. People are gaining the idea that Open Source generally equates with "free" (as in no-expense). However, in American English, the word "free" generally means "something of so little value that you can afford to give it away". Perhaps in German it has a different connotation, or in British English... Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Help needed with (JEDI-)SDL on Mac OS X with FPC 2.0.4 powerpc
I try to compile a little demo program for SDL, but it still fails.
I use fpc 2.0.4 on powerpc Mac OS X with sdl 1.2.7 installed through fink
(also tried it with SDL installed in /Library/Frameworks).
I consulted the wiki <http://wiki.freepascal.org/index.php/FPC_and_SDL>
and <http://userpage.fu-berlin.de/~molski/fpsdl/>.
The problem is in the linking phase (compile and assemble are OK).
It gives me some warnings like
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may result in
errors or different symbols being used
symbol _acosl used from dynamic library /usr/lib/libstdc++.6.dylib(single module
) not from earlier dynamic library /usr/lib/libSystem.B.dylib(ld64.o)
but what is worse it stops at
_HIPointConvert referenced from QuickTime expected to be defined in Carbon
demo02.pp(114,1) Error: Error while linking
Error: /usr/local/bin/ppcppc returned an error exitcode (normal if you did not s
pecify a source file to be compiled)
Any idea what I messed up?
This is what my command line looks like:
fpc -Fu/Users/wstomv/Download/JEDI-SDLv1.0/SDL/Pas -Fl/usr/X11R6/lib
-XMSDL_main -k-L/sw/lib -k-lSDL -k-framework -kOpenGL -k-framework -kCocoa
-Mdelphi demo02
The program demo2.pp contains
{$linklib gcc}
{$linklib SDLmain}
Uses SDL, crt;
This program was grabbed from <http://userpage.fu-berlin.de/~molski/fpsdl/>
and then adapted according to <http://wiki.freepascal.org/index.php/FPC_and_SDL>
Your advice would be greatly appreciated,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Help needed with (JEDI-)SDL on Mac OS X with FPC 2.0.4 powerpc
On Fri, Aug 17, 2007 at 10:47:27PM +0100, Milan Marusinec wrote: > Tom Verhoeff wrote: > >Any idea what I messed up? > > > >This is what my command line looks like: > > > >fpc -Fu/Users/wstomv/Download/JEDI-SDLv1.0/SDL/Pas -Fl/usr/X11R6/lib > >-XMSDL_main -k-L/sw/lib -k-lSDL -k-framework -kOpenGL -k-framework -kCocoa > >-Mdelphi demo02 > > I would suggest to pass the -k switch this way: > > -k"-framework Carbon -framework Cocoa -framework OpenGL -lSDL -L/sw/lib" > > because, fpc passes the "whole content of -k switch" to ld. I tried that, but it didn't work. Maybe shell-dependent; I use /bin/bash on Mac OS X 10.3.9. > This way it already worked for me in one of my projects. I notice that you also include -framework Carbon, so I tried that as well. But it did not help a bit. Could it be related to versions of the various libraries? E.g., it may require 10.4.x. Still, I would like to know what is the matter. Thanks for further advice, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FreePascal mentioned in Yahtzee book
Last February, I used my Yahtzee software to do some calculations for the book "Yahtzee Scratch & Play" (ISBN 1-4027-5091-9) <http://www.amazon.com/exec/obidos/ASIN/1402750919/theinternationscA> This software is written in FreePascal, and I managed to get this mentioned in the book's Introduction (p.6). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Serial port interrupts?
John Coppens wrote: Hello people. To make a debugging tool, I need to time changes on the serial port control and status lines on a Linux machine. The serial port hardware has this possibility, but is it possible to program this in a more or less high-level way? I did this a long time ago in DOS. I've looked at several libraries, but none seem to give access to line/status change events in realtime. I doubt that you could do the same with Windows XP. Hardware operations are abstracted such that the device is "managed" via a kernel device driver. To do what you want to do might require you to write / modify the serial port driver. Having said that, it would be doubtful as to how finite a measurement / control that you could exert over the serial port. Modern kernels are multi-tasking beasts, and by design, no one process (thread) should / could take up the full attention of the kernel for any significant amount of time. Even under an interrupt driven service there would be jitter and an unpredictable response time before the service routine is actually run. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?
On Mon, Oct 29, 2007 at 07:30:03AM -0700, L wrote: > > It's just one more funny thing one must realize, > > when comparing real numbers with some exact > > real constants. After this, I will try to never > > compare doubles directly, but using tricks like > > above. Because, in this digital world > > 1 + 0.4 - 0.4 <> 1. > > My opinion: > This is ludicrous. > > The end user is using a high level language and should not care whether the > computer is digital or analog. Unfortunately, there is a problem. One can try to hide it (as calculators attempt to do), but in the longer run that is going to be unsuccessful and even dangerous. The mathematical structures of floating point numbers and of real numbers do not match, and cannot be made to match faithfully. See e.g. any good textbook on numerical mathematics. However, most of those texts are not so accessible to the layman. I have written a short article on it for secondary educations, that I hope is more accessible: Gyula Horvath, Tom Verhoeff. ``Numerical Difficulties in Pre-University Informatics Education and Competitions'', Informatics in Education, Vol. 2, Number 1, pp.21-38. <http://www.win.tue.nl/~wstomv/publications/INFE012-final.pdf> URL checked OK (Sidenote: If your program only needs to deal with decimal fractions, then it is stronly advised not to use Real/Single/Double, but e.g. Currency. Floating-point numbers are useful in scientific and engineering applications.) Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)
On Mon, Oct 29, 2007 at 06:36:11PM +0100, Micha Nelissen wrote: > > It's possible to create a type that stores the numerator and > denominator, but then you would need to "simplify" to extract common > factors on every calculation, otherwise it would quickly run out of > range (Integer or whatever you choose). Extracting common factors takes > exponential time, so it's quite slow. The range would be quite limited > as well, it's as wide as the numerator. In fact, the GMP (GNU Multiple Precision Arithmetic Library ) offers this and more. Unfortunately, there does not seem to be a complete FreePascal interface for it. Maybe it is easy to adapt (if necessary?) the GNU Pascal interface for GMP <http://www.gnu-pascal.de/gpc/GMP.html>. I would be interested. There is also an initial attempt <http://fjf.gnu.de/misc/gmpop.inc> to make the GMP functions available as operators under GNU Pascal. The (ultimate) goal is that you can simply write things like r := (a + b) * c where a, b, and c have a GMP number type, instead of writing things like mpq_add ( r, a, b ) ; mpq_mul ( r, r, c ) . Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (more pi fun)
On Tue, Oct 30, 2007 at 07:36:39PM +0200, Musan Antal wrote: > The discussion about PI reminds me another funny quote: > > The primary purpose of the DATA statement is to give names to > constants; instead of referring to pi as 3.141592653589793 at every > appearance, the variable PI can be given that value with a DATA > statement and used instead of the longer form of the constant. This > also simplifies modifying the program, should the value of pi change. > -- FORTRAN manual for Xerox Computers Here is another funny pi quote (appearing in a footnote in a book on VLSI design): "pi = sqrt(10) for small values of pi" With apologies for the increasing off-topicness, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] copy(), length(), and setlength() is not mentioned in fpc docs?
On Wed, Dec 05, 2007 at 09:12:00AM +0100, Daniël Mantione wrote: > > Op Wed, 5 Dec 2007, schreef Bee: > > > Is it just me or above methods are indeed not mentioned within fpc's doc > > 2.2.0? Any texts that are supposed to be a link to above methods is not > > formed > > as a link. > > http://www.freepascal.org/docs-html/rtl/system/stringfunctions.html These functions are not only for strings, but (more generally) for dynamic arrays (as well). I haven't checked to see if they are documented there, but one would expect/hope so. Can someone confirm this? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] 2x HeapTrc: output with -gl on ppcx64; QuickTrace/KeepReleased bug?
We use the HeapTrc facility in our education to get an impression of
memory management issues in programs submitted for assignments.
Typically our Peach.win.tue.nl system runs programs to test functionality
and robustness (i.e. test for proper precondition checking through Assert)
on small and bigger cases. Memory management is tested only with one
or two small cases.
I was surprised to find out that the output depends on the platform.
We use FPC 2.2.0 on Linux.
With ppc386 -gl you get something like:
... (line with full path suppressed) ...
Heap dump by heaptrc unit
183 memory blocks allocated : 4419/5400
175 memory blocks freed : 4355/5336
8 unfreed memory blocks : 64
True heap size : 425984
True free heap : 425344
Should be : 425472
Call trace for block $F7F863C8 size 8
$08064540 TQUEUEOFINT__PUT, line 153 of Queue_Pointers.pas
$08048FCD TESTPUT, line 234 of unbounded_queue_pointers.pp
$080494A5 TESTMULTIPUT, line 290 of unbounded_queue_pointers.pp
$0804953C TESTSAW, line 314 of unbounded_queue_pointers.pp
$08049C94 PROCESSINFILE, line 431 of unbounded_queue_pointers.pp
$08049FC0 main, line 459 of unbounded_queue_pointers.pp
$0807C621
... etc. ...
With ppcx64 -gl (all options equal, also in config files) it produces:
... (line with full path suppressed) ...
Heap dump by heaptrc unit
183 memory blocks allocated : 6319/7304
175 memory blocks freed : 6191/7176
8 unfreed memory blocks : 128
True heap size : 393216
True free heap : 391936
Should be : 392192
Call trace for block $2AD11627F780 size 16
$00425DC5
$0040173B line 235 of unbounded_queue_pointers.pp
$00401E05 line 289 of unbounded_queue_pointers.pp
$00401EAC line 312 of unbounded_queue_pointers.pp
$004029A4 line 431 of unbounded_queue_pointers.pp
$00402DDA line 461 of unbounded_queue_pointers.pp
$004001B8
... etc. ...
The difference is that under ppcx64 no proc/func names are listed,
and some entries have no file name/line number at all (though they do
under ppc386). Furthermore, the line numbers are reported differently.
It is exactly the same program running the same test case.
This makes it harder to interpret the feedback (especially for beginners).
A second issue I encountered with HeapTrc is that setting
QuickTrace := False { default is True }
KeepReleased := True { default is False }
will produce a heap trace report that contains many of these lines:
error in linked list of heap_mem_info
Any idea whether this is a bug, or just the fact that the combination
of settings above should not be used. Either of
QuickTrace := True { default }
KeepReleased := True
and
QuickTrace := False
KeepReleased := False { default }
does not produce these error lines.
This second problem also appears on FPC 2.0.4 under Mac OS X.
Thanks for any feedback,
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science
PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2x HeapTrc: output with -gl on ppcx64; QuickTrace/KeepReleased bug?
On Fri, Dec 14, 2007 at 12:28:04PM +0100, Vincent Snijders wrote: > Tom Verhoeff schreef: > >We use the HeapTrc facility in our education to get an impression of > >memory management issues in programs submitted for assignments. > > > >Typically our Peach.win.tue.nl system runs programs to test functionality > >and robustness (i.e. test for proper precondition checking through Assert) > >on small and bigger cases. Memory management is tested only with one > >or two small cases. > > > >I was surprised to find out that the output depends on the platform. > >We use FPC 2.2.0 on Linux. > > > >With ppc386 -gl you get something like: > > > >Call trace for block $F7F863C8 size 8 > > $08064540 TQUEUEOFINT__PUT, line 153 of Queue_Pointers.pas > > $08048FCD TESTPUT, line 234 of unbounded_queue_pointers.pp > > $080494A5 TESTMULTIPUT, line 290 of unbounded_queue_pointers.pp > > $0804953C TESTSAW, line 314 of unbounded_queue_pointers.pp > > $08049C94 PROCESSINFILE, line 431 of unbounded_queue_pointers.pp > > $08049FC0 main, line 459 of unbounded_queue_pointers.pp > > $0807C621 > > > >With ppcx64 -gl (all options equal, also in config files) it produces: > > Maybe using dwarf debug info helps? Try ppcx64 -gwl That does not make any difference. Nor do -gd and -gv. Note that also stack traces (e.g. on unhandled exceptions) are different under Linux for i386 and Linux for x86-64. Any other ideas? Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Maybe a new fpc book :)
On Sun, Jan 06, 2008 at 02:18:32PM +0100, Vincent Snijders wrote: > > One of them is in Dutch called "Turbo Pascal in de praktijk" and can be > retrieved from SVN: http://svn.freepascal.org/svn/tpidp/trunk/ I cannot find this via ViewCVS. Is tpidp not set as a repository root on <http://svn.freepascal.org/cgi-bin/viewvc.cgi/> ? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
On Wed, Apr 9, 2008 at 5:53 AM, Codebue Fabio - P-Soft <[EMAIL PROTECTED]> wrote: > Take a look to a new Firebird 2.1 next month and probably you will change > your idea about it... > UDF: FreeAdHocUDF, a lot of internal SQL function... > and if you wanna a good book www.ibphoenix.com Helen Borrie book... a > MUST! > > Will 2.1 have a true auto increment attribute? A boolean field perhaps? Those are the only things that I miss when using FB. I am aware that all of these issues can be resolved by using generators/triggers and a validating domain. That is what I like about MySQL, MSSQL and others that are missing from FB. Do not misunderstand though. I've used FB for 8+ years with great success in embedded, small and large transactional systems without flaw. Never had a corrupt DB. AFAIK, never had a corrupt backup. Most of the time, I deploy FB on Linux servers and backup using gbak. Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] pascal on macbook
On Fri, Apr 25, 2008 at 09:10:25AM -0500, George R Smith wrote: > > I have not purchased the machine yet, looking at the MacBook with 4 meg of > memory. I do not want to buy a laptop that runs Microsoft, trying to get > away from them. I presume you mean 4 GIGAbyte, otherwise you'll have a hard time enjoying it. > Just want to make sure I can use Java or Pascal (prefer Pascal) before I > spend the 2,000 plus dollars. I have PowerBook G4 (and since yesterday a new MacBook Pro), and program on it under Mac OS X in Pascal (mostly fpc), Python, and Java (and ocaasionally some other languages like Eiffel, ...). For Pascal, you can also consider LWP (Light-Weight Pascal) at <http://www.pascal-central.com/lwp/lightweight.html> Have fun, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25| Technische Universiteit Eindhoven FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]No line numbers shown when Format raises an exception, compiled with -gl
Recently, I have been caught a couple of times by mistakes in my
programs using Format (from SysUtils). When the format string and
the supplied arguments do not match, Format raises an exception.
This is nice, but unfortunately, only a hexadecimal address is printed
when the exception is not caught (my programs do not catch this
exception). All the pieces of these programs have been compiled with
-gl under Linux on i386 with 1.0.10 (actually with ppc386 -vwn -gl -O2
-Sd -Ci -Cr -Co -Ct).
It is a small disaster to find out which Format call is in error, if
you have many of them. How can one get line numbers on the uncaught
exception? Shouldn't a normal backtrace be generated, including line
numbers?
Here is a small program and its response:
[EMAIL PROTECTED](228) cat formatexception.pp
program FormatException;
uses SysUtils; { for Format }
begin
writeln ( Format ( '%S', [ 1 ] ) ) { 1 is not a string --> ECONVERTERROR }
end.
[EMAIL PROTECTED](229) ppc386 -gl -Sd formatexception.pp
Free Pascal Compiler version 1.0.10 [2003/06/26] for i386
Copyright (c) 1993-2003 by Florian Klaempfl
Target OS: Linux for i386
Compiling formatexception.pp
Assembling formatexception
Linking formatexception
7 Lines compiled, 0.3 sec
[EMAIL PROTECTED](230) ./formatexception
An unhandled exception occurred at 0x0805093B :
ECONVERTERROR : Invalid argument index in format ""
0x0805093B
Thanks,
Tom
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Any Carbon users around?
On Wed, Nov 17, 2004 at 06:43:15PM +0100, Kris Herlaar wrote: > > So i'd like to know if there are more Mac users on this list who might > be interested in sharing their knowledge with me and each-other. I'd be > delighted to set up a website with the Pascal for Mac OS X topic, at > least if i'm not going to be the only one helped there. I am using FreePascal quite regularly, mostly on Linux, but also on Mac OS X. I would be interested in giving some of my (older) Pascal programs a (Mac) GUI. On the Mac, I used to program with THINK Pascal. Since then, life has become "somewhat" more complicated. I have yet to try FreePascal with XCode. I have only used XCode for some Eiffel programming (a very nice system, by the way). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Assert (in System) overhead
The System Unit provides the Assert procedures. Code generation for
Assert can be activated through a compiler switch or command-line option:
<http://www.freepascal.org/docs-html/rtl/system/assert.html>
However, if you do leave them in, what is the overhead? In particular,
(1) does the generated code always involve a procedure call,
or is the condition check inlined, and
(2) is the (optional) message parameter (when present) always evaluated,
or only when the condition fails?
>From the generated assembler listing of a small example, I get the
impression that the check is inlined and the message parameter is
evaluated only on failure.
Can someone confirm that this is indeed always the way it is handled?
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TObjectList in Contnrs in FCL (doc, usage)?
I would like to use TObjectList from Contnrs (because it occurs in some Delphi application that I wish to compile with FreePascal). There are two problems: (1) The compiler does not find the unit Contnrs. It turns out that this unit resides in /usr/lib/fpc/2.0.1/units/i386-linux/fcl/contnrs.* which the compiler does not find by itself (it does find Classes in .../rtl/classes.*). Of course, I can change my fpc.cfg, but shouldn't this just work? Or should I do something else to use FCL units? (2) The FCL (RTL?) documentation does not mention Contnrs (it does mention Classes). It would be useful to include a link on "FCL - Free Component Library" (fcl/fcl.html) to the online documentation <http://www.freepascal.org/docs-html/rtl/index.html> However, it is not completely clear to me where the boundary is between RTL and FCL. Classes is listed under FCL, and is documented under RTL. Thanks, Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TObjectList in Contnrs in FCL (doc, usage)?
On Thu, Jun 02, 2005 at 07:48:30PM +0200, Michael Van Canneyt wrote: > > > > > > Classes is RTL. I will update the web page. Will you also include Contnrs in the FCL unit overview? It is currently not mentioned. It would also be good to include a statement about FCL documentation. At the moment it is not clear if there is any documentation and if so, where to look for it. My understanding is that FCL units can simply be used and are found (should be found) with the default configuration of the compiler. For the documentation of Delphi-inspired units one needs to refer to the Delphi documentation. If I understand the situation better, I will contribute an article about FCL to the Wiki (there is an FCL entry, but it only contains a question, not useful information). Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Calling unassigned procedure gives no stack trace with -gl
When the following program is compiled with option -gl -Mdelphi
and executed, it results in
An unhandled exception occurred at $ :
EAccessViolation : Access violation
without a stack trace or line numbers. How come? Is that a bug?
(If so, I will submit it as such.)
The problem remains when SysUtils is used as well.
This makes it very awkward to find the source of such unhandled exceptions.
(Something similar seems to happen with incorrect calls to Format.)
Is there any workaround?
Tom
--
program UnassignedProcedureBug;
{ compile with -gl -Mdelphi }
{ causes an unhandled exception (Access Violation) without stack trace }
uses
Classes;
type
TProcedure = procedure of object;
TMyClass = class(TObject)
public
FP: TProcedure;
procedure P;
end;
procedure TMyClass.P;
begin
writeln ( 'P called' )
end;
var
VMyClass: TMyClass;
begin
VMyClass := TMyClass.Create;
//VMyClass.FP := VMyClass.P; { with this assignment, it works }
VMyClass.FP; { this causes an Access Violation }
end.
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling unassigned procedure gives no stack trace with -gl
On Thu, Jul 14, 2005 at 01:12:23AM +0200, Marcel Martin wrote:
> Tom Verhoeff a écrit :
> >begin
> > VMyClass := TMyClass.Create;
> > //VMyClass.FP := VMyClass.P; { with this assignment, it works }
> > VMyClass.FP; { this causes an Access Violation }
>
> Of course, at this point FP = nil since you didn't set it.
Just in case, I was not understood:
The point is that there is no stack trace with line numbers on the
(obviously correct) exception, in spite of the option -gl (even when
explicitly using SysUtils).
I admit that the comment "it works" is misleading/confusing the issue.
I wrote it that way, to show that the program is otherwise fine, and
that the exception should indeed be a "normal"/correctly raised exception.
This may be a more general problem with SOME KINDS of unhandled exceptions
stack traces/line numbers. Note that, in the following program, you do
get a stack trace with line numbers:
program AsssertOk;
uses
SysUtils;
begin
Assert(False, 'Assertion failed on purpose')
end.
when compiled with options `-Sa -gl', produces as output
An unhandled exception occurred at $0806834E :
EAssertionFailed : Assertion failed on purpose (assert-ok.pp, line 7)
$0806834E
$080540D4
$080480D1 main, line 7 of assert-ok.pp
That is, you get a stack trace with line numbers.
Without using SysUtils you just get (even if you compile w/o -gl):
Assertion failed on purpose (assert-ok.pp, line 7).
Use of SysUtils "converts" the unhandled exception. (Where is that
documented?)
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling unassigned procedure gives no stack trace with -gl
On Thu, Jul 14, 2005 at 10:27:01AM +0200, Peter Vreman wrote: > > Tom Verhoeff a écrit : > > > > The point is that there is no stack trace with line numbers on the > > (obviously correct) exception, in spite of the option -gl (even when > > explicitly using SysUtils). > > The problem is that the framepointer register EBP is 0 in the sigcontext. > We can't solve this. So, where should a solution come from? Where in the software/hardware chain would a change be needed to make it work properly? Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Reading past end of file, no error
I am pretty sure that FPC 1.0.10 would give a runtime error when
attempting to read past the end of file.
E.g.
program ReadPastEOF;
var
i: Integer;
begin
readln(i);
writeln(i);
readln(i);
writeln(i);
end.
when offered a file with just one line containing one integer,
would give a runtime error. This is the behavior I would in fact
expect.
At some point in the 1.9 branch, this changed (and now it bites me).
Now it silently assigns 0 to i on the second read. Even with -Ci as
option or {$I+}.
Can anyone comment on this?
Should I submit a bug report?
Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25| Eindhoven University of Technology
FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
