Re: [fpc-pascal] Exception handling and .dylibs on MacOS

Sven Barth wrote: Adriaan van Os mailto:adri...@adriaan.biz>> schrieb am Do., 3. Apr. 2025, 14:47: Well, in what form will a patch along these lines be accepted ? I really need this to be fixed. In no form, cause this is not a way in which we want to see this fixed. So, how are you

[fpc-pascal] Exception handling and .dylibs on MacOS

I recall this thread from last October I reported this, with a test program, as bug #40950 . The problem is that the fpc RTL, with its global variables, is duplicated in the .dylib as well as in the main program, which confuses the

Re: [fpc-pascal] InterlockedExchangeAdd64

Sven Barth via fpc-pascal wrote: Am 10.01.2025 um 15:43 schrieb Adriaan van Os via fpc-pascal: I have an arm64 (aarch64) test program on MacOS that calls InterlockedExchangeAdd64 with a target variable that is not 8-byte aligned. Running the test program emits "EBusError: Bus err

Re: [fpc-pascal] InterlockedExchangeAdd64

Is this really a bug? This depends on what you do in your ErrorProc implementation, doesn't it? Do a writeln the runtime number and break. But normally, a bus error, doesn't call into System.ErrorProc. Regards, Adriaan van Os ___ fpc-pascal mai

[fpc-pascal] InterlockedExchangeAdd64

I have an arm64 (aarch64) test program on MacOS that calls InterlockedExchangeAdd64 with a target variable that is not 8-byte aligned. Running the test program emits "EBusError: Bus error or misaligned data access". So far so good. But now I install a system.ErrorProc and run the same progr

Re: [fpc-pascal] External library name

Hairy Pixels via fpc-pascal wrote: I see this pattern in C translated header often but I’ve honestly never understood it entirely. Why does this “cDllName" need to be added to every single function which you could just use {$linklib }? This is a habit from the WIndows and Delphi world. In

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: On Sat, 14 Dec 2024, Adriaan van Os via fpc-pascal wrote: It's not because something is in the pascal standard, that FPC has it. It is. Appendix D6 of the Programmer's Reference says "This mode is selected by the $MODE ISO

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: Also, I wonder if "ISOPROGRAMPARAS" in the Programmer's Guide is spelled correctly. It is, as that is what is used in the compiler: globtype.pas:736 I don't mind, but it is rather weird/amusing Webster's dictionary para noun A piece of Turkish

Re: [fpc-pascal] Procedural parameters

Hairy Pixels via fpc-pascal wrote: On Dec 15, 2024 at 12:21:29 PM, Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> wrote: You mean the original pascal only allowed function declarations to be parameter types? Yes. And it is still true in the ISO 7185 Pascal

Re: [fpc-pascal] Procedural parameters

Hairy Pixels via fpc-pascal wrote: On Dec 15, 2024 at 1:22:25 AM, Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> wrote: Similarly, you also cannot write: function A(B : (one,two,three)) : double; Not really. The function type declaration is a Borland inven

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: On Sat, 14 Dec 2024, Adriaan van Os via fpc-pascal wrote: Macpascal and Iso pascal have procedural parameters, e.g. function A( function B: double): double; Is there a $modeswitch to allow this ? I searched "procedure parameter

[fpc-pascal] Procedural parameters

Macpascal and Iso pascal have procedural parameters, e.g. function A( function B: double): double; Is there a $modeswitch to allow this ? I searched "procedure parameter" and "procedural parameter" in the Language Reference, but could not find anything. Also, I wonder if "ISOPROGRAM

Re: [fpc-pascal] Incremental compiling not working in new version

Sven Barth via fpc-pascal wrote: Hairy Pixels via fpc-pascal > schrieb am Mi., 4. Dez. 2024, 13:56: Were there known changes in that area since March 3rd 2023? Honestly they were causing so many crashes maybe they got pulled for incremental bu

Re: [fpc-pascal] Printing unicode characters

Hairy Pixels via fpc-pascal wrote: ChatGPT is saying I can print unicode scalars like that but i don’t see it works and no compiler warnings even. Did it make this up or did I do something wrong? Writeln('Unicode scalar 1F496: ', #$1F496); // 💖 Writeln('Unicode scalar 1F496: ', WideChar($

[fpc-pascal] dlmopen on MacOS

I have a shared library on MacOS written in FPC. It needs to be loaded multiple times, that is each time with its own set of global (dylib) variables. On Linux I would use dlmopen with LM_ID_NEWLM, but MacOS doesn't have dlmopen and dlopen doesn't have LM_ID_NEWLM. I can create a copy of the dyl

Re: [fpc-pascal] Power operator fails in ordinal range definition

Hairy Pixels via fpc-pascal wrote: On Nov 14, 2024 at 1:53:17 PM, Sven Barth via fpc-pascal > wrote: The **-operator is not *implemented* by the compiler. It's provided through the Math unit. Thus you can't use it in constant declarations. Why is that

[fpc-pascal] Namespace collisions

In ObjectiveC we have the infamous namespace collision problem. I am wondering how this applies to Objective Pascal. For example, I have a plugin, written in Pascal, with only one global external symbol, the plugin entry point a6d0 (__TEXT,__text) external _MyPluginEntryPoint

Re: [fpc-pascal] type helpers in trunk

Thomas Kurz via fpc-pascal wrote: Do you have `{$MODESWITCH TYPEHELPERS}`? Yes ! 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 helpers in trunk

Has something changed for type helpers in fpc trunk ? I don 't see a note of it in . I have code that compiles with 3.2.2, but the trunk compiler doesn't recognize (or doesn't accept) dot operations on the type. Very strange. Regards, Adriaan van

Re: [fpc-pascal] Library packages

Sven Barth via fpc-pascal wrote: The main difference is that a program or library compiled without dynamic packages will each have a statically linked copy of the RTL (and any other code it uses). If a binary uses dynamic packages then the binary itself will not contain code that is contained

[fpc-pascal] Library packages

Can someone tell me what the status is of Library packages, aka "Delphi packages" ? I found the WIki but it looks like a preliminary document. My questions 1. For MacOS, are there any differences at the Mach-O level between a dynamic library and a library

Re: [fpc-pascal] AllocateThreadVars ?

In a small test program, exception handling works, in the main thread, with BeginThread as well as with pthread_create. In the big program, it doesn't. So the mystery still to solve, is why Maybe this is related to as the code r

Re: [fpc-pascal] AllocateThreadVars ?

In a small test program, exception handling works, in the main thread, with BeginThread as well as with pthread_create. In the big program, it doesn't. So the mystery still to solve, is why Maybe this is related to as the code r

Re: [fpc-pascal] AllocateThreadVars ?

Sven Barth via fpc-pascal wrote: You already wrote that you might have found a different cause, but nevertheless to clarify: the RTL initialization for the thread (which includes AllocateThreadVars) should already be done transparently by the RTL through hooks provided by pthread. Yes, I fo

Re: [fpc-pascal] AllocateThreadVars ?

Sven Barth via fpc-pascal wrote: Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Mi., 9. Okt. 2024, 16:44: I have a program on MacOS that calls CoreAudio which calls the application back in a so-called AURendererCallback in a

Re: [fpc-pascal] AllocateThreadVars ?

Adriaan van Os wrote: In that thread, a FreePascal try except block doesn't catch an exception. A globally installed TExceptProc does. if I look in the RTL code, it looks like a thread created with BeginThread does some extra things, like calling SysAllocateThreadVars. A comment notes that exc

[fpc-pascal] AllocateThreadVars ?

I have a program on MacOS that calls CoreAudio which calls the application back in a so-called AURendererCallback in a separate (com.apple.audio.IOThread.client) thread. This is a pthread created by the system software, not by the FreePascal RTL. In that thread, a FreePascal try except block do

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

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

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

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

[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 I use make clean crossa

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

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

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

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 w

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

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 __

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

[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 s

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 intrinsi

[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 no

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 intege

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

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.

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 us

[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 use

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 so

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

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

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

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

[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 corr

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 s

[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 n

[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

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 with various options (e.g. -u -r on OS

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

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 programm

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 { ";" paramet

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 das

[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 ) [ a

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 "

[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 modifi

[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 { ","

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

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 remov

[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

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 st

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 the

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

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 (

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

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" | "pasca

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

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 __

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

[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 ad

[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

[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-identifie

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

[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 d

[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" ) [ "

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 semicolo

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 } [ ";"

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" statemen

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

[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 implementati

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

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

[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 [ ".." con

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 fix

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 _

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

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 ___

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 v

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

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 u

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 inste

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

  1   2   >