I just committed a fixed version of the compileroptions.pp file with all the C style += replaced with the Pascal version. So the -Sc compiler flag shouldn't be necessary any more.

At the same time, I found a problem. When you open the Compiler Options dialog and press the Apply (or OK) button, everything works just fine the first time. If you press either of those buttons a second time, it crashes Lazarus. I am not absolutely certain, but it appears to be a problem with the xmlcfg.pp or dom.pp unit in the fcl/xml directory. Here is what I have traced down so far.

In the compileroptions.pp file, there is a procedure called TCompilerOptions.SaveCompilerOptions. This procedure is called any time the Apply or OK buttons are pressed. I commented out all the lines in this function except just the first SetValue call. It is as follows:

  xmlcfg.SetValue('CompilerOptions/Parsing/Style/Value', Style);

Style is an Integer. I added a couple of writeln statements to the bottom of the SetValue method in the xmlcfg.pp file. Here is what the modified function looks like:

procedure TXMLConfig.SetValue(const APath, AValue: String);
var
  node, subnode, attr: TDOMNode;
  i: Integer;
  name, path: String;
begin
  node := doc.DocumentElement;
  path := APath;
  while True do begin
    i := Pos('/', path);
    if i = 0 then break;
    name := Copy(path, 1, i - 1);
    path := Copy(path, i + 1, Length(path));
    subnode := node.FindNode(name);
    if not Assigned(subnode) then begin
      subnode := doc.CreateElement(name);
      node.AppendChild(subnode);
    end;
    node := subnode;
  end;
  attr := node.Attributes.GetNamedItem(path);
  if not Assigned(attr) then begin
    attr := doc.CreateAttribute(path);
    node.Attributes.SetNamedItem(attr);
  end;
writeln('++++++++++++++++++++++++ attr.NodeValue := AValue = ' + AValue);
  attr.NodeValue := AValue;
writeln('++++++++++++++++++++++++ attr.NodeValue := AValue finished.');
end;

So the final writeln should be executed every time the Apply or OK button is pressed. The first time, it is, but the second time it isn't and it crashes on "attr.NodeValue := AValue;". Here are the results that were written out:

1st Apply:

[TControl.GetText] TEDIT got: "./ppc386.cfg"
[TControl.GetText] TEDIT got:
"/opt/fpc/rtl/i386;/opt/fpc/rtl/inc;/opt/fpc/rtl/linux;/opt/fpc/rtl/objpas;/opt/fpc/fcl/inc;/opt/fpc/fcl/linux;/opt/fpc/lazarus/lcl"

[TControl.GetText] TEDIT got:
"/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66"
[TControl.GetText] TEDIT got:
"/opt/fpc/rtl/linux;/opt/fpc/rtl;/opt/fpc/rtl/objpas;/opt/fpc/fcl/linux;/opt/fpc/gtk"

[TControl.GetText] TEDIT got: "/opt/fpc/ppc386"
++++++++++++++++++++++++ attr.NodeValue := AValue = 1
++++++++++++++++++++++++ attr.NodeValue := AValue finished.

2nd Apply:

[TControl.GetText] TEDIT got: "./ppc386.cfg"
[TControl.GetText] TEDIT got:
"/opt/fpc/rtl/i386;/opt/fpc/rtl/inc;/opt/fpc/rtl/linux;/opt/fpc/rtl/objpas;/opt/fpc/fcl/inc;/opt/fpc/fcl/linux;/opt/fpc/lazarus/lcl"

[TControl.GetText] TEDIT got:
"/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66"
[TControl.GetText] TEDIT got:
"/opt/fpc/rtl/linux;/opt/fpc/rtl;/opt/fpc/rtl/objpas;/opt/fpc/fcl/linux;/opt/fpc/gtk"

[TControl.GetText] TEDIT got: "/opt/fpc/ppc386"
++++++++++++++++++++++++ attr.NodeValue := AValue = 1 An unhandled exception occurred at 0x08074299 :
EDOMHIERARCHYREQUEST in NodeWC.InsertBefore
0x08074299
0x00000000

It is interesting because the value is the same both times, but it is crashing the second time for some reason.

Can someone take a look at this and see if you can find out what is happening?

Curtis

Not related to #IFDEF DEBUG at all.

=====================================================

This uses the ASSERTIONS feature found in FPC.

At the top of most of the units you should find the following code:

{$ifdef Trace}
{$ASSERTIONS ON}
{$endif}

If you declare "Trace" either before this in the unit file or globally in the 'make' this turns on 'ASSERTIONS'.

In place of the writeln statement in the code us the following:

Assert(False, 'Trace:[whatever you want]');

This is a standard Assert call.

The 'False" tells the Assertion handler that the AssertionProc procedure should be called and passed the next parameter as a message.

The utrace.pp unit has replaced the standard AssertionProc with one that will handle the 'Trace:' key in the message. If the AssertionProc sees the leading work 'Trace:' in the message it assumes it is just being used to do code tracing and does not fire a normal Assertions. If this key word is not found it deals with the Assertion as it normally would by calling the original AssertionProc. You can see how this is done in the utrace.pp unit.

The output from the above line is everything after the 'Trace:' keyword. This output defaults to the console. However if someplace in your code you set the variable 'TraceFileName' to some value say 'trace.log' for example it will then output all of the trace statements to that file.

Here is an example of an Assert line as it is found in the customform.inc file.

   Assert(False, Format('Trace:[TCustomForm.LMPaint] %s, [ClassName]));

You can see that in this example it uses the Format function to create a dynamic output. As long as the first 6 characters of the string being passed to the Assert procedure equals 'Trace:' it will work correctly.

The beauty of this is that you can turn on tracing for the whole of the LCL or only for the unit you are working on. If you define the word 'Trace' in your 'make' call then all of the LCL units will use and report their Assert calls. If however you are working on a specific unit and only need info from it you only need place the '$define Trace' statement at the top of the file to make sure Assertions are turned on for that unit and that unit only. If the compiler directive 'Trace' is never set then the ASSERTIONS are never turned on which means that the application will not output to the console. It also means that the Trace code is not even INCLUDED in the BINARY. The Trace statements in the form of Assert calls can stay in the code forever because they are only included in the compiled binary if and only if $ASSERTIONS ON is set. As it stands now we need to either remove or attempt to comment out the writeln.

The advantage to this is that in the future if someone reports a problem it is a simple matter of having them turn on ASSERTIONS by recompiling with the $define Trace statement and giving us a dump of what is going on.

=========================================================

I will take the above piece of information and add it to the web site where appropriate.

+ From: Michael A. Hess
+
+ But you have total control over how much of the code actually
+ has Trace turned on. You can just turn on one unit if that is
+ all you are testing.

About the half of my debugging with Lazarus was across several units.

+ You don't have to turn on Trace for all the units or the whole
+ application. In fact you don't even have to turn it on for the whole
+ unit. There is no reason why you can't place your own +
+ {$ASSERTIONS ON}
+ .
+ .
+ .
+ .
+ {$ASSERTIONS OFF}
+
+ at specific points in a unit until you have worked out problems.

Then we are (allmost) back at the beginning. You'll have to remove them after debugging ;-)

Marc

?????

Which is why I wrote the utrace feature to be used with Assertions. However it appears that nobody uses this. It allows you to turn on and off any trace statements (currently writelns) by setting a compiler directive. If we could start using that again it would allow us to leave the trace information in for the developers and turn it off for people wanting to play with Lazarus.

The current developers are aware of this feature aren't they?

Aren't you?

i beleive i can translate that into english:

Marc Weustink wrote

At 17:52 02-05-2000 -0700, Bogdan M.Maryniuck wrote: >Hi all! >Tell-help me HOW TO debug a subj?

would you please be kind enough to give me some pointer on how to debug a program in pascal ?

>I have write a program, for example, buddy how I can to debug all of issues?

If i have written a program, for example a program called "buddy", how can i debug all the problem in that program ?
[note from translator: Note that this is only a example, and that is only a second version on the first question :o) ]

>For exmpl.: slow working, >bugworking, some else badworking...?

i want to figure out how to debug slow program (which shouldn't be that slow), bug workaround [nft:still need to identify the bug first] or something else not working... ?

?????

yes, i know.. but at least he tries :o)
(no offence..)

i know english is a tough language,... i am not an english speaker either, but in less that 2 years, i actually learned the language to a certain level ... and i'm sure that shows :op

no, seriously...

you can use GDB to debug your program, but it won't be as easy as Delphi (at least for now...).

Marc Weustink wrote

Then we are (allmost) back at the beginning. You'll have to remove them after debugging ;-)

True you would have to remove any extra {$ASSERTIONS ON} statements but you have to do that with the writelns. But in the Trace case the Asserts are still there when you need them. The writelns need to be recoded again.

The point of using the Trace method was so that at the end of the day when a snapshot of the source is made someone could download that source and build the code without setting the compiler directive 'Trace' in the make call and see what is working without all of the console output.

Hi all!
Tell-help me HOW TO debug a subj?
I have write a program, for example, buddy how I can to debug all of issues? For exmpl.: slow working,
bugworking, some else badworking...?

dvortex wrote

i beleive i can translate that into english:

[translation]

no, seriously... you can use GDB to debug your program, but it won't be as easy as Delphi (at least for now...).

Or you can use DDD as a graphical frontend.

As soon as I've finished my ApiWizz, I'll look to see if we can add gdb as debugger for Lazarus (unless sombody else started this).

Marc

Remove 2 lines or paste "Assert(False, " over an "WriteLn("

I could do just that. It sounds easier than solving the repainting problem on win32.

Tell me if it is apreciated or is there something else more urgent.

Have a look at the text mode IDE (cvs checkout ide), it contains a complete debugger implementation using the gdblib. If you've questions, ask Pierre () he implemented it. It shouldn't be that hard to port it to graphics mode because most is OOP with seperated visual/non visual objects (of course, this needs conversion to the classes object modell)

I Wrote: Then we are (allmost) back at the beginning. You'll have to remove them after debugging ;-)

+ From: Michael A. Hess
+
+ True you would have to remove any extra {$ASSERTIONS ON}
+ statements but you have to do that with the writelns.
+ But in the Trace case the Asserts are still there when
+ you need them. The writelns need to be recoded again.

OK :) we now get at a tricky point,
Remove 2 lines or paste "Assert(False, " over an "WriteLn("

:-) Don't get me wrong, I see the nice features of using trace.

Marc

We all pretty much stick with the writeln debugger which ships standard with fpc. ;)

Cliff

But you have total control over how much of the code actually has Trace turned on. You can just turn on one unit if that is all you are testing. You don't have to turn on Trace for all the units or the whole application. In fact you don't even have to turn it on for the whole unit. There is no reason why you can't place your own

  {$ASSERTIONS ON}
      .
      .
      .
      .
  {$ASSERTIONS OFF}

at specific points in a unit until you have worked out problems.

Having levels would not be a problem. I'll see about adding that.

From: Baeseman, Cliff

We all pretty much stick with the writeln debugger which ships standard

with

fpc. ;)

And compiling with debug-info means leaving a lot of writeln's in the code. It slows down execution the same way as the more advanced debuggers like gdb. ;-)

Vincent.

somewhere in the XML units.

Can someone take a look at this and see if you can find out what is happening?

I'll try to fix this, but it isn't easy as in most cases the XML units do exactly what they are supposed to do ;)

- Sebastian

Ok I worked out what is happening here.

The first pass through you create an element node and therefore the AppendChild works fine as TDOMNode_WithChildren.AppendChild method gets called. The second time you call it the element exists, but you force the element to be a node object not an element object. When the append child is called when replacing the old child, it works remove node then append node, then TDOMNode.AppendChild
is called which is a virtual method.

The solution is define subnode as element not node.

I am not.. please send me a "example".

i remember some time ago (when i was lurking around) about some discussion of {$IFDEF DEBUG} thingies.. but missed the end of it...

please :o)

Thanks.
dv

+ From: Michael A. Hess

[Trace manual]

+ I will take the above piece of information and add it to the web site
+ where appropriate.

Hi, In it's current form trace gives to much output. If I want to debug a certain piece of code I'm interested in I use WriteLNs. Once in a while when pieces are finished I move them to trace or remove them. I have to admit that some (most ?) of them are still hanging around. In cases I want to have the complete picture I use trace. It would be a nice feature to have a kind of trace levels/types.

Marc

Is anyone else having problems updating from CVS? I have been trying

freshen

my files from CVS all evening and it just hangs and doesn't do the update. I'm trying to figure out if it is just my ISP or if there is a problem

with

CVS. I can do an nslookup on cvs.freepascal.org and also on lazarus.freepascal.org without any problem. So DNS is working :-)

Same problem here. CVS connects and sets info to the server, but I don' receive patches.

Vincent

Vincent Snijders wrote

> Remove 2 lines or paste "Assert(False, " over an "WriteLn(" I could do just that. It sounds easier than solving the repainting problem on win32.

Eehhh... it is not as easy as it sounds some of them should be removed, some of them should be moved to asserts.

Tell me if it is apreciated or is there something else more urgent.

Maybe.... I dont know if others have more urgent things (haven't done direct lazarus code directly).
Just an idea, write an app/form (or apps) to test all our components. At least I don't know the status of all components. With the latest changes not all controls behave as they should (missing events and stuff). Starting with this you will find thing to fix.

Marc

Is anyone else having problems updating from CVS? I have been trying freshen my files from CVS all evening and it just hangs and doesn't do the update. I'm trying to figure out if it is just my ISP or if there is a problem with CVS. I can do an nslookup on cvs.freepascal.org and also on lazarus.freepascal.org without any problem. So DNS is working :-)

Curtis

Peter Dyson wrote

Ok I worked out what is happening here.

Not really ;)

[...]

The solution is define subnode as element not node.

No, there have been some bugs in the DOM unit, xmlcfg always worked (although I found some things which I was able to simplify): Bug #1: Replaced children didn't get reparented correctly Bug #2: When RemoveChild was called for the last child of a node, the parent's node FLastChild variable was set to NIL instead of the previous child.

I have just applied some patches to CVS; I couldn't find any further bugs now.

- Sebastian

This could be extended to contain some advanced test tool like the "gremlins" from the Palm Emulator: these gremlins do some pseudo random input to stress your application, it shouldn't be that hard by sending wm_keydown/wm_mouse*** messages.

Pseudo random because it must be reproducable if it crashes: this can be done easily using a specific randseed value instead of calling randomize.

I was told that borland has such a tool (for internal use); it runs about 40.000 tests or so. (Don't remember exactly, memory becomes fuzzy here :) )

You'll have to do some work in order to get to this number :-)

Michael.

That is a good idea. This is something I have been wanting to do for some time but never find the time. Make a simple form with all of the various components available. This serves 2 purposes. It allows us to test the functionality of controls and when changes are made it is easy to figure out if other controls are broken. Secondly it allows us to have a nice screenshot to place on the web site showing exactly what can be built with the LCL.

Be sure to include all of the standard dialogs and tabs, etc. etc. etc.