Re: [fpc-pascal] Proper preprocessor?

2018-06-21 Thread Ryan Joseph


> 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 subjective - point of view, your examples only serve to 
> demonstrate why we should definitely not support macros...

For any example I can give it’s easy to extrapolate into some scenario where it 
would be a disaster. I get that. The reason I ever wanted to make a macro was 
for personal use to give some project specific meaning to some construct or a 
quick hack. Frameworks like Apple uses,  often use macros to document parts of 
code in a way which otherwise isn’t part of the language and no suitable for 
comments. I’m not saying this is how we all should program. I don’t suggest 
people go out and start using macros in place of functions.

Btw why was the $define:= syntax ever introduced in the first place? adding a 
parameter to the syntax is a minor extension but it sounds like Pascal 
programers here really don’t like it in general.

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?

2018-06-21 Thread Sven Barth via fpc-pascal

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 assert(x):=if not (x) then writeln('assert: x')}

var
i: integer = 100;
begin
assert(i = 101); // assert: i=101
end.
That directly can't be done, but Assert() in Pascal is nice (and quite 
powerful) nevertheless:


=== code begin ===

program ttest;

{$Assertions on}

var
  i: LongInt;
begin
  i := 42;
  Assert(i = 21, 'Bla, Blubb');
end.

=== code end ===

This will print:

=== output begin ===

Bla, Blubb (ttest.pp, line 9).

=== output end ===

If $Assertions is set to Off the complete Assert() line will be absent 
from the compiled code.


If unit SysUtils is included then a failed assertion results in an 
EAssertionError though that can be changed by setting AssertErrorProc in 
unit System. If unit System is not included then the line above will be 
printed and the program terminated.


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?

2018-06-21 Thread Michael Van Canneyt



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), H5T_NATIVE_DOUBLE);
H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);



So there was a solution but I can see why the C macro version was easier to look at 
it. Was that not a good reason to use a macro? I like how the macro cleaned that up. 
Sven’s suggested answer of "@s1_t(nil^).a” is even more obscure imo.


The above qualifies IMHO as definite proof that macros are for real corner cases. 
It must have been somewhere in 1988 when I last needed such code.




If you guys don’t mind I may try to remember and collect the uses of
macros I’ve wanted at random times through out the year and see if there
is indeed not practical or good use for them in modern Pascal.

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.


'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 subjective - point of view, your examples only serve to demonstrate 

why we should definitely not support macros...

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

2018-06-21 Thread Ryan Joseph


> 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);
> H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
> 

So there was a solution but I can see why the C macro version was easier to 
look at it. Was that not a good reason to use a macro? I like how the macro 
cleaned that up. Sven’s suggested answer of "@s1_t(nil^).a” is even more 
obscure imo.

If you guys don’t mind I may try to remember and collect the uses of macros 
I’ve wanted at random times through out the year and see if there is indeed not 
practical or good use for them in modern Pascal.

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 assert(x):=if not (x) then writeln('assert: x')}

var
i: integer = 100;
begin
assert(i = 101); // assert: i=101
end.


Regards,
Ryan Joseph

___
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

2018-06-21 Thread Paul Breneman

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 (
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)...


It works and looks *easy* again.  Web page updated a little as I go 
celebrate!

___
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

2018-06-21 Thread Adriaan van Os

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 masked exceptions. That was with fpc-2.6.4. 
I can't reproduce it anymore with fpc-3.0.4, so it seems to be fixed.


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?

2018-06-21 Thread Marc Santhoff
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 wanted to reduce typing and copy/paste bugs.
> 
> {$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)} 

That funky code is the way some structured elements are defined when using
HDF5 file format library. It's pure C optimized for speed and my goal was to
adapt it to pascal. Using somesuch in C seems to be quite normal, it has an
entry in Wikipedia...

In the end I made the macro an inlined pascal function using the method of
"cruel casting"[tm]. After preprocessing C code should look similar.


#define HOFFSET(S,M)(offsetof(S,M)) // offsetof is a standard define

H5Tinsert(s1_tid, "a_name", HOFFSET(s1_t, a), H5T_NATIVE_INT);
H5Tinsert(s1_tid, "c_name", HOFFSET(s1_t, c), H5T_NATIVE_DOUBLE);



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);
H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);



> type 
> s1_t = record 
> a: longint; 
> b: single; 
> c: double; 
> end; 
> var 
> s1: s1_t; 
> BEGIN 
> s1.a := 12345; 
> s1.b := 1.1; 
> s1.c := 1.2; 
> 
> writeln(HOFFSET(s1, a));
> END. 
> 
> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
-- 
Marc Santhoff 
___
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

2018-06-21 Thread gtt


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.
Suppressing the exception makes them act like quiet nans, but the  
fact that they need suppressing of the exception makes them  
signaling nans.


This is not correct. Signal and quit NaNs ar precisly defined:

Quote from  
https://en.wikipedia.org/wiki/IEEE_floating_point#Interchange_formats


"For NaNs, quiet NaNs and signaling NaNs are distinguished by using the
most significant bit of the trailing significand field exclusively
(the standard recommends 0 for signaling NaNs, 1 for quiet NaNs, so
that a signaling NaNs can be quieted by changing only this bit to 1,
while the reverse could yield the encoding of an infinity),
and the payload is carried in the remaining bits."

In the IEEE-754 standard it is "3.4 Binary interchange format encodings"

You can test, that the Nan is a quiet NaN with

Uses
  math, sysutils;
var
  variable1, variable2:double;
  iv1: int64 absolute variable1;
Begin
  SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,  
exOverflow, exUnderflow, exPrecision]);

  variable1:= sqrt(-1);
  variable2 := Pi-4;
  variable1 := sqrt(variable2);
  Writeln(variable1, '  ', IntToHex(iv1, 16));
End.

C:\TMP>fpc64304 xx1.pas

C:\TMP>D:\FPC304\bin\i386-win32\ppcrossx64.exe xx1.pas
Free Pascal Compiler version 3.0.4 [2017/10/06] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling xx1.pas
Linking xx1.exe
13 lines compiled, 0.2 sec, 71824 bytes code, 4964 bytes data

C:\TMP>xx1.exe
 Nan  FFF8

The 8 nibble shows that the highest bit of the mantissa is 1 and
therefore you have a quiet NaN.

___
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

2018-06-21 Thread 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.   Suppressing the exception makes them act like quiet 
nans, but the fact that they need suppressing of the exception makes them 
signaling nans.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
g...@wolfgang-ehrhardt.de
Sent: Thursday, June 21, 2018 9:32 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] math with infinity and NaN


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 mean it would never cause  
> the runtime error?   To my understating signaling NaN raises the  
> exception, and Quiet Nan does not.. it just quietly sets the variable 
> to NaN and continues by default.
> It states that the DEFAULT result shall be this quiet NaN so if that's 
> the case then setting SetExceptionMask([exInvalidOp]); should not be 
> required to prevent the runtime error.  The default behavior should be 
> that it's a Quiet NaN.

As far as I understand: if the exInvalidOp is masked the default result is a 
quiet NaN. If exInvalidOp is not masked the excption is thrown.
(I do not know if a result is set to NaN and how this could be exploited).

___
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?

2018-06-21 Thread Sven Barth via fpc-pascal

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 glance unless I totally underestimate something it appears to be a 
trivial extension to the define:= syntax but admittedly it’s edge case stuff 
and probably not widely used.

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 
wanted to reduce typing and copy/paste bugs.

{$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)}

type
 s1_t = record
 a: longint;
 b: single;
 c: double;
 end;
var
 s1: s1_t;
BEGIN
 s1.a := 12345;
 s1.b := 1.1;
 s1.c := 1.2;

 writeln(HOFFSET(s1, a));
END.


The officially sanctioned way is this:

@s1_t(nil^).a

Though I do have the idea to extend the Ofs() intrinsic to handle a type 
expression as well. E.g. Ofs(s1.a) returns @s1.a, but I'd like 
Ofs(s1_t.a) to return @s1_t(nil^).a.


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?

2018-06-21 Thread Ralf Quint

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 usual point of making the code less readable applies as well.

+1



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

2018-06-21 Thread 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 glance unless I totally underestimate something it appears to be a 
trivial extension to the define:= syntax but admittedly it’s edge case stuff 
and probably not widely used.

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 
wanted to reduce typing and copy/paste bugs.

{$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)} 

type 
s1_t = record 
a: longint; 
b: single; 
c: double; 
end; 
var 
s1: s1_t; 
BEGIN 
s1.a := 12345; 
s1.b := 1.1; 
s1.c := 1.2; 

writeln(HOFFSET(s1, a));
END. 

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?

2018-06-21 Thread Sven Barth via fpc-pascal
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 (even if it’s hidden behind a
> modeswitch) and if so should I privately contact someone on the compiler
> team to verify that I’m doing compiler approved things? I have lots of
> stupid questions like is “array of ansistring” ok and can I use strutils
> functions etc.. and I don’t want to pollute the list with them.
>

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
usual point of making the code less readable applies as well.

To answer your further questions: AnsiString should not be used and units
that can be used are only those in the rtl directory. Everything inside
packages is not available. You could however check the cutils unit for
equivalent functionality.

For more questions you can start a thread in fpc-devel. That's the purpose
of that mailing list after all.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Equivalent of Delphi map files...

2018-06-21 Thread Adriaan van Os

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 linker has


 -map map_file_path
 Writes a map file to the specified path which details all symbols and their 
addresses in the output image.


and using for example -k"-map link-map.txt" works. It's not a big issue, but I suggest to either 
implement -Xm (if not already) or to remove it from the list of available options.


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?

2018-06-21 Thread Ryan Joseph
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 privately contact someone on the compiler team 
to verify that I’m doing compiler approved things? I have lots of stupid 
questions like is “array of ansistring” ok and can I use strutils functions 
etc.. and I don’t want to pollute the list with them.


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

2018-06-21 Thread gtt


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 mean it would never cause  
the runtime error?   To my understating signaling NaN raises the  
exception, and Quiet Nan does not.. it just quietly sets the  
variable to NaN and continues by default.
It states that the DEFAULT result shall be this quiet NaN so if  
that's the case then setting SetExceptionMask([exInvalidOp]); should  
not be required to prevent the runtime error.  The default behavior  
should be that it's a Quiet NaN.


As far as I understand: if the exInvalidOp is masked the default result
is a quiet NaN. If exInvalidOp is not masked the excption is thrown.
(I do not know if a result is set to NaN and how this could be exploited).

___
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

2018-06-21 Thread James Richters
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 Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
g...@wolfgang-ehrhardt.de
Sent: Thursday, June 21, 2018 2:46 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] math with infinity and NaN


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,  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?

The case SQRT(-1) seems to be handled by the compiler, just like the definition 
Nan = 0/0 in math.

If you have an expression, which is not handled at compile time you get the 
EInvalidOp exception, try

variable2 := Pi-4;
variable1 := sqrt(variable2);
Writeln(variable1);

___
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

2018-06-21 Thread 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 mean it would never cause the runtime 
error?   To my understating signaling NaN raises the exception, and Quiet Nan 
does not.. it just quietly sets the variable to NaN and continues by default.   
It states that the DEFAULT result shall be this quiet NaN so if that's the case 
then setting SetExceptionMask([exInvalidOp]); should not be required to prevent 
the runtime error.  The default behavior should be that it's a Quiet NaN.


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
g...@wolfgang-ehrhardt.de
Sent: Wednesday, June 20, 2018 3:42 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] math with infinity and NaN

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).
These operations are:

...
b) multiplication: multiplication(0, ∞) or multiplication(∞, 0)

...

d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction  
of infinities, such as:
addition(+∞, −∞)

e) division: division(0, 0) or division(∞, ∞)

...

g) squareRoot if the operand is less than zero


You get the expected quite NaN results if you add the line

SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,  
exOverflow, exUnderflow, exPrecision]);

to your test programs.

___
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

2018-06-21 Thread gtt


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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-06-21 Thread Sven Barth via fpc-pascal
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.
> Is there a command line flag to enable a modeswitch?
>

Not tested, but -MArrayOperators *should* work (it takes both modes and
modeswitches).
One point to keep in mind however: any single modeswitch setting is
overwritten once a mode is encountered, this includes both the $mode
directive and the -M option (or e.g. -S2).

Regards,
Sven

>
___
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

2018-06-21 Thread Sven Barth via fpc-pascal
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
> > 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 ===
>
> Sven, please could we have a further update when you decide what version
> of the compiler will get the new facility, so that those of us with code
> that might clash can make sure we have version-specific conditionals in
> place.
>

New language features are normally not merged to a fixes branch (there were
exceptions in the past, but they weren't too big). So if you check for >=
3.1.1 you're set.

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?

2018-06-21 Thread Sven Barth via fpc-pascal
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? I see ppcx64.lpi but not ppc386.
>

pp.lpi is the i386 one (it was the first one, so no suffix ;)).


> I figured out how to build the “pp” project (not sure if this is the right
> one) but I’m getting a PPU error now. What do I do about system.ppu?
>
> Ryans-MacBook-Pro:fpc ryanjoseph$
> /Developer/ObjectivePascal/fpc/compiler/i386/pp
> /Users/ryanjoseph/Downloads/macro_test.pas
> Free Pascal Compiler version 3.1.1 [2018/06/21] for i386
> Copyright (c) 1993-2018 by Florian Klaempfl and others
> Target OS: Darwin for i386
> Compiling /Users/ryanjoseph/Downloads/macro_test.pas
> PPU Loading /usr/local/lib/fpc/3.1.1/units/i386-darwin/rtl/system.ppu
> PPU Invalid Version 195
> Fatal: Can't find unit system used by macro_test
> Fatal: Compilation aborted
>

You need to pass the correct parameters. I usually pass the following:

-n -Furtl/units/- -viwn - FEtestoutput ./fpctests/mytest.pp

And set the current working directory to the top level directory of the
checkout.

testoutput and fpctests are two directories that I created in the top level
directory to keep things clean.

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

2018-06-21 Thread Adriaan van Os

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 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.


Even with masked exceptions, runtime errors are produced in the Math unit. That is not conformant 
to the standard.


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] Feature announcement: Dynamic array extensions

2018-06-21 Thread Ryan Joseph
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
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-06-21 Thread Mattias Gaertner
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-06-21 Thread Ryan Joseph


> 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);
i: integer;
begin
arr += [4];
for i in arr do
writeln(i);


thanks!



Regards,
Ryan Joseph

___
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

2018-06-21 Thread Mattias Gaertner
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
___
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

2018-06-21 Thread Mark Morgan Lloyd

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 
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 ===


Sven, please could we have a further update when you decide what version 
of the compiler will get the new facility, so that those of us with code 
that might clash can make sure we have version-specific conditionals in 
place.


--
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] math with infinity and NaN

2018-06-21 Thread gtt


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,  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?


The case SQRT(-1) seems to be handled by the compiler, just like the  
definition

Nan = 0/0 in math.

If you have an expression, which is not handled at compile time you get
the EInvalidOp exception, try

variable2 := Pi-4;
variable1 := sqrt(variable2);
Writeln(variable1);

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

2018-06-21 Thread Ryan Joseph


> 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 the “pp” project (not sure if this is the right one) 
but I’m getting a PPU error now. What do I do about system.ppu?

Ryans-MacBook-Pro:fpc ryanjoseph$ 
/Developer/ObjectivePascal/fpc/compiler/i386/pp 
/Users/ryanjoseph/Downloads/macro_test.pas 
Free Pascal Compiler version 3.1.1 [2018/06/21] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling /Users/ryanjoseph/Downloads/macro_test.pas
PPU Loading /usr/local/lib/fpc/3.1.1/units/i386-darwin/rtl/system.ppu
PPU Invalid Version 195
Fatal: Can't find unit system used by macro_test
Fatal: Compilation aborted

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

2018-06-21 Thread gtt


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't surfaced before.



You forgot the most important item: exInvalidOp! At least on Win7 the code
works as exptected.


___
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

2018-06-21 Thread gtt

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).

These operations are:

...
b) multiplication: multiplication(0, ∞) or multiplication(∞, 0)

...

d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction  
of infinities, such as:

addition(+∞, −∞)

e) division: division(0, 0) or division(∞, ∞)

...

g) squareRoot if the operand is less than zero


You get the expected quite NaN results if you add the line

SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,  
exOverflow, exUnderflow, exPrecision]);


to your test programs.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

2018-06-21 Thread Ryan Joseph


> 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 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. 
> 

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.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal