[fpc-pascal] test - ignore
test - ignore ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Prospects for running Lightspeed/THINK Pascal and Codewarrior Pascal with FPC
On Aug 21, 2014, at 12:11 PM, Ingemar Ragnemalm inge...@ragnemalm.se wrote:
On 21/08/14 07:41, Jerry wrote:
I have a lot of old Pascal that I am getting interested in reviving. It was
originally written in Lightspeed/THINK Pascal (did I mention it is old?)
and around 2000-2002 I converted it to Codewarrior Pascal. These are both
Macintosh dialects.
What are the prospects of running each of these dialects under FPC? Are
there compatibility flags to set? Would there be much rewriting?
The compatibility flag to set is the compiler directive {$mode macpas} (at
the top of the file), or the command line switch -Mmacpas. I don't know how
much there would be to rewrite, but in general that switch should make the
accepted syntax at least quite compatible to CodeWarrior's.
One of the things that I recall being possibly unique and possibly
troublesome now is that under THINK Pascal, there was a built-in text I/O
window and a built-in graphics drawing window, both of which I used. In the
latter case, it was mainly MoveTo(x, y) and LineTo(x, y) stuff. When I
moved to Codewarrior, I was somehow able to emulate that both text and
drawing windows. I suppose the text window became a normal terminal
(whatever Codewarrior offered). I can't remember if Codewarrior offered a
drawing window or if I had to make a crude one using a (now) Carbon window.
Maybe you could rewrite your code on top of TransSkel:
http://ragnemalm.se/lightweight/ (click on it in the navigation bar on the
left).
Thanks, Jonas!
I am very comfortable in porting old Mac code to FPC. FPC implements a very
nice and modern Pascal that handles most (but not all) old code. The only
problem I have had is with multiply nested code that does exit on the
enclosing function, which FPC can't do.
You have to make your own text/drawing windows, but that is fairly easy. If
you program for Carbon, your code can be pretty close to the old one, and you
can even use QuickDraw, but if you want to be a bit more future safe,
TransSkel 5 targets Cocoa, includes a partial replacement for much of the Mac
Toolbox GUI and a future safe QuickDraw layer, QDCG, where all those
MoveTo/LineTo should work just fine.
And if you want an IDE that is somewhat similar to Think, Lightweight IDE is
aiming in that direction. The debugger needs more work but we are quite
active right now so the plan is to fix the remaining limitations during the
coming months. (The latest upload was today.)
/Ingemar
Great to know that I seem to have a good shot. I'm looking into TransSkel5 now.
Thanks for the help!
Jerry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Prospects for running Lightspeed/THINK Pascal and Codewarrior Pascal with FPC
Hi list, I have a lot of old Pascal that I am getting interested in reviving. It was originally written in Lightspeed/THINK Pascal (did I mention it is old?) and around 2000-2002 I converted it to Codewarrior Pascal. These are both Macintosh dialects. What are the prospects of running each of these dialects under FPC? Are there compatibility flags to set? Would there be much rewriting? One of the things that I recall being possibly unique and possibly troublesome now is that under THINK Pascal, there was a built-in text I/O window and a built-in graphics drawing window, both of which I used. In the latter case, it was mainly MoveTo(x, y) and LineTo(x, y) stuff. When I moved to Codewarrior, I was somehow able to emulate that both text and drawing windows. I suppose the text window became a normal terminal (whatever Codewarrior offered). I can't remember if Codewarrior offered a drawing window or if I had to make a crude one using a (now) Carbon window. What do you think? Jerry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can variables be declared within a block?
On Oct 18, 2010, at 6:42 AM, Florian Klaempfl wrote: Am 18.10.2010 14:58, schrieb Frank Church: It's just a matter of readability, e.g. having a variable declared in two blocks with the same name can cause you a lot of headache: So don't allow identical names. Ada allows exactly this feature (declaration within a block) and it is extremely simple and not the least confusing. It's also an easy and error-free way to manage dynamic memory allocation without using pointers. Jerry procedure p; begin ... begin var i : integer; ... ... ... i:=12341234; ... ... ... ... end; ... ... ... begin var i : integer; ... writeln(i); --- this i is not the same as above so i does not contain 12341234 but it contains probably some garbage. end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Strange error with Pa_IsFormatSupported from portaudio when used with Pascal headers AND Mac OS X.
On Mar 8, 2010, at 5:40 AM, Schindler Karl-Michael wrote: Am 08.03.2010 um 10:04 schrieb Jonas Maebe: gdb backtrace shows that it is deep down in Apple libs (probably the reason, why it does not happen in linux). Have you tried disabling all FPU exceptions? Many Apple frameworks indeed perform invalid FPU operations. See e.g. http://community.freepascal.org:1/bboards/message?message_id=276227forum_id=24094 for more details. Jonas Jonas, you are my hero. This was exactly the problem. After adding SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]); everything works. I am trying now some more details. Thanks a lot. This thread implies that there are Pascal headers for portaudio but the link http://www.microbizz.nl/portaudio-20070809.tar.gz is dead. Is there another place to download these headers? Jerry Karl-Michael Schindler ___ 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] floating point an FPC
Don't compare floating points. Ever. Now you see why. Also, don't write loops that calculate a floating point number which is then tested for equality to exit the loop. Also, it is a bad idea to test for or for exiting unless you know in advance an accidental equality result will not yield surprising results. In other other words, don't do that (test for or ) either. Jerry On Feb 26, 2010, at 3:37 AM, ik wrote: Hello, I've made a small test: if (0.1+0.2) = 0.3 then The only compiler/interpator that actually tells that it equal is FPC. I've tested it using Javascript (in Firefox), Ruby, Python, C (gcc) and Perl. Except FPC, everyone tells that 0.1+0.2 = 0.30004 Can someone explain how FPC see the result and why others does not see it like that ? Thanks, Ido http://ik.homelinux.org/ ___ 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] floating point an FPC
On Mar 1, 2010, at 2:32 PM, ik wrote: http://ik.homelinux.org/ On Mon, Mar 1, 2010 at 23:20, Jerry lancebo...@qwest.net wrote: Don't compare floating points. Ever. Now you see why. So if I need for example to compare currency or something that is floating point, how do I do that ? Also, don't write loops that calculate a floating point number which is then tested for equality to exit the loop. Also, it is a bad idea to test for or for exiting unless you know in advance an accidental equality result will not yield surprising results. In other other words, don't do that (test for or ) either. As I understand, there is an old way to calculate floating point that is very popular and newer ways for that. The old way uses binary calculation and the newer I do not understand them :) The older way that you are thinking of might be binary coded decimal, BCD, in which each decimal digit is represented by its own bit string, usually four bits, to represent the digits 0–9. It is rarely used any more. I'm not sure but maybe Hewlett-Packard calculators use BCD. (HP calculators are known for their excellent numerical accuracy. The academic who did a lot of their work was also involved in the IEEE 754 standard, I think.) The newer way that you are thinking of is probably IEEE 754 floating point which is implemented widely on modern microprocessors. Its whole numbers (1.0, 2.0, etc.) are supposedly exact equivalents to integer counterparts up to a very large number, but you had _really_ better know what you are doing if you depend on that for comparisons. And expect portability problems when moving to non-IEEE 754 platforms. BTW, the way to write a loop that increments a floating point number properly is this (Please pardon if any Ada syntax slips in here): for i := 0 .. 100 begin a_float := 1.23 * i; end; whereas this is a bad idea: a := 0.0; while a = 100.0 do a_float := 1.23 * i; a := a + 1.0; end; as is this: a := 0.0; while a = 123.0 do a := a + 1.23; end; Jerry Jerry On Feb 26, 2010, at 3:37 AM, ik wrote: Hello, I've made a small test: if (0.1+0.2) = 0.3 then The only compiler/interpator that actually tells that it equal is FPC. I've tested it using Javascript (in Firefox), Ruby, Python, C (gcc) and Perl. Except FPC, everyone tells that 0.1+0.2 = 0.30004 Can someone explain how FPC see the result and why others does not see it like that ? Thanks, Ido http://ik.homelinux.org/ ___ 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 Ido ___ 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] Case in Record
On Oct 8, 2009, at 9:12 AM, Jürgen Hestermann wrote: And I don't know any other Pascal Compiler who does any checks in this direction. Do some? I don't know, but ADA reportedly does. I don't know the differences to Pascal. Does it have the same syntax for variant records? FWIW, here is a link to the BNF of the Ada Programming Language: http://www.seas.gwu.edu/~adagroup/ada95-syntax/ Jerry Such a feature definitely seems useful to me. Of course it would be. But how should it work? Setting the tag variable when assigning a value and raising an error when reading with different variant? Then what if the tag variable is changed directly? Or should it be readonly (which would make sense IMHO). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] pascal on macbook
If you haven't been around the Mac much lately, you might also like to know that there is another compiler, GNU Pascal, or GPC. Free Pascal is like Delphi and GPC is more compatible with ISO standards, but each accommodates several dialects. Also, there is an alternate IDE under development for the Mac called Lightweght Pascal, or LWP. I believe that it also uses Free Pascal and possibly also works with GPC. Finally, both FPC and GCP have plug-ins for Apple's IDE which is called Xcode. Sign up for the Pascal Central list at http://lists.sonic.net/mailman/ listinfo/mac-pascal. Jerry On Apr 24, 2008, at 2:24 PM, Felipe Monteiro de Carvalho wrote: I'd say yes. Free Pascal works very well with Mac OS X. Here are instructions to install it: http://www.freepascal.org/fpcmac.var After installing Free Pascal, I'd recommend you to download the latest subversion Lazarus and then build the Carbon native Lazarus IDE. It's a native Mac IDE, and works very well. Instructions here: http://wiki.lazarus.freepascal.org/Carbon_Interface#Getting_a_. 22carbonproof.22_Lazarus There are also some snapshots available if you don't wish to build it yourself. Lazarus requires installing the fpc source, which is available in the Lazarus downloads page: http://sourceforge.net/project/showfiles.php?group_id=89339 Note: I recommend installing only fpcsrc (and maybe fpc if not already installed) from the website above. Lazarus 0.9.24 for Mac OS X was released before the Carbon interface improved, and it's not native. With the current development of the Carbon interface I recommend that it be used instead. Information about what is Lazarus and how it can be used can be found here: http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus http://wiki.lazarus.freepascal.org/Lazarus_Tutorial http://wiki.lazarus.freepascal.org/Lazarus_Documentation Do you have a Intel or PowerPC machine? And what kind of software do you wish to develop? If you wish to build software directly using the Mac OS X APIs instead of via Lazarus, it's also possible. Carbon interfaces are available and Cocoa bindings are being developed. thanks, -- Felipe Monteiro de Carvalho ___ 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] memory layout of arrays
On Sep 14, 2006, at 2:00 AM, Marc Santhoff wrote: Hi, when using arrays in C the layout of arrays is sort of flat, since pointer arithmetics for accessing values works (e.g. pointer += 4 for 32 bit values). Is this the same for pascal/fpc? Do values of for example an integer array sit in memory at 4 Byte boundaries? I need to hand over arrays to a C library and have no influence on how access is done internally (still und investigation). Currently the C lib reads garbage from my array ... FWIW, GPC arrays seem to be laid out exactly like those for C. I have passed arrays to and from Ada by specifying C conventions, so at least with GPC things went well. I haven't tried this with FPC, however. Beware of 2D arrays in C because there seems to be no requirement in C that all of the data be allocated in contiguous memory; the parts of the 2D array (most likely, rows) can in effect be fragmented. I am told that some or most C compilers do allocate the memory as one big chunk, however. TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
