FPC 2.0.2 do not rasie exception on integer/floats division by Zero, which is suitable for calucaltion I currently developing. Instead, division return infinity:

writeln(1/0) -> +inf
writeln(1.0/0) -> +inf

With excluding zero exception from SetExceptionMask(), it dows not turn on the exception (unless there is another way). In any event, division by zero should raise exception by default. Perhaps it is solved in some latest release?

Sasa

Already fixed.

> FPC 2.0.2 do not rasie exception on integer/floats division by Zero,

which

Unfortunatelly, bug still persists when division is performed with constants.
Please take a look bug report #5018 for details.

We don't consider this as a bug, it's for delphi compatibility reasons. These expressions are evaluated at compile time, so it's something differnt. If you want to get an error, compile with -Cr.

We don't consider this as a bug, it's for delphi compatibility reasons. These expressions are evaluated at compile time, so it's something differnt. If you want to get an error, compile with -Cr.

The -Cr will point on error in the code, however, enabling range checking will also affect on global speed performance.

Definition in documentation (RTL.pdf):
"
29.20 EDivByZero
29.20.1 Description
EDivByZero is used when the operating system or CPU signals a division by zero error.
"
As defined, reported issue is a bug. As well globaly, in consistency terms.

Far I can see, the core of the problem is in definiton of Infinity constant as 1.0/0.0 and NaN with ln(-1.0) or 0.0/0.0 Perhaps this is necessary to avoid problem with probably difference between different CPU/FPUs. However, IEEE specification should be followed by all of them and bits manipulation to perform infinity should be enough, instead to calculate it (as is performed currently).

The program won't compile with -Cr.

... operating system or CPU ...
but not the compiler ;)

The point is: this div by zero is encountered at compilation time. The other option is to stop compilation always. Executing the operation at run time is useless imo and a waste of CPU cycles.

Far I can see, the core of the problem is in definiton of Infinity constant as 1.0/0.0 and NaN with ln(-1.0) or 0.0/0.0

No. These constants are defined in const blocks. A const block couldn't throw an exception.

The program won't compile with -Cr.

Program with -Cr will compile and link if all is correct. Eventually range check error compiler can predict, will stop compilation as usually. Otherwise, program itself will check range on each attemp to work with arrays or calculations, which is clearly waste of time.

... operating system or CPU ... but not the compiler ;)

"... As well globaly, in consistency terms." I can not see reasonability of different threaded division by zero by CPU/FPU or compiler. Delphi have several inconveniently basically solved problems, among of which is this one. Handling by inheritance Delphi solution in FPC mode is unfortunate.

Even better. In compilation time, if compiler detect division by zero with constants it should stop compilation - by default, without any switch. I can not see reason to be threaded differently.

In that case there is no problems: 'Writeln (1.0/0.0)' or 'a:=a*b+1/0' and similar constructions should be threaded by default. It is mathematical nosence continuing calculating ratinals - during complex calculations, simple error will lead to infinity result instead to simply stop during compilation and show the error.

I see no problem in implementation.

The compiler doesn't know at compile time how the exception mask would look at run time at this point, so it's not threaded differently, div by zero might be masked at this point and throwing an error would be wrong because at run time the code would evalute to Inf.

There is code out there defining Inf by 1/0. There was a bug report about this, see also below.

In that case there is no problems: 'Writeln (1.0/0.0)' or 'a:=a*b+1/0' and similar constructions should be threaded by default. It is mathematical nosence continuing calculating ratinals -

No, it's IEEE behavior: calculating with Inf etc. is completely valid.

People will complain, if FPC isn't delphi compatible. I implemented it this way because people complained that FPC behaves differently than Delphi in this case. And I see nothing wrong with it: the compiler can't know the fpu exception mask at execution time when compiling the program so throwing an error might be as wrong as returning Inf. So the only real solution would be to carry out the 1/0 at run time, however, this leads also to inconsistent code regarding const inf = 1/0; while writeln(1/0); could throw an exception, writeln(Inf); wouldn't. So imo any possible solution is wrong in some way.

People will complain, if FPC isn't delphi compatible.

FP actually is not 100% Delphi compatible by default mode and it is not intention to be (regarding available informations on internet) it is actually intented to be compatible with Turbo/Borland Pascal, I suppose. Delphi simulation mode (-Sd, or directive {$mode delphi} ) is not 100% compatible as well.

As I understood you (obviously not correct), you wrote that const block is not checked during compiling on division by Zero (as mentioned, infinity const can be set simply by bits setting)...

In any event, to be clear with suggestion: current solution is quiet problematic during testing quite complex calculations functionality, where dividing with zero constant is simple mistake. I have several quite complex statistical applications where simple mischanged constants division by 00 instead of 100 (for example) create quite serious poblem, implying time to find the bug. Long compilation time for checking only (with -Cr ) and then without it just double already enormous compiling time (Lazarus project). That issued problem was consist with Delphi, however ut since fast compilation error was located and fixed very fast...

Perhaps new {$AllowedDivisionByZero+-}compiler directive would be an convenient compromise.

Sasa Zeman wrote

> People will complain, if FPC isn't delphi compatible. FP actually is not 100% Delphi compatible by default mode and it is not

That's true.

intention to be (regarding available informations on internet) it is actually intented to be compatible with Turbo/Borland Pascal, I suppose.

No. It depends on the mode.

Delphi simulation mode (-Sd, or directive {$mode delphi} ) is not 100% compatible as well.

It tries to be ;)

Well, doing this by hand is several work: you need to distinguish between different endianesses, different data sizes and take care of non standard formats like the arm fpa uses.

From the compiler sources:

{$if defined(CPUARM) and defined(FPUFPA)}
       MathQNaN : tdoublerec = (bytes : (0,0,252,255,0,0,0,0));
       MathInf : tdoublerec = (bytes : (0,0,240,127,0,0,0,0));
       MathNegInf : tdoublerec = (bytes : (0,0,240,255,0,0,0,0));
       MathPi : tdoublerec =  (bytes : (251,33,9,64,24,45,68,84));
{$else}
{$ifdef FPC_LITTLE_ENDIAN}
       MathQNaN : tdoublerec = (bytes : (0,0,0,0,0,0,252,255));
       MathInf : tdoublerec = (bytes : (0,0,0,0,0,0,240,127));
       MathNegInf : tdoublerec = (bytes : (0,0,0,0,0,0,240,255));
       MathPi : tdoublerec = (bytes : (24,45,68,84,251,33,9,64));
       MathPiExtended : textendedrec = (bytes :
(53,194,104,33,162,218,15,201,0,64));
{$else FPC_LITTLE_ENDIAN}
       MathQNaN : tdoublerec = (bytes : (255,252,0,0,0,0,0,0));
       MathInf : tdoublerec = (bytes : (127,240,0,0,0,0,0,0));
       MathNegInf : tdoublerec = (bytes : (255,240,0,0,0,0,0,0));
       MathPi : tdoublerec =  (bytes : (64,9,33,251,84,68,45,24));
       MathPiExtended : textendedrec = (bytes :
(64,0,201,15,218,162,33,104,194,53));
{$endif FPC_LITTLE_ENDIAN}
{$endif}

Well, I consider the problem as minor so I don't know if it's worth to introduce a new switch. I guess the best solution is to throw always a hint. Since 1/0=Inf is IEEE compliant, it's no real error. If people really want an error, they can create their own error msg file making the hint an error.

Unfortunatelly, this is a major problem with specific environment and type of application... :-(

In this case, I consider it is much productively to concentrate on optimization of internal linker as well as compiler for computers with small phisical memory (<=128MB on Windows). Compiler, as well as internal linker currently consume over 80MB each for simples Lazarus application.

... and since these are handled by the compiler for constants, when running the user program, the CPU will never see it. So it should either not compile, or have the current behaviour, but a EDivByZero will never happen, since this is not calculated runtime.

Far I can see, the core of the problem is in definiton of Infinity constant as 1.0/0.0 and NaN with ln(-1.0) or 0.0/0.0 Perhaps this is necessary to avoid problem with probably difference between different CPU/FPUs.

It is done for Delphi compat as florian already said

I think even _if_ there is a focus on getting the memusage down (and there is, it is one of the internal linkers objectives), it should be more to let Lazarus perform optimally with say 512-1024MB memory, and not to try to squeeze it into sub 128 MB. That would be counterproductive.

Regarding division problem. Florian was precise in explanation (suggested to be part of documentation).

I think even _if_ there is a focus on getting the memusage down (and there is, it is one of the internal linkers objectives), it should be more to

let

Lazarus perform optimally with say 512-1024MB memory, and not to try to squeeze it into sub 128 MB. That would be counterproductive.

Inside total phisical memory of 128MB, Delphi compililation is very fast. That mean that process of compilation is optimized to work with available phisical memory (at least under 128MB). The same is case with command line compiler (dcc32). I doubt it is contra-productive, on the contrary. Any attempt to work with swapfile lead to enormous performance decreasing, which is currently case.

During building Lazarus, peak of used memory by comiler is over 85MB. As well, 192MB of minimum reserved virtual memory by Windows is often too small. All indicate that optimization of the compiling and internal linking process should be one of the top priority.

In my opinion, FPC and Lazarus can try to ratioinally use available resources, not to force developers or company to buy new hardware. Note that many companies still work with relatively old hardware and they are not willing for further investments (often mean replacement old hardware with new).

It is probably: it seems that delphi compiler source is completely unmaintainable and unportable else they would have developed it much faster.

Today, 1 GB of RAM cost 70 Eur, the 256 MB necessary for usable fpc are at 20 Eur, so memory usage has no real priority anymore for the current fpc developers. Since we have limited time, maintainability has highest priority followed by portability and speed.

Then they have to spent time into optimizing fpc regarding memory usage ;)

It may simply be that for some reason, Delphi requires less memory and doesn't reach 128 MB when compiling your project.

What Marco probably meant is that rewriting the compiler and Lazarus to work together with less than 128MB of RAM would be a lot of work, which would negatively impact work on other areas and maybe also reduce the ability to further extend and maintain the compiler and Lazarus.

FPC and Lazarus are each developed by a handful of people in their spare time, supports 6 different cpu architectures (i386, x86-64, ppc32, ppc64, arm, sparc32) and a ton of different OS'es (all of which also require some compiler support). Maintainability and extensibility are therefore much more important than memory usage and speed, although we aren't bad at all on those counts, especially if you compare FPC with C or C++ compilers.

There are no places in the compiler where we are allocating memory just for the heck of it, and we also regularly check the compiler for memory leaks. And when we see places where things can be done in a more efficient way, we do change them. But a target of max 120 MB memory usage for IDE + compiler + linker is quite something different.

Jonas

> Lazarus perform optimally with say 512-1024MB memory, and not to try to > squeeze it into sub 128 MB. That would be counterproductive. Inside total phisical memory of 128MB, Delphi compililation is very fast.

Not in a modern version. It won't even start probably.

The point however is, those delphi versions stem from times where memory was scarse, and a lot of effort went into optimizing memory usage.

If we would try to match that, uncompromisingly, with Free Pascal, we would have to put nearly everything else on hold. That is not sane.

The point is that 128MB simply is an arbitrary border. And IMHO not realistic in this day and age.

During building Lazarus, peak of used memory by comiler is over 85MB. As well, 192MB of minimum reserved virtual memory by Windows is often too small. All indicate that optimization of the compiling and internal linking process should be one of the top priority.

Yes, but for maximal throughput on a normal system and memory amount. Not some arbitrary antique one that Delphi4 or 5 had to deal with.

In my opinion, FPC and Lazarus can try to ratioinally use available resources

There you hit the core of the problem: You can't reliably detect the available _physical_ memory under most OSes. So you have to just take a CPU/mem point and optimize for that, and the user must make that available or live with the consequences.

not to force developers or company to buy new hardware.

That is one way to say it. The other way is just buy new memory to avoid FPC developers have to spend disproportionate amounts of time to keep the software running with very old systems.

Keep also in mind when the branch where this development is done reaches the ordinary release-using users, we are at least one, maybe two years further. How many of those old machines will still be running then?

Note that many companies still work with relatively old hardware and they are not willing for further investments (often mean replacement old hardware with new).

Companies that can't afford 256MB extra in a developer machine, are effectively already bankrupt. Even outside the USA and Western Europe.

Note that for Visual Studio and Delphi (current versions), 2GB is considered normal.

That's one reason why development machines should have adequate hardware. Another is the need of running many multiple processes (IDE, target program, debugger, browser or the like for reading docs, ...).

If you're talking of commercially working companies, you're wrong. If a company is not willing to buy some more memory at least but is wasting the time of the programmers, this company is doing something wrong. The monthly fee of one programmer should be enough to buy a couple of well equipped machines once, bored programmers are paid again and again.

And if a company has such big need for having fpc work their way, this company is free to do some sponsoring. ;)

SCNR,
Marc

IMHO you should already be happy with the internal linker because you are now able to create a smartlinked lazarus without requiring 1+ GB of memory.

Please stop asking for pathetic requirements. Especially for things where you don't know where you are talking about and therefor without in-depth analyses where things could be improved.

Peter

IMHO you should already be happy with the internal linker because you are now able to create a smartlinked lazarus without requiring 1+ GB of memory.

FPC and Lazarus are just testing alternatives. Comparing FPC performance of internal linker with Delphi's or with external LD, I found no reason use it on current environment.

Please stop asking for pathetic requirements. Especially for things where you don't know where you are talking about and therefor without in-depth analyses where things could be improved.

Please define "patetic requirements"... I find this very inpropriate and quite insolting.

Keep in mind that I'm not in FPC developer team nor I'm interested. Nor I have a time for code analysis, as already mentioned. Exceptioin that all people need to read 1000s lines of code is not realistic to wrote suggestions by your FPC team project vision. My goal is to use software which is suitable to produce working application on specifically used environment and from that naturaly comes suggestions may or my not be suitable for the project. Nobody force you or anyone else to accept it.

I did expected here an academical answer, raised from any banal insoltings.

Not in a modern version. It won't even start probably.

FPC can be comparable with command line compiler of Delphi 7. D2005-6 compile C/C++ (CBuilder) code among other features raise complexity, which are not FPC tasks.

If we would try to match that, uncompromisingly, with Free Pascal, we would have to put nearly everything else on hold. That is not sane.

It seems that all previously produced compiled code left in memory, even if it is not needed anymore. If that is true, small reorganization may be helpful.

That is one way to say it. The other way is just buy new memory to avoid FPC developers have to spend disproportionate amounts of time to keep the software running with very old systems.

Older comuters use memory type is not available anymore, which force replacing all hardware. Extra cost $750-1500 per developer.

Sasa Zeman wrote

> Not in a modern version. It won't even start probably. FPC can be comparable with command line compiler of Delphi 7.

Yes? So Delphi has multi platform support and has maintainable compiler sources?

It seems but it isn't the case :)

So you use older memory than edo-simms? Even more, SD-RAM is no issue and iirc SD is used for almost 10 years. Some months ago, I bought edo simms for an ~10 year old machine which couldn't be replaced and it was no problem to get the memory modules.

Sasa Zeman wrote

Keep in mind that I'm not in FPC developer team nor I'm interested.

Please keep in mind that FPC/Lazarus is OSS and that it lives from it's user's contributions. If you don't like the idea of OSS, better stay with Delphi and hope that it survives :)

> FPC can be comparable with command line compiler of Delphi 7. Yes? So Delphi has multi platform support and has maintainable compiler sources?

Multi platform support was not an issue here.

> It seems that all previously produced compiled code left in memory, even if It seems but it isn't the case :)

Helpful information would be exact cause.

So you use older memory than edo-simms? Even more, SD-RAM is no issue and iirc SD is used for almost 10 years. Some months ago, I bought edo simms for an ~10 year old machine which couldn't be replaced and it was no problem to get the memory modules.

EDO is more museum exponat and price is 10 times larger than the same memory size SD-RAM. The used memory is one module 128MB SD-RAM (PC100). I've manage to found only one 256MB module available on market with price of 50Euro, but only incompatible PC133.

Please keep in mind that FPC/Lazarus is OSS and that it lives from it's user's contributions.

It seem that you missunderstood. As a developer, I'm not interested in looking FPC code nor tracking future plans (details are alse never published, only future plans), but using it to create working applications.

From that point of view it is non-logocal and even insolting : "Please stop

asking for pathetic requirements. Especially for things where you don't know where you are talking about and therefor without in-depth analyses where things could be improved." Or "If you want to work with development code i think it is better to find out it yourself what is going wrong. " - especially that bugs in 2.0.2 require using development code...

This mailing list is for FPC developers only? Please clarify and update information on main mailing-list page.

If you don't like the idea of OSS, better stay with Delphi and hope that

it survives :)

Since I testing FPC and Lazarus, I'm intersting in using it. However, FPC and Lazarus currently cannot be competition to Delphi/Kylix. But the most important advantages are daily updates and upgrades and we hope it will become worthy competitor one day. And stay OpenSource, in which I doubt if Delphi discontinue.

Good luck.

O, you were not comparing to fpc (from www.freepascal.org)? Because that compiler *is* multi-platform and therefore had to trade something (memory and/or speed). You may argue that the trade of has been done badly, but you cannot ignore it.

Vincent.

No? Most of fpc's complexity is caused by this. Just compare the speed and memory requirements of 1.0.x and 2.0.x. The multi processor platform support causes a lot of the complexity in 2.0.x.

No, PC133 is backwards compatible.

It's not. There are a lot of PC100 machines that don't accept PC133. I know one mainbord for sure (and a common one) Asus P5A-B.

Then the memory module has a wrong eeprom, usually it works if the memory module has a correct programmed eeprom.

Sasa Zeman wrote

It seem that you missunderstood. As a developer, I'm not interested in looking FPC code nor tracking future plans (details are alse never published, only future plans), but using it to create working applications.

In that case, you cannot make any sort of demands or set our priorities. You can voice your opinion of course (which you did), but it is just as insulting to expect us to make your concerns our highest priority and to explain in detail the inner workings of the compiler without you willing to make any efforts, in particular since you do not intend to actually help everyone that uses the compiler (with patches) with that knowledge.

Afaik the main reason you use 2.1.1 is for the internal linker, not because of bugs in 2.0.2. The internal linker is not a bugfix, it's a new feature.

You forgot to add "for my environment and purpose" at the end of that last sentence.

And stay OpenSource, in which I doubt if Delphi discontinue.

Even if we would want to (and we don't, no matter how hard it may be for you to believe that), we could not make FPC suddenly closed source. It contains contributions from tens of people. We would have to track down and contact every single one of them, and convince all of them to transfer their copyright to us or to sign some contract before we could change the license of the compiler, rtl and pretty much all of the source distributed with FPC.

It's similar with Lazarus.

Jonas

I tested quite a lot of dimms. It was the mobo, not the DIMM It didn't even accept _only_ one PC133 dimm.

The memory ran fine in other 100MHz bus computers. (both were K6-2's, one early (K6-300), the other later (K6-500))

Ok, that's a border case then ;) Usually it works :)

In that case, you cannot make any sort of demands or set our priorities. You can voice your opinion of course (which you did), but

Please do not mis-interprete. I'm aware that any meber of FPC can be a bit more sensitive, but that is not a reson for inpropriate behavior instead of cultural argue, providing fact why specific suggestion can or cannot be incorporate. Unfortunately, it only indicate something else...

With free and opensource product you made a trade with voluniers and users to make a reliable and popular product, based on your own (i.e, FPC team) vision and user's requests. I can suggest features which suits to my own needs (declared as a priority to me regarding type of applications I create) and see it is suitable to be incorporate as a general benefit. Then I would have elements to decide to using it or not. Nothing wrong nor insulting I can see. This is obvious and I consider was not needed to be explained (obviously wrong assumption).

Once agin, I suggest to be precise on main page what you expect from members of this mailing list.

Afaik the main reason you use 2.1.1 is for the internal linker, not because of bugs in 2.0.2. The internal linker is not a bugfix, it's a new feature.

The main reason is #4922, as is mentioned already. Internal linker is tested to be used instead of problematic LD on current environmet.

Even if we would want to (and we don't, no matter how hard it may be for you to believe that), we could not make FPC suddenly closed source. It contains contributions from tens of people. We would have

It is highly unlikely that any project will stay OpenSource and free of charge forever. As example is popular RedHat where worked 100s, maybe 1000s of people (volonitiers and contributers). It become commercial since v 8.0. What is achived is commercial OS with minimum developer costs. In short, It is business decision non-sence that when commercial oportunity become real, simply ignoring it regarding foundation basis license.

to track down and contact every single one of them, and convince all of them to transfer their copyright to us or to sign some contract before we could change the license of the compiler, rtl and pretty much all of the source distributed with FPC.

If FreePascal founders are registrated as a company, contract would have legitimity in the law, otherwise will not.

The problem was when you kept insisting that the compiler wastes memory and should be optimized (with a target of 128MB physical memory for Lazarus + the compiler), while you (by your own admission) have no idea at all about how the compiler is built and also have no interest in spending time on learning about that.

This is insulting because it suggests that the people actually working on the compiler don't know what they are talking about, since you contradict them without even feeling the need of proving your point (and in fact ask from the other people to explain/prove to you that the compiler is not wasting memory).

Once agin, I suggest to be precise on main page what you expect from members of this mailing list.

We don't expect anything in particular. This list is to ask questions about problems you may have with using the compiler.

That does not force you to work with experimental features such as the undocumented internal linker.

Everything which was open source/Free Softwar is still open source/ Free Software. They cannot change anything about that. They created some add-on programs, but the main thing you pay for is commercial grade support, not the software.

In that respect, any addition to the compiler has to remain GPL. So the only thing which could become closed would be something like a new IDE or so. And the only thing we could ask money for is services (e.g. prioritization of bug handling or the implementation of new features and support).

In fact, anyone could already offer such services now, for free or for money, without owing us a dime. And we wouldn't mind at all, since it would only help FPC getting better.

Unless you have no interest at all in providing commercial grade support, because it's just a hobby and you want to be free regarding how much time you spend on it, on what you spend it.

This is completely separate from the fact that we would have to convince all those people to actually sign such a contract.

Jonas

The problem was when you kept insisting that the compiler wastes memory and should be optimized (with a target of 128MB physical

Please read all carfully, you mis-interpreting whole thing again.

If you want more developers in the team, simply "yes or not" is not enough. Explain how else to know more fact about current implementation without reading source and waste time on this. On that way I may want to look in the code and try to find way to optimize the process. You and Vreman constantly close the circle ("dead loop").

In any event, you cannot say that compiler and linker algorithm is optimized enough for each platform.

You also keep to ignore insulting and insinuations wrote here. If this is a way to prevent any suggestion and problem reporting, this mailing list should be declared "for developer only".

That does not force you to work with experimental features such as the undocumented internal linker.

That is not the point here. Please read Peter Vreman's and my own posts carfully again.

Unless you have no interest at all in providing commercial grade support, because it's just a hobby and you want to be free regarding how much time you spend on it, on what you spend it.

Unless you calculate number od Delphi developer world wide. I doubt that anyone will skip the lucruative oportunity.

And I doubt any contributor will work just for credit, except perhaps students or retirement people.

This is completely separate from the fact that we would have to convince all those people to actually sign such a contract.

That is the law - any unvalid document is worthless. Contributor have all right to requre fee after licence changing and without valid contract, this is just another "Perpetuum mobile"...

In any event, we will see in the near future what will happend.

Of course not and nobody said so. As I said several times, main design goal is portability and maintainability, speed and memory are considered as less important by the current contributors.

You should really start to understand Open Source. You don't do currently, sorry. All of us work just for credit or even only fun and we're neither students (ok, I'am preparing a PhD in my leisure, not related to FPC, but besides this I've a fulltime job) or retired. Same applies to most other current FPC contributors and Lazarus developers.

On the contrary:

Most of us do work just for credit. Most do have a day time job.

All people on the compiler team have a day time job. I think some of the people on the lazarus team are preparing a PhD, which also is considered a job here in Belgium.

So, yes: it IS for credit only. None of us gets payed.

On the contrary, we pay money to keep the servers running, DNS registration costs money. If we meet: we pay for it...

Michael.

If FreePascal founders are registrated as a company, contract would have legitimity in the law, otherwise will not.

Incorporating into a registered company doesn't really help secure anything down - for example Borland could cut off the Delphi product at any time (or sell it) even though they are a "legal" company. Companies spend more time yapping about their shareholders and what would be best for the shareholders instead of what would be best for the developers (read the Borland news groups - everyone always comes up with the excuse that "but what the developer wants isn't always good for our shareholders". Even though developers are buying the software and supporting the figurehead shareholders. Doesn't make sense to me.). Or maybe you mean a foundation, like a non-profit organization? Obviously FPC is not out for profit, but out to help the developer. So I can see a non-profit organization working - but this would mean that FPC team would spend more time on things like Accounting, Lawyers, etc. Look how free software foundation is spending time hiring lawyers and etc. for their foundation.

Although I do agree that freepascal should not just be a hobby for all, and some of us should start using it within their jobs to make it a better compiler. I'm sure lots of people rely on GCC and PHP at their jobs every day - and this helps make it better because it must be high quality at work, higher quality than just hobby. I use FPC for some of my work (websites, misc tools), but not experienced enough to be a development team member yet. I'm guessing there are a few others that use FPC in their real jobs. If you can't find jobs out there that use Pascal then you have to be really brave and start your own business and start hiring people with Pascal skills. Someone has to do the work. Or use FPC internally in your home/small business yourself without worrying about the current work available.

How to balance a clash of free vs open vs closed vs commercial? Some people could care less about source code (customer at home who has never programmed in his life, looking for a paint program on download.com, let's say). So sell software to those folks who don't need the sources. But keep some software open, such as the compiler and RTL - because in this case developers do care about the sources and fixes are easiler to apply with them.

Sasa Zeman wrote

It is highly unlikely that any project will stay OpenSource and free of charge forever. As example is popular RedHat where worked 100s, maybe 1000s of people (volonitiers and contributers). It become commercial since v 8.0.

Comercial is not contrary to Open Source.

Nothing prevents people to sell GPL software and that is what Red Hat does.

After you buy it, however, you are free to change it at your will and even repackage it and put on a server for download.

HI,

I think that we all agree now and we should close this thread.

Alain

Not to mention that a foundation only works with funding, which means money. Especially when we're talking about hiring lawyers. Trust me. :-)
And I don't think that there is awful lot of that where we are from.

it a better compiler. I'm sure lots of people rely on GCC and PHP at their jobs every day - and this helps make it better because it must be high quality at work, higher quality than just hobby.

Well, well. A lot of people rely on Java on the job and it didn't get better yet, did it? ;->

I use FPC for some of my work (websites, misc tools), but not experienced enough to be a development team member yet.

And I do not have the time because of work. (Sorry, and yes, I'm still looking at the DOS stuff from time to time. But currently there's absolutely no chance here...)

I'm guessing there are a few others that use FPC in their real jobs.

Yes. But that's just circumstantial luck. The decision between "Grab 120'000 lines of C++" and "grab 70'000 lines of Turbo Pascal" and make it work on a decent system was mine to take.

If you can't find jobs out there that use Pascal then you have to be really brave and start your own business and start hiring people with Pascal skills.

Yeah right. Sorry to bring that up again, but if I would do that I would never hire people that claim to have such specialized skills. What is needed are people who can actually engineer software and that particular skill has nothing to do with language skills (of course, if all else fails, I'd rather hire a Pascal guy than a "There *are* other languages than C?"-guy, because the Pascal guy might grasp the concepts much easier).

How to balance a clash of free vs open vs closed vs commercial?

I'd vote for open source. And you can sell it, basic argumentation goes like this: "Even if we are out of business for some reason, you still have the source code.".

Regards,

Vinzent.

I didn't say pure pascal programmers with no other skills. most pascal programmers know databases, Assembly, and C. They also usually know at least one scripting language such as PHP.

I plan to hire/pay Pascal programmers at some point for future commercial projects. Who will I hire? Probably the folks that have worked with me on open source projects before. If not hiring per hour - I mean contract jobs too. Or people who I've found helpful on a mailing list. People even get jobs by visiting wiki's.. a few people have gotten jobs off c2 wiki and others. It's all about networking isn't it? Lots of linux guru's get hired off by microsoft simply by starting up yet another linux distribution. (sorry to the fellow at gentoo, who now does not work for microsoft).

L505 wrote

I didn't say pure pascal programmers with no other skills.

Of course you didn't say *that*. But it still sounds like you are very focused on language skills. Language skills are much less important than people usually think.

most pascal programmers know databases, Assembly, and C. They also usually know at least one scripting language such as PHP.

It is *not* about knowing a language (or two, or more).

Knowing about stones won't give you the ability to build a house. Unfortunately most people in the software business seem to think it does. It doesn't. It's that simple.

Software development is not about *where* to put this or that statement, it is much more about the *why*: In the end it's math, logic and abstraction (among some others). A particular language is just one way to express those.

Of course, having some knowledge helps to get a project started, but this is too short-term thinking. I even learned by observation that having knowledge (especially about C-like languages) actually seems to hurt. And hell, I practically learned Java in a couple of days. Anything else from that point on consists in looking up the documentation on which class I may need.

Well, I don't consider being able to successfully scan a telephon book for a particalur name a special skill. I just expect people to be bright enough to do *that*. Are my expectations set way too high here?

I plan to hire/pay Pascal programmers at some point for future commercial projects. Who will I hire? Probably the folks that have worked with me on open source projects before.

Yes, that might be a good start. But you miss the main point: that these people showed motivation and you may even be able to judge their general "software-engineering" abilities (how they designed their projects, modularized it, how they managed it, etc.pp). Any specific language skills are just /not/ important, believe. Of course, the willingness to do it in a different language might be.

Regards,

Vinzent.

2006/4/20, Vinzent Hoefler :

I totally agree that software design and abstraction of the logic concepts are vital and most important to make the difference between a good programmer/analyst and a poor one. This is a must and even if you know or not a language you will be good or not at doing amazing software and software architecture. It is like being an architect.

But for the language part, I find it very important too. Maybe a little bit more that you do. I'm not fluent in English, but in French yes. I think in French, I abstract in French, I do jokes in French, I talk to people in French, I do poems and play on words in French; and I understand others doing the same thing. But in English this is not the case. I know enought to express myself with limitations. Yet, I could have amazing ideas, idioms, jokes, but be completely unable to express it or communication it in English, or "in the spirit of the language". Translating a joke is almost impossible.

This example being said, An architect also knowing massonery will be much better than a simple architect or a simple masson. He will understand both and be very much effective in his task. C was my first language, but I must say that Pascal is my native language in computer programming. I'm able to abstract and do pretty good software design; but when I try to put that in other languages, I'm limmited or it is impossible to apply the design with the actual langauge.

So when I know i'll code in Pascal, my design will be very much improved. I already know of what I'm talking about when I design the software. I can almost see the source in my head. I know the language capabilities and limmitations. Etc.

Well, it was only my point of view on the interresting point you have raised. (Still, I totally agree with you, except that language is also important. It will make the difference between two candidates with the same "software design / abstraction" skills and personality in the team.

Best regards.