Hello, all
May I ask you if there is any chance of fixing the
error in the Math unit that I reported here:
https://bugs.freepascal.org/view.php?id=32804
and provided a patch? Here is a test case:
Program Vartest;
uses Math;
const Size = 100;
var dataS: array of Single;
dataD: arr
Michael Van Canneyt to Anton Shepelev:
> > May I ask you if there is any chance of fixing
> > the error in the Math unit that I reported here:
> >
> >https://bugs.freepascal.org/view.php?id=32804
> >
> > and provided a patch? Here is a test case:
>
J. Gareth Moreton:
> For example, code such as this:
>
>Minutes := t div 60;
>Seconds := t mod 60;
>
> ...is badly optimised,
Or not at all.
> because the division is calculated twice (without
> the patch, 't div 60' uses a reciprocal constant,
> while 't mod 60' just uses 'DIV'), wher
Why is not FPProfiler shipped as a binary with the
standard FreePascal distribution? I belive many
users would appreciate it, especially those using
Windows (as I am), where the standard Unix utilities
are not readily available and require effort to in-
stall and configure.
Why does FPP
Florian Klampfl to Anton Shepelev:
>>Why is not FPProfiler shipped as a binary with the
>>standard FreePascal distribution?
>>
>>Why does FPProfiler seem to depend on Lazarus?
>
>Is it usable meanwhile?
I have not tried it, but asked this question when I
found it
Simon Ameis:
>However I think, FPC should generate the profiling
>code itself. Then there is no need to modify the
>code before and after the compilation.
Not, I think, for the naive light-weight profiling
that FPProfiler offers. Its functionality is easily
decoupled from that of the
I wrote:
>Begin a generic tool, a profiler that need not be
>limited to a specific IDE.
Correction:
Being a generic tool, a profiler need not be limited
to a specific IDE.
--
Please, do not forward replies to the list to my e-mail.
___
fpc-devel ma
Ondrej Pokorny:
> Is there a reason why multiple variable initial-
> ization is forbidden?
>
> program Test;
> var
>A:Integer = 0; // allowed
>B, C: Integer = 0; // not allowed
> begin
> end.
>
> Will a patch be applied that allows it?
That means another complication of the language
Florian Klaempfl to Ondrej Pokorny:
> > Anyway, my favorite example of non-pascalish
> > syntax within FPC are the +=, -= etc. operators.
> > I really don't understand how they made it into
> > FPC if so many FPC developers are stubbornly
> > against simple and helpful extensions :)
>
> T
Hello, all
FreePascal has many low-level cross-platform functions
scattered over multiple .inc files but not consolilated into
reusable cross-platform units. Consider, for example, the
functions
function do_read (h: longint; addr: pointer; len: longint) : longint;
function do_write(h: longin
Sven Barth:
> Pascal is a language where declaration and use of
> variables is separated. It makes it easy to see what
> variables are declared and what type they are. Inline
> variables mess this up as a variable can be declared
> somewhere inside the code. I use C++ to earn my living. I
> kno
Michael Van Canneyt to Anton Shepelev:
> > function do_read (h: longint; addr: pointer; len:
> > longint) : longint; function do_write(h: longint; addr:
> > pointer; len: longint) : longint;
>
> I also don't see why you need this. You have this
> functionali
Marco van de Voort:
> Really? So why can't you simply use untyped "file"?
I am writing a TextRec driver that shall work with a bare
THandle, e.g.:
Program Test;
uses TextDrv, SysUtils;
var
t: Text;
s: AnsiString;
h: THandle;
begin
h := FileOpen( 'C:\test.txt', fmOpenRead );
FdAsT
Michael Van Canneyt about FileWrite and FileRead:
> For these functions, you can get more info with
> GetLastOSError, and use that to set InOutRes.
Thank you, but how do I translate the return value of
GetLastOSError into a value of InOutRes? The translation
functions are privately implemented i
Michael Van Canneyt to Anton Shepelev:
> > Thank you, but how do I translate the return value of
> > GetLastOSError into a value of InOutRes? The
> > translation functions are privately implemented in
> > sysos.inc .
>
> You can copy them. It is open source, after
Sven Barth to Anton Shepelev:
>>Since we already have cross-platform functions FileRead
>>and FileWrite, would not it be useful to have them set the
>>InOutRes variable, or to publish a facility for converting
>>the value of GetLastOSError into an InOutRes value?
>
>
Sven Barth to Anton Shepelev:
> > Writers of drivers for this Pascal-style I/O interface
> > should have the ability to convert OS-specific error
> > codes into InOurRes values, which are not even
> > documented at:
> >
> >https://www.freepascal.or
I wrote:
>> > Notice also that FreePascal's TextRec handling is
>> > incompatible with that of Delphi. The TextRec
>> > operations OpenFunc, InOutFunc, FlushFunc, and CloseFunc
>> > return a longint, which Delphi interprets as the result
>> > code but FreePascal ignores. Therefore, I must set
>>
I wrote:
> system.inc defines FileFunc as a procedure without a
> return value:
>
>FileFunc = Procedure(var t : TextRec);
>
> whereas streamio.pp defines the same operations as
> functions returning longint, e.g.:
>
>Function StreamRead(var F: TTextRec) : longint;
Here are the relevant fr
Bart:
> Type
> SubRange = Chr(1)..Chr(2);
> begin
> end.
>
> This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't.
It also compiles in BP 7.0, but why? I think it can work
only if the compiler treats Chr(1) as a macro, not as a
function. Does any dialect Pascal allow function invocations
in
I wrote to Bart:
> > Type
> > SubRange = Chr(1)..Chr(2);
> > begin
> > end.
> >
> > This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't.
>
> It also compiles in BP 7.0, but why? I think it can work
> only if the compilers treats Chr(1) as a macro, not as a
> function. Does any dialect Pascal
21 matches
Mail list logo
