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,
> 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
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'
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)
> 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
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 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
> 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
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 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
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 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
>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
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
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
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: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 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
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
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
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,
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
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
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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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
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 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
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
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
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".
>
> 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:
> > 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 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
> 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 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
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
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
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
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
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
> 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
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
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 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
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 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
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 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
63 matches
Mail list logo
