[fpc-pascal] 64-bit ARM and CPUARM

[Ched via fpc-pascal]

Hello All,

Just a little question. In

In https://www.freepascal.org/docs-html/prog/progap7.html , there is specified 
that
CPUARM  Free Pascal target is an ARM 32-bit processor.

What about ARM 64-bit processors like the ones in Raspberries ?
Something similar to CPUPOWERPC with two subcatagories CPUPOWERPC32 and 
CPUPOWERPC64 ?

Cheers, Ched'
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cache-line alignment for records

[Ched via fpc-pascal]

Hello,

Ok for the records for internal calculations. But sometimes, records are used for reading/writing 
structured files. Does "packed" in "packed array" and "packed record" always forbid the compiler to play 
with alignments ?


Kindest regards, Ched'




Le 29.03.23 à 21:07, Jonas Maebe via fpc-pascal a écrit :

On 29/03/2023 16:00, Matias Ezequiel Vara Larsen via fpc-pascal wrote:

So if I have a type like:

test = record
   r: DWord;
   s: Word;
end;

Then, I define the variable `nada` as an array of `test` type:

var
   nada: array[0..2] of test;

Is the `@nada[1].r` element aligned to 4-bytes?


Records always get padded to a multiple of their internal alignment requirement. Unless you're on a 
system where the default packrecords value is 2 (msdos-i8086 has that probably), the above record's 
internal field alignment is 4 and hence its size will also be padded to a multiple of 4.



Jonas

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

Re: [fpc-pascal] Bug or feature ?

[Ched via fpc-pascal]

Le 27.07.2022 à 17:41, DougC via fpc-pascal a écrit :

WRITELN(F: 'Hello');
is not proper Pascal.


Yes, Doug, I agree ; but it is compiled with no warning and runs perfectly. Now, why the compiler do not 
complain... ?


Cheers, Ched'

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

[fpc-pascal] Bug or feature ?

[Ched via fpc-pascal]

Hello All,

I have a long code which include lines for writing stuffs into an assigned 
writable text-file F.

   WRITELN(F: 'Hello');

   WRITELN(F, 'Hello');

The code can be compiled with 3.2.2 in i386/windows and i386/linux and runs both times at perfection. 
But... i'm wondering if the first line is really legal... Any advice ?


Cheers, Ched'.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] {$include %dateyear%}

[Ched via fpc-pascal]

Well, Writeln('{$I %DATEMONTH%}'+'/'); can be compiled, but the answer is... 
{$I %DATEMONTH%} .

I think that my level of english is by far too low to make the correct sentence.

Cheers, James, Raoul





Le 25.12.21 à 21:06, James Richters a écrit :

I see what you mean... I thought it was an Integer because If you do something 
like:
Writeln({$I %DATEMONTH%}+'/'+{$I %DATEDAY%}+'/'+{$I %DATEYEAR%});
You get Error: Operator is not overloaded: "ShortInt" + "Char"

But that's not what it is it's  just like typing in hard coded numbers 
after it's compiled.. because you can do things like
Writeln('{$I %DATEMONTH%}'+'/');
And you wouldn't be able to do that with variables or any type... so it's 
really not any variable type, it's just numeric text being inserted.

I don't really know what to call it, but integer seems to indicate it has a 
type, so I agree it should be distinguished from any specific variable type.

James



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

Re: [fpc-pascal] {$include %dateyear%}

[Ched via fpc-pascal]

Helolo James,

Thank you for your comment and proposal. As there is no type associated with non-string results, would it 
be better to say number instead of integer ? Or integer number ?


Season's greetings !

Cheers, Ched'



Le 24.12.2021 à 22:32, James Richters via fpc-pascal a écrit :

I would agree that the documentation actually states quite clearly that they 
are ALL strings except %linenum% and the documentation should be improved to be 
accurate.

Perhaps

{$INCLUDE %XXX%}
the {$INCLUDE} directive inserts a string or integer constant in the source 
code.
Here XXX can be one of the following:

CURRENTROUTINE
Inserts a string containing the name of the current routine. Useful for debug 
logging.
DATE
Inserts a string containing the current date. It will be formatted as 
/MM/DD.
DATEYEAR
Inserts an integer containing the year part of the current date.
DATEMONTH
Inserts an integer containing the month part of the current date.
DATEDAY
Inserts an integer containing the day part of the current date.
FPCTARGET
Inserts a string containing the target CPU name. (deprecated, use FPCTARGETCPU)
FPCTARGETCPU
Inserts a string containing the target CPU name.
FPCTARGETOS
Inserts a string containing the target OS name.
FPCVERSION
Inserts a string containing the current compiler version number.
FILE
Inserts a string containing the filename in which the directive is found.
LINE
Inserts a string containing the line number on which the directive is found.
LINENUM
Inserts an integer containing the line number on which the directive is found.
TIME
Inserts a string containing the current time, formatted as HH:MM:SS
TIMEHOUR
Inserts an integer containing the hour part of the current time.
TIMEMINUTE
Inserts an integer containing the minutes part of the current time.
TIMESECOND
Inserts an integer containing the seconds part of the current time.

If XXX is none of the above, then it is assumed to be the name of an 
environment variable. Its value will be fetched as a string from the 
environment when compiled, if it exists, otherwise an empty string is inserted.
(we don't need to mention the integer exceptions here  because we are only 
talking about environment variables now)

I didn't know these directives existed, so thanks for the Christmas present, 
these will be very useful!

James



-Original Message-
From: fpc-pascal  On Behalf Of Il 
Grande Beppe via fpc-pascal
Sent: Thursday, December 23, 2021 7:12 PM
To: FPC-Pascal users discussions 
Cc: Il Grande Beppe 
Subject: [fpc-pascal] {$include %dateyear%}

Hello All,

I'm reading https://www.freepascal.org/docs-html/prog/progsu41.html

It seems to me that {$include %dateyear%} , {$include %datemonthr%}  and 
{$include %dateday%}  are treated as numbers in the source code, not a string 
as expected  from the description (only linenum is supposed to be a number).

I'm really happy with numbers, but I think that the description could be 
improved , isn't it ?

Best wishes and season's greetings to all Freepascalists.

Cheers, Ched'

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

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


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

Re: [fpc-pascal] Writing Pascal Physics and Vectors

[Ched via fpc-pascal]

> Fade := Fade * Fade * Fade * Fade * Fade;

Why not Fade:=sqr(sqr(Fade))*fade ?

Cheers, Anthony, Ched




Le 15.10.21 à 22:18, Anthony Walter via fpc-pascal a écrit :
I've been working on writing Pascal bindings a friendly object orient interface to a few open source 
projects. I have put together Chipmunk2D, NanoVG, MiniMP3, and SDL2 for rendering nice real time platform 
independent programs where fast logic can be easily controlled with physics or fast graphics can easily 
be rendered.


If you are interested in hearing more, I've put up a quick and dirty video of one of my test scene that 
precisely detects points of contact and the forces behind them at the page below.


https://www.getlazarus.org/videos/physics/collisions/ 


Source code for the test scene is included on that page. If you want to help, I need to bounce ideas off 
people as well as test on Raspberry Pi, Mac, and Windows. Message me and maybe we can try to meet on a 
Discord channel.


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



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

Re: [fpc-pascal] string vs char

[Ched via fpc-pascal]

Well, well, understand.


OTOH, declaring a string of length 1 is sort of futile -- it uses
two bytes where a plain char declaration takes just one byte.


Not so futile as a string can be empty, not a char !

Regards, Dennis, Ched'
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why the difference in the rounded results?

[Ched via fpc-pascal]

Hello All,

In https://wiki.freepascal.org/Variables_and_Data_Types about Strings:
 // where:  1 < length <= 255
is to read as
 // where:  1 <= length <= 255
isn't it ?

Cheers, Ched

Le 15.10.21 à 18:44, James Richters via fpc-pascal a écrit :

The difference is because of the way floating point math works.. and how 
rounding works.
Rounding something that ends with 5 is ambiguous, because it could round up, or 
it could round down...
You can control the behavior of rounding with SetRoundMode();
See https://www.freepascal.org/docs-html/rtl/math/setroundmode.html
It seems that SetRoundMode is defaulting to SetRoundMode(rmNearest) which 
doesn't resolve ambiguity for things like 22.57500...  because there is no 
nearest... 22.57 is EXACTLY the same distance away as 22.58... BUT since we are 
using floating point... there could be a tiny difference between one or the 
other making SetRoundMode(rmNearest) round one way for 32 bit and another way 
for 64 bit.
If you want them to always round the same way, you can just set SetRoundMode() 
to either SetRoundMode(rmUp) or SetRoundMode(rmDown) and that will remove the 
ambiguity...
Note that rmUp or rmDown or rmNearest only affect result that round off 
something with a 5
So with rmUP
22.575 will ALWAYS come out 22.58
And with rmDown
22.575 will ALWAYS come out 22.57

The reason Delphi is showing 2.258000E+0001
And FPC 64 bit is showing   2.2578E+001
Is because delphi is not showing all the floating point digits... if you do
Writeln(SimpleRoundTo(d1*d2):0:14); with FPC you get
22.58 because now you are only showing 14 digits after the decimal 
point like Delphi , not 16 digits like FPC

Note that floating point math with double precision, it's impossible to truly 
store the number 22.58,
It's either 22.579 on win 32  or 22.578 on 64bit 
there is no exact 22.58. you have 
to be one float value or the other.  So it doesn't make sense to round a 
floating point number then try to display more decimal points than you rounded 
it to,   if you are rounding to 2 decimal places than just to a writeln that 
shows 2 decimal places likeWriteln(RoundTo(d1*d2,-2):0:2);  and see 22.57 
otherwise you will always be seeing floating point weirdness.

There is a difference between the way 64bit stores 22.575, 22.570 and 22.580
If you do
Writeln(22.575:0:20);
Writeln(22.57:0:20);
Writeln(22.58:0:20);

On a 32bit, you get:
22.57500070
22.5670
22.5790

On 64bit you get:
22.5740
22.5700
22.5780
Yes, it's true, Win32 has more precision than Win64  I did not get them 
backwards.. see:
https://wiki.freepascal.org/Variables_and_Data_Types

Where it states:
Note that for Windows 64 bits and non-Intel targets Extended is an alias for 
Double.  So I don't use Win64,  I only use 32 bit so I can get the precision.

So when using SetRoundMode(rmNearest) which is the default to decide whether to 
round 22.575 up or down it's very slightly in nearest to 22.58 with 64 bit and 
very slightly nearest to 22.57 with 32 bit

James

-Original Message-
From: fpc-pascal  On Behalf Of Gabor 
Boros via fpc-pascal
Sent: Friday, October 15, 2021 5:50 AM
To: fpc-pascal@lists.freepascal.org
Cc: Gabor Boros 
Subject: [fpc-pascal] Why the difference in the rounded results?

Hi All,

I got different results with 32bit vs. 64bit, 3.2.2 vs. 3.3.1, FPC vs.
Delphi. Why?

var
d1,d2:Double;

begin
d1:=20.5;
d2:=1.05;
Writeln(RoundTo(d1*d2,-2));
Writeln(SimpleRoundTo(d1*d2));
d1:=28.9;
Writeln;
Writeln(RoundTo(d1*d2,-2));
Writeln(SimpleRoundTo(d1*d2));
d1:=21.5;
Writeln;
Writeln(RoundTo(d1*d2,-2));
Writeln(SimpleRoundTo(d1*d2));
Readln;
end.

- FPC 3.2.2 Win32

   2.1531E+001
   2.1531E+001

   3.0340E+001
   3.0340E+001

   2.2570E+001
   2.2570E+001

- FPC 3.2.2 Win64

   2.1523E+001
   2.1531E+001

   3.0347E+001
   3.0351E+001

   2.2574E+001
   2.2578E+001

- FPC 3.3.1 Win32

   2.1531E+001
   2.1531E+001

   3.0340E+001
   3.0340E+001

   2.2570E+001
   2.2570E+001

- FPC 3.3.1 Win64

   2.1523E+001
   2.1531E+001

   3.0347E+001
   3.0351E+001

   2.2574E+001
   2.2578E+001

- Delphi 10.4.2 Win32

   2.153000E+0001
   2.153000E+0001

   3.034000E+0001
   3.034000E+0001

   2.258000E+0001
   2.258000E+0001

- Delphi 10.4.2 Win64

   2.152000E+0001
   2.153000E+0001

   3.034000E+0001
   3.035000E+0001

   2.258000E+0001
   2.258000E+0001

Gabor

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Ched via fpc-pascal]

Hello,

For one software I compile with fpc, Avast always complained. But only when 
compiled for debugging.
That exe was sent to the false positive departement, and it toke about _one mounth_ to have a corrected 
version of the AV. Afterwhat, he never complained even with reworked source code.


Cheers, Ched




Le 13.02.21 à 12:02, Marco van de Voort via fpc-pascal a écrit :


Op 2021-02-12 om 22:48 schreef James Richters via fpc-pascal:
The problem I have had is when programs I compile generate a false virus detection.. sure on my own 
computer I can just disable that directory from the virus scanner but it becomes a problem when I 
release it to my customers and their virus scanners quarantine it.   I have no idea how to register a 
legitimate program as not having a virus.  I've had this issue before but managed to track down the 
section of code that caused it... after a completely exhaustive search.


Some tips:

  - don't use debug builds.

  - sign the binary, even if just selfsigned. Provide as much context to the OS (icon and the rest in 
that screen). Minimalistic binaries seem to be more suspect.


- use a well known installer package, and insist on using installers. Copied 
exes are also more suspect.

- unfortunately, some wellknown Delphi libraries like Indy and Zeos sometimes 
trigger also.

There is no real failsafe solution. It is all hedging and hoping.

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

[fpc-pascal] CRT unit and bug #32558

[Ched via fpc-pascal]

Dear All,

I have some difficulties using the crt unit.

For what I can see, https://bugs.freepascal.org/view.php?id=32558 could well be the answer, specialy a 
call like SetUseACP(False); . At the end of the bug report, it is said that the crt unit will be ugraded 
in 3.1.1. I run 3.2.0 under both Linux and W10, but there is apparently no callable SetUseACP procedure 
in the crt unit. Is it available in 3.2.0 ?


Cheers, Ched'
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Ethernet Relays

[Ched via fpc-pascal]

Hello James,

You'll find a source of happiness with unit fphttpclient .
Particularily with the simplget function:

TFPHTTPCLIENT.SIMPLEGET('http://192.168.1.4/3/00')

It is said that it works with https also, but under the Mageia7 distro, you probably encounter problems I 
haven't yet solved. But for http, that should be right.


Cheers, Ched




Le 24.05.20 à 18:46, James Richters a écrit :

Does anyone have any advice on how to get started sending commands from FPC to 
use these ethernet relays:

https://www.amazon.com/gp/product/B076CNJNFH


Default IP :192.168.1.4   prot:3http://192.168.1.4/3

HTTP Comment:
http://192.168.1.4/3/00 : Relay-01 OFF
http://192.168.1.4/3/01 : Relay-01 ON
http://192.168.1.4/3/02 : Relay-02 OFF
http://192.168.1.4/3/03 : Relay-02 ON
http://192.168.1.4/3/04 : Relay-03 OFF
http://192.168.1.4/3/05 : Relay-03 ON
...
http://192.168.1.4/3/14 : Relay-8 OFF
http://192.168.1.4/3/15 : Relay-8 ON
http://192.168.1.4/3/41 : Enter
http://192.168.1.4/3/40 : Exit
http://192.168.1.4/3/42 : Next Page
http://192.168.1.4/3/43 : Next Page

I don't really know what I even need to do to send commands like that over the 
network.  Of course I can get it to work just typing the commands from a 
browser but that's not what I want, I want my FPC console program to send the 
appropriate commands whenever I want one of the relays to come on or go off.

Any suggestions on how this might be accomplished?

James

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



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

Re: [fpc-pascal] Extended type under Win64

[Ched via fpc-pascal]

Le 26.02.20 à 15:11, denisgolovan via fpc-pascal a écrit :

In theory yes, but it's not recommended, because Microsoft does not recommend 
it (not to mention that it isn't even remotely tested as much as the normal 
Win64 target).

Regards,
Sven


Got it. Thanks for the clarification.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




Well, well... Does it means that if one have scientific computations needing the extended type available 
on an Intel based processor with time constraints forbiding software emulation, one have to rest under a 
32 bits version of windows ? Hoping/praying that 64 bits Intel based linuxes running fpc software will 
never experience such a monumental regression of Windows - what a nightmare ! Is Freddy Krueger so near us ?


Cheers, Ched'
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal