Re: [fpc-pascal] Building for Arduino
Adriaan van Os via fpc-pascal wrote: Christo Crause via fpc-pascal wrote: PS. My avr binutils version is 2.26 - old, but your version is about 10 years older still. WIth avr binutils 2.26 built and installed, the compiler builds ! /usr/local/bin/ppcrossavr -i says Supported FPU instruction sets: NONE,SOFT,LIBGCC but NONE seems to be the default and the other two produce an error: Cannot find system type "s32real". Check if you use the correct run time library. Is this something unimplemented or under development or added after the fpc-3.2.2 release ? I also got an error error: Can't find unit macpas used by Blinky for mode macpas. I guess a unit macpas.pp could easily be added (which I could do). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building for Arduino
Christo Crause via fpc-pascal wrote: PS. My avr binutils version is 2.26 - old, but your version is about 10 years older still. WIth avr binutils 2.26 built and installed, the compiler builds ! adriaan% /usr/local/bin/ppcrossavr -v Free Pascal Compiler version 3.2.2 Compiler date : 2024/07/08 Compiler CPU target: avr Supported targets (targets marked with '{*}' are under development): embedded: Embedded Supported CPU instruction sets: AVR1,AVR2,AVR25,AVR3,AVR31,AVR35,AVR4,AVR5,AVR51,AVR6 Supported FPU instruction sets: NONE,SOFT,LIBGCC etcetera Thanks for the help ! Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building for Arduino
Christo Crause via fpc-pascal wrote: The assembly line you showed above is obviously missing a closing parenthesis, so the error from avr-as is correct. I tested building ppcrosssavr 3.2.2 with all your cross options and added -a to retain the generated assembler source. This worked fine and line 28783 from system.s has balanced parentheses: ldi r20,lo8(gs(FPC_FINALIZE)) My mistake while copying the line, sorry. Somehow that line got truncated when you were building the cross compiler, but I have no idea what could have caused that. PS. My avr binutils version is 2.26 - old, but your version is about 10 years older still. I use 2.17 because of this still unresolved bug <https://sourceware.org/bugzilla/show_bug.cgi?id=11337> but that is probably relevant for windows only. I will try 2.26 and report the result. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building for Arduino
Christo Crause via fpc-pascal wrote: The level of support for AVR in 3.0.4 was rudimentary, only atmega128 is supported in the MakeFIle. The support for AVR is still improving with time so use either the development branch, or the latest release version (if you prefer release versions). The bootstrap compiler required is determined by the source version, not the cross target. Thanks for the reply. With fpc-3.2.2 and make clean crossall FPC=/usr/local/lib/fpc/3.2.2/ppcx64 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=avr5 BINUTILSPREFIX=avr- CROSSOPT="-O3 -XX -CX -v" I get an assembler error /Users/adriaan/fpc-3.2.2/compiler/ppcrossavr -Cpavr5 -Ur -Tembedded -Pavr -XPavr- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../avr -FE. -FU/Users/adriaan/fpc-3.2.2/rtl/units/avr-embedded -davr -dRELEASE -O3 -XX -CX -v -Us -Sg system.pp @system.cfg /Users/adriaan/fpc-3.2.2/rtl/units/avr-embedded/system.s: Assembler messages: /Users/adriaan/fpc-3.2.2/rtl/units/avr-embedded/system.s:28783: Error: `)' required /Users/adriaan/fpc-3.2.2/rtl/units/avr-embedded/system.s:28783: Error: garbage at end of line where the offended assembly line in system.s reads ldi r20,lo8(gs(FPC_FINALIZE) and avr-as was built from gnu-binutils version 2.17. Is there a minimal gnu-binutils version required ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Building for Arduino
I am trying to build fpc for Arduino on MacOS 10.8.5, using the fpc-3.0.4 sources and fpc-3.0.4 as bootstrap compiler. GNU binutils have been built and installed (but not yet avrdude). As suggested here <https://forum.lazarus.freepascal.org/index.php/topic,30960.0.html> I use make clean crossall OS_TARGET=embedded CPU_TARGET=avr SUBARCH=avr5 BINUTILSPREFIX=avr- CROSSOPT="-O3 -XX -CX" which results in objpas.pp(175,24) Fatal: Unknown compilerproc "fpc_ansistr_to_shortstr". Is this a known problem ? Is a specific minimal version of the fpc sources and a specific bootstrap compiler neeed to build for Arduino ? Obviously, I wouldn't need all packages. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sub-millisecond time measuring
Sven Barth via fpc-pascal wrote: I wouldn't introduce a dependency for something like GTK (especially GTK!) on macOS only to receive some timings. Simpler and more straight forward to just use the correct functions of the OS. Of course not, Unless you are doing some cross-development, developing on MacOS for gtk and larer moving it native to Linux. Then, you will run into the bug. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sub-millisecond time measuring
Michael Van Canneyt via fpc-pascal wrote: Is that a function in the RTL? I can't find it. No, these are platform-specific functions. g_get_monotonic_time is probably just an alias for the linux/freebsd unit functions clock_gettime(CLOCK_MONOTONIC_RAW). g_get_monotonic_time is in glib <https://docs.gtk.org/glib/func.get_monotonic_time.html> function g_get_monotonic_time: gint64; cdecl; external; but it requires a bug fix when using gtk on MacOSX <https://bugzilla.gnome.org/show_bug.cgi?id=728123> Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sub-millisecond time measuring
Hairy Pixels via fpc-pascal wrote: I had a large function which I was profiling with MilliSecondsBetween but I split it to be called many different times and now it's not accumulating the total time correctly because time is being lost to due millisecond precision. Is there anything in the RTL I can use which is more accurate? I searched and couldn't find anything. You can use Microseconds on MacOS, QueryPerformanceFrequency on Windows and g_get_monotonic_time with gtk on Linux. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Type-casting a class variable
Olivier Sannier via fpc-pascal wrote: Hello, You should cast to TWindowClass as TWindow is used to cast an instance, not a class reference. Note that you may not have TWindowClass, in which case you need to declare it like this: type TWindowClass = class of TWindow; OK. A typecast with TWindowClass works. Thanks, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Type-casting a class variable
Martin Frb via fpc-pascal wrote: My example (2nd part of it) was actually wrong. It was mentioned before On 01/05/2024 19:43, Jean SUZINEAU via fpc-pascal wrote: I didn't tested but I imagine it could be done with something like this ? type TWindow_Class= class of TWindow; begin ... (myClass as TWindow_Class).CreateNewWindow( ); It must be cast to another "class of" When I do that, the compiler emits Class or COM interface type expected, but got "TClass" I am using {$mode macpas} {$modeswitch class} {$interfaces corba} Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Type-casting a class variable
Martin Frb via fpc-pascal wrote: Silly question, but did you assign the value to the variable? myClass := TWindow; That's what I did. TWindow(myClass).CreateNewWindow; And this is what crashes. I can report this, if the type-cast is supposed to work. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Type-casting a class variable
In addition to what Martin said: as long as you have a non-static class method the value of the variable you call the class method on (e.g. myClass in your example) will be passed as Self parameter. So no need for extra parameters. But how can myClass be passed ? myClass.CreateNewWindow is not accepted by the compiler, because CreateNewWindow is not a method of TClass, whereas TWindow.CreateNewWindow doesn't pass myClass. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Type-casting a class variable
Suppose I have a var myClass: TClass and (for example) a class function TWindow.CreateNewWindow( ) Now I want to call CreateNewWindow for var myClass. Of course, depending on the class, CreateNewWindow will behave different. Type-casting myClass to TWindow crashes (in my setup). And even if it worked, wouldn't it loose the class information ? Of course, by adding an extra parameter of type TClass to CreateNewWindow, the issue can be solved. But that's far from elegant. How to solve this ? Anything I missed ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and SIMD intrinsics
Alecu Ștefan-Iulian via fpc-pascal wrote: Hello! I am interested in making a high-performance project which involves a lot of math, which is why I am interested in using SIMD (AVX2) on x86_64 (and for fun as well, if I'm honest). I am coming mainly from the C and C++ world where one has intrinsics (such as `_mm256_add_epi64`, to give an example from the Intel® Intrinsics Guide). I am most familiar with GCC (and to a lesser extent to Clang and ICC), where one can access these intrinsics through headers such as . Is there a Free Pascal equivalent for that? I have translated the Intel(R) Integrated Performance Primitives to FreePascal. I can send them if you like. On MacOS, you can use the Accelerate libraries <https://developer.apple.com/accelerate/> which have headers translated to FreePascal (see the univint pacakage) Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MachO $indirect symbols
When compiling for aarch64 with fpc 3.3.1 on macOS 14.2, I notice some new entries in the Mach-O symbol table of the produced executable, e.g. apart from SegmentName = __DATA_CONST SectionName = __const SymbolName = _VMT_$SYSTEM_$$_TOBJECT n_type = 15 there is now also an entry SegmentName = __DATA_CONST SectionName = __const SymbolName = _VMT_$SYSTEM_$$_TOBJECT$indirect n_type = 15 etcetera. I don't know if the new entries are specific for aarch64, for fpc 3.3.1 or for the linker and assembler used. Also the segment name seems to have changed from __DATA to __DATA_CONST. Just wondering what's behind this. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
James Richters via fpc-pascal wrote: What's apparently happening now is: MyExtended := ReducePrecisionIfNoLossOfData (8246) + ReducePrecisionIfNoLossOfData (33.0) / ReducePrecisionIfNoLossOfData (1440.0); But it is not being done correctly, the 1440.0 is not being reduced all the way to an integer, because it was, everything would work. The 1440.0 is being considered a single, and the division is also being now considered a single, even though that is incorrect. But 1440.1 is not being considered a single, because 1440.1 is not breaking everything. Indeed. It is wrong. And if Delphi does it wrong, it is still wrong for modes other than Delphi. What should be happening is: MyExtended := ReducePrecisionIfNoLossOfData(8246+33.0/1440.0); Pascal doesn't attach a floating-point type to a floating-point constant. So, the only correct way for the compiler to handle it is to NOT attach a floating-point type to the declared constant in advance, that is, the compiler must store it in a symbol table as BCD or as string. And decide LATER what type it has. And in this case, where the assignment is to an extended, as soon as that is clear, and not earlier, the compiler can do the conversion of the BCD or string floating-point constant to the floating-point type in question, i.c. extended. If the entire formula was calculated the original way at full precision, then only result was reduced if there was no loss in precision right before storing as a constant, then this solves the problems for everyone, and this is the correct way to do this. Then everyone is happy, no Delphi warnings, no needlessly complex floating point computations if the result of all the math is a byte, and no confusion as to why it works with 1440.1 and not 1440.0 Compatibility with all versions of Pascal, etc.. This calculation is only done once by the compiler, the calculation should be done at full possible precision and only the result stored in a reduced way if it makes sense to do so. Jonas has argued, not without reason, that calculating everything always at full precision has its disadvantages too. The problem I have with the changes made with v2.2, is that it's obvious that the change was going to introduce a known bug at the time: "Effect: some expressions, in particular divisions of integer values by floating point constants, may now default to a lower precision than in the past." How is this acceptable or the default?? Delphi/Borland invents some seemingly clever by factually stupid scheme and FPC wants to be compatible with it. Some applaud, but I am more impressed by logical reason than by what Borland does without logical reason. "Remedy: if more precision is required than the default, typecast the floating point constant to a higher precision type, e.g. extended(2.0). Alternatively, you can use the -CF command line option to change the default precision of all floating point constants in the compiled modules." The first remedy is unreasonable, I should not have to go through thousands of lines of code and cast my constants, it was never a requirement of Pascal to do this. Right. Great if -CF80 worked, but even if you are happy with -CF64, my problem is: how is anyone coming into FPC after 2.2 supposed to know that their constants that always worked before are going to no longer be accurate?? The better thing to do would be to do it RIGHT before releasing the change so that it can't be a problem for anyone, and make: "New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss" a true statement. If the entire formula was evaluated at full precision, and only the result was stored as a lower precision if possible, then there is never a problem for anyone. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
Jonas Maebe via fpc-pascal wrote: On 04/02/2024 13:50, Adriaan van Os via fpc-pascal wrote: 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 evaluating a constant MUST be done in extended by the compiler, or the answer is just wrong. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html I think this discussion shows that the 2.2 compiler change was a bad idea (for modes other than Delphi). This is not just about Delphi. It's also about being able to perform floating point calculations efficiently and getting rid of useless warnings. But not at the price of loss in precision ! Unless an explicit compiler switch like --fast-math is passed but then it is the resposibility of the programmer, not of the compiler. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
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 evaluating a constant MUST be done in extended by the compiler, or the answer is just wrong. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html I think this discussion shows that the 2.2 compiler change was a bad idea (for modes other than Delphi). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Crash with cthreads and snapshot ppca64 on macos 14.2.1
I get a "Threading has been used before cthreads was initialized." crash for a simple program program test; uses cthreads; begin writeln( 'Hello') end. on macos 14.2.1 with a fpc 3.3.1-14334-g5205ce30f4 snapshot, but the crash only occurs with mode -Mmacpas (which I assumes implicitely uses some unit that causes the issue). -Mmacpas adds macpas.pas, which uses math.pas and throught that sysutils.pas. But, looking at the RTL source code, I don't see anything that explains why the problem should be aarch64 (or aarch64-darwin) specific .... Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Crash with cthreads and snapshot ppca64 on macos 14.2.1
I get a "Threading has been used before cthreads was initialized." crash for a simple program program test; uses cthreads; begin writeln( 'Hello') end. on macos 14.2.1 with a fpc 3.3.1-14334-g5205ce30f4 snapshot, but the crash only occurs with mode -Mmacpas (which I assumes implicitely uses some unit that causes the issue). Regards, Adriaan van Os administrator% uname -a Darwin AdministorsMini 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:59:33 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8112 arm64 administrator% /usr/local/lib/fpc/3.3.1/ppca64 -iW 3.3.1-14334-g5205ce30f4 administrator% /usr/local/lib/fpc/3.3.1/ppca64 test.pas Free Pascal Compiler version 3.3.1-14334-g5205ce30f4 [2023/11/06] for aarch64 Copyright (c) 1993-2023 by Florian Klaempfl and others Target OS: Darwin for AArch64 Compiling test.pas Assembling (pipe) test.s Linking test -macosx_version_min has been renamed to -macos_version_min 6 lines compiled, 0.3 sec, 196608 bytes code, 81919 bytes data administrator% ./test Hello administrator% /usr/local/lib/fpc/3.3.1/ppca64 -Mmacpas test.pas Free Pascal Compiler version 3.3.1-14334-g5205ce30f4 [2023/11/06] for aarch64 Copyright (c) 1993-2023 by Florian Klaempfl and others Target OS: Darwin for AArch64 Compiling test.pas Assembling (pipe) test.s Linking test -macosx_version_min has been renamed to -macos_version_min 6 lines compiled, 0.1 sec, 540672 bytes code, 163839 bytes data administrator% ./test Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. Runtime error 211 at $000100B52E2C $000100B52E2C $000100AF409C $000100ADB390 $000100B01BDC $000100ADB310 $000100ADB368 $00018BF010E0 $F35F8000 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
Thomas Kurz via fpc-pascal wrote: 1. The "writeln" in line 32 correctly prints "0." when (cross-) compiling to win64, but "39.375" when compiling to win32 (with ppc386). Maybe the word "cross-compiling" gives a clue ? In a cross-compiler, floating-point operations of constants must be software-emulated, as the target hardware is (normally) not available to the host compiler. In theory, this shouldn't be noticeable, unless there is a bug somewhere. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Nested comments.
Guillermo Martínez Jiménez via fpc-pascal wrote: Hi Pascaloids, I'm wondering if it is possible to make FPC detect and warn (or even stop compillation when) it has detect a nested comment. That's because I'm using Vim and it closes odd comments. For example, the nex code: { This comment isn't closed. *) DoSomething (); { This is a nested comment. } I know this is a silly mistake, but sometimes I comment batchs of codde to deactivate them temporary and when un-comment they're non paired and it result in weird runtime bugs. A command line option that activate that functionality would be great. Something like -wn (because -vn is used for notes). ($modeswitch nestedcomments-} Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntToStr implementation
Michael Van Canneyt via fpc-pascal wrote: More accurately, I meant: you cannot write a function declaration to handle that syntax. It is true that a regular (non-built-in) procedure/function with that syntax can not be declared. Some more strange ducks - Exit allowing Program as parameter (UCSD-Pasca) - Scan allowing a partial-expression as second parameter (UCSD-Pascal) e.g. Scan( -26, =':', S) - SizeOf allowing a type-identifier as parameter etcetera. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntToStr implementation
Also something which cannot be handled by 'standard' syntax. (unless you wish to count generics and implicit specialization as "standard syntax") actual-parameter = expression { ":" expression } . actual-parameter-list = "(" actual-parameter { "," actual-parameter } ")" . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Trash variables (-gt) - Translation
LacaK via fpc-pascal wrote: Hi *, I am translating "Trash variables" (from English to Slovak), but I can not find appropriate words. That's why I want to describe it in more words. Is this correct: "Initialize local variables with random values" ? Or better suggestion? I once had a bug in a software package, written by me and running at a customer site, that turned out to be caused by an incorrect translation (into Dutch) of a book by Peter Norton. Since then, I refuse to read computer books in another language than the original one ..... Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] $definec and $define
The FreePascal Programmer's Guide version 3.2.0 reads in section 1.2.11 "Under Mac Pascal mode, the $DEFINEC directive is equivalent to the $DEFINE directive and is provided for Mac Pascal compatibility. {$DEFINE} can also be used to define macros or compile-time constants:" This is not correct. In Metrowerks Pascal, $definec and $define are two distinct directives $definec key value defines a macro where key is replaced by value $definec keydefines a macro where key is replaced by an empty string $define key defines key as a symbol (to test with $fdef c.s.) This is also how it actually works in FPC in Macpas mode, where $definec key and $define key are not equivalent. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's in Hello World
Nikolay Nikolov via fpc-pascal wrote: But that increases the binary size to 28 bytes. We can put a 'ret' That's still 27 bytes too much. Let's design a CPU that has "Hello World" as a one-byte instruction, implement that CPU in a Field-programmable gate array, write an OS for it and let it say hello. That's HelloWorld ad absurdum. Or just send some smoke signals <https://www.interestingfacts.org.uk/wp-content/uploads/2013/06/Smoke-Signals-300x275.jpg> Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] %LINENUM%
Section 1.2.41 of the Free Pascal Programmer’s Guide version 3.2.0 says: "As a result, this will generate a macro with the value of the XXX specifier, as if it were a string (or, in the case of LINENUM, an integer)." I don't think this is correct, or at least requires clarification. One can not insert integers (as such) into a text stream. I think, the correct description is: "As a result, this will generate a macro with the value of the XXX specifier, as a quoted string (or, in the case of LINENUM, as an unquoted string)." Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Quiz
Quiz. Which of below constant declarations are accepted by the compiler and what is their value ? const ki1 = + 2; ki2 = +2; ki3 = 2+; kr1 = 1.; kr2 = 1e-2; kr3 = 1e+2; kr4 = 1.e+2; kr5 = 1 . e + 2; kr6 = 1 . 0 e + 2; kr7 = 1.0e+2; kr8 = 1.0 e + 2; The more difficult question is, why ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's in Hello World
Peter B via fpc-pascal wrote: Try building with smartlinking, -XX I get 35k You can also experiment with ld linker options like --strip-all and --strip-debug or run the produced code through strip <https://www.man7.org/linux/man-pages/man1/strip.1.html> with various options (e.g. -u -r on OSX). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid Copy
Amir--- via fpc-pascal wrote: Hi all, I have a List of record, where the record has a WideString field. I have some code like the following: function check(constref v: TMyRecord; data: TListOfMyRecord): Boolean; var r: TMyRecord; begin Result := False; for r in data do if r.State = v.State then Exit(True); end; I call this method a lot and the CPU profiling shows a lot of cpu time spent on "fpc_copy_proc" (which I assume is doing the deep copy on records) from "TCustomListEnumerator.GetCurrent". I considered other alternatives like using enumerators but they all need a to return a record (and hence copying the widestring field). I can think of two solutions to get rid of the wasting(!) so much time on "fpc_copy_proc": 1) Changing the TMyRecord to TMyClass. But then I need to Create and Free a "lot" of objects. 2) Update TListOfMyRecord to TListOfPointerToMyRecord. This requires a "lot" of memory allocation/fragmentation. Is there a better solution? Pass the data parameter by reference. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Michael Van Canneyt via fpc-pascal wrote: This is not correct either, as it suggests that ( ... ) is correct. It is not, if you use ... there must be other arguments present. That is offending the reader: "You are to stupid to be given complete information". It misses the point that programmers must be taught to think precise, abstract, conceptually and logically. For the same reason, modern math teaching doesn't work. It tries to circumvent abstract thinking by showing pictures. But there is no alternative to learning to think in abstract concepts. The more stupid education becomes, the less their pupils do learn <https://www.tagesschau.de/inland/gesellschaft/pisa-studie-128.html>. If the language has the complexity built-in, there is no alternative but to be honest about it. You're also missing the ";" in front of the "...". Thanks for pointing that out. I have added it. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Michael Van Canneyt via fpc-pascal wrote: I added univ and documented it. Something seems to have gone wrong with the defintion on page 212. Having a better look, the rule defines just one parameter. So, we get instead formal-parameter-list = "(" [ parameter-declaration { ";" parameter-declaration } ] [ "..." ] ")" . parameter-list = formal-parameter-list . comprising also the "ellipsis" parameter, which, according to Appendix D.6 of the Programmer's Manual is functionally equal to the varargs keyword. Added to the diagrams. I changed the diagram to be more clear (hopefully). But the rule for on page 211 now suggests that "..." can be used in the middle of the other declarations, which is not true. formal-parameter-list = "(" [ parameter-declaration { ";" parameter-declaration } ] [ "..." ] ")" . Can't a variable also be qualified ? Therefore ? variable-reference = qualified-identifier . Yes. I didn't see a rule for yet in the Language Reference. But to parse that, the rules for and need something like an , don't they ? Yes, I had come to this conclusion myself, and I added it. I can't find the change yet. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Michael Van Canneyt via fpc-pascal wrote: The following zip file contains the updated documentation: http://downloads.freepascal.org/fpc/beta/3.2.4-rc1/docs/doc-pdf.zip Besides correcting your remarks, I did a general overhaul: - I changed the use of space character in syntactic elements to dash (-) - Improved some diagrams. - synchronized some syntactical elements. - Tried to make sure every syntactical element has a definition. Sorry, but are you sure this is the right download for all mentioned changes ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] inherited
Sections 5.5.2 and 6.6.8 of the FreePascal Language Reference discuss the "inherited" keyword, but I couldn't find it in the syntax diagrams. Sections 12.2 and 13.1.2. have procedure-statement = ( procedure-identifier | method-identifier | qualified-method-identifier | variable-reference ) [ actual-parameter-list ] . function-call = ( function-identifier | method-designator | qualified-method-designator | variable-reference ) [ actual-parameter-list ] . This can be changed to procedure-reference = qualified-identifier | procedure-identifier | variable-reference . function-reference = qualified-identifier | function-identifier | variable-reference . procedure-statement = ( "inherited" [ procedure-reference ] | procedure-reference ) [ actual-parameter-list ] . function-call = ( "inherited" [ function-reference ] | function-reference ) [ actual-parameter-list ] . That adds the "inherited" keyword, but doesn't include, for example, identifier-casts. The problem with identifier casts is that, grammatically, a cast can not be distinguished from a function call. Therefore, the cast has to be treated, in the grammar, as a (one-parameter) function call. So, things are more complex that indicated above. A solution may be along the line of what UCSD-Pascal defines selector = "[" expression { "," expression } "]" | "." identifier | "^" . variable = identifier { selector } . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] string-type
Adriaan van Os via fpc-pascal wrote: Section 3.2.4 of the FreePascal Language Reference defines string-type = "STRING" [ "[" unsigned-integer "]" ] | "TYPE" ( "STRING" | "ansistring" ) "(" unsigned-integer ")" . Ansistring is shown in the syntax diagram in boldface and thus as a keyword. But it is not listed as either a modifier or a reserved word in section 1.3. I suggest instead to define as a type-identifier. string-type = "STRING" [ "[" unsigned-integer "]" ] | "TYPE" ( "STRING" | ansistring ) "(" unsigned-integer ")" . ansistring = type-identifier . For other reasons, the indicated rule for is not correct, as the size specifier and the codepage specifier can both be a . So, with that I think we get string-type = "STRING" [ "[" ( unsigned-integer | constant-identifier ) "]" ] | "TYPE" ( "STRING" | ansistring ) "(" ( unsigned-integer | constant-identifier ) ")" . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] string-type
Section 3.2.4 of the FreePascal Language Reference defines string-type = "STRING" [ "[" unsigned-integer "]" ] | "TYPE" ( "STRING" | "ansistring" ) "(" unsigned-integer ")" . Ansistring is shown in the syntax diagram in boldface and thus as a keyword. But it is not listed as either a modifier or a reserved word in section 1.3. I suggest instead to define as a type-identifier. string-type = "STRING" [ "[" unsigned-integer "]" ] | "TYPE" ( "STRING" | ansistring ) "(" unsigned-integer ")" . ansistring = type-identifier . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] ordinal-type
Michael Van Canneyt wrote: 29. Am I correct to assume ? ordinal-type = ordinal-type-identifier . ordinal-type-identifier = identifier . Yes. That may not be correct after-all, because an e.g. indexes arrays array-type = [ "PACKED" | "bitpacked" ] "ARRAY" [ "[" ordinal-type { "," ordinal-type } "]" ] "OF" type . In ISO-7185 Pascal we have array-type = "array" "[" index-type { "," index-type } "]" "of" component-type . index-type = ordinal-type . ordinal-type = new-ordinal-type | ordinal-type-identifier . new-ordinal-type = enumerated-type | subrange-type . enumerated-type = "(" identifier-list ")" . subrange-type = constant ".." constant . And in the FreePascal Language Reference seems not to be referenced by any other rule. subrange-type = constant ".." constant . I suggest to change to ordinal-type = ordinal-type-identifier | subrange-type | enumerated-type . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Labels
Jean SUZINEAU via fpc-pascal wrote: Le 17/12/2023 à 17:47, Adriaan van Os via fpc-pascal a écrit : Turbo Pascal (5.5) defines label = digit-sequence . Are you sure ? I had a doubt and I had a look in some very old source code from 1990 made with tp 5.5, it seems you could have letters in labels. You are right. I have a printed cope of the Turbo Pascal 6.0 Programmer's Guide and it says, confusingly, on page 16 "The digIt sequence for a label must be in the range 0." and on page 8 "A label is a digit sequence in the range 0.999". but on page 9 "As an extension to Standard Pascal, Turbo Pascal also allows identifiers to functions as labels. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Michael Van Canneyt wrote: 32. Are the set operators "include", "exclude" missing in the syntax diagrams ? Is "><" missing (specifically) as set operator in the syntax diagrams ? Include/Exclude are not operators. They are procedure calls. Section 12.8.5 says "Elements can be added or removed from the set with the Include or Exclude operators" and table 12.6 lists them as "Set operators". So, that is confusing (to me). 22. Various rules refer to a rule for which I can't find the rule. What is it ? identifier. Can't a variable also be qualified ? Therefore ? variable-reference = qualified-identifier . 41. Is it correct that is referenced only in the record rule ? I would expect something like an in various declaration rules. To the best of my knowledge, only records support operator definitions. The 'operator' chapter handles 'global' operators which are at the level of global functions/procedures. Your reply puzzles me. I mean code like this {$mode fpc} unit Operators; interface const ki : complex = ( re: 0.0; im: 1.0); operator + ( z1: complex; z2: complex) sum: complex; operator + ( d1: double; z2: complex) sum: complex; operator + ( z1: complex; d2: double ) sum: complex; etcetera But to parse that, the rules for and need something like an , don't they ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Labels
According to Section 13.0 of the FreePascal Language Reference (version 3.2.0) "A label can be an identifier or an integer digit." What may be meant is that a label can be an identifier or an integer digit-sequence (and that's what the compiler accepts) label := digit-sequence | identifier . ISO-7185 and ISO-10206 Pascal both define label = digit-sequence . UCSD-Pascal defines label = unsigned-integer ":" . Turbo Pascal (5.5) defines label = digit-sequence . in the range 0.. MetroWerks Pascal (unfortunately) defined a label as label = identifier . The reason for restricting labels to digit-sequences (excluding identifiers) is a parsing problem: a :=3; can also be read as a : .. which is the optional <[ label ":" ]> in the rule for . statement = [ label ":" ] [ simple-statement | structured-statement | asm-statement ] . This can be solved, of course, but misses the elegance of the ISO-7185/ISO-10206/UCSD/Turbo Pascal label definition. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Tony Whyman via fpc-pascal wrote: Back in the early eighties, I worked at ICL and we made extensive use of the Prospero Pascal compiler building embedded systems based on the Z80 microprocessor. I still have a 1988 edition of the language specification, and this uses EBNF to define the case statement as: case-statement = "CASE" case-index "OF" case-list-element {";" case-list-element } [ ";" OTHERWISE statement][";"] "END" case-index = expression case-list-element = case-range-list ":" statement case-range-list = case-range {"," case-range } case-range = case-constant [".." case-constant ] case-constant = constant What is interesting about the above is not just that it uses "otherwise" but that it insists on a semi-colon before the "otherwise". This may not have been strictly necessary but it does enforce the separation between the case -list-elements and the "otherwise", making the "otherwise" clause into another case-list-element. It also aids readability and it may be why I have always added a semi-colon after the final case-list-element. Note that the final optional ";" is probably needed to allow those that always like to end a statement in a semi-colon. Prospero Pascal was close to ISO Pascal (although I have lost my original copy of ISO Pascal) and I would guess that the above is copied from ISO Pascal. ISO-7185 Pascal doesn't have an else/otherwise in the case-statement, ISO-10206 Extended Pascal does, but it is of later date. The change from "otherwise" to "else" is probably a Borland Pascal invention preferring a shorter word and then overlooking the importance of the semi-colon case-list-element separator and the resulting ambiguity. The same error then flowed through to exception handling. As the otherwise-clause is not in ISO-7185 Pascal, it seems more plausible that Borland invented the else-clause (without semicolon) independently. All other Pascals I have looked at, use an otherwise-clause (with an obligatory semicolon). The motivation for this, given in IBM Pascal is interesting. The manual says that the statement-part of the otherwise-clause can be intentionally "left blank" and be used "to prevent possible errors during execution". I recall that in ISO-7185 Pascal it is an error if no case discriminator matches at runtime. So, the otherwise-clause was seen as a way to get around that ! Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 2)
Michael Van Canneyt via fpc-pascal wrote: On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote: More questions about the FreePascal Language Reference (version 3.2.0) part 2 17. For the following rules, I couldn't find a definition in the Language Reference. Can I assume they can all be defined as ? object-type-identifier = identifier . field-identifier = identifier . interface-identifier = identifier . interface-type-identifier = identifier . method-identifier = identifier . procedure-identifier = identifier . protocol-identifier= identifier . protocol-type-identifier = identifier . qualified-method-identifier= identifier . result-identifier = identifier . type-identifier= identifier . function-identifier= identifier . unit-identifier= identifier . variable-identifier= identifier . Yes. The idea was to use these "dedicated names" to convey that the identifier must be of a certain type. You cannot express this concept in a formal syntax, but for a formal syntax the above is correct. Of course, a rule like proc-identifier = procedure-identifier | function-identifier . makes no sense without the semantics of a symbol table (to decide between the two), but rules like procedure-heading = "PROCEDURE" procedure-identifier function-heading = "FUNCTION" function-identifier procedure-identifier = identifier . function-identifier = identifier . do make sense, even without semantics, because in the parsing(-only) tree, a procedure-identifier (etc.) node is now marked as such, and not just as identifier. In certain applications of a parsing(-only) tree this is quite useful. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 4)
Michael Van Canneyt via fpc-pascal wrote: On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote: More questions about the FreePascal Language Reference (version 3.2.0), part 4 34. Are macpas LEAVE and CYCLE statements undocumented ? Yes. Well, according to Appendix D.6 of the Programmer's Manual, CYCLE is equivalent to CONTINUE and LEAVE to BREAK. Contrary to the information presented there, the CYCLE and LEAVE statements have been implemented for macpas mode. I don't see BREAK and CONTINUE in the syntax diagrams either. I put together some examples (stressing that I am not a proponent of these C constructs). procedure test; begin while true do leave; writeln( 'leave makes true=false'); while true do break; writeln( 'break makes true=false'); writeln( 'cycle forever'); while true do begin cycle; leave end; writeln( 'continue forever'); while true do begin continue; break end; end; 36. Is the macpas RETURN statement undocumented ? In MetroWerks Pascal, we have return-statement = "RETURN" [ expression ] . In a procedure the [ expression ] part is skipped, in a function it assigns the function-result and then jumps to the end of the function. In a procedure, it just jumps to the end of the procedure. FreePascal allows RETURN in macpas mode to be used in a function only, so the following compiles only in a function. repeat return until false; writeln( 'the point of no return'); Ceterum censeo C esse delendam. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Another use of UNIV is type-compatibility of procedural parameters. For example with function BinaryFind ( theValuePtr : univ UnivPtr; theFirstIndex : Int32; theLastIndex : Int32; function SmallerThan ( theIndex: Int32; theValuePtr : univ UnivPtr): boolean; function EqualTo ( theIndex: Int32; theValuePtr : univ UnivPtr): boolean; var theFoundIndex : Int32): boolean; But this kind of procedural parameter doesn't seem to be included in the rule for . it is allowed in macpas and iso modes. ISO-7185 Pascal has formal-parameter-list = "(" formal-parameter-section { ";" formal-parameter-section } ")" . formal-parameter-section = value-parameter-specification | variable-parameter-specification | procedural-parameter-specification | functional-parameter-specification | conformant-array-parameter-specification . functional-parameter-specification = function-heading . procedural-parameter-specification = procedure-heading . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote: More questions about the FreePascal Language Reference (version 3.2.0) part 3 26. Am I correct to assume the following equivalents for rules that I couldn't find a definiton for: formal-parameter-list = parameter-declaration . parameter-list = parameter-declaration . Having a better look, the rule defines just one parameter. So, we get instead formal-parameter-list = "(" [ parameter-declaration { ";" parameter-declaration } ] [ "..." ] ")" . parameter-list = formal-parameter-list . comprising also the "ellipsis" parameter, which, according to Appendix D.6 of the Programmer's Manual is functionally equal to the varargs keyword. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 4)
Michael Van Canneyt via fpc-pascal wrote: 37. Shouldn't the macpas "mwpascal" modifier be added to ? call-modifiers = "register" | "cdecl" | "pascal" | "stdcall" | "safecall" | "inline" | "mwpascal" . call-modifiers = "cdecl" | "inline" | "local" | "nostackframe" | "overload" | "pascal" | "register" | "safecall" | "saveregisters" | "softfloat" | "stdcall" | "varargs" | "mwpascal". Yes. There are even more. And, according to Appendix D.6 of the Programmer's manual: 7. The cdecl modifier keyword can be abbreviated to C. in macpas mode. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (part 3)
Michael Van Canneyt via fpc-pascal wrote: 28. The documentation for macpas "UNIV" is missing ? I have no idea what this is ? UNIV is macpas specific (as mentioned in Appendix D.6 of the Programmer's Manual) With UNIV, ... ":" [ "ARRAY" "OF" ] type-identifier ... in the syntax diagrams, becomes ... ":" [ "ARRAY" "OF" | UNIV ] type-identifier ... The modifier UNIV indicates that the actual parameter can be of any type that has the same byte-size as the formal parameter. Example: procedure HDispose( var theHandle: univ Handle); . which saves a value-type-cast when calling HDispose with handles that are not (precisely) of type Handle. Another use of UNIV is type-compatibility of procedural parameters. For example with function BinaryFind ( theValuePtr : univ UnivPtr; theFirstIndex : Int32; theLastIndex : Int32; function SmallerThan ( theIndex: Int32; theValuePtr : univ UnivPtr): boolean; function EqualTo ( theIndex: Int32; theValuePtr : univ UnivPtr): boolean; var theFoundIndex : Int32): boolean; we can call BinaryFind as follows theFoundFlag := BinaryFind ( @theCmdID, 1, kCmdCount, CmdIDSmallerThan, CmdIDEqualTo, where function CmdIDSmallerThan ( theIndex: Int32; theValuePtr : CmdIDPtr): boolean; . and function CmdIDEqualTo ( theIndex: Int32; theValuePtr : CmdIDPtr): boolean; ... because CmdIDPtr is through UNIV type-compatible with theValuePtr : univ UnivPtr Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
I find the idea of a "closest containing value" rather weird. For me, programming is strict logic, not finding something "closest". What I wrote here, is nonsense. "Closest containing" is rather a grammatical concept, that I misunderstood. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Tony Whyman via fpc-pascal wrote: Prospero Pascal was close to ISO Pascal (although I have lost my original copy of ISO Pascal) and I would guess that the above is copied from ISO Pascal. You can find the ISO-7185 document on the internet, just search for "iso7185.pdf". A less known aspect of the ISO-7185 Pascal case-statement is that it is an error if none of the case-conditions is met. 6.8 .3.5 Case-statements The values denoted by the case-constants of the case-constant-lists of the case-list-elements of a case-statement shall be distinct and of the same ordinal-type as the expression of the case-index of the case-statement . On execution of the case-statement the case-index shall be evaluated . That value shall then specify execution of the statement of the case-list-element closest-containing the case-constant denoting that value . One of the case-constants shall be equal to the value of the case-index upon entry to the case-statement ; otherwise, it shall be an error. I find the idea of a "closest containing value" rather weird. For me, programming is strict logic, not finding something "closest". Anyway, the innocent looking case-statement does have some interesting aspects. As an aside, I much prefer OTHERWISE to ELSE given that it is much closer to natural language. The IF...THEN..ELSE construct probably dates back to Algol 60 and I wonder why it was proposed. In normal English use, "else" is not used in this way. It usually follows another word, such as "anyone else", "anything else", "or else". You might say "If I go to town then I will be out. Otherwise, I will stay at home". I would never replace "otherwise" with "else" in such a sentence. "Else" belongs in a statement such "Does anyone else have a view". Interesting observation ! Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] More syntax questions (part 4)
More questions about the FreePascal Language Reference (version 3.2.0), part 4 34. Are macpas LEAVE and CYCLE statements undocumented ? 35. Are macpas ellipsis (...) parameters undocumented ? 36. Is the macpas RETURN statement undocumented ? 37. Shouldn't the macpas "mwpascal" modifier be added to ? call-modifiers = "register" | "cdecl" | "pascal" | "stdcall" | "safecall" | "inline" | "mwpascal" . call-modifiers = "cdecl" | "inline" | "local" | "nostackframe" | "overload" | "pascal" | "register" | "safecall" | "saveregisters" | "softfloat" | "stdcall" | "varargs" | "mwpascal". 38. Is a rule missing ? constref-parameter = "CONSTREF" identifier-list [ ":" [ "ARRAY" "OF" ] type-identifier ] . where parameter-declaration = value-parameter | variable-parameter | out-parameter | constant-parameter | out-parameter | constref-parameter . 39. Section 16.7 defines a rule and a rule library = library-header ";" [ uses-clause ] block "." . exports-clause = "exports" exports-list ";" . The exports-clause rule however doesn't seem to be referenced anywhere in the syntax, so it may have to be added to the rule ? 40. < recordoperator-definition> = ? 41. Is it correct that is referenced only in the record rule ? I would expect something like an in various declaration rules. (to be continued) Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] More syntax questions (part 3)
More questions about the FreePascal Language Reference (version 3.2.0) part 3 26. Am I correct to assume the following equivalents for rules that I couldn't find a definiton for: formal-parameter-list = parameter-declaration . parameter-list = parameter-declaration . hint-directives= { hint-directive } . hint-modifiers = call-modifiers . hintdirective = hint-directive . hintdirectives = hint-directives . integer := [ sign ] unsigned-integer . integer-constant := integer . integerconstant := integer-constant . typed-declaration = type-declaration . 27. Section 13.2 defines a rule for refering to a rule structured-statement = compound-statement | conditional-statement | repetitive-statement | with-statement | exception-statement . Am I correct to assume ? exception-statement = try-except-statement | try-finally-statement . where try-except-statement = "try" statement-list "except" exceptionhandlers "END" . try-finally-statement = "try" statement-list "finally" finally-statements "END" . 28. The documentation for macpas "UNIV" is missing ? 29. Am I correct to assume ? ordinal-type = ordinal-type-identifier . ordinal-type-identifier = identifier . 30. Am I correct to assume that was meant to be ? 31. Are the operators "<<" and ">>" missing in the syntax diagrams ? 32. Are the set operators "include", "exclude" missing in the syntax diagrams ? Is "><" missing (specifically) as set operator in the syntax diagrams ? 33. Section 12.1 gives "sign" in boldface in the rule for , suggesting that it is a keyword. Is that correct ? (to be continued) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] More syntax questions (part 2)
More questions about the FreePascal Language Reference (version 3.2.0) part 2 17. For the following rules, I couldn't find a definition in the Language Reference. Can I assume they can all be defined as ? object-type-identifier = identifier . field-identifier = identifier . interface-identifier = identifier . interface-type-identifier = identifier . method-identifier = identifier . procedure-identifier = identifier . protocol-identifier= identifier . protocol-type-identifier = identifier . qualified-method-identifier= identifier . result-identifier = identifier . type-identifier= identifier . function-identifier= identifier . unit-identifier= identifier . variable-identifier= identifier . 18. Section 14.4.1 defines a rule value-parameter = identifier-list ":" [ "ARRAY" "OF" ] parameter-type | identifier ":" type-identifier "=" default-parameter-value . I couldn't find a rule for . If equals then it may be easier to name it ? 19. Sections 3.6, 14.2 and 15.2 refer to a rule . function-header = "FUNCTION" formal-parameter-list ":" result-type . function-header = "FUNCTION" ( identifier | qualified-method-identifier ) formal-parameter-list ":" result-type [ modifiers ] [ hintdirectives ] . operator-definition = "operator" ( assignment-operator-definition | arithmetic-operator-definition | comparision-operator-definition ) result-identifier ":" result-type ";" subroutine-block . I couldn't find a rule for . Can I assume ? result-type = type-identifier . 20. For the following rules, I couldn't find a definition in the Language Reference. Can I assume they can all be defined as ? guid = single-quoted-string . string-constant-declaration = single-quoted-string . string-literal = single-quoted-string . stringconstant = single-quoted-string . where is a parser built-in rule that parses two consecutive single-quote chars as a literal single-quote char ? and that may not contain CR and LF characters ? or any other control characters ? 21. Can I assume ? statement-list = statement { ";" statement } . statementlist = statement-list . 22. Various rules refer to a rule for which I can't find the rule. What is it ? 23. Section 12.2 defines a rule that references rules and . function-call = ( function-identifier | method-designator | qualified-method-designator | variable-reference ) [ actual-parameter-list ] . I can't find the rules for and . What are they ? 24. Sections 14.4.1 and 14.4.4 define rules that refer to a rule . value-parameter = identifier-list ":" [ "ARRAY" "OF" ] parameter-type | identifier ":" type-identifier "=" default-parameter-value . constant-parameter = "CONST" ( identifier-list [ ":" [ "ARRAY" "OF" ] type-identifier ] | identifier ":" type-identifier "=" default-parameter-value ) . I can't find the rule for . What is it ? 25. Section 16.2 defines a rule that refers to a rule interface-part = "INTERFACE" [ uses-clause ] { constant-declaration-part | type-declaration-part | variable-declaration-part | property-declaration-part | procedure-headers-part } . I can't find the rule . What is it ? (more to follow) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More syntax questions (and more to follow)
Michael Van Canneyt via fpc-pascal wrote: Thanks for the replies. Please note that the syntax diagrams are NOT meant to be exhaustive. They are an aid to explain the syntax. I strive to make them as correct as possible, but they make no pretense to being complete. Anyway, I strive to make the syntax complete and correct. When it is ready, I can send it in to be added as an Appendix to the Language Reference manual. I have an ebfn-driven general (back-parsing) parser, that already works for Oberon-0 end UCSD-Pascal. So, the ebnf can be tested. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] More syntax questions (and more to follow)
More questions about the FreePascal Language Reference (version 3.2.0) 1. Section 17.1 defines a rule and raise-statement = "raise" [ exception-instance [ exception-address ] ] . exception-address = "at" exception-address [ "," address-expression ] . a) Is it correct that defines itself recursively ? b) I can't find the rule that defines . What is it ? c) I can't find the rule that defines . What is it ? 2. Section 12.1 refers to a rule factor = "(" expression ")" | variable-reference | function-call | unsigned-constant| "NOT" factor | "sign" factor | set-constructor | value-typecast | address-factor . I can't find the rule but it may be the same as the rule given in section 12.7 ? addressfactor = "@" ( variable-reference | procedure-identifier | function-identifier | qualified-method-identifier ) . 3. Section 2.2 refers to a rule typed-constant = constant | address-constant | array-constant | record-constant | procedural-constant . I can't find the rule . What is it ? 4. Section 2.2 also refers to a rule typed-constant = constant | address-constant | array-constant | record-constant | procedural-constant . I can't find the rule . What is it ? 5. Section 2.2 also refers to a rule typed-constant = constant | address-constant | array-constant | record-constant | procedural-constant . I can't find the rule . What is it ? 6. Section 2.2 also refers to a rule typed-constant = constant | address-constant | array-constant | record-constant | procedural-constant . I can't find the rule . What is it ? 7. Section 13.3 refers to a rule asm-statement = "asm" assembler-code "END" [ registerlist ] . I can't find a rule for What is it, from the point of view of parsing Pascal ? 8. Section 10.1 refers to a rule helper-type = ( "CLASS" | "RECORD" | "TYPE" ) "helper" [ "(" basehelper ")" ] "FOR" identifier { helper-component-list } "END" hint-modifiers . I can't find a rule for . What is it ? 9. Sections 17.2 and 6.1 refer to a rule exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO" statement . class-heritage = "(" class-type-identifier [ class-implemented-interfaces ] ")" . I can assume ? class-type-identifier = identifier . 10. Section 11.2 refers to a rule objc-class-heritage = "(" [ objective-Cclass-type-identifier ] [ objc-implemented-protocols ] ")" . I can assume ? objective-Cclass-type-identifier = identifier . 11. Section 6.1 refers to a rule class-reference-type = "CLASS" "OF" classtype . I can't find a rule for . What is it ? 12. Section 13.2 refers to a rule structured-statement = compound-statement | conditional-statement | repetitive-statement | with-statement | exception-statement . I can't find a rule for . What is it ? 13. Section 6.1 referes to a rule component-list = [ visibility-specifier ] { field-definition } { const-declaration-part | type-declaration-part | variable-declaration-part | class-variable-declaration-part | method-definition | property-definition } . I can assume ? const-declaration-part = constant-declaration-part . 14. Sections 2.2, 3.1.1, 3.3.2, 4.7 and 13.2.2 refer to a rule typed-constant = constant | address-constant | array-constant | record-constant | procedural-constant . subrange-type = constant ".." constant . variant = constant { "," constant } ":" "(" [ field-list ] ")" . default-specifier = "default" [ constant ] | "nodefault" . stored-specifier = "stored" ( constant | identifier ) . case = constant [ ".." constant ] { "," constant [ ".." constant ] } ":" statement . I can't find a rule for . What is it ? 15. Sections 5.1 and 6.6.1 refer to a rule const-definition = "CONST" identifier "=" constant-expression ";" . class-method-directives = ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] | "reintroduce" ";" | "override" ";" | "message" constant-expression ) [ call-modifiers ";" ] . I can assume ? constant-expression = expression . 16. Section 12.1 refers to a rule unsigned-constant = unsigned-number | character-string | constant-identifier | "NIL" . I can assume ? constant-identifier = identifier . (more to follow) Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] method-definition
I am puzzled by the syntax rule in Chapter 6. Classes of the FreePascal Language Reference (version 3.2.0) Section 6.1 Class definitions has method-definition = [ "CLASS" ] ( function-header | procedure-header | constructor-header | destructor-header ) ";" [ ( ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] ) | "override" | "message" ( integer-constant | string-constant ) ) ";" ] [ call-modifiers ";" ] . Section 6.6.1 Declaration has: method-definition = ( function-header | procedure-header | constructor-header | destructor-header ) ";" method-directives . method-directives = ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] | "reintroduce" ";" | "override" ";" | "message" constant-expression ) [ call-modifiers ";" ] . Is this supposed to be the same rule for ? Some notes: 1. I don't see a rule anywhere in the Language Reference 2. "reintroduce" is in just one of the two definitions. 3. the optional "CLASS" is in just one of the two definitions. What complicates things, is that many conflicting rules have the same name in the Language Reference. For example, conceptually we have object-methods, record-methods, class-methods, interface-methods and objcclass-methods. But only the record method rules are prefixed as such. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Jean SUZINEAU via fpc-pascal wrote: Le 15/12/2023 à 10:39, Adriaan van Os via fpc-pascal a écrit : I don't see a semicolon in the formal syntax. May be included in the ' "DO" statement ' ? No, have a look at the syntax diagrams, statements never end with a semicolon. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Michael Van Canneyt via fpc-pascal wrote: The fact that the semicolon before the else is optional ? I don't see a semicolon in the formal syntax. This works: OK, than an optional semicolon must be added to the rule exceptionhandlers = [ exception-handler { ";" exception-handler } [ ";" ] [ "ELSE" statement-list ] | statement-list ] . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Michael Van Canneyt via fpc-pascal wrote: On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote: Note that the same ambiguity exists in the syntax (and this is less well known) exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE" statement-list ] | statement-list ] . exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO" statement . as ends with a and the optional <"ELSE" statement-list> part start with "ELSE". Sloppy language design, I assume by Borland. What exactly do you consider "sloppy" ? The ambiguity in the syntax whether ELSE belong to or to <"ELSE" statement-list>. The fact that the semicolon before the else is optional ? I don't see a semicolon in the formal syntax. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Note that the same ambiguity exists in the syntax (and this is less well known) exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE" statement-list ] | statement-list ] . exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO" statement . as ends with a and the optional <"ELSE" statement-list> part start with "ELSE". Sloppy language design, I assume by Borland. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] implementation-part
The Freepascal Language Reference (version 3.2.0) states in section 16.2 "As can be seen from the syntax diagram, a unit always consists of a interface and an implementation part." and "Both the interface part or implementation part can be empty, but the keywords Interface and implementation must be specified. However, this was changed when implementing macpas mode (or at least for the macpas mode) in that the implementation part is no longer obligatory. This is useful for units with (only) external declarations. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
James Richters via fpc-pascal wrote: I didn’t know there was such a thing as OTHERWISE. Is there any functional difference between OTHERWISE and ELSE? No. It is just that OTHERWISE doesn't have the IF-THEN-ELSE ambiguity. Macintosh Pascal compilers had OTHERWISE but not ELSE. Maybe, OTHERWISE was added to FPC when imlementing the macpas mode. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Michael Van Canneyt via fpc-pascal wrote: On Thu, 14 Dec 2023, Adriaan van Os via fpc-pascal wrote: I am looking in detail at the syntax diagrams in the Freepascal Language Reference (version 3.2.0) Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN) the syntax is case-statement = "CASE" expression "OF" case { ";" case } [ else-part ] [ ";" ] . case = constant [ ".." constant ] { "," constant [ ".." constant ] } ":" statement . else-part = [ "ELSE" | "OTHERWISE" ] statementlist . If this is correct (and the compiler really allows it) then a semicolon between and is not required. It is not required. In addition to what I wrote, I believe the diagram is also incorrect in that it doesn't allow an optional semicolon between and . Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] case statement
I am looking in detail at the syntax diagrams in the Freepascal Language Reference (version 3.2.0) Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN) the syntax is case-statement = "CASE" expression "OF" case { ";" case } [ else-part ] [ ";" ] . case = constant [ ".." constant ] { "," constant [ ".." constant ] } ":" statement . else-part = [ "ELSE" | "OTHERWISE" ] statementlist . If this is correct (and the compiler really allows it) then a semicolon between and is not required. Consequently, there is an ambiguity between an if-then-else statement (as last statement of the ) and an if-then statement (as last statement of the ) and an . This is extremely dangerous and I feel that at least the Language Reference should warn against it. Even with an obliged semicolon, I always use "OTHERWISE instead of ELSE, but that's my personal preference. By the way, the Language Reference doesn't specify what a is. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] what is release plan for fpc?
Sven Barth via fpc-pascal wrote: The next version currently planned is 3.2.4 in a soonish time frame. At least as far as I'm aware MIPS64 should be supported there. If there are specific commits from main that would fix issues with that platform we could potentially still merge them to the fixes branch. I would be very happy if the fix for regression mantis #38492 will be included in a soon to release fpc-3.2.4 (git-svn-id: trunk@49160). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler probem?
Paul Renaud via fpc-pascal wrote: Hi, I have a question about some code. The following code segment generated a compiler error when I compiled it with... "A compiler error" assumes that we all have a crystal ball to look in Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new FP-like fork of Oberon
Liam Proven via fpc-pascal wrote: On Thu, 26 Oct 2023 at 08:57, Adriaan van Os via fpc-pascal wrote: It might interest you that I ported the Oberon-0 compiler, from the book Compiler Construction, to FreePascal. It does indeed! Is that FOSS? Is the code anywhere online? There are still a few changes I want to make, before putting it on github. However, I can send you the current code by private email. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new FP-like fork of Oberon
Liam Proven via fpc-pascal wrote: https://github.com/mikewarot/OberonSystem3FP It might interest you that I ported the Oberon-0 compiler, from the book Compiler Construction, to FreePascal. I guess this thread should be on fpc-other. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
That's absurd, there are many features in modes objfpc and macpas that don't compile with Delphi. That doesn't make it any less true. Also we won't add it anyway, so... 🤷♀️ Apperently, a sensible discussion, based on logical arguments, instead of dogma, is impossible. Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Sven Barth via fpc-pascal wrote: There will be no new visibility specifiers for something like this. And yes, it affects compatibility, as that means that code using that feature couldn't be compiled with Delphi and especially for library developers that might be an important point. That's absurd, there are many features in modes objfpc and macpas that don't compile with Delphi. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Michael Van Canneyt via fpc-pascal wrote: On Wed, 11 Oct 2023, Adriaan van Os via fpc-pascal wrote: Michael Van Canneyt via fpc-pascal wrote: $M controls the inclusion of RTTI, i.e. it allows or disallows the use of the published section. No more, no less. I don't see any use in allowing or disallowing something. And with the current design, it is, as I said, impossible, without macros, to compile the same code with {$M+} and {$M-}. While I agree with your statement about allowing/disallowing use of 'published' based on a directive, we inherited this from Delphi and it is a very basic part of the language & RTL, so changing it is simply not an option. Well, as I said, adding a new visibility specifier, e.g. "visible", meaning "public" in {$M-} state and "published" in {$M=}", does in no way degrade compatibility with Delphi code. One could reserve the new visibility specifier for modes objfpc and macpas. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Martin Frb via fpc-pascal wrote: On 11/10/2023 16:46, Adriaan van Os via fpc-pascal wrote: I don't see any use in allowing or disallowing something. And with the current design, it is, as I said, impossible, without macros, to compile the same code with {$M+} and {$M-}. Use $IfOpt instead of macros? {$IfOpt M+} published {$Else} public {$EndIf} I have a generic include file that has {$ifc not defined HaveTypeInfo} {$M-} {$definec visible public} {$elsec} {$ifc HaveTypeInfo} {$M+} {$definec visible published} {$elsec} {$M-} {$definec visible public} {$endc} {$endc} and now I can use "visible" as a new visibility specifier, which is more elegant and easy-to-read (and less typing) than polluting the code with lots of {$IfOpt M+} published {$Else} public {$EndIf} Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Michael Van Canneyt via fpc-pascal wrote: $M controls the inclusion of RTTI, i.e. it allows or disallows the use of the published section. No more, no less. I don't see any use in allowing or disallowing something. And with the current design, it is, as I said, impossible, without macros, to compile the same code with {$M+} and {$M-}. It has no impact on the other visibilities whatsoever. And that will not change, if only for Delphi compatibility. Adding a visibility specifier "visible" meaning "published" with {$M+} and "public" with {$M-} doesn't degrade Delphi compatibility. Anyway, I did that now for my source code with macros, but it's clumsy. If this is not acceptable, then you will need to wait for the extended RTTI or use fcl-passrc to solve your need. I tried fcl-passrc but it didn't produce anything but crashes. I much welcome the extended RTTI. Keep up the good work. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Sven Barth via fpc-pascal wrote: Ah, yes, only classes and interfaces can be used for published fields. For properties anything is allowed. However, what makes the whole thing unuseable is that with {$M-} the compiler doesn't accept "published". So, without using macros, the same source code can not be compiled with both {$M+} and {$M-}. That is really clumsy. With {$M-} "published" (or some other visibility specifier) should be equal to "public". Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Sven Barth via fpc-pascal wrote: Am 10.10.2023 um 11:18 schrieb Adriaan van Os via fpc-pascal: - In the released compiler, if you remove all visibility specifiers, you can get a list by specifying {$M+} on your base object and then list all published methods using the RTTI. My understanding is that I have to explicitely specify public for class fields, otherwise the compiler will issue an error. What exactly do you mean here? Do you have an example? {$mode macpas} {$M+} program testrtti; type T = object( TObject) i: integer; procedure A; end; procedure T.A; begin end; begin end. Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling testrtti.pas testrtti.pas(6,5) Error: Symbol cannot be published, can be only a class testrtti.pas(13) Fatal: There were 1 errors compiling module, stopping Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Hairy Pixels via fpc-pascal wrote: On Oct 10, 2023, at 4:18 PM, Adriaan van Os via fpc-pascal wrote: Interesting ! If I am correct, the docs referred to at <https://gitlab.com/freepascal.org/fpc/source/-/issues/38964> say ; visibility-clause: ; METHODS|PROPERTIES|FIELDS (visibility-expression) Does that mean that the "extended RTTI" branch supports RTTI for fields ? Yes, it should be compatible with Delphi so all fields with the specified visibility will be available at runtime. Great ! Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Michael Van Canneyt via fpc-pascal wrote: On Mon, 9 Oct 2023, Adriaan van Os via fpc-pascal wrote: Is there a trick to make (in mode macpas) all class methods implicitely virtual ? I mean, without adding the virtual keyword to all of them ? The reason is that I want to create a tree view of the class hierarchy with all the method names (not just those that are normally in the VMT because they are overridden). Any other ideas ? If you need this tree at run-time: - The "extended RTTI" branch of fpc allows you to list all methods, regardless of their visibility Interesting ! If I am correct, the docs referred to at <https://gitlab.com/freepascal.org/fpc/source/-/issues/38964> say ; visibility-clause: ; METHODS|PROPERTIES|FIELDS (visibility-expression) Does that mean that the "extended RTTI" branch supports RTTI for fields ? - In the released compiler, if you remove all visibility specifiers, you can get a list by specifying {$M+} on your base object and then list all published methods using the RTTI. My understanding is that I have to explicitely specify public for class fields, otherwise the compiler will issue an error. If you simply need this tree: - You can simply use fcl-passrc to analyse your source tree and create the complete list. No changes to code needed. I have several programs that do this. Will try that out, thanks. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Sven Barth via fpc-pascal wrote: No. Only those in the published section are part of the vMethodTable. And when compiled with $M+ the default visibility is changed from public to published. Also, I can get a list of the interfaces inherited from by a class, by looking at the vIntfTable of the VMT of the class. But is there also a way to get the method names from a CORBA interface ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] All methods vitrual ?
Sven Barth via fpc-pascal wrote: No. Only those in the published section are part of the vMethodTable. And when compiled with $M+ the default visibility is changed from public to published. OK, but that means that by explicitely specifying public/private/protected for fields and published for methods, a method list can be generated when compiling with {$M+}. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] All methods vitrual ?
Is there a trick to make (in mode macpas) all class methods implicitely virtual ? I mean, without adding the virtual keyword to all of them ? The reason is that I want to create a tree view of the class hierarchy with all the method names (not just those that are normally in the VMT because they are overridden). Hm, looking somewhat further, it seems that the vMethodTable of the class VMT does list all methods, not just the virtual methods, provided the code was compiled with type info {$M+} is that correct ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] All methods vitrual ?
Is there a trick to make (in mode macpas) all class methods implicitely virtual ? I mean, without adding the virtual keyword to all of them ? The reason is that I want to create a tree view of the class hierarchy with all the method names (not just those that are normally in the VMT because they are overridden). Any other ideas ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] overriden or not ?
Bart via fpc-pascal wrote: On Fri, Aug 18, 2023 at 10:21 AM Adriaan van Os via fpc-pascal wrote: Is there a way to see if a specific class/object method has been overridden or not ? There's an example of this in Lazarus Controls unit: // Check if SetTextBuf is overridden, otherwise // we can call RealSetText directly if TMethod(@Self.SetTextBuf).Code = Pointer(@TControl.SetTextBuf) then //not overridden Thanks, Adriiaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] overriden or not ?
Is there a way to see if a specific class/object method has been overridden or not ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Barriers semantics
Jonas Maebe via fpc-pascal wrote: See e.g. the explanation of "data dependency barrier" at https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In Interesting stuff to read. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Oberon-0
Ralf Quint via fpc-pascal wrote: What does Oberon and Forth have to do with the FreePascal compiler? 😕 1. Niklaus Wirth 2. Strong resemblance between Oberon and Pascal 3. An early version of his book Compiler Construction used Pascal rather than Oberon There is no relation with Forth, bur I didn't mention it in my original question. Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Oberon-0
Any suggestions for running simple Oberon-0 programs on the MacOSX command-line ? EIther by emulating its RISC processor or by changing the Oberon-0 compiler ? I prefer not to load the entire Oberon system (for which there do exist emulators). To answer my own question maybe the simplest option is to port the Oberon-0 compiler code to FPC and to link-in the Oberon-0 provided RISC module, which contains an interpreter for the target RISC processor, as described in the Wirth's Compiler Construction book. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Oberon-0
Any suggestions for running simple Oberon-0 programs on the MacOSX command-line ? EIther by emulating its RISC processor or by changing the Oberon-0 compiler ? I prefer not to load the entire Oberon system (for which there do exist emulators). Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working on a new way to educate people about pascal
Anthony Walter via fpc-pascal wrote: Hi guys, I had a new idea for an interface design to help people who either are not into programming yet or have only used a language other than Free Pascal. Please see this draft Introduction to Free Pascal web page I posted this morning. Well, I still remember the glorious day we were taught Pascal at university. As follows. We were given the Wirth Pascal Report. That was it. From that moment on we were supposed to know the language. I don't see how any "story telling" on the web can teach someone Pascal. The language is about abstract thinking and about expressing oneself elegantly and precisely. If the Wirth Report doesn't teach you that, nothing will. Modern mathematics education tries to teach by showing graphs and pictures, instead of formulas and proofs. But, by doing so, it misses the most important point — that mathematics is about abstract thinking. You will never get around the point that it is the abstract thinking that must be taught. And that's the whole point of the way we were taught Pascal at university. The details of the language can be looked up in a report. The only important thing is — to learn thinking. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] iOS
Jonas Maebe via fpc-pascal wrote: Unless you need FPC 3.2.2-specific fixes, you can probably just use FPC 3.2.0 instead for iOS. OK, I will do that, thanks. Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] iOS
OK, thanks, Adriaan van Os On Oct 6, 2022, at 7:12 PM, Adriaan van Os via fpc-pascal wrote: I would be pleased to know where I can find the latest iOS parsed headers and possibly a hello program. Also, the cross compilers for iOS don't seem to be available at <https://www.freepascal.org/download.html> on any of the listed mirrors. The last ones I did are ancient now at iOS 8 (where at 13 now!). https://github.com/genericptr/iOS_8_0 Not sure if anyone else has bothered to update since then. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] iOS
I would be pleased to know where I can find the latest iOS parsed headers and possibly a hello program. Also, the cross compilers for iOS don't seem to be available at <https://www.freepascal.org/download.html> on any of the listed mirrors. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access Violation When SetLength(DynArray, Value)
Peter B via fpc-pascal wrote: I suggest trying without optimisations and/or using cmem, to see if that changes the outcome. I would rather use a system memory debugger <https://elinux.org/Memory_Debuggers> to find the cause of the corruption. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
Sven Barth via fpc-pascal wrote: "However assigning a nested function variable to a function reference is much harder. Assigning a function reference to a nested function variable is hard as well. " "is nested" means that the actual function passed can be either global or local. ISO Pascal style function parameters are implicitely "is nested". The formal function reference for an "is nested" function contains space for both a function address and a context pointer. The context pointer is NIL if the actual function is declared global. For local functions, the context pointer typically contains a dynamic link chain pointer, required to address variables in the actual link frame. For object methods, the context pointer is the SELF pointer. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Not available duties
I got a message from UPS this morning stating "! Duties, taxes, and fees totaling NaN are due for this delivery." Oops, I don't hope I will ever get a message from UPS "! Duties, taxes, and fees totaling INF are due for this delivery." and with that I wish everybody a merry Christmas and a happy new year ! Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC PasCocoa/Differences
Jonas Maebe via fpc-pascal wrote: You are correct. OTOH, it feels kind of useless in general, because "A class extension bears some similarity to a category, but it can only be added to a class for which you have the source code at compile time (the class is compiled at the same time as the class extension)." That makes it rather useless indeed. Thanks for the reply. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC PasCocoa/Differences
The FPC PasCocoa/Differences wiki <https://wiki.lazarus.freepascal.org/FPC_PasCocoa/Differences> writes about ObjC class extensions: "You can use regular (non-external) categories defined in the implementation of a unit instead of class extensions, as the effect will be the same." However, the Apple Programming with Objective-C manual writes here <https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html> "Categories can be used to declare either instance methods or class methods but are not usually suitable for declaring additional properties." and "The only way to add a traditional property—backed by a new instance variable—to an existing class is to use a class extension, as described in Class Extensions Extend the Internal Implementation." So, the FPC PasCocoa/Differences wiki seems to ignore a crucial difference between ObjC categories and ObjC class extensions, namely the ability to add properties to an existing class. Am I correct that the latter is not possible in Objective-Pascal ? So, for example, I want to add a pointer field to NSView and all used classes inheriting from it. I could of course subclass NSView and used the classes inheriting from it, but that would be rather clumsy. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
Michael Van Canneyt via fpc-pascal wrote: You didn't configure your environment to deal correctly with Unicode. Wow ! what a sentence ! That sounds like "you didn't configure your car correctly to also take corners to the right." But alas, be it so. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
Michael Van Canneyt wrote: The output for me is the same, regardless of the -FcUTF-8 flag being present or not: question marks. But if I add uses cwstring; all will be well. Rationale: Without that, the RTL cannot convert whatever the compiler wrote in the binary to UTF8 to display it on the console. The compiler people will need to explain what exactly the compiler writes with or without the flag. Well, this should at least produce a warning, if not an error. Silently producing the wrong code is not a good idea. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
adriaan% cat uniquizz-utf8.pas {$codepage utf8} program uniquizz; var chars: UnicodeString; begin chars := '⌘ key'; writeln(chars); writeln(chars[1]); writeln( 'size ', sizeOf( chars)); writeln( 'length ', length( chars)); end. adriaan% fpc uniquizz-utf8.pas -FcUTF-8 Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling uniquizz-utf8.pas Assembling (pipe) uniquizz-utf8.s Linking uniquizz-utf8 14 lines compiled, 0.1 sec [l24:~/gpc/testfpc] adriaan% ./uniquizz-utf8 ? key ? size 8 length 5 This leaves me with a question mark too. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
To streamline the discussion, let me recapitulate: 1. multiple inheritance is nice to have, but it has the big issue that the inheritance tree becomes an inheritance graph and that makes overrules ambiguent. 2. interfaces don't have this issue with multiple inheritance, because they just declare, not implement 3. but that is also the weakness of interfaces, as we don't want to reimplement the same code each time 4. so, we really want an multiple-inheritance graph at the declaration level with clear tree-like unambigous inheritance paths at the implementation level 5. thus, the idea is to "push-in" implementation code into an interface that integrates fully at the declaration level but is independent at the implementation level. So, the idea (and the purpose of the discussion) I think is to implement (5) in an elegant way. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal