Hello,

The compiler message "PPU Invalid Version n" should be made a fatal error. This would help Lazarus to display the real problem (wrong ppu version), instead of displaying the error Massage "Fatal: Can't find unit x", which is misleading in this case.

Regards, Bernd.

Index: compiler/msgtxt.inc
=================================================================== --- compiler/msgtxt.inc (Revision 11559)
+++ compiler/msgtxt.inc (Arbeitskopie)
@@ -743,7 +743,7 @@
'10005_U_PPU Time: $1'#000+
'10006_U_PPU File too short'#000+
'10007_U_PPU Invalid Header (no PPU at the begin)'#000+
- '10008_U_PPU Invalid Ver','sion $1'#000+
+ '10008_F_PPU Invalid Ver','sion $1'#000+
'10009_U_PPU is compiled for another processor'#000+ '10010_U_PPU is compiled for an other target'#000+ '10011_U_PPU Source: $1'#000+
@@ -1127,4 +1127,4 @@
'**1*_'#010+
'**1?_Show this help'#010+
'**1h_Shows this help without waiting'#000
-);
+);
\ Kein Zeilenvorschub am Ende der Datei
Index: compiler/msgidx.inc
=================================================================== --- compiler/msgidx.inc (Revision 11559)
+++ compiler/msgidx.inc (Arbeitskopie)
@@ -660,7 +660,7 @@

    unit_u_ppu_time=10005;
    unit_u_ppu_file_too_short=10006;
    unit_u_ppu_invalid_header=10007;

- unit_u_ppu_invalid_version=10008;
+ unit_f_ppu_invalid_version=10008;

    unit_u_ppu_invalid_processor=10009;
    unit_u_ppu_invalid_target=10010;
    unit_u_ppu_source=10011;

@@ -758,4 +758,4 @@
MsgIdxMax : array[1..20] of longint=(
24,87,248,84,64,50,108,22,201,61,
43,1,1,1,1,1,1,1,1,1
- );
+ );
\ Kein Zeilenvorschub am Ende der Datei
Index: compiler/fppu.pas
=================================================================== --- compiler/fppu.pas (Revision 11559)
+++ compiler/fppu.pas (Arbeitskopie)
@@ -208,7 +208,8 @@
{ check for allowed PPU versions }

          if not (ppufile.GetPPUVersion = CurrentPPUVersion) then
           begin

-
Message1(unit_u_ppu_invalid_version,tostr(ppufile.GetPPUVersion),@queuecomment);
+ Message1(unit_f_ppu_invalid_version,
tostr(ppufile.GetPPUVersion) + ': ' +
+ ppufilename^ ,@queuecomment);

             ppufile.free;
             ppufile:=nil;
             exit;

@@ -1569,4 +1570,4 @@

          registerunit:=hp;
        end;

-end.
+end.
\ Kein Zeilenvorschub am Ende der Datei

This has a "small" draw back. If this message is fatal the compiler won't search anymore for the sources of the unit to recompile it.

sorry, I did not notice this, because I don't have the source of the unit.

Regards, Bernd.

As a workaround, I put the string "Fatal:" in front of the corresponding compiler message 10008_U_PPU... So Lazarus displays the correct error message ("PPU Invalid Version...") if the source of the unit is not present. If the source is present, fpc does compile it.

I think, the proper way could be, that fpc makes this message fatal, if the unit source is not present.

Regards, Bernd.

Bernd Mueller wrote

I think, the proper way could be, that fpc makes this message fatal, if the unit source is not present.

The proper way is probably for Lazarus to parse also other messages in case of Fatal, to give more context :-).

Micha

The problem is that there are multiple languages for FPC's error messages, so it's not that simple. Maybe each error message will start with the error code ?

Ido

Zitat von ik :

FYI:
Because there are several tools to parse FPC/Make/whatever output it is planned to tell fpc to always give english output and show the translated text in the messages window.

Mattias

Op Wed, 13 Aug 2008, schreef Mattias Gärtner:

FYI: Because there are several tools to parse FPC/Make/whatever output it is planned to tell fpc to always give english output and show the translated text in the messages window.

Ok, for once and for all, and please read up the following words loudly while reading them:

Never

Parse

Compiler

Messages!

It has always been communicated that the parsing of FPC output is a bad idea. The output is designed to be readbable for humans, not for computers. We want, and feel free to, have the options to change the text output of FPC completely.

If you don't want to use the compiler unit, feel free to design a protocol for more computer friendly messages.

Daniël

It easier to change the message parser if you change it, than to design a protocol for more computer friendly messages.

Vincent

Op Wed, 13 Aug 2008, schreef Vincent Snijders:

It easier to change the message parser if you change it, than to design a protocol for more computer friendly messages.

It's not about what is less work. It's about what has the best compatibility, the best maintainability, the best reliability and most features.

Daniël

The not yet designed protocol has a bad score on the feature list, because it is not available.

Vincent

Op Wed, 13 Aug 2008, schreef Vincent Snijders:

The text mode IDE can display statisics while compiling. Why can't Lazarus?

There is the compiler unit, which *is* available, and this is the only officially supported compiler interface. We are not against other officially supported interfaces, but parsing messages is definately not an offical interface and recommended against. It is not the first time we have this discussion, we discussed possible protocols before.

Daniël

Because it is a unit. Switching compilers would mean recompiling lazarus.

Vincent

Can you give a link?

Mattias

Because it is a unit:
* A crashing compiler would mean a crashing IDE.
* A compiler with memory leak would mean a IDE with memory leak.

Vincent

Op Wed, 13 Aug 2008, schreef Mattias Gaertner:

http://lists.freepascal.org/lists/fpc-devel/2006-May/007788.html

Daniël

Op Wed, 13 Aug 2008, schreef Vincent Snijders:

Because it is a unit: * A crashing compiler would mean a crashing IDE. * A compiler with memory leak would mean a IDE with memory leak.

Your point is correct, but the textmode IDE does survive compiler crashes and you can continue development (allthough it's not recommended). It could also clean up memory leaks in the past, it did heap swapping which code is no longer present today.

Still, you should think twice doing not recommended things. You can be 100% sure compiler messages will break one time and you should think about migrating away from parsing, rather than do more parsing.

Daniël

Thanks.
The thread did not discuss all problems, but it has one good idea: We need a machine readable output format for fpc.
Any progress?

Mattias

Hmm, the question remains:
"
Since some time FPC doesn't flush output on pipes after writeln. On linux I can use a pseudo terminal, what can I do on win32 to get flushed output from FPC into the message window of MSEide? "
"
I need no machine readable output (up to now), I need a way to get flushed writeln output from the RTL on widows to display it in the MSEide message window (compiler output) and the target window (program output). On linux I use a PTY to connect compiler and target -> all is OK, on win32 I can only use pipes AFAIK where the RTL doesn't flush output on writeln. "
"
The problem exists not only for the compiler but for all console programs. I found no way to display the interactive output in a IDE window on win32. On Linux I can use a pseudo terminal to get flushed output from target. There are no pseudo terminals on win32, I must use pipes. The current 2.0.3 RTL does not flush output on writeln if the filehandle is a pipe (2.0.2 does!). So the IDE target console window is unusable on win32 with FPC 2.0.3 RTL and works OK with FPC 2.0.2 RTL.
"
;-)

Martin

Indeed, people complained about the speed when redirecting output to a file.

So the answer is:
"It is not possible to get flushed writeln and compiler messages on win32 pipes with FPC"?

Martin

In our previous episode, Martin Schreiber said:

Maybe, (with a custom textio driver, so that the generic rtl isn't compromised) but as Daniel said, parsing the text compiler output isn't the most desirable outcome.

So far nobody needed this, e.g. I use an IDE with an integrated compiler ;) However, I guess we can add a switch which tells the compiler to flush when writing to a file/pipe.

This is not needed, it's just a switch which does
TextRec(Output).FlushFunc:=TextRec(Output).InOutFunc

MSEide+MSEgui and it's users = nobody, I see.
Thanks for the clear message. ;-)

Martin

Didn't you say recently that you didn't know that people still develop under windows ;)? Anyways, I'll implement a switch for now.

IIRC, we once had the idea to feed the compiler an error message file with only error numbers as error "messages" so parsing would be easier.

Marc

Zitat von Marc Weustink :

The error number is needed, yes.
But without text debugging becomes harder.

Mattias

In our previous episode, Mattias G�rtner said:

So you would need a dual system, all info in the beginning of the line easily (and safely) parsable, and the text version behind it to pass through to the user?

Zitat von Marco van de Voort :

Yes.
I know, I can do that simply by sed-ing the errore.msg.

Mattias