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;
B
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 th
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 ha
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
> 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 som
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
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 s
> 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
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
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
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 th
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. Th
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? Oth
> 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
> 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 i
> 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
> yo
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 er
> 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 persona
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".
>
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 t
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
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 thu
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,
> s
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
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. Ev
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 d
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
> 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
> 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
> b
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’
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 t
> 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
> 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
> 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 d
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 t
> 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 si
> 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 w
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
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 w
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,
w
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
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 calling
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,
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 et
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
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() a
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 ma
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:doubl
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. I
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 infi
>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
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
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.f
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
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 generati
> 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
> 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 thing
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
>
> On Jun 21, 2018, at 12:51 PM, Sven Barth via fpc-pascal
> wrote:
>
> 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 Lazaru
This is compatible with IEEE-754. Section 7.2 says
7.2 Invalid operation
For operations producing results in floating-point format, the default
result of an operation that signals the
invalid operation exception shall be a quiet NaN that should provide
some diagnostic information (see 6.2)
Zitat von C Western :
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'
> On Jun 21, 2018, at 1:21 PM, Ryan Joseph wrote:
>
> Thanks Sven. So it was the Lazarus step I was missing! I know about using
> “lazbuild” from the command line but there are many .lpi projects in
> /compiler. Which one is ppc386? I see ppcx64.lpi but not ppc386.
I figured out how to build
Quoting James Richters :
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,
63 matches
Mail list logo
