Hi Frank
[...]
Never say impossible ...
program Chief44;
uses Chief44u;
type TMemoStrings = abstract object (TStrings) end;
begin WriteLn ('OK') end.
unit Chief44u;
interface
type TStrings = abstract object procedure foo; abstract; end;
implementation
end.
--- p/gpc-decl.c.orig Tue Mar 25 13:33:12 2003 +++ p/gpc-decl.c Wed Mar 26 08:48:09 2003
[...]
Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing?
I forgot to say: After applying the patch, you'll have to recompile all Pascal files (remove all GPIs). If this still doesn't help, I need some example code.
Frank
On 27 Mar 2003 at 16:20, Frank Heckenbach wrote:
Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing?
I forgot to say: After applying the patch, you'll have to recompile all Pascal files (remove all GPIs). If this still doesn't help, I need some example code.
Are you talking about my own files, or the RTS files p/rts?
I already removed the former - to no effect. As for example code, unless you want 30,000 lines of code, all my attempts to reduce the problem to a small program have failed. I will continue trying though - but in the meantime I will have to revert to the previous alpha.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 27 Mar 2003 at 16:20, Frank Heckenbach wrote:
Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing?
I forgot to say: After applying the patch, you'll have to recompile all Pascal files (remove all GPIs). If this still doesn't help, I need some example code.
Are you talking about my own files, or the RTS files p/rts?
The former.
I already removed the former - to no effect.
:-(
As for example code, unless you want 30,000 lines of code, all my attempts to reduce the problem to a small program have failed.
If you really can't reduce it (by successively removing unrelated parts while the bug is still there -- that's usually more successful than guessing what the reason might be and trying to write a test from scratch), that's still better than nothing. :-/
Frank
On 27 Mar 2003 at 19:00, Frank Heckenbach wrote:
[...]
As for example code, unless you want 30,000 lines of code, all my attempts to reduce the problem to a small program have failed.
If you really can't reduce it (by successively removing unrelated parts while the bug is still there -- that's usually more successful than guessing what the reason might be and trying to write a test from scratch), that's still better than nothing. :-/
That is what I have been trying to do so far (i.e., write a test from the scratch). So I will go back and try to reduce the existing code ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Hi Frank
I have been able to reduce the problem to a small program. The problem seems to lie in the handling of the declaration of virtual methods, and how units use each other. I am attaching the test program (chief45). I have embedded some comments as to how to circumvent the problem (without fixing the bug) - but this is obviously not the solution.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief45v.pas Date: 28 Mar 2003, 0:46 Size: 122 bytes. Type: Program-source
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief45.pas Date: 28 Mar 2003, 0:47 Size: 186 bytes. Type: Program-source
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief45u.pas Date: 28 Mar 2003, 0:45 Size: 356 bytes. Type: Program-source
Prof A Olowofoyeku (The African Chief) wrote:
I have been able to reduce the problem to a small program. The problem seems to lie in the handling of the declaration of virtual methods, and how units use each other. I am attaching the test program (chief45). I have embedded some comments as to how to circumvent the problem (without fixing the bug) - but this is obviously not the solution.
Thanks. With this example, I could fix the bug (hopefully this time the right one, and without breaking anything else ...).
You can then probably undo the other patch, but it doesn't matter much.
Frank
On 28 Mar 2003 at 16:19, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
I have been able to reduce the problem to a small program. The problem seems to lie in the handling of the declaration of virtual methods, and how units use each other. I am attaching the test program (chief45). I have embedded some comments as to how to circumvent the problem (without fixing the bug) - but this is obviously not the solution.
Thanks. With this example, I could fix the bug (hopefully this time the right one, and without breaking anything else ...).
Something else is broken. The attached revised chief45u.pas shows it. The problem is when one unit uses another (interface section) and that other one uses the first one (implementation section). All you need to do to trigger it is to add "uses chief45v;" in the implementation section of chief45u.pas.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief45u.pas Date: 29 Mar 2003, 9:02 Size: 404 bytes. Type: Program-source
Hi Frank
I found another bug involving when 2 units use each other - this is probably the same as I reported earlier today. I have attached a test program. Note that the error is there whether you use the new "initialization" or just "begin end."
This program should output "OK", and does so under BP and Delphi.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief46v.pas Date: 29 Mar 2003, 12:23 Size: 98 bytes. Type: Program-source
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief46.pas Date: 29 Mar 2003, 12:16 Size: 67 bytes. Type: Program-source
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: chief46u.pas Date: 29 Mar 2003, 12:23 Size: 127 bytes. Type: Program-source
"Prof A Olowofoyeku (The African Chief)" wrote:
... snip ...
This program should output "OK", and does so under BP and Delphi.
... snip ...
Part 1.2 Type: Plain Text (text/plain) Description: Attachment information.
Name: chief46v.paschief46v.pas Type: unspecified type (Application/Octet-stream) Encoding: BASE64
Part 1.4 Type: Plain Text (text/plain) Description: Attachment information.
Name: chief46.paschief46.pas Type: unspecified type (Application/Octet-stream) Encoding: BASE64
Part 1.6 Type: Plain Text (text/plain) Description: Attachment information.
Name: chief46u.paschief46u.pas Type: unspecified type (Application/Octet-stream) Encoding: BASE64
May I suggest that, if you must have attachments, which are encoded and thus expanded anyhow, you at least pack them into a single .zip file? That will preserve dates, etc. and make for much easier handling and more compact transmissions.
Prof A Olowofoyeku (The African Chief) wrote:
I found another bug involving when 2 units use each other - this is probably the same as I reported earlier today.
Unfortunately not.
I have attached a test program. Note that the error is there whether you use the new "initialization" or just "begin end."
This program should output "OK", and does so under BP and Delphi.
First of all, EP does not even allow initializers in mutually dependent modules (for good reasons, since in general the order of execution is not well-defined; e.g., if the main program uses the other unit, they're executed in reverse order, and if it uses both, or uses some other units which in turn use one or both of these, it gets really hairy).
But that's not actually the issue here. The following patch should fix it, but still I'd be very careful with such initializers (especially if their order of execution matters, like here).
--- p/util.c.orig Sat Mar 29 15:02:20 2003 +++ p/util.c Sat Mar 29 15:06:14 2003 @@ -1682,6 +1682,10 @@ expand_start_cond (run_condition, 0); expand_expr_stmt (build_modify_expr (run_condition, NOP_EXPR, boolean_false_node));
+ /* Initialize this module's variables since another module's initializer + could access them (via circular references, though violating EP). */ + un_initialize_block (decls, 0); + for (imported_interface = current_module->imports; imported_interface; imported_interface = TREE_CHAIN (imported_interface)) @@ -1734,7 +1738,6 @@ Pmode); if (current_module->main_program) emit_constructor_call ("_p_DoInitProc"); - un_initialize_block (decls, 0); }
/* Generate special code at the end of a module/unit constructor. */
Frank
Prof A Olowofoyeku (The African Chief) wrote:
Something else is broken. The attached revised chief45u.pas shows it. The problem is when one unit uses another (interface section) and that other one uses the first one (implementation section). All you need to do to trigger it is to add "uses chief45v;" in the implementation section of chief45u.pas.
Fix.
Frank
On 30 Mar 2003 at 3:02, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Something else is broken. The attached revised chief45u.pas shows it. The problem is when one unit uses another (interface section) and that other one uses the first one (implementation section). All you need to do to trigger it is to add "uses chief45v;" in the implementation section of chief45u.pas.
Fix.
Many thanks. All my problems with objects and units are fixed now.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 30 Mar 2003 at 3:02, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Something else is broken. The attached revised chief45u.pas shows it. The problem is when one unit uses another (interface section) and that other one uses the first one (implementation section). All you need to do to trigger it is to add "uses chief45v;" in the implementation section of chief45u.pas.
Fix.
Many thanks. All my problems with objects and units are fixed now.
Frank Heckenbach wrote:
On 30 Mar 2003 at 3:02, : You can then probably undo the other patch, but it doesn't matter much.
There have been several fixes. Did you apply all of them ?
Regards,
Adriaan van Os
On 31 Mar 2003 at 13:53, Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
[...]
Many thanks. All my problems with objects and units are fixed now.
Frank Heckenbach wrote:
On 30 Mar 2003 at 3:02, : You can then probably undo the other patch, but it doesn't matter much.
There have been several fixes. Did you apply all of them ?
Yes - but only those that related to the problems that I reported.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 30 Mar 2003 at 3:02, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Something else is broken. The attached revised chief45u.pas shows it. The problem is when one unit uses another (interface section) and that other one uses the first one (implementation section). All you need to do to trigger it is to add "uses chief45v;" in the implementation section of chief45u.pas.
Fix.
Many thanks. All my problems with objects and units are fixed now.
Frank Heckenbach wrote:
On 30 Mar 2003 at 3:02, : You can then probably undo the other patch, but it doesn't matter much.
There have been several fixes. Did you apply all of them ?
I meant the patch for chief44.pas. The one for chief45.pas is more general. However, keeping the chief44 patch won't hurt much (just put a little unnecessary information in GPI files).
Otherwise, all the patches I sent can be applied together.
Frank
-
Adriaan van Os -
CBFalconer -
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)