Re: [fpc-pascal] FP IDE sources

Am 14.03.2024 um 11:04 schrieb Michael Van Canneyt via fpc-pascal: On Thu, 14 Mar 2024, Karoly Balogh via fpc-pascal wrote: Hi, On Thu, 14 Mar 2024, Guillermo Martínez Jiménez via fpc-pascal wrote: I thought "packages" were libraries not applications, as there is an "utils" directory with

Re: [fpc-pascal] Floating point question

> Am 16.02.2024 um 15:34 schrieb Bernd Oppolzer via fpc-pascal > : > > Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal: >> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal >> <mailto:fpc-pascal@lists.freepascal.org>: >>> >>

Re: [fpc-pascal] Floating point question

> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal > : > >  Compile-time math needs to be as correct as possible. RUN-time math can > worry about performance. So you are saying when constant propagation is on, an expression should have a different result than with constant

Re: [fpc-pascal] Floating point question

On 09.02.24 15:00, greim--- via fpc-pascal wrote: Hi, my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code. The compiler throws an error message for calculating HH and II with explicit type conversion. The results of FF and GG are the same! Even on 16 bit system! I think

Re: [fpc-pascal] Floating point question

Am 04.02.2024 um 18:54 schrieb James Richters: I can understand storing the constant in the lowest precision that doesn't cause data loss, thus making thing more efficient, but the actual calculation done by the compiler should be done at maximum precision and only the final result stored in

Re: [fpc-pascal] Floating point question

Am 04.02.2024 um 18:25 schrieb James Richters via fpc-pascal: I agree with Aadrian 100% "New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss" We are getting data loss So it's doing it WRONG. So we are all living with a

Re: [fpc-pascal] Floating point question

> Am 04.02.2024 um 13:50 schrieb Adriaan van Os via fpc-pascal > : > > Jonas Maebe via fpc-pascal wrote: >> On 03/02/2024 18:42, James Richters via fpc-pascal wrote: >>> Constants are also evaluated wrong,you don’t know what that constant is >>> going to be used for, so all steps of

Re: [fpc-pascal] What's in Hello World

> Am 07.01.2024 um 13:21 schrieb Ingemar Ragnemalm via fpc-pascal > : > > Just for comparison, I fired up Think Pascal and made Hello world! > > Plain Hello world, closes so quickly that you don't have time to see it: 4625 > bytes. > > Including ShowText and while not Button do; 4639 bytes.

Re: [fpc-pascal] What's in Hello World

> Am 06.01.2024 um 20:05 schrieb Matthew Phillips via fpc-pascal > : > > I compiled the Hello World program from the docs and noticed that it's > 435k. Compared to a lot of newer languages, like Golang, that's not bad > at all. > > I then compiled the equivalent C program with gcc which came

Re: [fpc-pascal] aligned?

> Am 30.01.2023 um 14:03 schrieb Mattias Gaertner via fpc-pascal > : > > Hi, > > What does the fpc built-in function aligned? > > For example in FloatToStrFIntl: > > Str(Double(Extended(Aligned(Value))):precision+7, Result); It tells the compiler that the argument is properly aligned

Re: [fpc-pascal] FreePascal and the OrangePi

> Am 22.10.2022 um 00:19 schrieb Terry A. Haimann via fpc-pascal > : > > Dumb ? > > What download should I use to install the latest version of FreePascal > on the OrangePi 4 LTS, I am running Debian 3.0.6 Bullseye. > > The Orange Pi 4 LTS is an SBC running an ARM Processor. > Rockchip 3399

Re: [fpc-pascal] $modeswitch declared before $mode fails without warning

Am 18.09.22 um 14:22 schrieb Hairy Pixels via fpc-pascal: One more thing today working with closures. Declaring the modeswitch before the mode does not actually enable the feature and gives no warning. What happens then is basic syntax fails and you’re totally confused as to why. Shouldn’t

Re: [fpc-pascal] Strange "division by zero" error using variants

Am 24.05.22 um 19:28 schrieb Thomas Kurz via fpc-pascal: Dear all, please consider the following code: program Project1; {$booleval off} var v1, v2: variant; a: boolean; b: integer; begin a := true; b := 0; // this works as expected: if a and (b > 0) and ((0+1) mod b =

Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR

> Am 13.03.2022 um 16:26 schrieb Peter via fpc-pascal > : > > On 12/03/2022 11:33, Florian Klämpfl via fpc-pascal wrote: >> >>> Am 12.03.2022 um 12:05 schrieb Peter via fpc-pascal >>> : >>> >>> Its looking like it was fixed in ma

Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR

> Am 12.03.2022 um 12:05 schrieb Peter via fpc-pascal > : > > Its looking like it was fixed in main somewhere between > > 31cd3df724 Jan, 2021 > & > 837b433a28 Apr, 2021 Can you bisect it by any chance? See https://wiki.freepascal.org/FPC_git#bisect.27ing

Re: [fpc-pascal] bug or feature?

Am 13.02.2022 um 10:25 schrieb Sven Barth via fpc-pascal: Michael Van Canneyt via fpc-pascal mailto:fpc-pascal@lists.freepascal.org>> schrieb am So., 13. Feb. 2022, 09:47: On Sun, 13 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > On Sat, 12 Feb 2022 12:14:14 +0100 (CET) >

Re: [fpc-pascal] target mipsel-embedded

> Am 29.11.2021 um 09:39 schrieb Michael Ring via fpc-pascal > : > > Startup Code and Modules for chips had a license that Florian was not happy > with. So those parts are missing. Also the files where huge due to the I/O capabilities of those microcontrollers IIRC. > > I have not built

Re: [fpc-pascal] FreePascal and MySQL 8.0

> Am 19.09.2021 um 10:46 schrieb Michael Van Canneyt via fpc-pascal > : > > > > On Sun, 19 Sep 2021, Florian Klämpfl via fpc-pascal wrote: > >> >> >>> Am 19.09.2021 um 10:16 schrieb Michael Van Canneyt via fpc-pascal >>> : >>&g

Re: [fpc-pascal] FreePascal and MySQL 8.0

> Am 19.09.2021 um 10:16 schrieb Michael Van Canneyt via fpc-pascal > : > > > > On Sat, 18 Sep 2021, Florian Klämpfl via fpc-pascal wrote: > >> Am 18.09.21 um 17:34 schrieb Michael Van Canneyt via fpc-pascal: >>> On Sat, 18 Sep 2021, Terry A. Haima

Re: [fpc-pascal] FreePascal and MySQL 8.0

Am 18.09.21 um 17:34 schrieb Michael Van Canneyt via fpc-pascal: On Sat, 18 Sep 2021, Terry A. Haimann via fpc-pascal wrote: I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0 . I also see there is no connector in my Free Pascal install for MySQL 8.0.  I do see that

Re: [fpc-pascal] FPC & Lazarus moving to gitlab

There is a third conversion of the FPF repository meanwhile (from June): https://gitlab.com/freepascal.org/fpc/testconversion3 Please check and report any problems, this is most likely the last chance to get things fixed before the final

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

> Am 16.06.2021 um 18:07 schrieb Dennis Lee Bieber via fpc-pascal > : > > On Wed, 16 Jun 2021 13:15:10 +0200 (CEST), Michael Van Canneyt via > fpc-pascal > declaimed the following: > >> ~$ ldd /usr/bin/ls >> linux-vdso.so.1 (0x7ffc3f9c1000) >> libselinux.so.1 =>

Re: [fpc-pascal] How to find where my app consumes CPU?

> Am 19.05.2021 um 19:00 schrieb Bo Berglund via fpc-pascal > : > > On Wed, 19 May 2021 16:02:00 +0200, Bo Berglund via fpc-pascal > wrote: > >> The "other" items might be hidden inside other used classes such as the >> Indy10 >> components I use to implement the TCP/IP communications. >>

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

> Am 19.04.2021 um 07:52 schrieb Karoly Balogh via fpc-pascal > : > > Hi, > > On Mon, 19 Apr 2021, Sven Barth via fpc-pascal wrote: > >>> Am 18.04.2021 um 23:29 schrieb Zamrony P. Juhara via fpc-pascal: >>> >>> I would like to propose to separate RTL release from compiler release >>> so

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

> Am 19.04.2021 um 11:36 schrieb Michael Van Canneyt via fpc-pascal > : > > > > On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: > >> On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote: >>> On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 09:28,

Re: [fpc-pascal] Background info on Generics in FPC

> Am 17.04.2021 um 21:07 schrieb Graeme Geldenhuys via fpc-pascal > : > > Hi > > I'm looking at the wiki and official FPC language documentation. What was > the reason for the decision to make the FPC syntax so verbose regarding > Generics? Same reason why we have a : array[0..10] of

Re: [fpc-pascal] Version 3.2.2 changes

> Am 08.04.2021 um 21:27 schrieb Jonas Maebe via fpc-pascal > : > > On 08/04/2021 21:07, Peter via fpc-pascal wrote: >> Does anyone have a link to useful list of changes or bug fixes for 3.2.2? > > Unfortunately, no. In theory you could see it on >

Re: [fpc-pascal] Pascal Ardiono (avr) library

>>> >>> And then, afterwards, once code has been generated for the whole 'block', >>> the register-allocator fills in the registers. And store/restores them when >>> needed. This can be done using an algorithm that uses a tree to 'peel-down' >>> (is this English?) all the solutions. Just like

Re: [fpc-pascal] Pascal Ardiono (avr) library

> Am 04.04.2021 um 15:36 schrieb Joost van der Sluis via fpc-pascal > : > > > > Op 04-04-2021 om 13:33 schreef Florian Klämpfl via fpc-pascal: >>> Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal >>> : >>> >>> Isn't

Re: [fpc-pascal] Pascal Ardiono (avr) library

> Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal > : > > Isn't it at least a good practice to store self at Y. So we have Z free for > other calculations and can access members directly using ldd (),y+(). > > But maybe that's difficult? Using Y might be indeed difficult

Re: [fpc-pascal] Pascal Ardiono (avr) library

> Am 03.04.2021 um 19:49 schrieb Joost van der Sluis via fpc-pascal > : > > Hi all, > > During some spare free time I've ported parts of the Arduino AVR library to > Free Pascal. So now it is possible to use things like 'DigitalWrite' and > 'Delay'. > > More info here: >

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

> Am 10.03.2021 um 10:28 schrieb Bernd Mueller via fpc-pascal > : > > On 3/5/21 6:22 PM, Florian Klämpfl via fpc-pascal wrote: > >> It is not expected that it works as RiscV support is still work in >> progress, but it should work ;) I'll look into it. > >

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

> Am 10.03.2021 um 04:59 schrieb Toru Takubo via fpc-pascal > : > >> Can you please post the output of -va of the arm compiler and provide some >> information about the arm system you are using? > > The output message with -va option can be downloaded from below. > >

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

Am 09.03.21 um 01:47 schrieb Toru Takubo via fpc-pascal: On 2021/03/08 16:54, Michael Van Canneyt via fpc-pascal wrote: On Mon, 8 Mar 2021, Toru Takubo via fpc-pascal wrote: Hi, I am developing my app on Windows and building apps for other platforms by using cross compiler. Now I have a

Re: [fpc-pascal] Unicode chars losing information

> Am 09.03.2021 um 10:06 schrieb Michael Van Canneyt via fpc-pascal > : > >  > >> On Tue, 9 Mar 2021, Graeme Geldenhuys via fpc-pascal wrote: >> >>> On 09/03/2021 1:44 am, Tomas Hajny via fpc-pascal wrote: >>> UnicodeString may be used in a program simply because the included unit has >>>

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

Am 06.03.21 um 13:56 schrieb Bernd Mueller via fpc-pascal: I saw your changes in revision 48881, downloaded latest trunk, compiled with make crosszipinstall CPU_TARGET=riscv32 OS_TARGET=embedded SUBARCH=rv32i but the problem remains: make[4]: Entering directory

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

Am 05.03.21 um 10:41 schrieb Bernd Mueller via fpc-pascal: Hello, I would like to use fpc to program a FPGA softcore RISC-V cpu. The softcore has the RV32I instruction set implemented. I modified the Makefile in rtl/embedded, so that the known SUBARCH rv32imac replaces the option -Cprv32imac

Re: [fpc-pascal] 50 Years of Pascal

Am 24.02.21 um 17:50 schrieb Liam Proven via fpc-pascal: I thought this might interest folks. Apologies if I am late to the party. https://cacm.acm.org/magazines/2021/3/250705-50-years-of-pascal/fulltext I didn't know, thanks for the heads up :-)

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

> I've also noticed that if you have any timing routines in your code, it tends > to get flagged by virus scanners. No clue why, but I've run afoul of that > issue more than once. > Debugger detection? ___ fpc-pascal maillist -

Re: [fpc-pascal] Compilation speed on Apple M1

> Am 22.11.2020 um 11:45 schrieb Michael Van Canneyt via fpc-pascal > : > >  > >> On Sun, 22 Nov 2020, Florian Klämpfl via fpc-pascal wrote: >> >>> Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal: >>> Hello, >>> first and

Re: [fpc-pascal] Compilation speed on Apple M1

Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal: Hello, first and foremost, many thanks to the creators and contributors of FPC and Lazarus, who enabled me to release my product natively for Apple Silicon only one day after receiving an M1 Mac. Fantastic work! FPC and Lazarus both

Re: [fpc-pascal] Compilation speed on Apple M1

Am 21.11.20 um 17:29 schrieb Ryan Joseph via fpc-pascal: On Nov 21, 2020, at 9:23 AM, Florian Klämpfl via fpc-pascal wrote: All. FPC typically uses several ten MBs and accesses it rather randomly. Wow 10-100 MB is enough to limit speed due to memory access times? I understand

Re: [fpc-pascal] Compilation speed on Apple M1

Am 21.11.20 um 17:22 schrieb Ryan Joseph via fpc-pascal: What are the plans for the native code generator if it's being outperformed by the LLVM backend? Only the generated code is a little bit faster. The compiler using LLVM is ~10 times slower.

Re: [fpc-pascal] Compilation speed on Apple M1

Am 21.11.20 um 17:07 schrieb Ryan Joseph via fpc-pascal: On Nov 21, 2020, at 6:15 AM, Florian Klämpfl via fpc-pascal wrote: Large parts of FPC are memory throughput limited so I suspect the M1 is not that much better in this regard, not to mention that most likely the AAarch code

Re: [fpc-pascal] Compilation speed on Apple M1

Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal: According to Geekbench, the single core performance on the new Mac is around 1.8x as fast as my Intel Mac. Multicore is also much faster. I wonder why I don't see the speed increase in compiling though. Yes I am using different FPC

Re: [fpc-pascal] Worse performance with 64bit binary

Am 25.07.20 um 16:49 schrieb Gabor Boros: Hi All, I cannot show the real application but attached a simple example. If compile with 3.2.0 "ppc386.exe -O3 test.pas" the execution time of the resulting example binary is 0.4s, and 2.2s if compile with "ppcx64.exe -O3 test.pas". Any idea why?

Re: [fpc-pascal] FPC for Win64

Am 05.07.20 um 09:04 schrieb Jonas Maebe: On 2020-07-02 22:30, Evert van Dijken via fpc-pascal wrote: I like to use the 64 bits FPC compiler, but I cannot find any documentation how to use it. I see a WIN32 compiler and a WIN64 cross compiler. How it works is a mystery for me. Can I still use

Re: [fpc-pascal] Question about compiling FPC trunk after revision 44849

Am 29.04.20 um 21:12 schrieb Marco van de Voort: Op 2020-04-29 om 19:50 schreef Jonas Maebe: Yes, but you cannot use "clean" and "all" in the same make invocation. This was in fact never supported, and did not work on all platforms either. So simply split it: make -j 9 clean make -j 9 all

Re: [fpc-pascal] Wiki Image Database Corruption

Am 12.04.20 um 03:28 schrieb Trev: I've been trying to attract the attention of someone/anyone with virtual access to the Wiki webserver to fix the corrupted image database since January. I've tried (in order): * Wiki Feedback page: https://wiki.freepascal.org/Site_Feedback * Forums:

Re: [fpc-pascal] Error format question

Am 11.04.20 um 08:11 schrieb Ryan Joseph via fpc-pascal: Sorry to ask this yet again but I keep forgetting or remembering wrong. I thought this was a one time error that was fixed but I'm still getting different error formats with the trunk (as of today) vs 3.0.4. Can anyone please confirm

Re: [fpc-pascal] [OT] inline procedures in TP 7.0

Am 17.02.20 um 12:31 schrieb Anton Shepelev via fpc-pascal: Florian Klampfl to Anton Shepelev: What about the other registers -- does Turbo Pascal take care of them, perhaps enveloping each expansion of an inline procedure into a POPs and PUSHes? No. Thank you for the reply, Florian. Does

Re: [fpc-pascal] fpmmap arm-linux issue

Am 01.02.20 um 18:13 schrieb je...@j-software.dk: Agreed, the rtl should definitely divide by pagesize if MMAP2 is defined. I've run into this discrepancy before on ARM at work I have fixed it meanwhile. ___ fpc-pascal maillist -

Re: [fpc-pascal] [OT] inline procedures in TP 7.0

Am 16.02.20 um 22:28 schrieb Anton Shepelev via fpc-pascal: But which registers shall be preserved by inline proceudres and functions? IIRC (it is 25 years ago :)): sp and bp In this example from the manual, the SP register is not preserved within the statement: It is reset to it's value

Re: [fpc-pascal] Best start point for adding new FPC target

Am 28.01.20 um 20:40 schrieb Yuriy Sydorov: On 28.01.2020 21:14, Fabio Luis Girardi via fpc-pascal wrote: Em ter., 28 de jan. de 2020 às 16:04, Yuriy Sydorov > escreveu:     You need to add support of a new CPU to the existing freebsd target. The target would be

Re: [fpc-pascal] Error format changes between compilers

Am 30.12.2019 um 17:08 schrieb Ryan Joseph via fpc-pascal: Notice how the format of the error changes between ppcrossx64 (built for iPhone simulator) and ppcx64. Is this a bug? It broke my regex for capturing errors and that's why I'm asking btw. The old syntax was wrong, some days ago I

Re: [fpc-pascal] Two possible generics bugs

Am 30.11.19 um 18:51 schrieb Sven Barth via fpc-pascal: Am 28.11.2019 um 16:14 schrieb Ryan Joseph via fpc-pascal: {$mode objfpc} program test; uses    FGL; // Type identifier expected // Internal error 2019112401 generic function CopyList(source: specialize FGL.TFPGObjectList): specialize

Re: [fpc-pascal] get_caller_frame

Am 20.11.19 um 07:56 schrieb Sven Barth via fpc-pascal: Ryan Joseph via fpc-pascal > schrieb am Mi., 20. Nov. 2019, 04:36: I came across get_caller_frame  in some unrelated code and I was just curious about this so I wanted to ask. What does

Re: [fpc-pascal] FPC_CURRENCY_IS_INT64

Am 14.10.19 um 19:40 schrieb LacaK: So it is safe to assume that in memory is Currency always stored as Int64 on Win32, Win64? Yes. To get it's value, divide it by 1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] ppc64le ABI problem

Am 27. August 2019 15:03:46 schrieb tobiasgie...@gmail.com: > Hello, > > yes I will send you a minimal program to call XGetWindowProperty. > > Cheers, > Tobias > > > > On Tue, 27 Aug 2019 11:35:01 +0200 > Pierre Muller wrote: > >> Hi, >> >> >> the testsuite results show no difference, >>

Re: [fpc-pascal] ppc64le ABI problem

Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > 14:01: > >> Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: >> >>> Hello, >>> >>> >>> >>> &g

Re: [fpc-pascal] ppc64le ABI problem

Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > Hello, > > > while examining a crash when running Lazarus on ppc64le, I found the > following issue in function calls. > > > Calls to functions with more than eight parameters seem to be > implemented differently from how gcc does it

Re: [fpc-pascal] server up?

Am 15.06.2019 um 15:19 schrieb Ryan Joseph: > Is the fpc-devel server back up yet? I’m not seeing new messages getting > posted. Just tested, works. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] mode switch madness

Am 14.04.2019 um 04:07 schrieb Ben Grasset: > I dunno about setting them globally, but generally I do find modeswitches > rather annoying, as the combination of > features is pretty arbitrary, and they mostly just *disallow* things that > couldn't break the code of people who weren't > using

Re: [fpc-pascal] *.rst vs *.rsj

Am 06.03.19 um 22:09 schrieb Graeme Geldenhuys: Hi, Somewhere after FPC 2.6.4 the FPC compiler changed to generating JSON based *.rsj files for resource strings. 1. What was the benefit of doing that? After all, FPC always prides itself in not breaking backward compatibility (Florian and

Re: [fpc-pascal] "crtbegin.o" not found

Am 03.01.19 um 18:31 schrieb Bart: I put it on my user page on the wiki: http://wiki.lazarus.freepascal.org/User:Bart#Notes_for_myself Maybe there's an appropriate page it can gi into. I added it to the explanation of the compiler error. ___

Re: [fpc-pascal] Rest in peace Martin Schreiber

Am 27.12.2018 um 00:49 schrieb Graeme Geldenhuys: > Hi everybody, > > Today I became aware of very sad news. Martin Schreiber, author of the > MSEide+MSEgui project, has unexpected succumbed of cardiac arrest on 29 > November 2018. Sad to hear. All the best to his family and friends. Rest in

Re: [fpc-pascal] Building trunk

Am 25.11.2018 um 14:30 schrieb Colin Western: > What generates the header? Is it fpc, an external linker or the loader? > Can you please run the following C program: #include #include int main() { printf("AT_PHDR: %lx\n",getauxval(AT_PHDR)); printf("AT_PHNUM: %lx\n",getauxval(AT_PHNUM));

Re: [fpc-pascal] Building trunk

Am 25.11.2018 um 13:58 schrieb Jonas Maebe: > On 25/11/18 13:51, Florian Klämpfl wrote: >> I am not aware that somewhere a fixed offset is applied. All info is read >> from the auxiliary data and the header. > > You can have a load address offset in case there is a PT_PHDR

Re: [fpc-pascal] Building trunk

Am 25.11.2018 um 13:51 schrieb Florian Klämpfl: > Am 25.11.2018 um 13:06 schrieb C Western: >>>>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org >>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >>>> That gives the s

Re: [fpc-pascal] Building trunk

Am 25.11.2018 um 13:06 schrieb C Western: fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >>> That gives the same value as shown above, even after applying the patch. >>> Single stepping the code indicates that both

Re: [fpc-pascal] Building trunk

Am 25.11.2018 um 12:20 schrieb C Western: > On 24/11/2018 22:21, Florian Klämpfl wrote: >> Am 24.11.2018 um 10:08 schrieb C Western: >>> On 23/11/2018 09:50, Sven Barth via fpc-pascal wrote: >>>> Am Fr., 23. Nov. 2018, 10:26 hat C Western >>>

Re: [fpc-pascal] Building trunk

Am 24.11.2018 um 10:08 schrieb C Western: > On 23/11/2018 09:50, Sven Barth via fpc-pascal wrote: >> Am Fr., 23. Nov. 2018, 10:26 hat C Western > > geschrieben: >> >>     I haven't been able to build trunk i386 fpc for a couple of weeks. Is >>     this supposed to be

Re: [fpc-pascal] Constants in generics

Am 10.11.2018 um 13:20 schrieb Ryan Joseph: >>> - the compiler contains already a type called tgenericdef >>> >>> I think I changed that name in the last commit. Btw I made all those types >>> because I didn’t want to populate the main types like ttypesym with extra >>> bytes but I don’t

Re: [fpc-pascal] Constants in generics

Am 09.11.2018 um 03:13 schrieb Ryan Joseph: > > >> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl wrote: >> >> I like the idea of const in generics, but it needs serious cleanup when it's >> working: >> - commit messages like "first commit" are usel

Re: [fpc-pascal] Constants in generics

Am 09.11.2018 um 05:20 schrieb Ryan Joseph: > > >> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl wrote: >> >> I like the idea of const in generics, but it needs serious cleanup when it's >> working: > > Question: should other consts besides integers be allo

Re: [fpc-pascal] Constants in generics

Am 06.11.2018 um 08:13 schrieb Ryan Joseph: > I implemented a first draft of constants (integers) in generics. My reason > was specifically that I wanted a way to add methods to static arrays and > generic records is the only way to accomplish this AFAIK. > > If I fix this up will it be

[fpc-pascal] Vote for Source Forge project of the month

FPC is again a candidate for the project of the month at Source Forge. In case somebody wants to support FPC in this voting, here is the link: https://sourceforge.net/blog/community-choice-project-month-vote-december-2018/ ___ fpc-pascal maillist -

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

Am 03.10.2018 um 12:06 schrieb Florian Klämpfl: > really stored with extended precision representing exactly the > value 51009.9. This was sloopy wording by myself: the representation is not exact for extended either, but it must be actually the best possible presentation with extended pre

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

Am 03.10.2018 um 11:28 schrieb mailingli...@geldenhuys.co.uk: > > graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence >> fpc -Criot TestOperatorPrecedence.pas > Free Pascal Compiler version 3.0.2 [2017/02/13] for i386 > Copyright (c) 1993-2017 by Florian Klaempfl and others > Target

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

Am 03.10.2018 um 10:40 schrieb mailingli...@geldenhuys.co.uk: > I have this simple little test. My expected answer for all the calculations > are 0 (zero), but both FPC and Delphi give > different results. Java is the only one that seems consistent regarding the > results. Compile/run on the

Re: [fpc-pascal] Branch table

Am 26.08.2018 um 11:43 schrieb Giuliano Colla: > Il 23/08/2018 11:34, Marco Borsari via fpc-pascal ha scritto: > >> It would be for the Wirth optimization in the access of an array, >> when the index is 0 or 1, allowing the elimination of a multiplication. > > I'm afraid that this sort of

Re: [fpc-pascal] Branch table

Am 21.08.2018 um 11:42 schrieb Marco Borsari via fpc-pascal: > Il 20/08/2018 17:32, Giuliano Colla ha scritto: > >> On the Intel architecture you cannot perform pointer arithmetic as if a >> pointer were just a number. >> A pointer is composed of two parts: a "selector" and an "offset", which >>

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

Am 19.08.2018 um 15:08 schrieb Martok: But I don't actually want to debate that here, just collect information for users. Well, you have to as you give people the wrong impression that they can control what happens if they suppress/ignore run time errors.

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

Am 19.08.2018 um 14:44 schrieb Martok: as soon as [something changes], Delphi shows exactly the same behavior as FPC. But that's kind of the point of this collection: sometimes the rules intersect, but for most cases, they don't. Please note again: in general, there are no defined rules for

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

Am 19.08.2018 um 01:49 schrieb Martok: Am 18.08.2018 um 23:39 schrieb Florian Klämpfl: This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). It is actually shortint ... Correct, I was thinking of the default PackEnum. Which of course

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

Am 18.08.2018 um 23:26 schrieb Florian Klämpfl: Am 18.08.2018 um 22:59 schrieb Martok: Hi all, There is the old "Porting TP" document at <https://www.freepascal.org/port.var>, but it is rather incomplete (and probably on an older language level). It also covers mostly synta

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

Am 18.08.2018 um 22:59 schrieb Martok: Hi all, There is the old "Porting TP" document at , but it is rather incomplete (and probably on an older language level). It also covers mostly syntactic differences - things a programmer will notice because of the

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 13.07.2018 um 16:36 schrieb Martok: Am 12.07.2018 um 23:38 schrieb Florian Klämpfl: This will result in different results for runtime and compile time calculated expressions => bad idea. Aye, doing the same at runtime and compile time would be the sane idea. Still, the Delphi

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 10.07.2018 um 19:35 schrieb Martok: I seem to remember that this was once documented somewhere for Delphi. Can't seem to find it though, so maybe it was a 3rd-party book? There is no hint of it in the FPC documentation, anyway. As already noted, it is not necessary in DelphiAh sorry, I was

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 22:11 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl :  But actually, I just found out that we have something like this already for years: {$minfpconstprec 64} OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 versions? I dug

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 21:43 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : So you want float constants being evaluated always with full precision (which would be required for consistency) causing any floating point expression containing a constant being evaluated with full

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 20:33 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 19:42 schrieb g...@wolfgang-ehrhardt.de: Zitat von Vojtěch Čihák : will not give any warning even if correct result is 2.5. It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you tell him. If you need floating

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 14:33 schrieb Wolf: Maybe we do get some views from the key authors of Free Pascal. Not from me. These topics have been discussed zillion times. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] how to get rid of hints

Am 25.06.2018 um 09:19 schrieb Mattias Gaertner: Hi, How to get rid of hint 6068? With fpc 3.1.1 using some units like fgl the compiler emits: .../fpc/rtl/objpas/fgl.pp(899,1) Hint: "inherited" not yet supported inside inline procedure/function .../fpc/rtl/objpas/fgl.pp(899,1) Hint: Inlining

Re: [fpc-pascal] Proper preprocessor?

Am 23.06.2018 um 04:30 schrieb Ryan Joseph: On Jun 23, 2018, at 3:13 AM, Florian Klämpfl wrote: {$macro on} {$define TypeStr:=specialize _TypeStr} begin Writeln(TypeStr); end. ;) You have a good sense of humor about it at least. :) So you can in fact print types, albeit with a more

Re: [fpc-pascal] Proper preprocessor?

Am 22.06.2018 um 08:01 schrieb Michael Van Canneyt: On Fri, 22 Jun 2018, Ryan Joseph wrote: 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

Re: [fpc-pascal] Proper preprocessor?

Am 22.06.2018 um 22:07 schrieb Sven Barth via fpc-pascal: Am 22.06.2018 um 10:12 schrieb Ryan Joseph: On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal wrote: If $Assertions is set to Off the complete Assert() line will be absent from the compiled code. Good to know thanks.

Re: [fpc-pascal] math with infinity and NaN

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.

Re: [fpc-pascal] math with infinity and NaN

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;   

  1   2   3   4   >