1. Fact I am unable to run the code Delphi clone constructs are not working all that well.

3. Fact The compiler is having a time with the complexity of our code.

4. Fact It is difficult for us to work on seperate portions of the code in the currrent model.

Now call me stupid or whatever but here is what I am opening for discussion. I suggest we step back for a moment and take a look at a simpler
way to get to the initial goal.

1. We create a single object which inherits TComponent called TControl.

2. We create for instance a mainform.pp which inherits TControl.

3 TControl will contain only two things fComponent: pGtkWidget and a TList of children.

4. Each widget wrapper TMainForm for instance will be responsible for implementing its own event handlers. It will also implement methods to allow control placement of objects how they apply. TMain for for instance will have methods to add a object of TControl. Now this could be a TTable that has multiple child widgets. Now on a resize event of the form, first it will cycle all children and force the resize signal. The children will in turn fire their list of children etc... Thus propagating the signal to the highest child level.

5. the code to manipulate the children is also up to the individual component.

6. This would allow each developer to control his component development completely independent of the other. We only have to get a few components working good to get the first ide going.

7. We all do a very good job at communicating so coordinating things at that level should be easy. We are also working on stuff now that uses the whole component tree and it is making it difficult to deal changes.

I would also suggest keeping the individual units seperated until we have them all built and then maybe merge them into one inc. later..

This would also allow me to take something like TForm and develop it to its fullest right away.
Plus I think debugging would go a little better also. We need to put in a but load of writeln in each of our components with maybe a ifdef debug around them so we can shut them off when we do not need the debugging messages.

Give me your thoughts on this one. It might cost us a few days but I think it would be worth it.

I really do not care how Borland does anything. I just want it to look like delphi code it does not have to work exactly the same to make me happy. ;)
I do not even care if the components have the same name as long as they have easy to use wrappers I am a happy man.

Am I taking nonsense?

Cliff

Sergio,

If it is components you like to do than so be it. myself and shane wish to build a first pass editor.
We will then work the components with you. I am going to add your code to the CVS this evening because I think it is
a very nice clean piece of work. You can keep working the component stuff and myself and shane will get our editor working using a straight GTK. We only wish to get this done to allow some of our windows delphi fans a friendlier environment in which to use FPC. This will help ramp up development of the IDE and component libraries.

Thanx for the code I will be using it tonight I am sure....

Cliff

Cliff Baeseman wrote

1. Fact - I am unable to run the code just did a totally clean new checkout of lazarus from CVS and I had no

problem compiling and running it. It still cores when I attempt to load a file but I can run the code.

2. Fact - Delphi clone constructs are not working all that well.

Why do you say this?

3. Fact - The compiler is having a time with the complexity of our code.

Agreed, but that is not a fault of ours. After all we are still trying to do what we are with a product, FPC, that is still in development phase. It is growing along with the lazarus code.

4. Fact - It is difficult for us to work on seperate portions of the code in the currrent model.

Again I ask why do you say this? It appeared to me that things seem to be moving along nicely.

Now call me stupid or whatever but here is what I am opening for discussion. I suggest we step back for a moment and take a look at a simpler way to get to the initial goal.

Well that all depends on the question, "What is your goal?"

I assumed at this point that the goal and only goal was to build an IDE for FPC in Linux. By using gtk+ as the GUI API it means it can also be used in Windows. Nice addition but not part of the real goal.

Point in fact the IDE doesn't have to use ANY of the TControl or TComponent or any of the class structures as they now stand. I believe you wanted to use them to at least get somewhat of a start on building up the component base. Nice if you/we could but is it the goal?

In my opinion go hog wild making your classes do WHATEVER you want them to do. Use gtk+. embed it as tight as you want. You are developing lazarus. Lazarus by definition is an IDE for FPC. It isn't the FCL for FPC. If we can in the future use some of the lazarus code as part of the FCL well then that is great.

The fpide for Windows is written in Delphi for heavens sake. The Linux IDE doesn't even NEED to be written in FPC.

At this point the lazarus directory could be deleted from the FPC CVS and it wouldn't effect FPC in any way, shape, or form. It is a separate item until it is cleaned up and generic enough to become part of the FCL of FPC. That might not ever happen. Maybe the FCL will take a different path but we would have an IDE, Lazarus, to use to work on it.

So my answer to the "Open for Opinion" is do whatever you need to do to make a working IDE. Don't worry if some of the code or classes you create aren't extensible anywhere else. At this point they don't need to be.

Cliff Baeseman wrote

1. Fact I am unable to run the code the How-To and you will do it fine :) 2. Fact Delphi clone constructs are not working all that well.

Hmmmm, I don't know...

3. Fact The compiler is having a time with the complexity of our code.

Yep, the current code is a big mess.

4. Fact It is difficult for us to work on seperate portions of the code in the currrent model.

Yep.

Now call me stupid or whatever but here is what I am opening for discussion. I suggest we step back for a moment and take a look at a simpler way to get to the initial goal.

I agree, in Open Source, simplicity and modularity are the keys.

well, the TControl could have the signaling also, maybe we want to use the stuff Michael H. is working on.

yep.

Yep, that's my point. I don't care how Borland does thing, all I care is to get compatible code as much as possible.

I do not even care if the components have the same name as long as they have easy to use wrappers I am a happy man.

well, I think that having the same names is trivial :)

Am I taking nonsense?

no way.

Sergio
(trying to catch up with emails)

Ok Ok....

I was just a little pissed off last night.

I will try a snapshot of the compiler intead and go back to my old build procedure.

I am using yesterdays compiler and getting End of ExceptionAddressStack in the middle of creating the first form and the app then crashes.

Thing is it compiles normal?

Cliff

Hmmm, I don't think that the mess inside the lazarus directory is fault of FPC.

With the current code is a nightmare to create more components...

This is the wrong way to get multiplataform support, the _very_ wrong way, multiplataform issues should be worked on the FCL, (and no, I'm not talking about ifdefs) _not_ in the GUI toolkit.

Point in fact the IDE doesn't have to use ANY of the TControl or TComponent or any of the class structures as they now stand. I believe you wanted to use them to at least get somewhat of a start on building up the component base. Nice if you/we could but is it the goal?

I agree here, the Editor should not use any gtk specific.

ok, I will be really honest, I'm not interested very much in lazarus the editor, hey, I have a bunch of good editors in my box (currently using gEdit), I'm a little more interested in the component library, I don't think that a good IDE could be contructed without a working component library first.
I don't want to lie you, but I think I have more than 10 editors in my box, wich are installed /out of the box/ (not to mention how many I can download)
So a editor is not my problem.
Sure, lazarus could be good for testing the component library, but I think it should be modelled _after_ the CL, on _top_ of the CL, not before.
So, I think that there is a difference betwen MH. and me, MH want an Editor rigth now, no matter if the CL is crapy piece of code (someday we'll fix), and I want a CL done rigth _and_ easy to do (later we'll do the editor).

Hey, tonigth I will try the IDE that is in the CVS :)

So, _someone_ has to take the decisions, someone has to do the job of the benevolent dictator, then I want decisions, I can't work in a nebulus.

How, we'll proceed ??

yep just keep doing what you are doing Shane I will work on this editor. Sergio can stick with you and Mike H I do not know his intentions at the moment. I am keeping close contact with a few guys that are comming up to speed now.

Getting the compiler installed etc.

Cliff

Shane Miller wrote

just suggestions. BTW, RAD GUI IDE is on it's way.. (I just wanted to use 4 in a row) :-)

How about

FWIW IMHO FPC FCL RAD GUI IDE should make a big impact. :-)

I think the RAD diferential is the great deal.(See Delphi and Visual Basic). RAD languages changes the world of programming, and makes the Windows very common ( before Visual Basic, just good and experience programmer in C and C++ gets a good development in Windows. With the appear of the RAD languages , the development became more fast and easy, because the programmers can concentrate more in their problem and less in the "HOW-TO-CREATE-THAT-VISUAL-CONTROL" stuff.With this the number of small and "direct" applications for Linux will grown. But i think a good IDE dont get if dont exist a good Object Class, with a good and pratical language or compiler. (Because that was the ingredients for Delphi make success)

(please sorry my poor english :))

Actually Paul. If your familiar with Linux AND Delphi then your actually ahead of some others (me). If your looking for a place to start, simply grab the code and start creating some classes. Just let the list know what classes your doing. Go to http://www.lakefield.net/~smiller/lazarus and look at the list of things to do. Select a class and run with it....

Otherwise, there's plenty of messy code in our classes that needs to be cleaned up. Not fun but it's somewhere to start to get used to our code.

just suggestions. BTW, RAD GUI IDE is on it's way.. (I just wanted to use 4 in a row) :-)
Shane

My opinion? I'm more interested in the final result (ie a nice RAD IDE tool).

Cheers
Michael A

PS Paul is really far to bust to contribute much effort, aren't you Paul ? 8^)

Hello,

Shanes and my goal is to get a working IDE that you can edit and compile FPC code from the same app. A super completely functional IDE? Maybe not but something to work in as opposed to a text editor and the command line.

If there're so many editors, why are they creating a new one?

Because an IDE "a la" Delphi is something more than editing and calling the compiler. The key point are designers: object inspector, component palette and form designer will be next plugged in. And they need to be synchronized with the code editor: clicking on the event pane of the Object Inspector creates an skeleton of the event handler in the code editor. Adding a component to a form inserts its declaration and makes it available in Object Inspector... and so on.

These features *need* a well designed CL, not only a working editor, because they rely on components interface. Not talking about streaming...

greetings

Nico

I use gEdit myself but it doesn't do syntax highlighting or allow you to compile from inside.

ok, it doesn't do syntax highlighting (a matter of a plugin), about the compile from inside, with Lazarus editor will be two clicks, with my current environment is one click -> upper key -> Enter key

Of course, this doesn't mean that the editor shouldn't be done.

Sergio

How about some feedback from some of the other list members. Are you more interested in the Object Class and the FCL or a working IDE that you can use?

Personally I'm more interested in the object class. I'm happy to use any editor for my code, but it will be nice when I can easily port from Delphi over to Linux (and vice-versa).

OTOH, while the text editor is of no real interest to me, I'm looking forward to the RAD GUI IDE. (can 3 TLAs in a row be used to write a meningful sentence?)

I'd probably try to be active in the list if it weren't for the fact that I feel like I've arrived in the middle, and I don't know where to begin.

Did I answer your question?

Regards,
Paul

Paul Gearon

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam.
(Translation from latin: "I have a catapult. Give me all the money, or I will fling an enormous rock at your head.")

"Shane Miller" el d�a Wed, 19 May 1999 20:44:50 -0700, escribi�:

I guess my idea was to create an IDE that you could edit AND compile in. That way it would be easier to hammer out the component code. If my OPEN and SAVE actually are working (I think they are) that means that we are

so the editor will use the CL or not ?

Sergio

The current editor (Lazarus) will use the CL, the small editor that Cliff and I speak of will be a flat gtk/pascal editor that will bypass the objects until the compiler and our code are a bit more bug free and we feel something could be built on it.

Of course I'm still going to continue working on the Lazarus editor and the classes under it.

Shane

>> "Sergio A. Kessler" 05/20 2:26 PM >>>

"Shane Miller" el d�a Wed, 19 May 1999 20:44:50 -0700, escribi�:

I guess my idea was to create an IDE that you could edit AND compile in. That way it would be easier to hammer out the component code. If my OPEN and SAVE actually are working (I think they are) that means that we are

so the editor will use the CL or not ?

Sergio

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Sergio A. Kessler wrote

ok, I will be really honest, I'm not interested very much in lazarus the editor, hey, I have a bunch of good editors in my box (currently using gEdit), I'm a little more interested in the component library,

Ok this is exactly why I asked the question, "What is the goal". Cliffs, Shanes and my goal is to get a working IDE that you can edit and compile FPC code from the same app. A super completely functional IDE? Maybe not but something to work in as opposed to a text editor and the command line.

I use gEdit myself but it doesn't do syntax highlighting or allow you to compile from inside.

I don't think that a good IDE could be contructed without a working component library first.

Maybe not, but no one said it had to use a component library.

So, I think that there is a difference betwen MH. and me, MH want an Editor rigth now, no matter if the CL is crapy piece of code (someday we'll fix), and I want a CL done rigth _and_ easy to do (later we'll do the editor).

Again this boils down to the goals. For example right now we have over 50 people on this mailing list. How many do we hear from? About 8 of us with 3 of those being major FPC players. What do you think the rest are doing? I can only guess that they are lurking waiting for a usable IDE. Many of those coders don't ever want to use the FCL because they are writing code directly with gtk+ or QT or they are writing with xForms or whatever. What they want is an IDE environment that they can use to code with FPC.

How about some feedback from some of the other list members. Are you more interested in the Object Class and the FCL or a working IDE that you can use?

I will still participate in the small editor like we discussed. I figured I would look into the memo and notebook this weekend if you don't get it working by then.

Shane

No problem I will keep working it.

Cliff

Cliff wrote

... Mike H I do not know his intentions at the moment.

If you are going to hammer at the editor it might be faster to let you do it. If there is something you can break out that I might be able to work on let me know. Otherwise I am going to keep working on the message handling we will eventually want to use in the CL.

I will have it in there soon as I get home.

;)

Cliff

Nicolas Aragon wrote

<snip>

These features *need* a well designed CL, not only a working editor, because they rely on components interface. Not talking about streaming...

All true, but you need to walk before you can run. Also FPC can be used to write code that doesn't use OOP. An IDE would be nice for that as well. There is text based IDEs and a GUI IDE for Windows but no GUI IDE for doing any kind of work in Linux. Once we have a simple IDE like the Windows version and like the text based version then we can more easily work on an actual RAD IDE.

Well at least that is my 2 cents. :-)

I guess my idea was to create an IDE that you could edit AND compile in. That way it would be easier to hammer out the component code. If my OPEN and SAVE actually are working (I think they are) that means that we are that much closer to our goal. Once we get the compiler running from Lazarus we will be able to hammer out the component code. The more we improve the component code, the better Lazarus will be (because it is built on those classes), and the better we make LAzarus the better the classes get.

I agree that some people don't want an IDE or are using something else. I intend to work on creating the classes for components so I can eventually add them into Lazarus but of course we need those classes/components built first.

Now that lazarus is in the early stages of being usable we can start concentrating on the classes/components and when we hve the classes, we can add them to lazarus as we see fit.

I would love to hear what some of the others are looking for. Classes/components or an IDE to develop on Linux through FPC.

Just rambling, I'm estatic I finally got it to save and open files... :-)

Shane

---

Shane is still working the component lib as far as I know. I will hammer on the editor tonight some more. If you wish to work on the editor that is ok, if not you can stick with the component lib. I will personally code most of the editor myself if the others do not wish to write code in it.

That way we get the editor and the lib is still being built.

cliff

Agreed. (totalmente de acuerdo :)

Sergio

I would love to hear what some of the others are looking for. Classes/components or an IDE to develop on Linux through FPC

What I am looking for is an easy to use cross-platform development tool, preferably as compatible with Delphi as possible. How that is achieved is secondary. If it can be done by writing the editor without the FCL, fine. If not, that's fine to. I hope to get my first Linux install of Lazarus set up this weekend, and then start on a Win32 install. If anyone else is interested in these goals, then I'll be happy to write the wrappers to ensure Linux<->Win32 compatability, and make things as Delphi-like as is practical (I don't think anyone expects a complete port of the Win32 API !!!)

Whether the IDE or the FCL is finished first makes little difference to me. I am a little turned off by some of the hardcore people in the list not being able to even compile the code much of the time ;^)

Jeff.

No, No It is not a step backwards at all but a major step forward. First of all yes there are many editors out there but the key here is that this one is gtk, fcl, fpc based and yes we hold the source. It provides a great test bed for our object based code.

I am finding some interesting things out about gtk by doing this.

After all I am the only one working on this, everyone else is still working the original code base.

Cliff

I am trying it now...please hold... :-)

Shane

>> Payne Thomas E CNIN 05/21 11:19 AM >>>

<clip>

<clip>
The latest CVS update on my machine cured the GTK compile issues.

Now I am having a problem compiling stdcontrols.pp. Has anyone seen this?

Tom
----------------------------------------
lazarus]# ppc386 lazarus
Free Pascal Compiler version 0.99.11 [1999/05/21] for i386 Copyright (c) 1993-98 by Florian Klaempfl
Target OS: Linux for i386
Compiling lazarus.pp
Compiling guiapi.pp
Compiling forms.pp
Compiling controls.pp
Compiling vclglobals.pp
Assembling vclglobals
Compiling graphics.pp
Assembling graphics
controls.pp(157,1) Warning: Function result does not seem to be set controls.pp(152,28) Hint: Parameter not used WIDGET controls.pp(166,1) Warning: Function result does not seem to be set controls.pp(161,22) Hint: Parameter not used WIDGET controls.pp(173,1) Warning: Function result does not seem to be set controls.pp(169,22) Hint: Parameter not used WIDGET controls.pp(180,1) Warning: Function result does not seem to be set controls.pp(176,24) Hint: Parameter not used WIDGET controls.pp(187,1) Warning: Function result does not seem to be set controls.pp(183,22) Hint: Parameter not used WIDGET controls.pp(194,1) Warning: Function result does not seem to be set controls.pp(190,22) Hint: Parameter not used WIDGET controls.pp(201,1) Warning: Function result does not seem to be set controls.pp(197,25) Hint: Parameter not used WIDGET controls.pp(402,1) Warning: Function result does not seem to be set controls.pp(399,50) Hint: Parameter not used PARENTWINDOW controls.pp(657,1) Note: Local variable not used TABLE controls.pp(655,36) Hint: Parameter not used AOWNER Assembling controls
Compiling guiapi.pp
Assembling guiapi
Compiling main.pp
Compiling compiler.pp
compiler.pp(42,4) Warning: An inherited method is hidden by TCOMPILER.DESTROY
Assembling compiler
Compiling stdcontrols.pp
Panic : Internal compiler error, exiting.
stdcontrols.pp(159,85) Fatal: Internal error 9999
lazarus]#

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

you wrote

Why isn't gdbint included when I do a cvs -z 3 co fpc? Everytime I do a make all I have to go back and checkout gdbint.

gdbint is in the gdbpas/ repository. I'll move it this weekend to the fpc repository

<<snip>>

It's probably OK, but I would be a little concerned about this. QT slots are not guaranteed to receive their signals in any particular order, whereas gtk signals ARE guaranteed to occur in the order in which they were connected. Most of the time this won't mean a thing, but every so often it might have real consequences.

Or are my fears groundless?

Regards,
Paul

Paul Gearon

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam.
(Translation from latin: "I have a catapult. Give me all the money, or I will fling an enormous rock at your head.")

do you delete the .o and .ppu files from the lazarus directory before compiling.?

Just a guess!

Shane might have seen this.

Cliff

There are many GUI editors that can be used perfectly with FPC. XCoral, Nedit, FTE. All of them support commands to compile and build, syntax highlighting etc.

I tend to agree with Nicolas. I think that creating a 'flat' ide is a step backwards, and should be avoided. I didn't want to influence the discussion, hence I stayed silent till now. But something came up recently...

The main argument seems that the compiler isn't ready for OOP yet. Poppycock. The classes have been functioning fine for ages. The compiler itself is completely written in OOP !

The two main problems are, at the moment:
- Ansistrings. Florian just did a complete overhaul of the ansistring code, and it seems to be running fine (from the tests we do, of course)
- The dispatch mechanism, and related the procedure of object. In principle, this has been fixed too, by Peter Vreman, and Florian.

It is my firm belief that the first of these two problems has been the principal source of problems that have been experienced by the lazarus people. I have seen some pretty dubious code in the ansistring department when I checked out the lazarus code so it could compile on Win32. Heck, it even didn't compile because of the faulty string handling.

Hence, the principal argument for making a 'flat' IDE has been rebuffed :-) Can we get back to OOP please ? Sergio has been doing a great job with 'Opendialog', it would be a shame to loose that :)

Furthermore, and this is more serious:

There are 2 germans working on what they call KCL : A FCL descendent like Lazarus the builds on top of QT and KDE ! (they solved somehow the C++ name mangling problems) I have been in contact with them for some time, and they seem enthousiast in co-operating with lazarus in the sense that we should try and build a common GUI-independent class tree as much as possible.

They will also write a IDE in this (for the same reasons you do), but it will be completely OOP on top of this.

They also have a signal-and-slot mechanism (as found in Qt) that could be adopted to GTK, from what I saw. This would allow multiple slots for 1 signal etc. (i.e. multiple event handlers get triggered for the same event).

Since they'll be using OOP from the very start (no other way with Qt :) ) I think it should be so for Lazarus too.

I hope I have convinced you that OOP is the way to go from the start, or at least that I have opened the discussed again...

But let's not stay on the discussion level too long. There is code to be written. Preferably OOP code :-)

Michael V.

<clip>

<clip>
The latest CVS update on my machine cured the GTK compile issues.

Now I am having a problem compiling stdcontrols.pp. Has anyone seen this?

Tom
----------------------------------------
lazarus]# ppc386 lazarus
Free Pascal Compiler version 0.99.11 [1999/05/21] for i386 Copyright (c) 1993-98 by Florian Klaempfl
Target OS: Linux for i386
Compiling lazarus.pp
Compiling guiapi.pp
Compiling forms.pp
Compiling controls.pp
Compiling vclglobals.pp
Assembling vclglobals
Compiling graphics.pp
Assembling graphics
controls.pp(157,1) Warning: Function result does not seem to be set controls.pp(152,28) Hint: Parameter not used WIDGET controls.pp(166,1) Warning: Function result does not seem to be set controls.pp(161,22) Hint: Parameter not used WIDGET controls.pp(173,1) Warning: Function result does not seem to be set controls.pp(169,22) Hint: Parameter not used WIDGET controls.pp(180,1) Warning: Function result does not seem to be set controls.pp(176,24) Hint: Parameter not used WIDGET controls.pp(187,1) Warning: Function result does not seem to be set controls.pp(183,22) Hint: Parameter not used WIDGET controls.pp(194,1) Warning: Function result does not seem to be set controls.pp(190,22) Hint: Parameter not used WIDGET controls.pp(201,1) Warning: Function result does not seem to be set controls.pp(197,25) Hint: Parameter not used WIDGET controls.pp(402,1) Warning: Function result does not seem to be set controls.pp(399,50) Hint: Parameter not used PARENTWINDOW controls.pp(657,1) Note: Local variable not used TABLE controls.pp(655,36) Hint: Parameter not used AOWNER Assembling controls
Compiling guiapi.pp
Assembling guiapi
Compiling main.pp
Compiling compiler.pp
compiler.pp(42,4) Warning: An inherited method is hidden by TCOMPILER.DESTROY
Assembling compiler
Compiling stdcontrols.pp
Panic : Internal compiler error, exiting.
stdcontrols.pp(159,85) Fatal: Internal error 9999
lazarus]#

Why isn't gdbint included when I do a cvs -z 3 co fpc? Everytime I do a make all I have to go back and checkout gdbint.

Shane

>> "Shane Miller" 05/21 11:38 AM >>>

I am trying it now...please hold... :-)

Shane

>> Payne Thomas E CNIN 05/21 11:19 AM >>>

<clip>

<clip>
The latest CVS update on my machine cured the GTK compile issues.

Now I am having a problem compiling stdcontrols.pp. Has anyone seen this?

Tom
----------------------------------------
lazarus]# ppc386 lazarus
Free Pascal Compiler version 0.99.11 [1999/05/21] for i386 Copyright (c) 1993-98 by Florian Klaempfl
Target OS: Linux for i386
Compiling lazarus.pp
Compiling guiapi.pp
Compiling forms.pp
Compiling controls.pp
Compiling vclglobals.pp
Assembling vclglobals
Compiling graphics.pp
Assembling graphics
controls.pp(157,1) Warning: Function result does not seem to be set controls.pp(152,28) Hint: Parameter not used WIDGET controls.pp(166,1) Warning: Function result does not seem to be set controls.pp(161,22) Hint: Parameter not used WIDGET controls.pp(173,1) Warning: Function result does not seem to be set controls.pp(169,22) Hint: Parameter not used WIDGET controls.pp(180,1) Warning: Function result does not seem to be set controls.pp(176,24) Hint: Parameter not used WIDGET controls.pp(187,1) Warning: Function result does not seem to be set controls.pp(183,22) Hint: Parameter not used WIDGET controls.pp(194,1) Warning: Function result does not seem to be set controls.pp(190,22) Hint: Parameter not used WIDGET controls.pp(201,1) Warning: Function result does not seem to be set controls.pp(197,25) Hint: Parameter not used WIDGET controls.pp(402,1) Warning: Function result does not seem to be set controls.pp(399,50) Hint: Parameter not used PARENTWINDOW controls.pp(657,1) Note: Local variable not used TABLE controls.pp(655,36) Hint: Parameter not used AOWNER Assembling controls
Compiling guiapi.pp
Assembling guiapi
Compiling main.pp
Compiling compiler.pp
compiler.pp(42,4) Warning: An inherited method is hidden by TCOMPILER.DESTROY
Assembling compiler
Compiling stdcontrols.pp
Panic : Internal compiler error, exiting.
stdcontrols.pp(159,85) Fatal: Internal error 9999
lazarus]#

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

I got the same thing. Can;t compile lazarus now.

Keeps crashing when it gets to stdcontrols.pp
Panic: Internal compiler error, exiting
stdcontrols.pp (159,85) Fatal: Internal error 9999

Solution: Delete the dafault false on that line, ALSO delete the default cbunchecked on the next line.

Then it compiles.
Why is this error occuring when it compiled fine with the older version of the compiler????????

Shane

>> "Shane Miller" 05/21 11:38 AM >>>

I am trying it now...please hold... :-)

Shane

>> Payne Thomas E CNIN 05/21 11:19 AM >>>

<clip>

<clip>
The latest CVS update on my machine cured the GTK compile issues.

Now I am having a problem compiling stdcontrols.pp. Has anyone seen this?

Tom
----------------------------------------
lazarus]# ppc386 lazarus
Free Pascal Compiler version 0.99.11 [1999/05/21] for i386 Copyright (c) 1993-98 by Florian Klaempfl
Target OS: Linux for i386
Compiling lazarus.pp
Compiling guiapi.pp
Compiling forms.pp
Compiling controls.pp
Compiling vclglobals.pp
Assembling vclglobals
Compiling graphics.pp
Assembling graphics
controls.pp(157,1) Warning: Function result does not seem to be set controls.pp(152,28) Hint: Parameter not used WIDGET controls.pp(166,1) Warning: Function result does not seem to be set controls.pp(161,22) Hint: Parameter not used WIDGET controls.pp(173,1) Warning: Function result does not seem to be set controls.pp(169,22) Hint: Parameter not used WIDGET controls.pp(180,1) Warning: Function result does not seem to be set controls.pp(176,24) Hint: Parameter not used WIDGET controls.pp(187,1) Warning: Function result does not seem to be set controls.pp(183,22) Hint: Parameter not used WIDGET controls.pp(194,1) Warning: Function result does not seem to be set controls.pp(190,22) Hint: Parameter not used WIDGET controls.pp(201,1) Warning: Function result does not seem to be set controls.pp(197,25) Hint: Parameter not used WIDGET controls.pp(402,1) Warning: Function result does not seem to be set controls.pp(399,50) Hint: Parameter not used PARENTWINDOW controls.pp(657,1) Note: Local variable not used TABLE controls.pp(655,36) Hint: Parameter not used AOWNER Assembling controls
Compiling guiapi.pp
Assembling guiapi
Compiling main.pp
Compiling compiler.pp
compiler.pp(42,4) Warning: An inherited method is hidden by TCOMPILER.DESTROY
Assembling compiler
Compiling stdcontrols.pp
Panic : Internal compiler error, exiting.
stdcontrols.pp(159,85) Fatal: Internal error 9999
lazarus]#

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Michael Van Canneyt wrote

The two main problems are, at the moment:

<snip>

- The dispatch mechanism, and related the procedure of object. In principle, this has been fixed too, by Peter Vreman, and Florian.

Then why doesn't it work?

If we are going to be writing a GUI independent class tree as we have suggest doing all along and as they seem to want to do why would they write and IDE as well. Wouldn't the same IDE build with either GUI if it is class independent?

How far along are they with the class tree? Are we redoing their work?

I hope I have convinced you that OOP is the way to go from the start, or at least that I have opened the discussed again...

I think what is frustrating for me is working with a compiler that is still in development mode. I did a complete fresh checkout of ALL of CVS last night, built an updated compiler and that worked fine. However, when I try to build gtk it dies on a procedure parameter name. Just because another procedure uses the same name. Then stdcontrols.pp in lazarus dies because two properties declare "default false". All of this compiled before but now it dies. As I said this was a completely fresh checkout.

I'm not faulting anything or anybody it just tends to make it frustrating trying to build the FCL to build and IDE when you have to figure out if and error is your coding or the compiler itself.