No. this is definately a problem with overloaded operators. AFAIK all definitions are valid, which means it has to be a compiler issue. Since this does not occur at all in current versions of the 1.1 compiler, and from what I am understanding, only sometimes/with certain versions of 1.0.7, I can only assume this is a problem in the 1.0.6 compiler which has finally been fixed in later/more recent versions of the compiler in CVS. I can only guess at this, but my first thought is that it is

operator := (TFloatPoint) : TPoint;

that is causing this problem, so Karl, why don't you try disabling this operator and see if it still happens. If it does, try disabling the

operator := (TPoint) : TFloatPoint;

it may be that having both these definitions at the same time is causing some sort of compiler loop in one of the routines which uses TFloatPoint's (such as BezierMidPoint). I will see if I can't get an old version of the compiler installed on another computer to test it and compare with other versions and try and duplicate this bug.

Andrew

_________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

confounding.. I cannot duplicate this problem. This poses a dilemna as I was planning on adding even more overloaded operators for Beziers and the like. I suppose we can always add a compiler switch and turn off these particular operators by default until everyone has upgraded or the problem goes away or whatever.

Andrew

Today I compiled lazarus under debian with 1.0.7 from May 23 and compilation aborted in graphicsmath.pp with a seg fault. Updating the compiler fixed the problem. So there was definitely a bugfix. The current fpc rpm on the laz website works for me, but not for Jens, so I'm not sure if a newer fpc will solve this problem.

The interdependent units:
There are a lot of circles in the LCL, inherited from the VCL. I think, circles are design flaws. And I think, they can be broken without loosing too much compatibility. But IMO each of such changes should be discussed first on this list.
Should we begin such a discussion?

Mattias

Yes, let's talk about it.

I for one would be happy to be rid of the crop circles. You said that there is a way that we can get what we need without the circular references ? How would that work ?

Cheers
DC

Does anyone know a better solution or think that this solution will break compatibility too much?

Mattias

That's why we should discuss each point. You are right; every change will break a little compatibility. But I hope we will find solutions to minimize incompatibility.

For example menus.pp <-> controls.pp.
- menus.pp includes controls.pp in the implementation section. In the LCL you can simply comment this out. Do we need this for some not implemented features?
- menus.pp includes forms.pp in the implementation section, which uses controls.pp. TMenu.Destroy needs TCustomForm to unlink. We could add a OnUnparentMenu event to TMenu, which is set by the parent form to handle this in forms.pp.

Mattias

If you just use a straight "cvs update", it ignores any new directories, so if there has been a directory structure change you have to do a "cvs update -d" instead to make sure it creates the new directories. Though every now and again changes are so profound it sort of hiccups and getting a whole new version is the easiest way to go anyway, but this has really only happened to me once.

Andrew

TTFN
Genius(in name only)

Well as to this one.. I just figured it out.. this will not break compatibility. I new we didn't any extra proprty for this one. The ONLY reason menu's uses Forms, is to set its parent menu to nil on destroy. This should be done in TCustomForm.Notification anyway! All we need to do is remove the Form code from menus and remove controls and forms from menu's uses. Then On TCustomForm.Notification do

  If (Operation = opRemove) and (AComponent = Menu) then Menu := nil;

And boom. One less circle, with no compatibility lost! At least it works fine on my system.

(I Would commit this right now myself, but I can't access CVS from the current internet connection)

Andrew

_________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp

Again ???

Marc

The circles are a problem again. And they will stay a problem. They are unnecessary and make it difficult to control the order of the initialization and finalization sections. They make it harder to understand code. All this makes the LCL a bad example for writing code. We are using mode objfpc to disallow Delphi ambiguities, but we don't use any of the nice extensions (e.g. c operators, inline, exit(), ... ) of this mode. All this to give a good example for readable pascal code (and some other more abstract reasons). But OTOH we use circles. Also circles are not very helpful for smartlinking. I don't mean the circle between the interfaces and the LCL, although this can be broken rather easily as well.
I mean circles like: controls.pp needs menus.pp, for the only reason that it needs TPopupMenu.

I don't want to ignore the old discussion, but I hope someday the LCL will become an easy hierachy instead of the furball it is now.

Mattias

I had have problems occasionally after CVS updates. I couldn't compile after you guys added some directories and such in the CVS tree. Not that it froze mind you... so probably a different issue.

So about once a month or so I end up just completely blowing away the Lazarus directory and redownloading all the sources again from CVS.

A stack overflow most of the times has to do with having too many interdependent units. Restarting the compilation with already some ppu's available can 'fix' the problem.
In the development (1.1) compiler this problem should be fixed.

You are right. The current LCL implementation is incompatible to the VCL.
So, we can break a circle and improve compatibility. :) Committed.

Mattias

On 19 Oct 2002 18:19:44 +1000
David Creelman wrote

The only thing that has changed in graphicsmath is that I added 2 more overloaded operators for Point := FloatPoint, and for FloatPoint := Point. This should have no bearing on compiler problems. Are you using the Lazarus 1.0.7 or the nightlies? I no longer have 1.0.6 to test on, so it could be a operator overloading problem there I suppose.

Andrew

_________________________________________________________________ Get a speedy connection with MSN Broadband.� Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp

I just got a response from Carl(he tried to post to the list but it didn't take):

to

_________________________________________________________________ Unlimited Internet access -- and 2 months free!� Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Hi

I have the 1.0.7 from the Lazarus-Page and the compile freezes, too :( Any ideas???
Possible compiler-bug with too many operator overloads ???

Jens

I'm on broadband, so I do a cvs update (now I'll always add -d, but that doesn't solve the problem). I'm running fpc 1.0.6 on Mandrake 8.2. If I compile it in a console (ie. not in an gnome terminal), it fails to compile, but doesn't crash out X. It fails when trying to compile graphicsmath.pp which is pulled in by allunits.pp.

Is it necessary to have 1.0.7 now ? If it is should the makefile stop me from using 1.0.6 ?

Let me know if you want any verbosity flags turned on if you want me to look into it.

I no longer have 1.0.6 to test on, so it could be a

operator overloading problem there I suppose. Andrew

Cheers
David

graphicsmath.pp uses only Classes, SysUtils and Math, and when i try to compile it manually (alone) the same error occurs. I don't think that the error resides in interdependent units

Just tried the rpm: works nice for me.

Mattias

I'm having similar problem when i try to compile the lcl under win32: I get the following message:
Compiling graphicsmath.pp
Error: Stack Overflow
Compilation aborted graphicsmath.pp:152
C:\BIN\CODE\FPC\BIN\WIN32\MAKE.EXE: *** [allunits.ppw] Error 202

I'm using win98 SE with fpc 1.0.6 lazarus 20/10/02

Menu's..back before they were started to be implemented properly, were based on TWinControl. I think this is why the uneeded uses. It is probably just a little left over include on account of that.

TMenu.Destroy needs TCustomForm... why again? Okay.. I see the need. But I think I agree on this one. Though I am not certain about the needed extra property(yet).

Andrew

_________________________________________________________________ Unlimited Internet access for only $21.95/month.� Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Yes, on 9/21 1.0.7 was declared the required compiler on account of certain bug fixes which were needed for proper Form streaming, and other misc. problems in the 1.0.6 compiler. So there is a new 1.0.7 rpm you can get from the lazarus ftp site, or you can always use the 1.0.7 nightly, or the 1_0_0 fixes branch from fpc cvs(its probably easiest to get the rpm or nightlies unless you've done it from cvs before). Up until now lazarus was compiling fine uner 1.0.6, but there were problems in form streaming on acount of a buffer problem, but I guess now it is required to compile as well. If you still have issues after upgrading your compiler, then we can start worrying about verbosity & debugging. If it IS a compiler issue, on account of the other issues it'll be easiest if when this problem arrises we just tell people to get a newer compiler then too try and track it down and make a work around for it.

Andrew

+ From: Mattias Gaertner
+
+ On Mon, 21 Oct 2002 16:41:12 +0200
+ Marc Weustink wrote:
+
+ > At 15:48 21-10-2002 +0200, Mattias Gaertner wrote:
+ >
+ > >The interdependent units:
+ > >There are a lot of circles in the LCL, inherited from the VCL. I
+ > >think, circles are design flaws. And I think, they can be broken
+ > >without loosing too much compatibility. But IMO each of such changes
+ > >should be discussed first on this list.
+ > >Should we begin such a discussion?
+ >
+ > Again ???
+
{SNIP]

+ I mean circles like: controls.pp needs menus.pp, for the only reason
+ that it needs TPopupMenu.
+
+ I don't want to ignore the old discussion, but I hope someday the LCL
+ will become an easy hierachy instead of the furball it is now.

If we want to have a LCL that is more or less compatible with the VCL, I don't see a solution to your given example. Sure, one can avoid this with Interfaces (non't know if abstract calles would help here). But then we are designing a complete new component library.

Marc

Strange,

For me I can't even compile lazarus now. I do cvs update;make clean all and then on graphicsmath.pp, the compiler becomes extremely busy and XWindows response becomes very slow and eventually it crashes X11. This is before even running it. Everything worked okay a few days ago. What has changed ?

Regards
David

have

> > >such a freezer. > > >The freezes appear on a RH7.3 to RH8.0 upgraded computer and with

the

but

> > I never removed it when I was done. Since Hint Window's are still > > popup's..it is possible that they could get stuck recieving all > > Lazarus Mouse calls, though I thought this had been fixed, but if > > something in X or later versions of GTK has changed the behaviour

of

> > popup's this could have some deadly results. Try disabling the

code

> > that set hint windows transient for now. It is in the create

routine..

freezes.

>I looked at the grabbing code in the gtk itself and found out, that

the

least

the hintwindow errors on destroy widget are gone now. I think that

transient

windows are destroyed with the parent, so if hint windows still

existed(had

When will fpc 1.1 be ready ?

At least not very soon, for multiplatform there still needs to be bigger changes. But it is planned to release some developper releases before the real release.

Peter

On second thoughts, if we are aiming for Delphi compatibility, and this breaks aspects of that compatibility perhaps it's not such a good idea....

When will fpc 1.1 be ready ?

Andrew Johnson wrote:
(...)

If i disable one of the two, the unit compiles fine.

I'te. I have added a IfnDef ver1_0 on the TPoint := TFloatPoint. This one isn't really as needed anyway. It would be better though if I could add some sort of

{$Ifdef FPC1_0_8}so that on 1.0.8 or higher it was enabled too.

Andrew

Hi All,

Just did an update and recompile and it all worked !! Thanks for fixing that one.

Seems it was the TPoint issue after all and not the circular references (though it's good to be rid of them too).

On a side note, even when the compile was failing, if it was started from a console window it would lock up but could still be killed with ^c without killing XWindows. So if we ever run into that kind of compile lock up it might be useful to remember that.

It is a bit of a worry that a the compiler, a user program, could lock up the whole machine so tightly. I run seti on my machine here and I noticed that it was running so hot that the idle task (setiathome) didn't even get a look in (via the system usage meter before it truly bit the dust). Do the FPC guys know about this ?

Cheers
DC