Re: [fpc-pascal] Type-casting a class variable

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

Jonas Maebe via fpc-pascal wrote:

On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
Constants are also evaluated wrong,you don’t know what that constant 
is going to be used for, so all steps of 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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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.

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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 



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%

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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 
.


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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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)

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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?

[Adriaan van Os via fpc-pascal]

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?

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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 ?

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

The FPC PasCocoa/Differences wiki  
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 



	"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

[Adriaan van Os via fpc-pascal]

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 van Os via fpc-pascal]

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

[Adriaan van Os via fpc-pascal]

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

Re: [fpc-pascal] Traits Proposal

[Adriaan van Os via fpc-pascal]

Michael Van Canneyt via fpc-pascal wrote:



On Tue, 9 Feb 2021, Ryan Joseph via fpc-pascal wrote:

We had talked about this some time ago and it's been rattling around 
in my brain so I wanted to write it down into a formal proposal where 
we can discuss it and hopefully agree upon a syntax. Everything is 
preliminary and tentative but this is a syntax which allows a 
"composition over inheritance" model, also known as "mix-ins" in some 
languages. That idea is similar to multiple inheritance except you 
have a concrete reference to the trait being implemented so you can 
resolve conflicts easily.


Here's what I have so far. Please feel free to look at it and give any 
feedback.


https://github.com/genericptr/freepascal/wiki/Traits-Proposal


In general, I am charmed by this idea.


I am, in whatever form it is implemented, also a proponent of the basic idea behind it, formulated 
on Ryan's  page as:


"Traits allow a "composition over inheritance" model which complement the existing single 
inheritance model introduced in Object Pascal. Traits are similar to multiple inheritance in 
languages such as C++ and Java, with the difference being an explicit reference to the class (or 
trait) which is being implemented."


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] Statically linked-in fpc code

[Adriaan van Os via fpc-pascal]

Michael Van Canneyt via fpc-pascal wrote:

Not sure where the 1.3.31 came from, but stack checking is mentioned in
1.7.72;


For fpc-3.0.4 stack stacking is mentioned in 1.3.31 as a global directive. For 3.2.0 stack checking 
is indeed mentioned in 1.2.72 as a local directive. If the directive has changed from global to 
local, that change (if not doc-only) could have triggered that it is now broken for statically 
linked-in code.


Anybody made code changes related to stack-checking ?

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] Statically linked-in fpc code

[Adriaan van Os via fpc-pascal]

Adriaan van Os via fpc-pascal wrote:

Jonas Maebe via fpc-pascal wrote:

On 2021-02-05 09:24, Adriaan van Os via fpc-pascal wrote:

It's crazy !
<https://bugs.freepascal.org/view.php?id=38440>


The default fpc.cfg file contains this (both in 3.0.4 and 3.2.0):



Thanks for tne reply.

# For a debug version compile with debuginfo and all codegeneration 
checks on

#IFDEF DEBUG
  -gl
  -Crtoi
  #WRITE Compiling Debug Version
#ENDIF


I find such sneaky configuration files an extremely bad idea !


Also

1. Section 1.3.31 of the Programmer's manual says "By default, no stack checking is 
performed."

2. If it is broken with gpc-3.2.0, such the more reason to put it off. It doesn't do real 
stack-checking anyway.


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] Statically linked-in fpc code

[Adriaan van Os via fpc-pascal]

Jonas Maebe via fpc-pascal wrote:

On 2021-02-05 09:24, Adriaan van Os via fpc-pascal wrote:

It's crazy !
<https://bugs.freepascal.org/view.php?id=38440>


The default fpc.cfg file contains this (both in 3.0.4 and 3.2.0):



Thanks for tne reply.

# For a debug version compile with debuginfo and all codegeneration 
checks on

#IFDEF DEBUG
  -gl
  -Crtoi
  #WRITE Compiling Debug Version
#ENDIF


I find such sneaky configuration files an extremely bad idea !



It seems the stack checking code causes issues for you in 3.2.0 for some 
reason.


It runs fine when compiling on the same Mac with gcc-3.0.4. So, there must have been a change 
between 3.0.4 and 3.2.0 ?


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] Statically linked-in fpc code

[Adriaan van Os via fpc-pascal]

Jonas Maebe via fpc-pascal wrote:

On 04/02/2021 21:26, Adriaan van Os via fpc-pascal wrote:

I am getting crashes on Mac OS X 10.8.5 in a C-program with statically
linked-in fpc code. The crashes seem related to fpc unit initialisation.
This happens with fpc-3.2.0 but not when compiling the same code with
fpc-3.0.4. Has something changed from 3.0.4 to 3.2.0 related to unit
initialisation ?


Not that I remember. Where exactly does it crash?


It's crazy !
<https://bugs.freepascal.org/view.php?id=38440>

Regards,

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

[fpc-pascal] Statically linked-in fpc code

[Adriaan van Os via fpc-pascal]

I am getting crashes on Mac OS X 10.8.5 in a C-program with statically linked-in fpc code. The 
crashes seem related to fpc unit initialisation. This happens with fpc-3.2.0 but not when compiling 
the same code with fpc-3.0.4. Has something changed from 3.0.4 to 3.2.0 related to unit 
initialisation ?


Regards,

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

[fpc-pascal] Coalition for App Fairness

[Adriaan van Os via fpc-pascal]

Leading App Developers Form The Coalition for App Fairness to Promote Competition and Protect 
Innovation on Digital Platforms




Regards,

Adriaan van Os

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

[fpc-pascal] x86-linux-gnu cross

[Adriaan van Os via fpc-pascal]

On Mac OS X 10.8, I have built an fpc-3.0.4  runtime-library for CPU_TARGET=x86_64 OS_TARGET=linux 
BINUTILSPREFIX=x86_64-linux-gnu- after building gnu binutils-2.34 for  --target=x86_64-linux-gnu 
--host=i686-apple-darwin --build=i686-apple-darwin --prefix=/usr/local.


Now the following program crashes when compiled on OSX and executed on 64-bit 
debian 6.0.7.

{$linklib libgcc_s.so}
program Hello;
  uses
cmem;
  begin
writeln
  ( 'Hello');
  end.

but this runs fine

{$linklib libgcc.a}
{$linklib libgcc_eh.a}
{$linklib libc.a}
program Hello;
  uses
cmem;
  begin
writeln
  ( 'Hello');
  end.

Linking with other shared libs (maybe dependent on libgcc_so?) also causes a segmentation fault on 
start. All the libs are from .


My impression is that somehow linking-in the c-libs causes the entry-point of the program to be 
wrong. Maybe there is a linker option (I don't know of) to prevent 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] Linux GTK-2 GUI app

[Adriaan van Os via fpc-pascal]

Michael Van Canneyt wrote:

Normally a zip file with a the binary and supporing files, plus a README 
file should be enough.


Can you refer me to an example ?

Thanks,

Adriaan van Os

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