Hi,

seems as if I'll have some more time to focus on lazarus the next weeks and thus started to review some of the code already present. Here're some observations:

- Some source files are messed up with writeln's and assert statements and sometimes contain redundant code. gtkobject.inc is a good example for this and it must be very hard for new developers to understand what's going on. I'd recommend to do a major cleanup. If nobody has anything against it I'll start with this saturday.
One question: Few weeks ago there have been some mails about asserst versus writeln. I'd prefer to only use asserts so are there any writeln's that should be protected?

- What kind of strategy shall we use for error-handling? Currently some classes throw exceptions, others use asserts or use default values when something illegal is done (e.g. some index out of range).

- Currently gtk complains a lot about font-stuff and missing pixmaps. Does anybody know the reason? From my point of view it's very important to fix this because people new to lazarus might get a bad feeling about the project in general. BTW: Most examples will crash when they are closed. Whats the reason for that? (I can't trace into it because the debugger also hangs when it happens:-((

- Currently we use lot's of casts and if-statements to determine the componentstyle for different classes. The reason for this is that the fcomponentstyle member is not in a a common baseclass (TComponent could be a good choice but it's in fcl). Should we introduce a new class (derived from TComponent) which contains fcomponentstyle and will be the base for all lcl classes?
(This class could possibly also get the members "Fenabled" and "Handle" but I'm not absolutely sure about that right now)

Thats all for now,

Stefan

Hi!

Lazarus is work in progress right now and I don't think that you will be satisfied if you only want to port some apps to linux. If you want to help however, you're pretty much welcome, but to do so it's absolutely important that you have a working cvs-environment. If you want to join the pack please post some more details about your problems and we will help you as good as we can.

bye

Stefan

Hi

Since we're all doing this in our spare time just take the time you need.

I never took a closer look at the IDE code but I think we're running in the same direction: Some parts of the lazarus/lcl project suffer from their history and need some cleanup.

Beeing at this point I think it's time to throw in some thoughts (I don't wanna create a general debate here, but it may be good to look where we are now):

1) What we want

* a RAD environment
- supporting the Pascal language
- supporting different development platforms (win / linux for now)
* a component library
- wrapping different widget-sets (gtk, qt, winapi ...)
- compatible to the VCL where it can be achieved without too much trouble

2) What's already there

* a very good pascal compiler (Thanks to the fpc team, you're doing a great job)
* the FCL with all those base classes (Thanks again to the fpc/fcl team)

* basic code for the wrapper-interfaces around gtk, win & qt
* a set of working (gtk-)components
* basic code to integrate the compiler and an editor into one IDE

3) What's missing / tasks to be done

a) code cleanups in a lot of files
b) Most controls need much more testing, some still need much work. c) Nearly all controls need a review, so that we can update the status page.
(If somebody wants to spend some time on this: TEdit could be a good starting point for tests, cleanups and enhancements) d) all those database controls are missing completly (TDataset and some descendants are already in fcl but TDataSource and the edit-controls are missing. Is there anybody willing to implement parts of this?)
e) a form designer
(Cliff, are you still working on this? What about glade?) f) Much work has to be done on the IDE which will glue together all the stuff.

From my point of view we should currently focus on a, b and c whereas d, e and f have lower priority, because they all depend on a working set of visual components. To be clear about this: I don't wanna keep anybody from working on the ide/designer but instead want to encourage anybody to get the basic components stable. This can also mean that you simply point out which controls have bugs or need more work. One of our major problems right now seems to be that nobody knows exactly what's working and what's not.

bye,

Stefan

+ From: Stefan Hille

+ On Fri, Jun 30, 2000 at 10:34:56AM +0200, Marc Weustink wrote:

+ > Its one of my low priority things to fix. As long as
+ > Lazarus runs whithout noticeble problems, they are OK
+ > for me. What do you expect for an alpha state of a project. +
+ Not much more than it actually does, but I see that nearly every new
+ subscriber sends mail regarding these errors. Personally I
+ don't mind too much about these errors although I'm sometimes
+ not sure if they don't have side-effects. So if it won't take you
+ too much time please fix these issues.

OK you're right. Since it is the last message you see, you expect the problem there while it is somewhere else.
Fixing may take a while (or not) since I was that fustrated yesterday about the new IDE code (while debugging) that I decided to do some rewrite/cleanup before it gets completely out of hand.
At this moment I think the code is absolutely unreadable, uncomprehensable and not mainainable.
Using globals anywhere, so you can have for instance one project. Using complete clueless class names. When I see a class TUnitList I expect it to be a list of units or something like that, *not* some info about a unit.
Using complete clueless var names, what do you think Form1, Project1 represent ?
And if I reread the code again (yesterday was the last time so I cant remember it all) I can continue a while.

Please ppl, when coding keep in mind that others also have to understand whats going on and not only you. It doesn't matter that it is faster this way. In the end it will not.
This way every newcomer will be shocked and think again to participate.

Marc (still a bit fustrated)

This is obviously my fault as I am the one doing the majority of the coding on the IDE. I was coding simply to get something up and running and not really concerned with making it readable at this point by others.

Obviously that's not a good thing and I will be a bit more watchful of this in the future.

Shane

>> 07/05/00 03:55AM >>>

+ From: Stefan Hille

+ On Fri, Jun 30, 2000 at 10:34:56AM +0200, Marc Weustink wrote:

+ > Its one of my low priority things to fix. As long as
+ > Lazarus runs whithout noticeble problems, they are OK
+ > for me. What do you expect for an alpha state of a project. +
+ Not much more than it actually does, but I see that nearly every new
+ subscriber sends mail regarding these errors. Personally I
+ don't mind too much about these errors although I'm sometimes
+ not sure if they don't have side-effects. So if it won't take you
+ too much time please fix these issues.

OK you're right. Since it is the last message you see, you expect the problem there while it is somewhere else.
Fixing may take a while (or not) since I was that fustrated yesterday about the new IDE code (while debugging) that I decided to do some rewrite/cleanup before it gets completely out of hand.
At this moment I think the code is absolutely unreadable, uncomprehensable and not mainainable.
Using globals anywhere, so you can have for instance one project. Using complete clueless class names. When I see a class TUnitList I expect it to be a list of units or something like that, *not* some info about a unit.
Using complete clueless var names, what do you think Form1, Project1 represent ?
And if I reread the code again (yesterday was the last time so I cant remember it all) I can continue a while.

Please ppl, when coding keep in mind that others also have to understand whats going on and not only you. It doesn't matter that it is faster this way. In the end it will not.
This way every newcomer will be shocked and think again to participate.

Marc (still a bit fustrated)

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

New rpm packages of the compiler version needed to compile lazarus will be available this weekend with the 1.0 release we've planned.

Peter

hi

can someone send me rpm packages of lazarus? i tried to compile lazarus but i couldn't manage. then i compiled and installed freepascal. i got rid of some (ppc386 command not found) error messages. but i still can not compile lazarus. i am using linux mandrake 7.1 (2 cd version).

i program in windows for about 9 years with delphi and c. if you can help i want to begin programming in linux. i can use c++ but lazarus seems to offer better IDE....

thanx
zekai oguz ozalp

Hi,

Not much more than it actually does, but I see that nearly every new subscriber sends mail regarding these errors. Personally I don't mind too much about these errors although I'm sometimes not sure if they don't have side-effects. So if it won't take you too much time please fix these issues.

bye,

Stefan

+ From: Stefan Hille
+
+ Hi,
+
+ seems as if I'll have some more time to focus on lazarus the
+ next weeks and thus started to review some of the code already
+ present. Here're some observations:
+
+ - Some source files are messed up with writeln's and assert
+ statements and sometimes contain redundant code. gtkobject.inc
+ is a good example for this and it must be very hard for new
+ developers to understand what's going on. I'd recommend to do
+ a major cleanup. If nobody has anything against it I'll start
+ with this saturday.
+ One question: Few weeks ago there have been some mails
+ about asserst versus writeln. I'd prefer to only use asserts
+ so are there any writeln's that should be protected?

I think we all preferred asserts. The only writelns which should be left untouched are the ones starting with WARNING: or ERROR:. When everything is OK you narmally wouldn't see them. They are shown in cases where you as programmer did something strange (Like the GTK errors)

+ - What kind of strategy shall we use for error-handling?
+ Currently some classes throw exceptions, others use asserts
+ or use default values when something illegal is done
+ (e.g. some index out of range).

This depends on the situation.
You always throw an exeption if you enter a illegal situation (like index out of range)
Asserts are placed on locations where we as Lazarus developers assume a certain situation is valid. It is a catch if a developer forgot to do something to set/call. There is something like this in TControl when setting a parent. A control cant have istelf (or decendants) as Parent. This is checked when setteng the parent. Through the rest of the code you can safely assume that this is the case. However when implementing the Controls unit you also have direct acces to FParent. You can (illegally) set this whithout checking. Asserts can pinpoint this so the tracking of bugs are easier. Use defaults if an illegal input doesn't matter. You can see this in the WinAPI stuff.

+ - Currently gtk complains a lot about font-stuff and missing
+ pixmaps. Does anybody know the reason?

Yep

+ From my point of view it's very important to fix this
+ because people new to lazarus might get a bad feeling about
+ the project in general.

Its one of my low priority things to fix. As long as Lazarus runs whithout noticeble problems, they are OK for me. What do you expect for an alpha state of a project.

+ BTW: Most examples will crash when they are closed. Whats
+ the reason for that? (I can't trace into it because the
+ debugger also hangs when it
pens:-((

Hmmm.... Some weeks ago I applied some patches from Vincent which fixed most of them. Have to recheck this.

+ - Currently we use lot's of casts and if-statements to determine the
+ componentstyle for different classes. The reason for this
+ is that the fcomponentstyle member is not in a a common baseclass
+ (TComponent could be a good choice but it's in fcl).
+ Should we introduce a new class (derived from TComponent) which
+ contains fcomponentstyle and will be the base for all lcl classes?

Nope, IMO FComponentStyle is a temporary issue. In a later stage I see it created through RegisterClass, CreateWindow and CreateParams.

+ (This class could possibly also get the members "Fenabled" and
+ "Handle" but I'm not absolutely sure about that right now)

These are in the previous case not handled anymore by GTKObject.

Marc