On Thu, 21 Jun 2018 15:17:39 +0700
Ryan Joseph wrote:
>[...]
> Finally got to try this. It’s really satisfying being able to do:
>[...]
> for i in arr do
Note: This was supported for a long time.
Mattias
___
fpc-pascal maillist -
I mean the += [] part. :)
> On Jun 21, 2018, at 3:37 PM, Mattias Gaertner
> wrote:
>
> Note: This was supported for a long time.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Florian Klämpfl wrote:
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
Ryan Joseph schrieb am Do., 21. Juni 2018,
08:37:
>
>
> > 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?
Mark Morgan Lloyd schrieb am Do., 21.
Juni 2018, 09:11:
> On 20/06/18 20:00, Sven Barth via fpc-pascal wrote:
>
> > 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
> >
Mattias Gaertner schrieb am Do., 21. Juni 2018,
09:24:
> On Wed, 20 Jun 2018 21:56:56 +0200
> Sven Barth via fpc-pascal wrote:
>
> >[...]
> > The modeswitch is enabled by default in Delphi modes as this feature was
> > added for Delphi compatibility.
>
> I would like to use that for objfpc.
>
> On Jun 21, 2018, at 2:56 AM, Sven Barth via fpc-pascal
> wrote:
>
> Addendum: the support for the "+" operator is now coupled to a new modeswitch
> "ArrayOperators".
Finally got to try this. It’s really satisfying being able to do:
var
arr: array of integer = (1, 2, 3);
On 20/06/18 20:00, Sven Barth via fpc-pascal wrote:
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
On Wed, 20 Jun 2018 21:56:56 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> The modeswitch is enabled by default in Delphi modes as this feature was
> added for Delphi compatibility.
I would like to use that for objfpc.
Is there a command line flag to enable a modeswitch?
Mattias
Zitat von Adriaan van Os :
Even with masked exceptions, runtime errors are produced in the Math
unit. That is not conformant to the standard.
Even with masked exInvalidOp? Can you give an example?
___
fpc-pascal maillist -
I’m actually making rapid progress on a macro function syntax where the
parameters are replaced by the inputs when called:
{$define put(x):='into_x’}
put(100); // replaces to ‘into_100’
Do I have permission to develop this feature (even if it’s hidden behind a
modeswitch) and if so should I
Peter Vreman wrote:
The -Xm is 2.1.1 only and not available in 2.0.x. The -Xm is also
available for linux and can be added for other platforms if needed and
the linker supports it.
Is -Xm supposed to work on Mac OS X ? I don't see any file being generated, nor do I get an error
message. The
>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).
If it shall be a quiet NaN doesn't that mean it would never cause the
The compiler does seem to be filtering out the conditions that hard coded to
resolve to NaN. That explains the seemingly inconsistent results, when I set
variables and try the operations that seemed to work before they now produce
the error.
Thanks for pointing that out.
-Original
Zitat von James Richters :
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).
If it shall be a quiet NaN doesn't that
On 6/21/2018 8:08 AM, Sven Barth via fpc-pascal wrote:
Of course you have permission to work on this, after all this is Open
Source software. However whether we'd want to integrate this is a
totally different topic.
I personally am against it, cause I see no real world use in it and
the
Ryan Joseph schrieb am Do., 21. Juni 2018,
15:53:
> I’m actually making rapid progress on a macro function syntax where the
> parameters are replaced by the inputs when called:
>
> {$define put(x):='into_x’}
>
> put(100); // replaces to ‘into_100’
>
> Do I have permission to develop this feature
> On Jun 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal
> wrote:
>
> For more questions you can start a thread in fpc-devel. That's the purpose of
> that mailing list after all.
>
Thanks, I’ll post there tomorrow about the technical stuff.
At first glance unless I totally underestimate
The fact that it raises the exception at all makes it a signaling NaN not a
quiet Nan, but they are supposed to be Quiet Nan which never throw the
exception according to the specification which clearly states they are Quiet
Nans, not Signaling Nans. Suppressing the exception makes them act
g...@wolfgang-ehrhardt.de wrote:
Zitat von Adriaan van Os :
Even with masked exceptions, runtime errors are produced in the Math
unit. That is not conformant to the standard.
Even with masked exInvalidOp? Can you give an example?
Math.power with a negative base would except, even with
Am 21.06.2018 um 17:25 schrieb Ryan Joseph:
On Jun 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal
wrote:
For more questions you can start a thread in fpc-devel. That's the purpose of
that mailing list after all.
Thanks, I’ll post there tomorrow about the technical stuff.
At first
Zitat von James Richters :
The fact that it raises the exception at all makes it a signaling
NaN not a quiet Nan, but they are supposed to be Quiet Nan which
never throw the exception according to the specification which
clearly states they are Quiet Nans, not Signaling Nans.
On Thu, 2018-06-21 at 22:25 +0700, Ryan Joseph wrote:
> >
> I did a search and found only a few hits on the topic. Since I’ve been
> giving theoretical examples here’s something more practical a user
> attempted. Can you do that without macros? If I had to guess he had some
> funky code and just
On 06/20/2018 12:01 PM, Paul Breneman wrote:
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 (
> On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt
> wrote:
>
> 'Nice' is not an argument.
>
> If someone else assumes that assert() works as expected - i.e. throws an
> exception, then your macro will mess up his code, leading to
> unpredictable results.
>
> From my - admittedly
On Fri, 22 Jun 2018, Ryan Joseph wrote:
On Jun 22, 2018, at 3:19 AM, Marc Santhoff wrote:
function HOFFSETP(rectypevar: pointer; fieldvar: pointer): longint; inline;
begin
HOFFSETP := longint(fieldvar - rectypevar);
end;
H5Tinsert(s2_tid, 'c_name', HOFFSETP(@s2[0], @s2[0].c),
> On Jun 22, 2018, at 3:19 AM, Marc Santhoff wrote:
>
> function HOFFSETP(rectypevar: pointer; fieldvar: pointer): longint; inline;
> begin
> HOFFSETP := longint(fieldvar - rectypevar);
> end;
>
> H5Tinsert(s2_tid, 'c_name', HOFFSETP(@s2[0], @s2[0].c), H5T_NATIVE_DOUBLE);
>
Am 22.06.2018 um 06:35 schrieb Ryan Joseph:
Here’s a macro I like from C. It captures the assert expression and prints it
back out into the console (it would halt the program also). Can this be done in
Pascal? In C they return the file name and line number also which is really
nice.
{$define
> 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
> 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
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
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
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,
33 matches
Mail list logo
