On Wednesday 15 August 2007 00:40, mm wrote:
> there would not be much places where I could set {$R+} without having
> to reset {$R-} almost immediately.
[EMAIL PROTECTED]:/opt/mdc/dtg/src> grep \$R *.pas
mdc0lzw.pas: {$IFOPT R+} {$DEFINE OPT_R} {$R-} {$ENDIF}
mdc0lzw.pas: {$IFDEF OPT_R
On Tuesday 14 August 2007 21:26, Daniël Mantione wrote:
> You almost never ship a binary with range checking, since a range
> check crash is for a end user generally as usefull as the protection
> fault that can happen when you disable range checking.
Hmm.
[EMAIL PROTECTED]:/opt/mdc/dtg/src> gre
Hello,
I don't want to start a big discuss on the subject (it would
presumably lead nowhere) but I would like to answer to both J.M. and
P.V. who added notes to the report.
To J.M.
---
You said "To be compatible with Delphi". With its current behaviour,
FPC 2.1.4 is not compatible with Delp
Daniël Mantione a écrit :
James Smith a écrit :
Well, I know programmers who turn off range checking and let exceptions
fall through empty exception blocks. They don't work with me on projects.
Though it is sometimes the best way of doing. It is sometimes better
to check ranges explicitly (wh
Op Tue, 14 Aug 2007, schreef mm:
> James Smith a écrit :
> > Well, I know programmers who turn off range checking and let exceptions
> > fall through empty exception blocks. They don't work with me on projects.
>
> Though it is sometimes the best way of doing. It is sometimes better
> to check
James Smith a écrit :
Well, I know programmers who turn off range checking and let exceptions
fall through empty exception blocks. They don't work with me on
projects.
Though it is sometimes the best way of doing. It is sometimes better
to check ranges explicitly (where it is needed to do so)
Of course it will be considered. I don't think we are there yet though.
First, Tom needs to say he is ready for merging though. Second we need to
do some peer review on the code. However, I don't think anyone in the team
is again his work.
Excellent, thanks Daniël.
James
Op Tue, 14 Aug 2007, schreef James Smith:
> Before completely dismissing this issue, I hope you guys will consider merging
> Tom's qualified work into the trunk at some point.
Of course it will be considered. I don't think we are there yet though.
First, Tom needs to say he is ready for mergin
Let's first get people of type unsafe languages. Type safety with range
checking etc. are a big improvement over type unsafe languages. Yes,
Pascal is already the language to use if you are interrested in software
correctness.
And perhaps Tom Verhoeff's work will lead to contract programming. B
There's a company already doing that:
http://www.praxis-his.com/sparkada/intro.asp
I've read their book. Cool stuff.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 14/08/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> fpdoc notifies you of nodes it cannot find. The opposite (unused nodes)
> has not yet been done, but should be easy to add.
>
I'll have to play with fpdoc some more... I'm currently writing a
little fpGUI app (just because I can ), b
On Tue, 14 Aug 2007, [EMAIL PROTECTED] wrote:
> >> Maybe we can make a TCustomInstaller and TInstaller where the TInstaller
> >> will default to install a
> >> FPC package (=units) in the default location so the units work
> >> out-of-the-box for fppkg and fpc.
> >> The TCustomInstaller can be t
On Tue, 14 Aug 2007, Graeme Geldenhuys wrote:
> On 14/08/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> >
> > Well, makeskel has an update option. It will generate nodes for all
> > missing elements.
>
> Sorry, maybe I was a bit unclear. I know it's got the update option.
> So after a ref
>> Maybe we can make a TCustomInstaller and TInstaller where the TInstaller
>> will default to install a
>> FPC package (=units) in the default location so the units work
>> out-of-the-box for fppkg and fpc.
>> The TCustomInstaller can be the base for a complete custom installation
>> of independen
Vincent Snijders schreef:
Graeme Geldenhuys schreef:
ps:
Will the fpdoc.css file used by FPC and Lazarus docs be included as
the default in the next FPC release? The default css file in FPC
2.0.4 look crap compared to the one used on the web.
? It's the same file.
Not in my copy. The one
Graeme Geldenhuys schreef:
ps:
Will the fpdoc.css file used by FPC and Lazarus docs be included as
the default in the next FPC release? The default css file in FPC
2.0.4 look crap compared to the one used on the web.
? It's the same file.
Not in my copy. The one with 2.0.4 generates black
On 14/08/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> Well, makeskel has an update option. It will generate nodes for all
> missing elements.
Sorry, maybe I was a bit unclear. I know it's got the update option.
So after a refactor, I update my xml with makeskel. Now my description
xml fi
On Tue, 14 Aug 2007, Graeme Geldenhuys wrote:
> Hi,
>
> What is the best method to clean up documentation files after a class
> or unit refactor was done. My xml files are all outdated now -
> referencing methods or sometimes even classes that don't exist
> anymore.
>
> What is the options ava
Hi,
What is the best method to clean up documentation files after a class
or unit refactor was done. My xml files are all outdated now -
referencing methods or sometimes even classes that don't exist
anymore.
What is the options available to me. Lets hope I have more choices
than to recreate the
On Tue, 14 Aug 2007, Peter Vreman wrote:
> >
> >
> > On Tue, 14 Aug 2007, [EMAIL PROTECTED] wrote:
> >
> >> >> 1) why is the colon converted to a slash which yields invalid paths (at
> >> >> least
> >> >> on windows)
> >> >> 2) although fpmake initially was developed to be a make tool for FPC, i
>
> The point is that the compiler is not "free", it is encumbered by a
> license. People are gaining the idea that Open Source generally equates
> with "free" (as in no-expense). However, in American English, the word
> "free" generally means "something of so little value that you can afford
On Tuesday 14 August 2007 09:36, Daniël Mantione wrote:
> So, would it be the end of bugs? Not at all. You would prevent
> implementation bugs, not design bugs.
Precisely. Proving that the program behaves according to the
specification doesn't help if the specification is wrong. See Ariane5.
Or
Op Tue, 14 Aug 2007, schreef Vinzent Hoefler:
> On Tuesday 14 August 2007 08:08, Florian Klaempfl wrote:
> > Vinzent Hoefler schrieb:
> > > On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
> > >> Lastly, pre and post conditions are just another runtime check.
> > >
> > > No. If you can pr
On Tuesday 14 August 2007 08:08, Florian Klaempfl wrote:
> Vinzent Hoefler schrieb:
> > On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
> >> Lastly, pre and post conditions are just another runtime check.
> >
> > No. If you can prove that the conditions always hold, you don't
> > even need
>
>
> On Tue, 14 Aug 2007, [EMAIL PROTECTED] wrote:
>
>> >> 1) why is the colon converted to a slash which yields invalid paths (at
>> >> least
>> >> on windows)
>> >> 2) although fpmake initially was developed to be a make tool for FPC, it
>> >> can
>> >> (and will be) used for other projects. The
>> I also think so; I don't think the copy/symlink is necessary; The binary
>> should
>> simply be outputted in the bin/os-cpu directory.
>>
>> fpmake can write a message like 'Writing binary to bin/os-cpu directory' so
>> the user knows where to look.
> Here's a patch that implements all of the a
On Tue, 14 Aug 2007, [EMAIL PROTECTED] wrote:
> >> 1) why is the colon converted to a slash which yields invalid paths (at
> >> least
> >> on windows)
> >> 2) although fpmake initially was developed to be a make tool for FPC, it
> >> can
> >> (and will be) used for other projects. Therefore I wo
>> 1) why is the colon converted to a slash which yields invalid paths (at
>> least
>> on windows)
>> 2) although fpmake initially was developed to be a make tool for FPC, it
>> can
>> (and will be) used for other projects. Therefore I would propose not to
>> initialize FBaseInstallDir with the FPC
Vinzent Hoefler schrieb:
> On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
>
>> Lastly, pre and post conditions are just another runtime check.
>
> No. If you can prove that the conditions always hold, you don't even
> need to compile to the program to prove its correctness.
>
> There's
On Tue, 14 Aug 2007, Darius Blaszijk wrote:
> In fpmkunit.pp I found the function FixPath for which I don't understand the
> exact purpose of. What happens is that if I issue an install command the
> BaseInstallDir takes the FPCDIR env variable (which is c:\fpc in my case)
> (line 1472). This va
On Tue, 14 Aug 2007, Darius Blaszijk wrote:
> In fpmkunit.pp I found the function FixPath for which I don't understand the
> exact purpose of. What happens is that if I issue an install command the
> BaseInstallDir takes the FPCDIR env variable (which is c:\fpc in my case)
> (line 1472). This va
On Tuesday 14 August 2007 06:49, Daniël Mantione wrote:
> Op Tue, 14 Aug 2007, schreef Vinzent Hoefler:
> > On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
> > > Lastly, pre and post conditions are just another runtime check.
> >
> > No. If you can prove that the conditions always hold, you
Real world need for DbC, or some way to show due diligence:
http://www.lightbluetouchpaper.org/2007/08/10/house-of-lords-inquiry-personal-internet-security/
Quote:
"The third area, and this is where the committee has been most far-sighted, and
therefore in the short term this may well be their
Java is glueware really. It's great for net-traversal situations.
Pascal is an application development platform. And IMHO, the best of breed.
We use both for situations where they are suited, respectively.
Having said that, IT departments in businesses are amazingly stupid and
opt for the wron
34 matches
Mail list logo
