Fatal: Internal error 200305108

[paule32]

Thank You very much.
I tested the Code, and it works.
Sorry for idle, its nearly 11:30 am - late morning dinner ... :-)

What about strict protected ?

[Thaddy]

What about strict protected ?

Strict protected prevents other classes in the same unit that do not derive from QObject to modify the Fparent field. A simple protected does not do that. Other entities in the unit can then still modify it which you don't want.
Actually, this was a bug in the design of the original Delphi. Hence the introduction of strict private and strict protected in both Delphi and Freepascal. private and protected are still mainstream, because that bug is misused in too much code in the wild.

In this case it does not matter much, but I simply wanted to show you best practice. (And nobody did, what annoyed me)

Trying my unit code is one thing (of course it works) but understanding all my comments in the code and my posts is way more important.

Test for correctness:

Code: Pascal  [Select][+][-]

1. program qobjecttest;
2. {$mode objfpc}
3. uses
4.   Qt_Object; { my version, tdk }
5.  
6. { test for correctness }
7.  var  
8.    a,b:QObject;
9. begin
10.   { root object }
11.   a:=QObject.Create(b); { note remark below }
12.   { derived object }  
13.   b:=QMyObject.Create(a);
14.   { should be true, even if b is not created yet }
15.   writeln(a.Parent = nil, ', should be true' );
16.   { should be false }
17.   writeln(b.Parent = nil, ', should be false');
18.   { should be false }
19.   writeln(b.parent = a.parent,', should be false' );
20.   { should be true}
21.   writeln(b.parent = a, ' should be true');
22.   { should be true }
23.   writeln( b is QObject, ', should be true' );
24.   b.free;
25.   a.Free;
26.  end.

[Thaddy]

Note the internal error still needs to be reported. Even wrong code should not cause this.
The rule is: internal error? Always report. Attach the wrong code and document it is wrong and you know that.

[PascalDragon]

Actually, this was a bug in the design of the original Delphi. Hence the introduction of strict private and strict protected in both Delphi and Freepascal. private and protected are still mainstream, because that bug is misused in too much code in the wild.

That allows for tight coupling between related types in the same unit, thus simplifying designs. Protecting accesses of classes inside the same unit against each other is more often than not unnecessary micro management.

Note the internal error still needs to be reported. Even wrong code should not cause this.
The rule is: internal error? Always report. Attach the wrong code and document it is wrong and you know that.

Normally I'd agree, but paule32 left out a very important point: they use their own RTL with the TObject base type missing (which is related to both errors that paule32 gets). If one writes ones own RTL one must know what one is doing and how the compiler and the RTL interact with each other.

[Thaddy]

@1 I strongly disagree, it was a design bug. I was there in the (some part of) discussion. It is an excuse, with some benefits as you describe. Now we are stuck with that. It was always the intention to avoid that. It is not the more often case (what happens all over the place) but the NOT case.
@2 I agree, and I missed that,  but is not in anyway clear from his repository.
Anyway, my code explanation works in both scenario's and put him on the right track. Unless you find my code and explanation faulty, which it isn't.

[PascalDragon]

@2 I agree, and I missed that,  but is not in anyway clear from his repository.
Anyway, my code explanation works in both scenario's and put him on the right track. Unless you find my code and explanation faulty, which it isn't.

The thing is that the original code would already compile correctly with a standard RTL, thus the issue is the custom RTL.

[paule32]

when the issue is the custom RTL, why stuck in Error's ?
I can involve cdecl extern(al) ASM/C/Pascal methods, as Helper/Wrapper, that alloc (AnsiString Assign), and re-alloc/re-size (AnsiString concat) Memory for String Operations (astring.pas) by using TAnsiRec.
Each other GNU-Like Software (C/C++) can be used to compile a C-Toying Compiler with printf Strings on the Console - either through IBM-PC compatible $B8000 Screen Buffer (if you don't have any HAL under your OS) or with (win32)API Functions/Calls - without lose the Character of the Compiler.
I don't understand, that the system.pas need compilerproc members.
If one of those "needed" members are missing or incorrect - I get fault, and I could not create a custom RTL.
The next Thing is, that the Code is very redunanted in the Valuta in context of Position in Source Code.
It cost me some hour's, and day's to get a valid running executable, that was compiled with FPC.
Is this an Idea, to NOT create a custom RTL's by the expierences Programmer's ?
I would not say, that a Beginner User of Pascal should create a Compiler.
But it is very inoperable if Student's have to learn the Syntax, the Pro, and Cons of Pascal, and the internal Structures of FPC.
You would say: This topics are well documented.
But what does the RTL stuff have to do with System stuff ?

[Thaddy]

compilerproc is used for core language support and need to be implemented.

[paule32]

and, I can not import external Pascal modules aka:
uses Foo; in system.pas

[PascalDragon]

when the issue is the custom RTL, why stuck in Error's ?

Because the compiler and the RTL go hand in hand. The compiler expects specific functionality that the RTL provides and if it doesn't then that is an error.

Each other GNU-Like Software (C/C++) can be used to compile a C-Toying Compiler with printf Strings on the Console - either through IBM-PC compatible $B8000 Screen Buffer (if you don't have any HAL under your OS) or with (win32)API Functions/Calls - without lose the Character of the Compiler.

FPC isn't a C compiler.

I don't understand, that the system.pas need compilerproc members.
If one of those "needed" members are missing or incorrect - I get fault, and I could not create a custom RTL.

Correct, because these are the functions that the compiler calls directly for some of the functionality.

Is this an Idea, to NOT create a custom RTL's by the expierences Programmer's ?
I would not say, that a Beginner User of Pascal should create a Compiler.
But it is very inoperable if Student's have to learn the Syntax, the Pro, and Cons of Pascal, and the internal Structures of FPC.

Why would a student want to implement their own RTL? For learning the syntax, the pros and the cons of Pascal that isn't required. And what the core RTL provides is part of the language (in this case Object Pascal).

And no, in general one should not implement ones own RTL except if one has a very good reason for it.

But what does the RTL stuff have to do with System stuff ?

The System unit is part of the RTL. And some of the RTL units have a very close relationship with the compiler for one reason or another.

and, I can not import external Pascal modules aka:
uses Foo; in system.pas

Because the System unit is the core unit of Object Pascal. Every other unit automatically uses the System unit, thus the System unit can not use another unit.

[Joanna from IRC]

I have something more to add about my encounters with internal error.
Yesterday in my helpers unit an internal error appeared next to code that has not been modified recently.

Instead of doing cleanup and build I just did build and the error moved to different places in the unit each time I did build and finally disappeared.

I still have no idea of what is causing it to happen. 

I also sometimes have a problem when I use control space to try to open Lazarus autocomplete popup menu it sends me to some unit of code o didn’t write, and the only way I know to fix it is restart Lazarus.

[jamie]

Help From the Service Department:

  Did you update to the latest drivers and security patches ? 

[ccrause]

I have something more to add about my encounters with internal error.
Yesterday in my helpers unit an internal error appeared next to code that has not been modified recently.

Instead of doing cleanup and build I just did build and the error moved to different places in the unit each time I did build and finally disappeared.

I still have no idea of what is causing it to happen. 

There are several variants of internal error reports that appear to have one fact in common: compiling a project which uses other units that are already compiled.  This kind of error can be avoided if the project is rebuilt completely.  My speculation is that loading a pre-compiled unit somehow does not initialize all the information the compiler requires, while after a fresh compile of a unit the required information is available to the compiler.  Since I lack an understanding of the compiler design, this may not even make sense.

I also sometimes have a problem when I use control space to try to open Lazarus autocomplete popup menu it sends me to some unit of code o didn’t write, and the only way I know to fix it is restart Lazarus.

This is a separate Lazarus issue, not compiler related.

[Joanna from IRC]

@jamie not likely 

My speculation is that loading a pre-compiled unit somehow does not initialize all the information the compiler requires, while after a fresh compile of a unit the required information is available to the compiler.  Since I lack an understanding of the compiler design, this may not even make sense.

That is definitely possible. My helpers unit is called from many other units although I’m trying to reduce the number of units in project. I don’t know if that will help or not.. 

[paule32]

Hello Joanna,
I solve Your (me) issue with rm -rf ./units
where rm stands for remove directory/files -r for recursive (also all files, and directories).
Please take attention if you use this command - it is a *nix Command, and it is available under my MSYS2 Shell under Windows, too.
If you logged in as your "own" Admin, you can damage your file system in just few seconds !
So, use rm with caution, and NOT in Admin/root mode !

After you delete your developer unit Tree (not source Tree), make a complete new fresh build.
Take attention on your compile strategy (the position of source compile), it can be, that one or more units have to be compiled before the main compile. Especially when you compile per script (not LD-Script itself) - the Makefile or Shell/Batch file the source manually.