On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel
wrote:
>> I'll write a simple example in the wiki (there's a ToDo for that
>> currently).
> Please do.
Done.
It's a bit more elaborate than just a few lines though.
--
Bart
___
fpc-devel
On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel
wrote:
> Management operators are already part of 3.2.x (
> https://wiki.freepascal.org/FPC_New_Features_3.2.0#Management_operators_for_record_types
> ). Or did I misunderstand your remark? 樂
I misread the wiki page (it mentions 3.1.1
On Thu, Apr 25, 2024 at 11:18 AM Sven Barth via fpc-devel
wrote:
> If there exists a built-in operator then overloading that operator is
> forbidden to avoid confusion when what operator might be used (operators can
> after all be declared *anywhere* and thus they might sometimes be used and
Hi,
Overloading the := (assignment) operator for equal types is forbidden.
Out of curiosity I would like to know why that is?
When you have e.g. a record definition containing a dynamic array, not
being able to overload the assignment operator is just a PITA.
OK, once you know why the
On Thu, Apr 4, 2024 at 9:49 PM Martin Frb via fpc-devel
wrote:
> The below writes: -9223372036854775808
>
> Shouldn't absolute return a positive number?
>
> program Project1;
> begin
>writeln( abs(low(int64)) );
> end.
See https://gitlab.com/freepascal.org/fpc/source/-/issues/40694
There
On Sun, Dec 17, 2023 at 6:14 PM Marco van de Voort via fpc-devel
wrote:
> Never mind, it is merged. The road blocks turned out to be in the
> dotted RTL related revisions (since it is a pchar based routine), so in
> the end I manually merged.
Thank you very much.
--
Bart
Hi,
Just noticed that AdjustLineBreaks is broken if the Style parameter is
set to tlbsCR. (Tested with 3.2.2).
In fpc main this is fixed, in fixes_3_2 this still seems broken.
The fix in main was committed in 1c4151d8 (1 merge reques t!396 Fix,
shorten*, and speed up AdjustLineBreaks.( MR by
On Mon, Oct 2, 2023 at 9:01 AM Michael Van Canneyt via fpc-devel
wrote:
> I did so, I left a small request.
I attached a small test program to the bugreport (with a question).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hi,
Issue 40261 is about TStrings.AddObject issueing 2 consecutive
OnChange events (and in the first one the to be added object is
unassigned when accessing Objects[] property) when using InsertObject,
AddObject and AddPair.
This is Delphi incompatible.
The patch attached to
On Thu, Jul 20, 2023 at 7:59 AM Sven Barth via fpc-devel
wrote:
> It is indeed by design that not every integer type is a suitable index
> variable for a for-loop. In this case that a 64-bit variable can't be used on
> a platform with less than 64-bit width. The same is probably also true for
On Wed, Mar 29, 2023 at 11:43 PM Bart wrote:
> I'll report it in the bugtracker.
https://gitlab.com/freepascal.org/fpc/source/-/issues/40225
I condensed the program even further.
Just concatenating 2 strings in Foo and assigning them to S will be
enough to trigger the memory leak.
--
Bart
On Wed, Mar 29, 2023 at 11:44 AM Ondrej Pokorny via fpc-devel
wrote:
>
> FYI: Delphi doesn't create a memory leak.
>
The memory leak seems to be related to string concatenation in the
getter for the Text property.
A getter like this is enough to get the leak:
function TBar.GetTextStr: String;
Hi,
The following program gives a memory leak:
===
program test;
{$mode objfpc}
{$h+}
uses
Classes;
var
SL: TStringList;
procedure Foo;
const
S: String = '';
begin
S := SL.Text; // << this is line 13
end;
begin
SL := TStringList.Create;
SL.Add('1');
Foo;
SL.Free;
end.
===
On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel
wrote:
> So for a while now fpc 3.3.1 receives new optimizations => which is
> great / big fan of it.
>
> And hence I thought, lets see how much of an impact they have. And in my
> test, they had none :(
Optimizations beyond O2 (or even
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel
wrote:
> Error "Range check error while evaluating constants (18446744071562067969
> must be between -2147483648 and 4294967295)"
> is wrong here:
>
> property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER;
>
>
On Mon, Feb 13, 2023 at 8:20 AM Ondrej Pokorny via fpc-devel
wrote:
> I wouldn't publish the HKEY property but create an own enumeration for it:
>
> TRegKey = (rgClassesRoot, rgCurrentUser, )
>
...
>
> Then make a simple transformation to HKEY:
>
> RegKeyToHKey: array[TRegKey] of HKEY =
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel
wrote:
> Afaik it's because "default" doesn't support qword values, iirc because
> of (at least old) Delphi compatibility.
OK, I removed the "default".
Theoretically would that lead to problems when storing the value in
lfm and reading
On Sun, Feb 12, 2023 at 10:49 PM Bart wrote:
> For 32-bit builds this results in the final HKEY value being identical
> to the original literal value, but for 64-bit builds, because of the
> intermediate signed LONG cast which is then cast to the larger
> unsigned ULONG_PTR type, the original
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel
wrote:
> Afaik it's because "default" doesn't support qword values, iirc because
> of (at least old) Delphi compatibility.
Would the original code example compile in a modern 64-bit Delphi
(targeting Win64)?
My old D7 doesn't even know
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel
wrote:
> Declarations like this have been made on purpose:
> HKEY_CURRENT_USER = HKEY(longint($8001));
>
> On Win64 HKEY_CURRENT_USER must be $8001, but on Win32 it must
> remain $8001.
>
> See commit
On Sun, Feb 12, 2023 at 6:26 PM J. Gareth Moreton via fpc-devel
wrote:
>
> If HKey is unsigned, then yes, the definition should be
> HKEY(DWORD($8001)). I do wonder why Win64 produces that particular
> error though because the final destination is an unsigned 64-bit integer.
Because
Hi,
This code compiles happily for Win32, but refuses to compile for Win64:
program test;
{$mode objfpc}
{$h+}
uses
Registry;
type
TA = class
private
FRootKey: HKey;
public
//Win64/X86_64 Error: Range check error while evaluating constants
(18446744071562067969 must be
On Wed, Feb 1, 2023 at 11:56 AM Adriaan van Os via fpc-devel
wrote:
> That is wrong. It should read
>
> "A const parameter is be passed by reference or (for small-sized parameters)
> by value, whatever is
> most efficient. A constref parameter is guaranteed to be passed by reference
> in all
Hi,
I have a function that has a parameter to a datastructure with some
arrays with records is it.
This function needs to return a pointer to a specific record inside
that structure.
The function is not supposed to alter the contents of this datastructure.
So, I need to pass this structure by
On Fri, Jan 13, 2023 at 1:16 PM Michael Van Canneyt
wrote:
> > Should I report this as a bug?
>
> Yes.
Done.
https://gitlab.com/freepascal.org/fpc/source/-/issues/40108
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Consider the follwoing program:
===
program test;
uses
Version;
begin
{$if TheVersion >= 1}
writeln('Version 1 or higher');
{$else}
writeln('Version < 1');
{$endif}
end.
===
unit version;
interface
const
TheVersion = 1;
implementation
end.
===
Compile with -vh
You get the hint:
On Fri, Jan 13, 2023 at 11:13 AM wkitty42--- via fpc-devel
wrote:
>
> > First of all, adding a 'end;" for the "with" compiles under Linux.
> > That's because widestring=unicodestring on Linux.
>
> i'm a little surprised there is no "mismatched begin/end" error with the caret
> pointing to the
rted as issue #40106
On Thu, Jan 12, 2023 at 9:39 PM Sven Barth wrote:
>
> Am 11.01.2023 um 23:58 schrieb Bart via fpc-devel:
> > Given the following program (an excerpt form a test program for a
> > bugreport about the fpwidestring unit):
> >
> > ===
Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):
===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}
uses
FpWideString;
var
WSource: WideString = 'source';
USource: UnicodeString = 'source';
WDest: WideString = '' ;
UDest:
Hi,
In #989895c8 I introduced a check for NaN in the IntFloatToTextFmt function.
This check is performed on the untyped parameter Value, typecasted to
Extended (or possibly Currency) (variable E).
As it turns out this only evaluated to True if Value actually is an Extended.
If you would call the
Hi,
When in Lazarus I set a property of type Double to -Inf or +Inf, I get
a compilation error:
Error: Invalid property value (at 41,17, stream offset 031A)
sp.lpr(20,1) Error: Error while compiling resources -> Compile with
-vd for more details. Check for duplicates.
(Compiling with -vd
On Sun, Sep 18, 2022 at 3:27 PM Martin Frb via fpc-devel
wrote:
> And if the base class has
> function SameValue(AValue1, AValue2: T): Boolean; virtual; // but
> not abstract
>
> Which implements the old call, without typecast?
I think Werner already tried that and it faile on type
On Sun, Sep 18, 2022 at 3:09 PM Werner Pamler via fpc-devel
wrote:
> > Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1.
> Sorry if I was not precise here: I only tested with fpc 3.2.0.
I misread, my mistake.
Q1: these ifdef-ed code: does it have to be in the
On Sun, Sep 18, 2022 at 2:29 PM Bart wrote:
> > Just enable fpc_math_samevalue_bug
> >
> > {$if FPC_FullVersion=30202}{$ifdef Win64}
> >{$define fpc_math_samevalue_bug}
> > {$endif}{$endif}
OMG.
I only found out right now that this define is already there.
Oh, and on Linux my fpc was still
On Sun, Sep 18, 2022 at 1:34 PM Martin Frb via fpc-devel
wrote:
> Just enable fpc_math_samevalue_bug
>
> {$if FPC_FullVersion=30202}{$ifdef Win64}
>{$define fpc_math_samevalue_bug}
> {$endif}{$endif}
This suggest that the bug is in Windows 3.2.2
> Make it
> {$if FPC_FullVersion<=30202}
>
On Sun, Sep 18, 2022 at 1:17 PM Maxim Ganetsky via fpc-devel
wrote:
> As far as I see from CI build log, FPC 3.2.0 is the culprit. FPC 3.2.2
> compiles your code fine both on Linux and Windows.
Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1.
--
Bart
Hi,
The following program will compile for Windows 32 and 64 bit.
It fails to compile for Linix 64 bit (and if I understand correctly,
also for MacOS 64 bit).
=== begin code ===
program test;
{$mode objfpc}
{$H+}
{$ifdef FPC_HAS_TYPE_EXTENDED}
function SameValue(const A, B: Extended):
Hi,
The RegisterConversionType() function has an overload with two
paramters of type TConversionProc.
It is used for conversions that have different offsets on their
respective scales (like temperature).
If used like:
=== code ===
tuFahrenheit :=
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel
wrote:
> I doubt that there are mission critical convutils programs out there,
> given the fact that it took 10+ years to find out the temperature
> conversion didn't work :-)
>
> Usage is low, risk is small, I say, go ahead.
On Thu, Jun 9, 2022 at 1:53 PM Stefan Glienke via fpc-devel
wrote:
> I usually don't take 20 year old compilers as reference
That's all that I have.
I do Lazarus/Fpc as a hobby and am unwilling to spend lost of money on Delphi.
Also the latest "free" versions are way to bloated to have them on
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel
wrote:
> I doubt that there are mission critical convutils programs out there,
> given the fact that it took 10+ years to find out the temperature
> conversion didn't work :-)
I agree.
I only stubled upon this unit because I have
On Wed, Jun 8, 2022 at 3:55 PM Stefan Glienke via fpc-devel
wrote:
> Actually the behavior in Delphi depends on the $R switch.
D7:
{$R+}
ConvTypeToDescription(-1)=[$]
{$R-}
ConvTypeToDescription(-1)=[$]
Bart
--
Bart
___
fpc-devel
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
Actually it is documented to be of type Word:
https://docwiki.embarcadero.com/Libraries/Sydney/en/System.ConvUtils.TConvType.
I guess nobody needs more than
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
>
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
And as a consequence compilation in Delphi fails if a negative value
is supplied to a function that takes a TConvType as a parameter, but
also code like this
And another observation: on Delphi 7 TConvType seems to be unsiged (in
fpc it's signed).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi,
I've been trying to improve the ConvUtils unit.
Now I've ran into a problem.
ConvTypeToFamily returns CIllegalConvFamily (=0) if AType is not registered.
This however is a problem. If AType is a type registered in the first
registered family, ConvTypeToFamily will also return 0.
This means
Fpc 3.3.1
===
D := ConvUtils.Convert(100.0, tuCelsius, tuKelvin);
write('100.0 Celsius --> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuCelsius);
writeln(D:12:4, ' Celsius');
D := ConvUtils.Convert(100.0, tuFahrenheit, tuKelvin);
write('100.0 Fahrenheit
Hi,
User Nimral in the wiki noted this:
If you specify ifoWriteStringBoolean in Options for TIniFile _and_ you
forget to assign values to BoolTrueStrings/BoolFalseStrings, then
writing and reading boolean values is not symmetrical.
Writing a boolean will write either 'true' or 'false', but
On Wed, Jan 12, 2022 at 1:38 PM Martin Frb via fpc-devel
wrote:
> As I said, I do not know, what is currently provided by the Fpc
> "combined 32-/64-bit download".
> No Idea, if any of the fpc/ppc executable in this download are already
> 64-bit.
It provides 32-bit fpc (so it builds for 32-bit
Hi,
There's been a hot debate in the bugtracker about fixing Val() for
signed variables.
There's a patch (in fact there are several), and an attempt to speed
Val() up significantly by having helper functions for each type of
input.
It looks like this is going to be fixed soon (and hopefully be
On Sat, Jan 1, 2022 at 1:21 PM Jonas Maebe via fpc-devel
wrote:
> > And the consequence is that even if we eventually have native 128-bit
> > integer support, the problem will persist but now for Int128?
>
> Yes, unless we would only support/use it for intermediate results.
Thanks for
On Thu, Dec 30, 2021 at 1:05 PM Jonas Maebe via fpc-devel
wrote:
> > Nor why it only triggers with Byte + Byte + Unsigned, and not with
>
> In you original mail, you said it triggered for Byte + Byte + Signed.
Yes, of course, the original mail is correct.
> It doesn't trigger for Byte +
From the forum discussion:
https://www.simplemachines.org/community/index.php?topic=580033.0
Could be related to the following fix
September 2021
---
! Fix handling 2x-encoded entities in
On Fri, Dec 31, 2021 at 8:49 AM Marc Weustink via fpc-devel
wrote:
Somebody on the forum said it happened before the server upgrade.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hi Marc,
> It took a bit longer than expected, but I'm happy to inform you that the
> Lazarus services are back online.
> For those interested in why it took longer, I'll explain at the end of
> the message.
Are you aware that there is a problem with the forum?
It will change any single quote
On Tue, Dec 28, 2021 at 9:38 PM Jonas Maebe via fpc-devel
wrote:
>
> https://gitlab.com/freepascal.org/fpc/source/-/issues/37875
OK, but from reading that it is still unclear to me wether this is a bug or not.
Nor why it only triggers with Byte + Byte + Unsigned, and not with
Byte + Unsigned.
On Mon, Jun 28, 2021 at 8:33 PM Bart wrote:
> Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with
> value < 0) will always give a range check error on X86_64 platform (if
> range checking is enabled).
Bump...
--
Bart
___
fpc-devel
On Tue, Dec 28, 2021 at 9:41 AM Marc Weustink via fpc-devel
wrote:
>
> To be continued...
Wow..
Hats off to you.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Fri, Dec 24, 2021 at 12:00 PM Adriaan van Os via fpc-devel
wrote:
> Neither would the compiler allow (I hope) the const parameter to be passed as
> a var parameter.
It does not:
{$mode objfpc}
{$h+}
procedure foo(var x: integer);
begin
end;
procedure bar(const y: integer);
begin
On Mon, Dec 20, 2021 at 12:07 PM Martin Frb via fpc-devel
wrote:
> https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4
> > Specifying a parameter as Constant is giving the compiler a hint that
> the contents of the parameter will not be changed by the called routine.
On Tue, Nov 30, 2021 at 7:53 PM Bart wrote:
> I think I also discussed this on the
> fpc-devel list, musty have been august this year, since around that
> time I created my "unlinkcommondll" utility as a workaround.
Indeed:
Building trunk of today fails on Windows: Error: Invalid DLL
On Tue, Nov 30, 2021 at 7:42 PM J. Gareth Moreton via fpc-devel
wrote:
>
> Yeah, that's the exact same file that I have problems with.
>
That file links to many more libs trhat I don't have, which does not
create a problem when building (it would of course not run).
It's just that you happen to
Hi,
Can somebody move
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39381 to
fpc please?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Sat, Sep 4, 2021 at 3:26 AM Gennady Agranov via fpc-devel
wrote:
IIRC then there were som bugs regarding optimization in win64.
You can try to compile with optimizations disabled: -O- (or use the
Lazarus dialog to do so).
--
Bart
___
fpc-devel
On Wed, Aug 25, 2021 at 11:11 AM Tomas Hajny via fpc-devel
wrote:
>
> > And, being curious: any idea why make clean failed when %PATH% was set
> > to just C:\fpc\3.2.2\bin\i386-win32 ?
>
> No idea - I just tested on a MS Win machine I have access to and 'make
> clean all' succeeded with PATH
On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel
wrote:
> Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there
> would be no problem. However a 64-bit DLL in the SysWOW64 directory
> (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in
>
On Mon, Aug 23, 2021 at 8:04 PM Bart wrote:
> And, of course, the guide on how to remove this utility
> (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
> do not apply.
> No XtuService in "Apps and Features", no XtuService.exe.
On Mon, Aug 23, 2021 at 8:15 PM Yuriy Sydorov via fpc-devel
wrote:
> On 64bit Windows system32 contains only 64 bit system files. syswow64
> contains only 32 bit files and is seen as system32 for 32 bit apps. For
> some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need
> to
On Mon, Aug 23, 2021 at 7:45 PM Bart wrote:
> Productname: Intel(R) Extreme Tuning Utility
And, of course, the guide on how to remove this utility
(https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
do not apply.
No XtuService in
Looking with Windows Explorer at the Common.dll in question:
Productname: Intel(R) Extreme Tuning Utility
File version 7.3.0.33
Product version 7.3.0.33
Modified: 24-02-2021 (that's dd-mm-)
In the tab "Previos Version" it says: no previous version.
This must have been installed in some
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote:
> I tried to build with only the path to the starting compiler in %PATH%:
>
> PATH /devel/fpc/3.2.2/bin/i386-Win32
> make clean
> make all OPT=...
>
> That failed on make clean:
That error goes away if I add C:\Windows to the path.
However, then I
On Mon, Aug 23, 2021 at 3:19 PM Bart wrote:
> Should I start the build process with a %PATH% that does NOT have
> C:\Windows\system32 in it?
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That failed on
On Mon, Aug 23, 2021 at 2:45 PM Michael Van Canneyt via fpc-devel
wrote:
> Use objdump, provided with FPC:
Thanks!
C:\devel\fpc\trunk>objdump -f \windows\SysWOW64\Common.dll
\windows\SysWOW64\Common.dll: file format pei-x86-64
architecture: i386:x86-64, flags 0x012f:
HAS_RELOC,
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
wrote:
> Just move common.dll from SysWOW64 to system32. The file is placed wrongly
> by some installer.
If I understand Tomas correctly then that would not make any
difference: wether or not that specific common.dll is in system2 or
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel
wrote:
> The problem is that MS Windows employs a special trickery by which the
> path to c:\windows\system32 (almost surely in your PATH) translates to
> c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that
> directory
On Mon, Aug 23, 2021 at 3:01 PM Tomas Hajny via fpc-devel
wrote:
> The compiler finds the DLL by looking to C:\Windows\system32. As
> mentioned in another e-mail, the fact that this request is redirected to
> C:\Windows\SysWOW64 instead by the underlying operating system is a MS
> Windows
On Mon, Aug 23, 2021 at 2:28 PM Tomas Hajny via fpc-devel
wrote:
> Does it exist in C:\Windows\SysWOW64\ on your machine?
Yes, there is a common.dll there.
I think that syswow64 is not in my %PATH%, but currently I'm at work
and cannot check.
I also do not know how to examine wether this one
On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel
wrote:
> > Does anybody have a common.dll in \windows\system32 at all?
>
> I don't have it, neither in system32 nor in SysWOW64.
OK.
> Just pulled the current revision of fpc-trunk, and did not observe this
> error (Win 10, fpc3.2.2
On Mon, Aug 23, 2021 at 12:23 PM Tomas Hajny via fpc-devel
wrote:
>
> Hi *,
>
> Not directly related at all, but while trying to have a look at the
> compiler code related to the error message about the DLL header size, I
> realized that there are quite a few error messages (including this one)
>
On Mon, Aug 23, 2021 at 10:49 AM Florian Klämpfl via fpc-devel
wrote:
> Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only
> 32 Bit DLLs.
I have no idea how to test this.
Mind you: a simple test program with {$linklib common} fails for me
for either 32 or 64, wether
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
I have now
On Sun, Aug 22, 2021 at 10:20 AM Bart wrote:
> So, this baffles me.
As does this:
C:\devel\fpc\trunk\packages\oracle>type README.txt
These units provides interface to Oracle Call Interface.
For the older 'oraoci' unit to compile you need oracle
server installed, these units was tested and
On Sun, Aug 22, 2021 at 1:51 PM wkitty42--- via fpc-devel
wrote:
> if that Common.dll file is only valid for 64bit windows builds, perhaps the
> better thing to do is to wrap the $linklib line in a check to see if you are
> building 64bit... if 64bit then loadlib otherwise, noop... seems logical
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
Tha cannot
Hi,
C:\devel\fpc\trunk>git log -1
commit a77f5221f341b32bb964c03dc61c1e80b71714dd (HEAD -> main,
origin/main, origin/HEAD)
Author: florian
Date: Sat Aug 21 20:36:29 2021 +0200
C:\devel\fpc\trunk>make clean
C:\devel\fpc\trunk>make all
...
[ 19%] Compiled package odbc
Start compiling
Hi,
Something like this:
Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with
value < 0) will always give a range check error on X86_64 platform (if
range checking is enabled).
From a mathematical POV, this can never give a range error, max value
would be 2147484157 (255 +255
Hi Marco,
You made a typo in the comment:
// extended colosr (from lazarus Graphics)
Should be
// extended colors (from lazarus Graphics)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hi,
Just installed 3.2.2RC1.
All OK.
Just one minor issue.
The installer asked me if it was OK to remove the path to 3.2.0 form
my systems %path%.
I agreed.
It then added the path to 3.2.2.
However, it did not do that in the place where the path to 3.2.0 was,
but added it as last.
So on my
On Wed, Mar 24, 2021 at 12:25 PM Marco van de Voort via fpc-devel
wrote:
> >> We have placed the first release candidate of the Free Pascal Compiler
> >> version 3.2.2 on our ftp servers.
I seem to mis the win32->wince crosscompiler at
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/i386-win32/
On Wed, Feb 24, 2021 at 1:42 PM J. Gareth Moreton via fpc-devel
wrote:
> The messages are marked as private.
They weren't in the past though.
The good news is that I don't have to get new glasses.
--
Bart
___
fpc-devel maillist -
On Wed, Feb 24, 2021 at 10:06 AM Bart wrote:
> I have downloaded that file (some time ago)
The download links seems to have gone from the bugreport?
(Or maybe I need new glasses)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, Feb 24, 2021 at 8:36 AM Michael Van Canneyt via fpc-devel
wrote:
> I am also using Mozilla Firefox.
So do I.
I have downloaded that file (some time ago) just to see if I could
simplify the problem.
I had no problems, it was just a zip file with enormous amounst of
code with a gazillion
On Sun, Jan 10, 2021 at 11:59 AM Sven Barth via fpc-devel
wrote:
> Displaying the message at the correct location would be more involved...
> you might want to open a bug report for that so that it's remembered
> somewhere, but it's definitely going to be a low priority one.
On Sat, Jan 9, 2021 at 12:00 PM Sven Barth via fpc-devel
wrote:
> Right click the error message in Lazarus, then click "Help". For me a dialog
> with the following text appeared:
Hah!
Learned something new today!
> The *why* is not important for users. Those that are interested can ask, just
On Fri, Jan 8, 2021 at 9:00 PM Sven Barth via fpc-devel
wrote:
>> It seems I cannot use a stand-alone function that is declared in the
>> implementation of the unit?
> Generics are a stream of tokens that is reparsed when specialized. Functions
> declared in the implementation section are
Hi,
While trying to solve https://bugs.freepascal.org/view.php?id=38306 I
got this error I have never seen before.
_gdeque.pp(249,4) Error: Global Generic template references static symtable
_gdeque.pp(302) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Line
I filed a bugreport: https://bugs.freepascal.org/view.php?id=38309
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Jan 4, 2021 at 11:00 PM Bart wrote:
> So, most likely this has nothing to do with generics?
> I'm using r47193 of fpc trunk
Try to compile attached program for Win64-bit with either 3.2.0 or trunk:
Free Pascal Compiler version 3.2.0 [2020/06/04] for x86_64
Copyright (c) 1993-2020 by
On Mon, Jan 4, 2021 at 5:13 PM Bart wrote:
>
> > What is strange to me is that the compilation issue does not happen with
> > the LazControls package alone, but only when ExCtrls package is added.
> > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)
64-bit Windows:
On Mon, Jan 4, 2021 at 12:57 PM Werner Pamler via fpc-devel
wrote:
> What is strange to me is that the compilation issue does not happen with
> the LazControls package alone, but only when ExCtrls package is added.
> Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)
1 - 100 of 163 matches
Mail list logo
