2006/4/20, Vinzent Hoefler <[EMAIL PROTECTED]>:
> On Wednesday 19 April 2006 16:32, 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 imp
On Wednesday 19 April 2006 16:32, 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 progr
> > 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
On Tuesday 18 April 2006 17:24, L505 wrote:
> 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
HI,
I think that we all agree now and we should close this thread.
Alain
On Tue, 2006-04-18 at 16:04 +0200, Sasa Zeman wrote:
> > 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,
On 4/18/06, Sasa Zeman <[EMAIL PROTECTED]> 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 c
> 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 the
On Tue, 18 Apr 2006, Sasa Zeman wrote:
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 doub
Sasa Zeman wrote:
>> 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 en
> 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 kn
On 18 apr 2006, at 12:49, Sasa Zeman wrote:
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 p
> 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 arg
Marco van de Voort wrote:
>> Marco van de Voort wrote:
> 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 pr
> Marco van de Voort wrote:
> >>> 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
>
On 18 apr 2006, at 03:38, 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
Marco van de Voort wrote:
>>> 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.
>
> > 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.
>
> No, PC133 is backwards
Sasa Zeman wrote:
>>> 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.
No? Most of fpc's complexity is caused by this. Just compare the speed and
m
Sasa Zeman wrote:
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.
O, you were not comparing to fpc (from www.freepascal.org)? Because that
compiler
> 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
> > 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 is
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 :)
___
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?
> D2005-6
> compile C/C++ (CBuilder) code among other features raise com
> 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
> wo
> 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 reas
> 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.
Ins
Am Montag, den 17.04.2006, 16:52 +0200 schrieb Sasa Zeman:
> 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 objectiv
> > 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,
On 17 Apr 2006, at 16:52, Sasa Zeman wrote:
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).
It may simply be that for some reason, Delphi requires le
Sasa Zeman wrote:
> 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
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 51
> > 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 cons
>
> 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.
> "
... and since these are handled by the compiler for constants, when running
the user program, the CPU will never se
> 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
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 Pasca
> 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,
Sasa Zeman wrote:
>> 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 calcula
> 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
Sasa Zeman wrote:
>> 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 checki
> 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 gl
Sasa Zeman wrote:
>>> 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
>> Already fixed.
>
> Unfortunatelly, bug still
> > 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
> Already fixed.
Unfortunatelly, bug still persists when division is
> 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
43 matches
Mail list logo
