Re: [fpc-pascal] Proper preprocessor?
Ryan Joseph schrieb am Do., 21. Juni 2018, 05:30: > > > > On Jun 20, 2018, at 10:57 PM, Marc Santhoff wrote: > > > > When I looked around it was in > > > > scanner.pas > > symsym.pas > > > > Just grep for "macro". > > > > If there is more or I'm wrong hopefully one of the "compiler guys" will > help > > out here, please. ;) > > Thanks for the tips. One of the first things that ever stopped me from > working on the compiler was doing incremental builds that don’t clean the > entire build first and take like 5 minutes to compile. > As long as you don't change code that is related to reading from or writing to PPU files it's enough to do a "make clean all" in the top level directory once after an "svn up" and then build the compiler inside Lazarus using the corresponding project and you can run it inside the IDE as well as long as you set the parameters and working dir correctly. And for outside building the binary is then located at compiler//pp. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 10:57 PM, Marc Santhoff wrote: > > When I looked around it was in > > scanner.pas > symsym.pas > > Just grep for "macro". > > If there is more or I'm wrong hopefully one of the "compiler guys" will help > out here, please. ;) Thanks for the tips. One of the first things that ever stopped me from working on the compiler was doing incremental builds that don’t clean the entire build first and take like 5 minutes to compile. On Mac this is the first command I use to build. Is there a way to do this but only compile changed files? make FPC=/usr/local/lib/fpc/$BASEFPCVERSION/ppc386 OPT="-ap" distclean all -j 2 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 21, 2018, at 12:21 AM, Marco van de Voort wrote: > > That would be C incompatible, which I thought was the main reason to have > it? It would also replace me in identifiers (like 'varwithme'), which C > afaik wouldn't without ## That was just a stupid example but it was meant to only capture hello(...) syntax. This fact alone makes it not very compatible with FPC’s current macros because it requires () in the identifier instead of a single word. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
SetExceptionMask(GetExceptionMask + [exInvalidOp]); Works!Thank you for the help! I'm curious why things like SQRT(-1) just produce NAN without needing to change the exception mask and (+inf) - (+inf) does not behave the same way. They both are invalid, why treat one method of generating an invalid number one way and another method of getting just as invalid of a number another way? If there is flexibility in the standard, then why not choose to always be consistent?I have a lot of examples of things that do produce NAN without needing to change the exception mask... like ln(-1) or 0/0 why do some cause the exception and others do not? If someone wanted to volunteer time to adjust the math unit to always behave the same way, would it be something that would be accepted or is there some fundamental reason why it is like this? James -Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Sven Barth via fpc-pascal Sent: Wednesday, June 20, 2018 5:23 PM To: fpc-pascal@lists.freepascal.org Cc: Sven Barth Subject: Re: [fpc-pascal] math with infinity and NaN Am 20.06.2018 um 23:15 schrieb James Richters: > Is there a way to prevent getting the runtime error? === code begin === SetExceptionMask(GetExceptionMask + [exInvalidOp]); === code end === Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
On 20/06/18 22:16, C Western wrote: On 20/06/18 21:58, Florian Klämpfl wrote: Am 19.06.2018 um 23:50 schrieb James Richters: I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program Uses math; var variable1:double; variable2:double; Begin variable1:= Infinity; variable2:= -1*Infinity; Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); End. My output is: Running "i:\programming\test\testmath.exe " An unhandled exception occurred at $004015F6: EInvalidOp: Invalid floating point operation $004015F6 main, line 8 of i:/programming/test/testmath.pas +Inf -Inf According to the link here: https://en.wikipedia.org/wiki/NaN NaN should be produced: No. The invalid operation is not masked by default. If you do so, FPC just write Nan. My initial testing indicates that, even with exceptions masked, the exception was raised: (or am I using the wrong routine?) Uses math; var variable1:double; variable2:double; Begin SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision]); variable1:= Infinity; variable2:= -1*Infinity; Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); end. ./t An unhandled exception occurred at $004002A1: EDivByZero: Division by zero $004002A1 main, line 9 of t.pas +Inf -Inf Colin Using: SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision,exInvalidOp]); gives: +Inf -Inf Nan though I would have to say the requirement to mask invalid operation when the exception reported is divide by zero is confusing Colin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
Am 20.06.2018 um 23:15 schrieb James Richters: Is there a way to prevent getting the runtime error? === code begin === SetExceptionMask(GetExceptionMask + [exInvalidOp]); === code end === Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
On 20/06/18 21:58, Florian Klämpfl wrote: Am 19.06.2018 um 23:50 schrieb James Richters: I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program Uses math; var variable1:double; variable2:double; Begin variable1:= Infinity; variable2:= -1*Infinity; Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); End. My output is: Running "i:\programming\test\testmath.exe " An unhandled exception occurred at $004015F6: EInvalidOp: Invalid floating point operation $004015F6 main, line 8 of i:/programming/test/testmath.pas +Inf -Inf According to the link here: https://en.wikipedia.org/wiki/NaN NaN should be produced: No. The invalid operation is not masked by default. If you do so, FPC just write Nan. My initial testing indicates that, even with exceptions masked, the exception was raised: (or am I using the wrong routine?) Uses math; var variable1:double; variable2:double; Begin SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision]); variable1:= Infinity; variable2:= -1*Infinity; Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); end. ./t An unhandled exception occurred at $004002A1: EDivByZero: Division by zero $004002A1 main, line 9 of t.pas +Inf -Inf Colin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
>Please read the standard, exceptions are part of it. Not much of a 'standard' if it's full of exceptions so everyone just does it however they want and therefore nothing is actually standard. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
Is there a way to prevent getting the runtime error? James -Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Florian Klämpfl Sent: Wednesday, June 20, 2018 4:59 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] math with infinity and NaN Am 19.06.2018 um 23:50 schrieb James Richters: > I’ve been updating my old programs to use the MATH unit in freepascal > and while testing things I came across a runtime error 217 Invalid > floating point operation. Here is my test program > > Uses math; > > var > > variable1:double; > > variable2:double; > > Begin > > variable1:= Infinity; > > variable2:= -1*Infinity; > > Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); > > End. > > My output is: > > Running "i:\programming\test\testmath.exe " > > An unhandled exception occurred at $004015F6: > > EInvalidOp: Invalid floating point operation > >$004015F6 main, line 8 of i:/programming/test/testmath.pas > > +Inf -Inf > > According to the link here: https://en.wikipedia.org/wiki/NaN > > NaN should be produced: No. The invalid operation is not masked by default. If you do so, FPC just write Nan. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
Am 20.06.2018 um 10:59 schrieb Adriaan van Os: James Richters wrote: I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program I suggest to file a bug report. It is very unfortunate that the Math unit doesn't conform to IEEE-758. Please read the standard, exceptions are part of it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
Am 19.06.2018 um 23:50 schrieb James Richters: I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program Uses math; var variable1:double; variable2:double; Begin variable1:= Infinity; variable2:= -1*Infinity; Writeln(variable1,' ',Variable2,' ',Variable1+Variable2); End. My output is: Running "i:\programming\test\testmath.exe " An unhandled exception occurred at $004015F6: EInvalidOp: Invalid floating point operation $004015F6 main, line 8 of i:/programming/test/testmath.pas +Inf -Inf According to the link here: https://en.wikipedia.org/wiki/NaN NaN should be produced: No. The invalid operation is not masked by default. If you do so, FPC just write Nan. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
Am 20.06.2018 um 10:33 schrieb Ryan Joseph: Are there any plans to make a proper preprocessor like #define in C? No. 1. From http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html: > Pascal >The compiler won't let you shoot yourself in the foot. 2. The unit concept renders macros often useless. I’m not saying this is good programming practice or anything but I just had a really annoying copy and paste chore on some temporary code which I could have easily accomplished if I had #define like in C. It’s such a trivial thing to add I wonder why it was never included in Pascal. Such quick and dirty temp. code can be often easily created by the macro functionality of the use editor. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Am 20.05.2018 um 14:23 schrieb Sven Barth:
Hello together!
I'm pleased to announce that after nearly a year various extensions
for dynamic arrays have been finished. This includes the following
features:
- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)
Addendum: the support for the "+" operator is now coupled to a new
modeswitch "ArrayOperators".
If the modeswitch is enabled, then the operator can not be overloaded
and it also won't be used even if an overload from a unit without the
modeswitch is in scope (the compiler however issues a warning if this is
the case, so you can either remove the overload or disable the
modeswitch). If the modeswitch is not enabled then everything behaves as
before.
The modeswitch is enabled by default in Delphi modes as this feature was
added for Delphi compatibility. If you want to disable it in those modes
then you need to do this:
=== code begin ===
{$mode delphi}
{$modeswitch arrayoperators-} // Note the "-"
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On 20/06/18 17:30, Marco van de Voort wrote: That would be C incompatible, which I thought was the main reason to haveit? I don't believe Ryan said that (and I certainly didn't). It's the functionality that counts, not slavish adherence to any particular syntax. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Ryan Joseph said:
> > On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt
> > wrote:
> >
> > Because it is a simple textual token replacement at present. Supporting
> > arguments would mean parsing the macro, parsing whatever comes after it,
> > matching the arguments etc. A whole added layer of complexity.
>
> It?s like a simplified regular expression. Capture anything inside () on the
> left side and replace occurrences on the right side.
>
> {$define hello(me) := writeln(?hello me')}
>
> hello(world) becomes writeln(?hello world?)
That would be C incompatible, which I thought was the main reason to have
it? It would also replace me in identifiers (like 'varwithme'), which C
afaik wouldn't without ##
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
Ryan Joseph schrieb am Mi., 20. Juni 2018,
17:41:
>
>
> > On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >
> > Because it is a simple textual token replacement at present. Supporting
> arguments would mean parsing the macro, parsing whatever comes after it,
> matching the arguments etc. A whole added layer of complexity.
>
> It’s like a simplified regular expression. Capture anything inside () on
> the left side and replace occurrences on the right side.
>
> {$define hello(me) := writeln(‘hello me')}
>
> hello(world) becomes writeln(‘hello world’)
>
In Pascal you'd use inline functions for this one though of course with
strong typing and not some identifier that both a human and the IDE will
have to guess what it is.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
Mark Morgan Lloyd schrieb am Mi., 20. Juni 2018, 18:38: > On 20/06/18 14:45, Marc Santhoff wrote: > > But I speak up for another reason: > > Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in > compilersource code, the lexer and parser part. IIRC there were some hooks > for callinga proprocessor in the code at that time. If they are still > there, wouldn't itbe a solution for both sides? > > The compiler programmers only have to activate (or complete) a way to > call apreprocessor, solving the problem of mangled error messages. > > The preprocessor user could implement whatever is needed on his or her > side? > > My 2 cent,Marc > > Is that what the PREPROCWRITE define is for? > That is merely for the ability to output a preprocessed source file after all the compiler directives and macros have been handled. AFAIK it hasn't worked for a long time... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On 20/06/18 16:00, Marc Santhoff wrote:
On Wed, 2018-06-20 at 22:45 +0700, Ryan Joseph wrote:> > On Jun 20, 2018, at 10:20 PM, Marc Santhoff
wrote:> > > > The spots where resolving single parameter macros is done are pretty easy> > to> > find. Parsing
the macro text and replacement will be the hardest part, as> > Michael wrote. A bit of housekeeping for parameter-type lists,
etc...> > Easy? I’ve wanted to contribute to the compiler for years but it’s so> daunting finding anything I give up. I’m
curious how the parser works so> please show me where the parser does the $defines. Maybe I can figure it out> this time.
When I looked around it was in
scanner.passymsym.pas
Just grep for "macro".
If there is more or I'm wrong hopefully one of the "compiler guys" will helpout
here, please. ;)
Word of caution: IIRC macros only work properly in comments delimited by
braces {}
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On 20/06/18 14:45, Marc Santhoff wrote: But I speak up for another reason: Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compilersource code, the lexer and parser part. IIRC there were some hooks for callinga proprocessor in the code at that time. If they are still there, wouldn't itbe a solution for both sides? The compiler programmers only have to activate (or complete) a way to call apreprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent,Marc Is that what the PREPROCWRITE define is for? My 1½d :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal console programs on Android are easy
On 06/04/2017 08:00 AM, Paul Breneman wrote: On 05/09/2014 07:06 PM, Paul Breneman wrote: On 03/24/2014 12:08 PM, Paul Breneman wrote: On 03/15/2014 07:33 PM, Paul Breneman wrote: ... My main specialty is communication software ( www.turbocontrol.com/APro.htm ), so right now that is what I'm working on. I have a USB hub working with a keyboard on my Nexus 7 (via OTG), but a FTDI USB-serial adapter doesn't show up in /dev so I hope to get that (and some other Bluetooth and TCP/IP stuff) working next. But a GUI Hello World would be nice! I did install the "libc-dev" package to compile a Synapse Synaser program so if anyone wants to try www.CtrlTerm.com that would be appreciated. My main (first) goal in this is to be able to run a single program (for machine control) on an inexpensive tablet. Maybe even with embedded Firebird (I have an Android tablet with an Intel CPU if that is needed). Well, maybe I can wait on doing more with Free Vision and use fpGUI instead! :) GNURoot has been updated! See this text: "WheezyX rootfs type added - it has Xterms working. After launching it, use a vncviewer on your Android device or you PC to connect to it." Now I hope to get Control Terminal working (first for WiFi and Bluetooth, then with USB OTG for Ethernet and Serial)! http://turbocontrol.com/gnuroot.htm I just updated the above web page with a Control Terminal console program that uses Synapse to get the header of a web page. Nice to see what can be done with a 2 MB zip and Free Pascal and Synapse. Thanks for the great tools! Can I reply to a 3 year old message? I could use some help and feedback with this *simple* topic! GNUroot (with new Android versions) no longer works with Free Pascal so I made this new page that has a link to a new wiki page: http://controlpascal.com/self-hosted.htm There is a *new* Android program *UserLAnd* that replaces GNUroot so hopefully we'll soon have Free Pascal working again on Debian on Android: www.turbocontrol.com/userland.htm Yes, I know that Free Pascal works on straight Debian (and Raspbian)... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 2018-06-20 at 22:45 +0700, Ryan Joseph wrote: > > On Jun 20, 2018, at 10:20 PM, Marc Santhoff wrote: > > > > The spots where resolving single parameter macros is done are pretty easy > > to > > find. Parsing the macro text and replacement will be the hardest part, as > > Michael wrote. A bit of housekeeping for parameter-type lists, etc... > > Easy? I’ve wanted to contribute to the compiler for years but it’s so > daunting finding anything I give up. I’m curious how the parser works so > please show me where the parser does the $defines. Maybe I can figure it out > this time. When I looked around it was in scanner.pas symsym.pas Just grep for "macro". If there is more or I'm wrong hopefully one of the "compiler guys" will help out here, please. ;) -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 10:20 PM, Marc Santhoff wrote: > > The spots where resolving single parameter macros is done are pretty easy to > find. Parsing the macro text and replacement will be the hardest part, as > Michael wrote. A bit of housekeeping for parameter-type lists, etc... Easy? I’ve wanted to contribute to the compiler for years but it’s so daunting finding anything I give up. I’m curious how the parser works so please show me where the parser does the $defines. Maybe I can figure it out this time. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt
> wrote:
>
> Because it is a simple textual token replacement at present. Supporting
> arguments would mean parsing the macro, parsing whatever comes after it,
> matching the arguments etc. A whole added layer of complexity.
It’s like a simplified regular expression. Capture anything inside () on the
left side and replace occurrences on the right side.
{$define hello(me) := writeln(‘hello me')}
hello(world) becomes writeln(‘hello world’)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 2018-06-20 at 21:34 +0700, Ryan Joseph wrote: > My impression was it was trivial extension to the current macros system but > the compiler team was adverse to the idea because it creates “bad code” and > all the other (very reasonable) reasons to not use macros in code (I read > some old threads to this effect). It’s hard to understand why the current > macros can’t be extended so I suspect this issue will just keep coming up > over and over again. If it's that important to you, do it yourself. The compiler is open source, pure, readable pascal. The spots where resolving single parameter macros is done are pretty easy to find. Parsing the macro text and replacement will be the hardest part, as Michael wrote. A bit of housekeeping for parameter-type lists, etc... -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 9:54 PM, Martin Schreiber wrote: > > Isn't this obfuscation by > definition? Indeed it is. I really do agree 100% but strangely enough it doesn’t matter. :) Keep in mind often we’re writing code that only ourselves will ever see and we don’t need any justification to do something non-standard or otherwise very stupid. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 9:06 PM, Michael Van Canneyt > wrote: > > So, it really is not dogma, but a simple weighing of pros and cons. Thanks for your input guys. If it’s going to mess up PPUs and break things then that I’m satisfied that’s a good enough reason not to include it. My impression was it was trivial extension to the current macros system but the compiler team was adverse to the idea because it creates “bad code” and all the other (very reasonable) reasons to not use macros in code (I read some old threads to this effect). It’s hard to understand why the current macros can’t be extended so I suspect this issue will just keep coming up over and over again. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 9:16 PM, Mark Morgan Lloyd
> wrote:
>
>> How can you integrate a preprocessor without misaligning error messages and
>> debugging information?
>
> I forget the detail but some language implementations have pragmata which
> tell subsequent processing steps that at this point the source should be
> considered to have come from such-and-such a line number in such-and-such a
> file.
I think you’re right but that’s internal to the compiler and not really
something we can replicate ourselves. In fact that’s what the $include
directive does right? Again correct me if I’m wrong but I think $define:= does
the same thing otherwise column numbers (at least) in error messages would be
misaligned.
If macros took parameters it’s the same as before it just includes some extra
text. I keep saying it but it’s really difficult to understand why this is
compiler breaking stuff.
{$define foo(xx) := DoFoo(xx)}
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Ryan Joseph wrote: On Jun 20, 2018, at 9:26 PM, Marc Santhoff wrote: Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler source code, the lexer and parser part. IIRC there were some hooks for calling a proprocessor in the code at that time. If they are still there, wouldn't it be a solution for both sides? I hope that’s not true. :) Marco says otherwise but it’s hard to imagine why the current $define:= couldn’t take an argument. Because it is a simple textual token replacement at present. Supporting arguments would mean parsing the macro, parsing whatever comes after it, matching the arguments etc. A whole added layer of complexity. I’m sorry to say for the compiler team this issue is just going to come up over and over because programmers are going to be confused as to why the current macros don’t take parameters. To put things in perspective: in 25 years it came up only a handful of times. So I'm not inclined to perceive it as a pressing problem... Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wednesday 20 June 2018 16:38:10 Ryan Joseph wrote: > > On Jun 20, 2018, at 9:21 PM, Martin Schreiber wrote: > > > > Macros are the worst code obfuscating feature ever. > > Ironically everyone agrees but back to my original point that’s just dogma > (sorry I said it!). If I was doing C I wouldn’t refuse to use the macros to > solve simple problems because “there the worst code obfuscating feature > ever”. > > At the end of the day I just want to be happy and productive programming. > If a macro helps me do that then so be it. Life’s too short. > I daily read code from many people. Beleave me, “there the worst code obfuscating feature ever” is one of the most proven in use dogma ever. ;-) That you will not misuse it does not mean nobody will misuse it. The C-example which has been provided looks like a misuse for me. Macros replace text in code with something other which can be anything. Isn't this obfuscation by definition? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 9:26 PM, Marc Santhoff wrote: > > Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler > source code, the lexer and parser part. IIRC there were some hooks for calling > a proprocessor in the code at that time. If they are still there, wouldn't it > be a solution for both sides? I hope that’s not true. :) Marco says otherwise but it’s hard to imagine why the current $define:= couldn’t take an argument. I’m sorry to say for the compiler team this issue is just going to come up over and over because programmers are going to be confused as to why the current macros don’t take parameters. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 9:21 PM, Martin Schreiber wrote: > > Macros are the worst code obfuscating feature ever. Ironically everyone agrees but back to my original point that’s just dogma (sorry I said it!). If I was doing C I wouldn’t refuse to use the macros to solve simple problems because “there the worst code obfuscating feature ever”. At the end of the day I just want to be happy and productive programming. If a macro helps me do that then so be it. Life’s too short. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 2018-06-20 at 15:09 +0200, Michael Van Canneyt wrote: > > On Wed, 20 Jun 2018, Mark Morgan Lloyd wrote: > > > The other alternative would be break the compiler in such a way that it > > was usable from a standard makefile, but since there isn't separate > > compilation of definition and implementation parts this would probably > > impact on type safety. I believe that this too has been debated in the > > past, and has attracted even less enthusiasm than a hook for an extrnal > > preprocessor preprocessor. > > Nothing stops people from preprocessing their code if they need really > advanced preprocessing: The toolchain can handle it already. > > But there is no need to integrate it in the compiler and thus needlessly > complicating it even more. The consequences of such a step are far-reaching. > > And till now, no-one has presented the really pressing use cases that would > warrant such a step. The only use case for me would be macros having more than one parameter, needed when translating C-code. But I speak up for another reason: Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler source code, the lexer and parser part. IIRC there were some hooks for calling a proprocessor in the code at that time. If they are still there, wouldn't it be a solution for both sides? The compiler programmers only have to activate (or complete) a way to call a preprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent, Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Martin Schreiber wrote: On Wednesday 20 June 2018 16:06:13 Michael Van Canneyt wrote: Please stop calling it 'dogma'. As with all features, it is a trade-off between the burden this places on the compiler (and the people maintaining it) and the expected gain. And the damage it causes on readability of code. Every new language feature will be used, every new language feature forces all programmers which have to read code from others to learn the new features. This is especially important for languages which are established in open source world. Macros are the worst code obfuscating feature ever. Exactly... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wednesday 20 June 2018 16:06:13 Michael Van Canneyt wrote: > > Please stop calling it 'dogma'. > > As with all features, it is a trade-off between the burden this places on > the compiler (and the people maintaining it) and the expected gain. > And the damage it causes on readability of code. Every new language feature will be used, every new language feature forces all programmers which have to read code from others to learn the new features. This is especially important for languages which are established in open source world. Macros are the worst code obfuscating feature ever. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On 20/06/18 13:45, Ryan Joseph wrote: On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt wrote:> > Nothing stops people from preprocessing their code if they need really> advanced preprocessing: The toolchain can handle it already.> > But there is no need to integrate it in the compiler and thus needlessly> complicating it even more. The consequences of such a step are far-reaching.> > And till now, no-one has presented the really pressing use cases that would warrant such a step. How can you integrate a preprocessor without misaligning error messages and debugging information? I forget the detail but some language implementations have pragmata which tell subsequent processing steps that at this point the source should be considered to have come from such-and-such a line number in such-and-such a file. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Michael Van Canneyt said: > Till now, the burden of preprocessing is considered simply too big for the > gain. > > One consequence, for example, is that the ppu files are thrown out of the > window. The compiler would have to compile every used unit every time again, > since it has no idea what the user of the preprocessor can/will/wants to do. > Just as the C compiler is forced to do, by the way. > > Second consequence is the generation of debug info: you need to work back to > the original source location. This places a restriction on the preprocessor, > since it somehow needs to communicate back the original source locations to > the > compiler. etc. > > Same is true for error locations, and so on. And afaik you need to introduce (more?) line based parsing in the preprocessor rather than a token stream. Just try to put #line or #define in the middle of a statement in C. This is also alien to pascal. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Ryan Joseph wrote: On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt wrote: Nothing stops people from preprocessing their code if they need really advanced preprocessing: The toolchain can handle it already. But there is no need to integrate it in the compiler and thus needlessly complicating it even more. The consequences of such a step are far-reaching. And till now, no-one has presented the really pressing use cases that would warrant such a step. How can you integrate a preprocessor without misaligning error messages and debugging information? I would have already done this myself if I thought it was possible. A way to hook into the compiler to run external programs would be very handy and let us craft our own solutions without adding junk into the compiler. This will not solve your misalignment problem, and see below. I put this into the category of dogma because we’re being asked to provide “valid” use cases instead of trusting that we have know what’s best for our own code. It’s not possible to know in advance what people may need so providing them good tools as a fail safe is only sensible. Please stop calling it 'dogma'. As with all features, it is a trade-off between the burden this places on the compiler (and the people maintaining it) and the expected gain. Gain can only be estimated by giving use case(s). Till now, the burden of preprocessing is considered simply too big for the gain. One consequence, for example, is that the ppu files are thrown out of the window. The compiler would have to compile every used unit every time again, since it has no idea what the user of the preprocessor can/will/wants to do. Just as the C compiler is forced to do, by the way. Second consequence is the generation of debug info: you need to work back to the original source location. This places a restriction on the preprocessor, since it somehow needs to communicate back the original source locations to the compiler. etc. Same is true for error locations, and so on. Is there a workaround ? Yes, there is: you can do the preprocessing by yourself. Lazarus is equipped for it. Use makefiles if you want. Speed should be mentioned: all this will add another layer on top of the compiler, which will aversely affect speed. People already complain about speed... So, it really is not dogma, but a simple weighing of pros and cons. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
No, that’s not normal, it's not supposed to give you a runtime error. Anything that results in an answer that is Not a Number is supposed to be set to NaN, not give you a runtime error 217 and terminate. Infinity minus itself is undefined and therefore Not a Number and should be set to NaN, but I don't get NaN, I get a fatal runtime error 217. To answer your question: if you know Inf + Inf = Inf and you know Inf - Inf = Nan then Properly evaluating from left to right: Inf + Inf - Inf = Inf - Inf = NAN or if you want to do it the other way: inf - inf + inf = NaN + Inf = NaN (+inf) + (+inf) should and does give you (+inf) (-inf) + (-inf) should and does give you (-inf) (+inf) - (+inf) should give you (NAN) but it gives you Runtime Error 217 (-inf) - (-inf) should give you (NAN) but it gives you Runtime Error 217 (+inf) + (-inf) should give you (NAN) but it gives you Runtime Error 217 (-inf) + (+inf) should give you (NAN) but it gives you Runtime Error 217 Snip from refrence at: https://en.wikipedia.org/wiki/NaN Operations generating NaN: There are three kinds of operations that can return NaN: 1. Operations with a NaN as at least one operand. 2. Indeterminate forms: a. The divisions (±0) / (±0) and (±∞) / (±∞). b. The multiplications (±0) × (±∞) and (±∞) × (±0). c. The additions (+∞) + (−∞), (−∞) + (+∞) and equivalent subtractions (+∞) − (+∞) and (−∞) − (−∞). d. The standard has alternative functions for powers: The standard pow function and the integer exponent pown function define 0⁰, 1∞, and ∞⁰ as 1. The powr function defines all three indeterminate forms as invalid operations and so returns NaN. 3. Real operations with complex results, for example: The square root of a negative number. The logarithm of a negative number. The inverse sine or cosine of a number that is less than −1 or greater than 1. #2c clearly defines that NaN is set for the above conditions that are failing with a runtime error 217 Also reference: https://www.philforhumanity.com/Infinity_Minus_Infinity.html James -Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marco van de Voort Sent: Wednesday, June 20, 2018 9:21 AM To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] math with infinity and NaN In our previous episode, C Western said: > > I can do things like +infinity*2 and +infinity-3 and even > > sqr(infinity) and power(infinity,10) the results are still +Inf which is > > expected? > > ??but I can?t do anything involving subtracting infinity from > > infinity.? Isn't that normal? Otherwise, what would inf+inf-inf be if you know that (inf+inf) =inf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Ryan Joseph said: > > If the preprocessor really does such extended work, can't one simply keep > > the intermediate output of the preprocessor as a source file and then > > relate to that? > > Then you have 2 versions of the source code right? No. One source, and one temporary preprocessed form for the compiler which you don't need to store. But there are many such temporary digested forms, like assembler and .o's in FPC's case True. Error handling would be a problem, but if you keep the hacky constructs in separate files that is quite workable. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Ryan Joseph said: > > > > I've done my fair share of language advocacy in the past and in general am > > no friend of C, but I suggest that a number of people- on both the "pure" > > and the "pragmatic" sides of the argument- could very much do with "cooling > > it". > > I don?t understand why there's so must resistance to letting programmers > make ugly macro hacks if they want to. There is no resistance against using macro hacks. Use six layers of preprocessors if you want to. There is only resistance against us implementing and maintaining it. And fix the zillions of corner cases which will all come with similar reasoning as yours. We simply want to avoid spending the time on a major feature that we don't believe in. > Why does anyone care if I have some edge case and I need a solution > quickly which macros fulfill? The compiler should be helpful, not force > into some programming paradigm and best practices etc.. etc? Why do we have to cater for every hypothetical edge case that you could encounter? Tomorrow somebody wants space idented blocks to easier borrow code from Python (and we will also tell him to take a hike). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 5:54 PM, Schindler Karl-Michael > wrote: > > If the preprocessor really does such extended work, can't one simply keep the > intermediate output of the preprocessor as a source file and then relate to > that? Then you have 2 versions of the source code right? I personally would have a very difficult time trying to manage both branches and I guarantee I would make errors all the time where I typed into the wrong file and lost data. The compiler needs to be aware of the insertions so that it can offset the line numbers properly. Please correct me if I’m wrong though. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Ryan Joseph said: > > complicating it even more. The consequences of such a step are far-reaching. > > > > And till now, no-one has presented the really pressing use cases that would > > warrant such a step. > > How can you integrate a preprocessor without misaligning error messages > and debugging information? Have the preprocessor generate some form of lineinfo that your IDE can mine? > I put this into the category of dogma because we?re being asked to provide > ?valid? use cases instead of trusting that we have know what?s best for > our own code. Then trust us that we know our business with respect to the compiler internals. > It?s not possible to know in advance what people may need > so providing them good tools as a fail safe is only sensible. Good and "fail" are horribly subjective here. > My own case I had just know was hard coded some vertex data from a C > program and if I had a good macro syntax I could have finished it much > quicker and it would have looked nicer. It doesn?t matter if this was > ?best practice? or not. I just wanted to finish it so I could move on to > more important things. Which is an argument that can be made for every external language feature. Not really convincing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 6:36 PM, Giuliano Colla > wrote: > > A #define makes it possible to compare the two solutions with the same > efficiency you'll get in the final version. A workaround, such as an extra > procedure which does the same job, generates some extra code and may not tell > you the full story. > > It's not matter of rethinking the design, but of picking up the best design. This is the perfect example! I never thought of doing that myself and neither did other people, who despite that are trying to prevent even the possibility you could try. I don’t get it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 6:37 PM, Mark Morgan Lloyd > wrote: > > I've done my fair share of language advocacy in the past and in general am no > friend of C, but I suggest that a number of people- on both the "pure" and > the "pragmatic" sides of the argument- could very much do with "cooling it". I don’t understand why there's so must resistance to letting programmers make ugly macro hacks if they want to. Why does anyone care if I have some edge case and I need a solution quickly which macros fulfill? The compiler should be helpful, not force into some programming paradigm and best practices etc.. etc… Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt > wrote: > > Nothing stops people from preprocessing their code if they need really > advanced preprocessing: The toolchain can handle it already. > > But there is no need to integrate it in the compiler and thus needlessly > complicating it even more. The consequences of such a step are far-reaching. > > And till now, no-one has presented the really pressing use cases that would > warrant such a step. How can you integrate a preprocessor without misaligning error messages and debugging information? I would have already done this myself if I thought it was possible. A way to hook into the compiler to run external programs would be very handy and let us craft our own solutions without adding junk into the compiler. I put this into the category of dogma because we’re being asked to provide “valid” use cases instead of trusting that we have know what’s best for our own code. It’s not possible to know in advance what people may need so providing them good tools as a fail safe is only sensible. My own case I had just know was hard coded some vertex data from a C program and if I had a good macro syntax I could have finished it much quicker and it would have looked nicer. It doesn’t matter if this was “best practice” or not. I just wanted to finish it so I could move on to more important things. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
In our previous episode, C Western said: > > I can do things like +infinity*2 and +infinity-3 and even sqr(infinity) > > and power(infinity,10) the results are still +Inf which is expected? > > ??but I can?t do anything involving subtracting infinity from > > infinity.? Isn't that normal? Otherwise, what would inf+inf-inf be if you know that (inf+inf) =inf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
In our previous episode, Michael Van Canneyt said: > > Nothing stops people from preprocessing their code if they need really > advanced preprocessing: The toolchain can handle it already. > > But there is no need to integrate it in the compiler and thus needlessly > complicating it even more. The consequences of such a step are far-reaching. > > And till now, no-one has presented the really pressing use cases that would > warrant such a step. (note that external preprocessing also creates an extra level above FPC preprocessing. There is no conflict between those, because external is always first. I agree fully with Michael. It is the usual "if all you have is a hammer" argument) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Mark Morgan Lloyd wrote: The other alternative would be break the compiler in such a way that it was usable from a standard makefile, but since there isn't separate compilation of definition and implementation parts this would probably impact on type safety. I believe that this too has been debated in the past, and has attracted even less enthusiasm than a hook for an extrnal preprocessor preprocessor. Nothing stops people from preprocessing their code if they need really advanced preprocessing: The toolchain can handle it already. But there is no need to integrate it in the compiler and thus needlessly complicating it even more. The consequences of such a step are far-reaching. And till now, no-one has presented the really pressing use cases that would warrant such a step. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On 20/06/18 10:00, Ryan Joseph wrote:
On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt wrote:>
> Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It really
sucks trying to fight the compiler sometimes because of engrained dogma.
How does an external preprocessor work if the compiler doesn’t about it?
Doesn’t it totally mess up the line numbers for debugging? I’d happily write my
own even if it was compatible with the compiler.
Pascal has some trivial macro support. {$define m:=xyz}> > If you need more than
that, you can use m4 or so. Lazarus has support for> pre-compile commands, so you can
always configure it to preprocess your> files if you are so inclined.
We've been here before, and not long ago.
I've done my fair share of language advocacy in the past and in general
am no friend of C, but I suggest that a number of people- on both the
"pure" and the "pragmatic" sides of the argument- could very much do
with "cooling it".
I'm pretty sure that the preprocessor issue was discussed a few months
ago with somebody pointing out that the Pascal compiler's macro handling
was deficient in that it had no concept of parameters. I believe that
the consensus was that it might possibly be desirable for the compiler
to be able to invoke an external preprocessor for the main unit and then
for each one that it imported, but that we didn't get as far as
considering its implications for include files etc.
The other alternative would be break the compiler in such a way that it
was usable from a standard makefile, but since there isn't separate
compilation of definition and implementation parts this would probably
impact on type safety. I believe that this too has been debated in the
past, and has attracted even less enthusiasm than a hook for an extrnal
preprocessor preprocessor.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
Il 20/06/2018 12:14, Michael Van Canneyt ha scritto: If you need a preprocessor, maybe you simply need to rethink your design. If you could explain your actual problem, maybe we can help solving it without resorting to preprocessing. In my experience a preprocessor comes handy mainly during the development of an application. E.g.: you need to evaluate if solution A is better than solution B, and each solution involves calling a different procedure with a different number of parameters, in dozens of points of your code. This is an example from a C program: #define CON_TMAX #ifdef CON_TMAX #define AspettaRisposta(x,y,z) SMD aspetta_risp(y,z) #else #define AspettaRisposta(x,y,z) SMD rqwait(x,z) #endif A #define makes it possible to compare the two solutions with the same efficiency you'll get in the final version. A workaround, such as an extra procedure which does the same job, generates some extra code and may not tell you the full story. It's not matter of rethinking the design, but of picking up the best design. Just my 2 cents Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> Am 20.06.2018 um 12:00 schrieb fpc-pascal-requ...@lists.freepascal.org: > > Date: Wed, 20 Jun 2018 16:25:39 +0700 > From: Ryan Joseph > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] Proper preprocessor? > Message-ID: > Content-Type: text/plain; charset=utf-8 > > How does an external preprocessor work if the compiler doesn’t about it? > Doesn’t it totally mess up the line numbers for debugging? If the preprocessor really does such extended work, can't one simply keep the intermediate output of the preprocessor as a source file and then relate to that? I did quite some work in transposing C header files to Pascal. Most of the defines could simply be converted into const statements by h2pas. For more elaborate stuff, like versions of installed C libs and such, the usual tools known C programming (m4, configure, …) can be used (Ultrastar Deluxe has quite some use of them), as already mentioned by Michael Van Canneyt. Due to their complexity, I would avoid them as much as possible. My 2 cents - MiSchi. signature.asc Description: Message signed with OpenPGP ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Ryan Joseph wrote: On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt wrote: Because it is simply a bad idea ? Yeah that’s what the programming gurus in ivory towers and professors keep saying but what about the person actually trying to finish some work? It really sucks trying to fight the compiler sometimes because of engrained dogma. There are plenty of languages out there without preprocessor support. People manage to program without it just fine. No dogma is involved. If you need a preprocessor, maybe you simply need to rethink your design. If you could explain your actual problem, maybe we can help solving it without resorting to preprocessing. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018 16:25:39 +0700 Ryan Joseph wrote: > > On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt > > wrote: > > > > Because it is simply a bad idea ? > > Yeah that’s what the programming gurus in ivory towers and professors keep > saying but what about the person actually trying to finish some work? It > really sucks trying to fight the compiler sometimes because of engrained > dogma. It's your dogma, that only professors dislike macros. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt
> wrote:
>
> Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It really
sucks trying to fight the compiler sometimes because of engrained dogma.
How does an external preprocessor work if the compiler doesn’t about it?
Doesn’t it totally mess up the line numbers for debugging? I’d happily write my
own even if it was compatible with the compiler.
>
> Pascal has some trivial macro support. {$define m:=xyz}
>
> If you need more than that, you can use m4 or so. Lazarus has support for
> pre-compile commands, so you can always configure it to preprocess your
> files if you are so inclined.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
James Richters wrote: I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program I suggest to file a bug report. It is very unfortunate that the Math unit doesn't conform to IEEE-758. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wed, 20 Jun 2018, Ryan Joseph wrote:
Are there any plans to make a proper preprocessor like #define in C? I’m
not saying this is good programming practice or anything but I just had a
really annoying copy and paste chore on some temporary code which I could
have easily accomplished if I had #define like in C. It’s such a trivial
thing to add I wonder why it was never included in Pascal.
Because it is simply a bad idea ?
Pascal has some trivial macro support. {$define m:=xyz}
If you need more than that, you can use m4 or so. Lazarus has support for
pre-compile commands, so you can always configure it to preprocess your
files if you are so inclined.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Proper preprocessor?
Are there any plans to make a proper preprocessor like #define in C? I’m not saying this is good programming practice or anything but I just had a really annoying copy and paste chore on some temporary code which I could have easily accomplished if I had #define like in C. It’s such a trivial thing to add I wonder why it was never included in Pascal. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math with infinity and NaN
On 19/06/18 22:50, James Richters wrote:
I’ve been updating my old programs to use the MATH unit in freepascal
and while testing things I came across a runtime error 217 Invalid
floating point operation. Here is my test program
Uses math;
var
variable1:double;
variable2:double;
Begin
variable1:= Infinity;
variable2:= -1*Infinity;
Writeln(variable1,' ',Variable2,' ',Variable1+Variable2);
End.
My output is:
Running "i:\programming\test\testmath.exe "
An unhandled exception occurred at $004015F6:
EInvalidOp: Invalid floating point operation
$004015F6 main, line 8 of i:/programming/test/testmath.pas
+Inf -Inf
According to the link here: https://en.wikipedia.org/wiki/NaN
NaN should be produced:
The additions (+∞) + (−∞), (−∞) + (+∞) and equivalent subtractions (+∞)
− (+∞) and (−∞) − (−∞).
I can do things like +infinity*2 and +infinity-3 and even sqr(infinity)
and power(infinity,10) the results are still +Inf which is expected…
but I can’t do anything involving subtracting infinity from
infinity. Here is another test program that illustrates this more clearly:
Uses math;
var
variable1:double;
variable2:double;
Begin
variable1:= 1/0;
variable2:= -1/0;
Writeln(' V1',variable1);
Writeln(' V2',variable2);
Writeln(' SQRT(-1)',Sqrt(-1));
Writeln(' V1*V1',variable1*variable1);
Writeln(' V1*V2',variable1*variable2);
Writeln(' V1+3',variable1+3);
Writeln(' V1+V1',variable1+variable1);
Writeln(' V1-3',variable1-3);
Writeln(' Sqr(V1)',Sqr(Variable1));
Writeln(' Sqr(V2)',Sqr(Variable2));
Writeln(' Sqrt(-1)',Sqrt(-1));
Writeln(' Sqrt(V1)',Sqrt(Variable1));
Writeln('Power(V1,10)',Power(Variable1,10));
Writeln(' ABS(V2)',ABS(Variable2));
Writeln(' Sqrt(-1*V1)',Sqrt(-1*Variable1));//runtime error 217
Should be NAN
Writeln(' Sqrt(V2)',Sqrt(Variable2)); //runtime error 217
Should be NAN
Writeln(' V1-V1',variable1-variable1); //runtime error 217
Should be NAN
Writeln(' V1+V2',variable1+variable2); //runtime error 217
Should be NAN
End.
Running "i:\programming\test\testmath.exe "
V1 +Inf
V2 -Inf
SQRT(-1) Nan
V1*V1 +Inf
V1*V2 -Inf
V1+3 +Inf
V1+V1 +Inf
V1-3 +Inf
Sqr(V1) +Inf
Sqr(V2) +Inf
Sqrt(-1) Nan
Sqrt(V1) +Inf
Power(V1,10) +Inf
ABS(V2) +Inf
An unhandled exception occurred at $00401A43:
EInvalidOp: Invalid floating point operation
$00401A43 main, line 22 of I:/Programming/Test/testmath.pas
Sqrt(-1*V1)
It seems to me that the whole purpose of +Inf, -Inf, and NaN was so you
could evaluate complex formulas and NOT get a runtime error… Is this
behavior just a bug that should be reported? Testing was done with V3.0.4
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
My first reaction is that
SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision])
would be required (I can't remember what the default is), but it doesn't
stop the error (x86_64/linux). I suspect a bug, though I am slightly
surprised it hasn't surfaced before.
Colin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
