On 06/07/2025 16:17, Zoë Peterson via fpc-devel wrote:
I would personally call that unusual at best
What do you two expect this construct to do that you think the current behavior
is wrong? It’sobviously correct and expected to me as a fundamental part of
Object Pascal’s polymorphism. Const
I stumbled (by accident) on (maybe) a curiosity
TFooClass = class of TFoo;
can store a class (that must be TFoo or subclass of it).
I would have expected that the type TFooClass itself is not a class.
(Its a container for a class / for lack of better wording)
Yet
TFooClass.Create
compiles. An
On 17/06/2025 20:05, Michael Van Canneyt via fpc-devel wrote:
Thanks, merged.
Thanks.
Off topic, remember we talked about the TDictionary generic?
Any comments on
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/988
___
fpc-devel mai
On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote:
But then please do it so the comparison is done only once, i.e.
something like:
if aExpected=aValue then
Inc(AssertCount)
else
Fail(ComparisonMsg(aMessage, aExpected,aValue),CallerAddress);
https://gitlab.com/freepascal.org/f
On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote:
I have heaps and heaps of testcases, but I've never felt the need to
investigate
the speed of the Assert* calls.
I wasn't actually looking at it... I found it by random chance.
I was trying to kcachegrind some of my code, and the
I have/had several tests that took very long to run.
I have no figured out that between 50% and 80% of the time, went into
concatenating/formatting the message for "AssertEqual" (and related).
Yes, some of my tests now run in less than 20% of the original time.
That is
- Any concatenation my c
On 18/04/2025 15:23, Florian Klämpfl via fpc-devel wrote:
I checked, I can do "git log" on both files, and I get the full
history (for
oldheap.inc you need to add --follow to get it)
Is this not what you wanted ?
When I do git blame I get:
c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:4
On 13/04/2025 21:39, Michael Van Canneyt via fpc-devel wrote:
If keys could be accessed by index (the internal slot), the
TDictionary.IndexOfKey
and
TDictionary.Keys[idx]
That seems like a more 'conventional' solution to me.
I'll leave it up to you how to enhance TDictionary using either
so
On 15/04/2025 14:16, Martin Frb via fpc-devel wrote:
Quick question
When re-using known hash in rehash
https://gitlab.com/martin_frb/fpc-src/-/commit/9b398efb33897b3b5e98678033ddaafd1bcea883
Rehash is (mostly?) used for resize.
But an inherited class could change the hash algorithm and
Quick question
When re-using known hash in rehash
https://gitlab.com/martin_frb/fpc-src/-/commit/9b398efb33897b3b5e98678033ddaafd1bcea883
Rehash is (mostly?) used for resize.
But an inherited class could change the hash algorithm and call it.
So there need to be a way to force new hashes.
1)
On 13/04/2025 21:37, Michael Van Canneyt via fpc-devel wrote:
On Sun, 13 Apr 2025, Martin Frb via fpc-devel wrote:
On 13/04/2025 20:43, Michael Van Canneyt via fpc-devel wrote:
But why don't you simply use a TList with your custom
comparer ?
You can then use List.BinarySearch(
When the mailer decides to sent
On 13/04/2025 21:17, Martin Frb wrote:
On 13/04/2025 20:43, Michael Van Canneyt via fpc-devel wrote:
But why don't you simply use a TList with your custom comparer ?
You can then use List.BinarySearch() and retrieve the existing TRange
at once?
Your solut
On 13/04/2025 20:43, Michael Van Canneyt via fpc-devel wrote:
But why don't you simply use a TList with your custom comparer ?
You can then use List.BinarySearch() and retrieve the existing TRange
at once?
Your solution seems quite hackish to me. So if you really need it in
TDictionary, make
On 13/04/2025 19:49, Michael Van Canneyt wrote:
On Sun, 13 Apr 2025, Martin Frb via fpc-devel wrote:
Just want to know if there is any interest? Or if I just gonna do
my own copy (somewhere in LazUtils)
The 1-4 are interesting so MR is welcome,
ok, I will work on that.
the 5 I don&#
Just want to know if there is any interest? Or if I just gonna do my
own copy (somewhere in LazUtils)
If its too busy right now, then just an ack, and a "maybe in 4/6/8/10?
weeks"... would be nice.
Thanks
On 05/04/2025 12:07, Martin Frb via fpc-devel wrote:
On 03/04/2025 13:
According to a comment in the Lazarus Highlighter code, there either is
or used to be a class section "automated" (just like public, private, ...)
I can't find many refs in the fpc source. The most helpful (if calling
it that) is from packages\fcl-passrc\tests\tcresolver.pas
This shows at leas
On 07/04/2025 08:01, Sven Barth via fpc-devel wrote:
Also it would be best to simply document as UTF8Copy working 1-based
because you can't detect from the callee-side whether it had been
enabled on the caller-side (especially if they're from different units).
Just an idea.
Maybe having 2
On 05/04/2025 13:27, Sven Barth via fpc-devel wrote:
This is called contra-variance and is in general not something that
programming languages support. See for example here:
https://stackoverflow.com/questions/2995926/why-is-there-no-parameter-contra-variance-for-overriding
Thanks.
I hadn't
On 03/04/2025 13:52, Martin Frb via fpc-devel wrote:
On 27/03/2025 12:28, Martin Frb wrote:
There are 2 features, I am missing.
I did a couple of experiments... Those are not finished code. They
only showcase the ideas, and only for the one OpenAddressingLp case
https://gitlab.com
See the below code. (tested 3.2.3 and 3.3.1)
Is this intentionally allowed?
Technically it should work. TSubTest.Test always returns something that
fits the inherited requirement.
program Project1;
type
TFoo = class end;
TBar = class(TFoo) end;
TTest = class
function Test: TFoo; v
On 03/04/2025 13:52, Martin Frb via fpc-devel wrote:
On 27/03/2025 12:28, Martin Frb wrote:
There are 2 features, I am missing.
4) GetOrAddMutable
Just an extension, like AddOrSetValue.
Having it as one call, avoids recalculating the hash/index.
Actually needs bool result, to indicate if
"class of" can use qualified identifiers. It works with "unit.classname".
But it can't be used on a class nested in another container?
(same if TFoo is advanced record)
Is that intentional?
program Project1;
type
TFoo = class
public type
TBar = class end;
end;
TFooClass = class of
On 27/03/2025 12:28, Martin Frb wrote:
There are 2 features, I am missing.
I did a couple of experiments... Those are not finished code. They only
showcase the ideas, and only for the one OpenAddressingLp case
https://gitlab.com/martin_frb/fpc-src/-/compare/main...rtl-gen-opt?from_project_id
On 27/03/2025 12:45, Martin Frb via fpc-devel wrote:
On 27/03/2025 12:33, Marco van de Voort via fpc-devel wrote:
Op 27-3-2025 om 12:28 schreef Martin Frb via fpc-devel:
which returns True, if Akey was found and therefore APtr points to
existing Data, while otherwise APtr points to the
On 27/03/2025 12:33, Marco van de Voort via fpc-devel wrote:
Op 27-3-2025 om 12:28 schreef Martin Frb via fpc-devel:
which returns True, if Akey was found and therefore APtr points to
existing Data, while otherwise APtr points to the empty slot, where
the data can be copied to.
Without a
There are 2 features, I am missing.
And I can't see a way to add them via subclassing, as the internal
FItems array is private, and neither TItem, nor TPair can be gotten by
the integer index into that array.
1) AddOrGetPointerToEmpty
This would actually just be to try and see if it gives any
It is possible to declare a type for a cdecl function like
type a=procedure cdecl;
But, not for "assembler" which makes sense, because its not a calling
convention. Same should likely be the case for NoStackframe.
But
program Project1;
type a=procedure {assembler} NoStackFrame ;
begin
end.
On 20/03/2025 22:38, Marco van de Voort via fpc-devel wrote:
Op 20-3-2025 om 20:46 schreef Martin Frb via fpc-devel:
So why does the compiler interpret NoStackFrame in the type
declaration, when it does not do that for other non-relevant
modifiers (like assembler)?
I think it is because
NoStackFrame ;
type a=procedure NoStackFrame assembler;
So why does the compiler interpret NoStackFrame in the type declaration,
when it does not do that for other non-relevant modifiers (like assembler)?
Just curious...
On 20/03/2025 20:23, Marco van de Voort via fpc-devel wrote:
Op 20-3-2
On 23/02/2025 20:42, Martin Frb wrote:
function Foo: ansistring;
var s: ansistring;
begin
SetLenght(s, 1); fillchar(@s[1], 1, ' ');
SetLenght(Result, 1); fillchar(@Result[1], 1, ' ');
end;
...
So in the original example above, if either string is having a large
content (poi
Ok, so we all (should?) know
function Foo: ansistring;
var s: ansistring;
begin
SetLenght(s, 1); fillchar(@s[1], 1, ' ');
SetLenght(Result, 1); fillchar(@Result[1], 1, ' ');
end;
This will give the "uninitialized" warnings, as SetLength takes a "var
param".
However, despit
On 23/02/2025 14:16, Jonas Maebe via fpc-devel wrote:
On 23/02/2025 14:14, Martin Frb via fpc-devel wrote:
Is it correct (i.e. by design) that the compiler emits some "may not
be initialized" warnings, only on certain optimization levels?
Yes. Those warnings depends on data flo
Is it correct (i.e. by design) that the compiler emits some "may not be
initialized" warnings, only on certain optimization levels?
The following is
- NOT given with -O1
- present with -O3
lazsyntextarea.pp(1325,54) Warning: Local variable "ViewedRange" does
not seem to be initialized
O1 is
On 09/02/2025 14:39, Bart via fpc-devel wrote:
Hi,
The Delphi compatible unit System.UITypes is getting out of sync with Lazarus.
The reason for this is twofold:
1. the faster release cycle of Lazarus
2. the fact that Lazarus supports more widgetsets, for which we also
need enumerations, and Del
-
Further 3.3.1
program Project1;
{$R-}
type TFoo =(a, b);
begin
writeln(ord(TFoo(1)));
writeln(ord(TFoo($)));
writes
1
-1
--
In that light my earlier mail "packed enum too small?" below...
Should that be reported as bug?
On 13/11/2024 16:50, Martin Frb via fpc-devel
The below gives a size of 1 byte => meaning that both values are the
same $FF
program Project1;
{$PackEnum 1}
type
Tfoo = (f1=-1, f2=255);
var
a,b: TFoo;
begin
writeln(SizeOf(TFoo));
a:= f1;
b:= f2;
b:= f2;
end.
Changing it to:
Tfoo = (f1=-129, f2=255);
gives a size of 2 byte
Following up some question on the forum:
https://forum.lazarus.freepascal.org/index.php/topic,69149.msg537855.html#msg537855
I wanted to confirm one of my assumptions.
If I start compiling a project (on any single file which could be
program or library or unit, and could use other units that ne
I have a problem with a cross compiler build...
I know there officially isn't a win-32 64bit to 32bit cross compiler. So
taking my chances here...
But afaik that is due to diff results between compile time and run time.
Not due to wrong range checks?
Anyway this works fine in 3.2.2 and 3.2.3
Google didn't deliver an answer...
If I do
specialize TDictionary
specialize T{Fast}HashMap
will it actually has the string content? Or is the string the address in
the string variable => and therefore 2 strings with the same text can be
different?
And if the latter, how do I get the f
I don't have much info, but maybe someone can look here.
It's about fpc 3.3.1, and my best guess is that the compiler enters an
endless loop.
There is a bit of a stacktrace,but not much possible unit loading
related.
https://forum.lazarus.freepascal.org/index.php/topic,69067.msg535575.htm
Is the below meant to be allowed?
It compiles, it also compiles if you have no default in the base, but a
default in the sub class.
type
TFoo = class
procedure Bar (const Item: String; AnObject: TObject = nil); virtual;
end;
TFoo2 = class(TFoo)
procedure Bar (const Item: String; A
On 18/10/2024 14:30, Michael Van Canneyt via fpc-devel wrote:
On Fri, 18 Oct 2024, Nikolay Nikolov via fpc-devel wrote:
On 10/18/24 12:10 AM, Martin Frb via fpc-devel wrote:
https://wiki.freepascal.org/Threadvar
If threads are used then a copy is made for each thread (including
the main
https://wiki.freepascal.org/Threadvar
If threads are used then a copy is made for each thread (including the
main thread). Note that the copy is made with the original value of
the variable, not with the value of the variable at the time the
thread is started.
But what is that original value
I just got an update on the Dwarf mailing list on how the property spec
my look.
I thought I forward it here, in order to get additional feedback.
My initial proposal can be found here:
https://dwarfstd.org/issues/240507.1.html
My reply is here:
https://lists.dwarfstd.org/pipermail/dwarf-disc
On 28/09/2024 10:56, Karoly Balogh via fpc-devel wrote:
Fromt the top of my head, I only know one example of a big endian system
which has an 80 bit extended type in hardware, and it's the Motorola 68000
family. Which actually stores exteded in a 96 bit format in memory, with a
gap. :) (See: Moto
On 28/09/2024 09:45, Martin Frb via fpc-devel wrote:
On 28/09/2024 09:34, Pierre Muller via fpc-devel wrote:
I think that the big endian version (see grep below)
would suffer if you would use packed
because the high field of size 2,
would put the low field of size 8 at offset 2,
which would
On 28/09/2024 09:34, Pierre Muller via fpc-devel wrote:
I think that the big endian version (see grep below)
would suffer if you would use packed
because the high field of size 2,
would put the low field of size 8 at offset 2,
which would trigger unaligned access to this field.
For the little en
Is there any indention in
floatx80 = record
case byte of
1: (low : qword;high : word);
// force the record to be aligned like a double
// else *_to_double will fail for cpus like sparc
// and avoid expensive unpacking/packing operations
2: (dummy : extended);
Sorry, seems the VM itself went bonkers. All fine after a reboot of the
guest system.
On 17/08/2024 18:27, Martin Frb via fpc-devel wrote:
On 17/08/2024 17:25, Martin Frb via fpc-devel wrote:
Ok, right now, not sure where to start.
I have a modified Lazarus source, that I am trying to build
On 17/08/2024 17:25, Martin Frb via fpc-devel wrote:
Ok, right now, not sure where to start.
I have a modified Lazarus source, that I am trying to build.
I tried with -va
it stopped a lot faster
90.461] (1) Unitsearch:
/home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux
Ok, right now, not sure where to start.
I have a modified Lazarus source, that I am trying to build.
Only, when FPC tries to compile it, it never returns. And freezes my
Fedora (in a Virtualbox).
It will eventually (after an hour or longer) be killed by the OS. Which
at least at one time repor
Other functions of TBasicActionLink have checks like
if FAction <> nil then
But "Update" does not. Is that intended?
Or shall I bug report it?
function TBasicActionLink.Update: Boolean;
begin
Result := FAction.Update;
end;
___
fpc-devel maillist
On 10/07/2024 23:55, Sven Barth via fpc-devel wrote:
The SoftFpu unit is only intended for use by the compiler. If you want
to use 80-bit floating point yourself you need to use ufloat80 and
sfpux80 (the later wraps the same include files as SoftFpu, but for
use by the user).
Thanks. Now
Any hints on using unit SoftFpu? (or any alternative)
I have an 80 bit float (from an external source) that needs to be
converted to double.
But if I do
uses softfpu, ufloatx80
then I get
Error: Multiple defined symbol "INT32_TO_FLOAT64"
and many more...
On 28/06/2024 09:44, Werner Pamler via fpc-devel wrote:
I having the same experience as Laz-dev: I see a report which looks
interesting, but cannot address it at the moment. Not sure whether I
really can fix the issue I do not assign it to myself at this moment.
And later, when I could have a c
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-May/002424.html
While reviewing
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002451.html
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002462.html
I got thinking, are the "stored" and "default" (default for st
On 06/06/2024 16:50, Martin Frb via fpc-devel wrote:
On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote:
To get finally forward with the 3.2.4 release, fixes will be frozen
by 9th June, so if there are some last second cherry picks needed,
now it’s time to speak up :)
Has the line info
On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote:
To get finally forward with the 3.2.4 release, fixes will be frozen by 9th
June, so if there are some last second cherry picks needed, now it’s time to
speak up :)
Has the line info field for Dwarf 4 been merged?
https://lists.freepasc
On 02/06/2024 21:06, J. Gareth Moreton via fpc-devel wrote:
I admit I'm not overly sure how to handle Thaddy sometimes:
"They fixed it in the wrong way. It is fixed in a way to solve a
single - rare - problem by an OP that seems to have more infuence than
me and the fixer(s) would not listen."
While not sure how 3.2.4 preparation are going, nor what is still
outstanding for merging, I just wanted to quickly check if the following
is know (and hopefully making the list)
https://forum.lazarus.freepascal.org/index.php/topic,67448.0.html
From what I can tell
- present in today's 3.2.3
-
On 23/05/2024 22:55, Florian Klämpfl via fpc-devel wrote:
On 23.05.24 14:51, Martin Frb via fpc-devel wrote:
If I am not missing any detail
Using -gw 4 it seems fpc writes the same header for line info as it
does for dwarf 3.
However, when the line info version is set to 4 (at least if
If I am not missing any detail
Using -gw 4 it seems fpc writes the same header for line info as it does
for dwarf 3.
However, when the line info version is set to 4 (at least if all units
are dwarf 4 / if some are dwarf 3 this may not be the case)
Dwarf 4 has a new field in the header,
Anyone any feedback, please?
Or, who would be knowledgeable, and might at least tell me when there
might be time, if too busy right now?
On 17/05/2024 13:49, Martin Frb wrote:
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
Looking at the time other proposals have taken, I think it is reasonable
to implement properties as custom extension now. And then later mak
The below fails to compile.
However "b" is a class var. The fact that it is reached via a normal
field, does not change that. The address/value of TBar.f.b can be known
without on instance of TBar required.
Mind, this is a theoretical question, I don't actually need it, just
came across the
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Maybe of interest?
The include file {$i ascdef.inc} is used from unit Windows with
{$calling stdcall}
in effect.
Most functions in it therefore don't have "stdcall". But some do. Is
that known/wanted/...?
Similar in some other includes.
___
fpc-deve
On 03/05/2024 14:17, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
Fr., 3. Mai 2024, 12:13:
In case it goes ahead, I am trying to thing of what would be
needed
Can anyone think of any feature for Pascal properties that is not
covered by the below?
A
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote:
---
I don't have background on the Apple properties.
It's not Apple, but Objective-C.
Does FPC create such Objective-C code / properties?
If yes, how does it decide on how to translate "property Foo..."?
__
In case it goes ahead, I am trying to thing of what would be needed
Can anyone think of any feature for Pascal properties that is not
covered by the below?
# Proposal to implement "properties" for Pascal
## Background
Pascal has a property construct, that allows a "variable like"
ident
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote:
---
I don't have background on the Apple properties.
It's not Apple, but Objective-C.
property goes from the member to the property strikes me as odd.
(first example of dwarf)
It indicates, that the property is only meant t
https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1
Objective C properties exist separately from class members. A
property can be
defined only by "setter" and "getter" selectors, and be calculated
anew on each
access. Or a property
On 27/04/2024 22:10, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 21:40, Martin Frb via fpc-devel wrote:
First, telling the asm to store ".l99 - .ldebuginfo" or telling the
asm to store 733 (having done the math already) will result in the
same dwarf info.
Of course this only
On 27/04/2024 20:29, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 17:18, Martin Frb via fpc-devel wrote:
One of the posts also brings up the idea of avoiding labels (in asm),
and keep track of locations by counting the bytes in the generated
dwarf as part of the compilers work (IMHO
On 27/04/2024 17:05, Martin Frb via fpc-devel wrote:
On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 13:45, Martin Frb via fpc-devel wrote:
Ok, I would like to start another attempt to support properties when
using fpdebug as debugger.
I would recommend asking guidance on
On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 13:45, Martin Frb via fpc-devel wrote:
Ok, I would like to start another attempt to support properties when
using fpdebug as debugger.
I would recommend asking guidance on the DWARF list (dwarf-discuss).
Maybe there are
Ok, I would like to start another attempt to support properties when
using fpdebug as debugger.
The idea is to add custom tags in the dwarf info. This can be done by a
new option -godwarfporperties
Though, it may be better to go with -godwarffpdbg / similar to -godwarfcpp
Making it fpdebug sp
On 04/04/2024 16:39, J. Gareth Moreton via fpc-devel wrote:
Essentially, an arithmetic overflow is happening. Since the largest
Int64 possible is 9,223,372,036,853,775,807, going one above that (the
result to abs(low(int64))) wraps back around to
-9,223,372,036,853,775,808.
Internally, you c
The below writes: -9223372036854775808
Shouldn't absolute return a positive number?
program Project1;
begin
writeln( abs(low(int64)) );
end.
Seems
writeln( abs(low(longint)) );
also returns negative...
___
fpc-devel maillist - fpc-devel@lists
On 20/03/2024 10:14, Michael Van Canneyt via fpc-devel wrote:
I just did the same for 55 platforms (cross-compile), on ubuntu. All
work without errors ?
Apologies, probably my fault. I export the sources from git before
build, but did not remove old files. Starting without any old files in
th
Older Ubuntu, trying to update (starting compiler is 3.2.2)
make clean
make all OPT=" -O-1 -gw3 "
make install INSTALL_PREFIX=/home/m/fpc/
Compiling ./fcl-web/src/fcm/fpfcmstrings.pp
Writing Resource String Table file: fpfcmstrings.rsj
Compiling ./fcl-web/src/jwt/fpjwarsa.pp
fpjwarsa.pp(21,35
On 19/03/2024 15:41, Mattias Gaertner via fpc-devel wrote:
On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote:
[...]
#7 944.7 fpmake.pp(228,5) Error: Identifier not found "T"
Ah, you are using fpc 3.3.1 to compile it.
Fixed.
But I get strange linker errors compiling webidl2pas:
(9015)
https://www.freepascal.org/docs-html/rtl/system/default.html
Default is a compiler intrinsic: it returns for every type T a default
value. In essence, this is a block of memory that is zeroed out. It
can be used to correctly initialize any type, and more importantly, a
managed type. It also wor
The code below (avail as download, wrongly reported at
https://gitlab.com/freepascal.org/fpc/source/-/issues/40634#note_1777253148
=> gen331_b.zip )
compiles in in 3.2.3, but not in 3.3.1
As for as I am concerned 3.3.1 is right. But should that change be
mentioned on the user changes
https://
https://www.freepascal.org/docs-html/ref/refse35.html
Strict Protected
Is the same as Protected, except that the members of a Protected
section are also accessible to other classes implemented in the
same unit. Strict protected members are only visible to descendent
classes, not
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40768
Are there any defaults, with which precision each float type
(single/double/extended) should be printed?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepasca
The below leads to debug info reporting TAlphaColor as Cardinal.
Maybe it could be changed (like TColor is a distinct type)?
unit System.UITypes;
Type
...
TAlphaColor = Cardinal;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://l
https://www.freepascal.org/docs-html/rtl/system/inc.html
- says it operates on pointers
- also gives examples for unsigned types such as word
But can it be used to increment a QWORD?
Inc(FAddress, (Opcode div FOwner.FLineInfo.LineRange) *
FOwner.FLineInfo.MinimumInstructionLength);
FAd
https://www.freepascal.org/docs-html/ref/refsu3.html
Is this list complete/correct?
1)
It lists bitpacked, but
program foo; var bitpacked: integer; begin end;
gives an error.
I thought modifiers can be used as var names?
2)
Is there, or has there once been?
(found in the synedit highligh
On 11/01/2024 17:30, Marco van de Voort via fpc-devel wrote:
Let me state it more clearly:
The point is that given a precompiled Linux RTL, to my best knowledge
you can't test any define outside the FPC build environment to see if
the RTL was compiled with FPC_USE_LIBC or not. Maybe there is
On 11/01/2024 16:34, Marco van de Voort via fpc-devel wrote:
Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:
- Can (on any linux/unix) "uses SysCall" be compiled (without error)
You can test that yourself on a Linux system by compiling a cycle with
-dFPC_USE_LIB
Is this page up to date?
https://www.freepascal.org/docs-html/prog/progap7.html
Maybe I am wrong, but looking at the tsysteminfo does the value in
extradefines specify values that will be defined during compilation
(such as those given on that page)?
If the do then "sunos" has
ext
fpc 3.2.3
The below prog prints 3 times: 11, -1 (signed values)
https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1
Free Pascal also supports the ByteBool, WordBool, LongBool and
QWordBool types. These are of type Byte, Word, Longint or Int64,
Besides the fact that a
Enums must be ascending. Otherwise a compiler note will be issued... Or not.
Below prog gives
project1.lpr(4,32) Note: Values in enumeration types have to be ascending
But if the values are cast first, then no warning.
The 2nd line will print 255, 0,-2 => which is not ascending.
program Projec
On 14/12/2023 21:33, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 21:27 schreef Martin Frb via fpc-devel:
I am actually pretty sure, on Linux, I can get what I want by doing
it in the "OnFork" event of TProcess.
But on Windows it is well hidden away in the "
On 14/12/2023 20:54, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 20:29 schreef Martin Frb via fpc-devel:
Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided
On 14/12/2023 18:13, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided).
It does, if you need a runcommandloop like routine
On 14/12/2023 18:06, Michael Van Canneyt via fpc-devel wrote:
Actually, I already started an implementation of an extension half a
year ago.
Is there an accessible branch for that? (maybe in a fork?)
___
fpc-devel maillist - fpc-devel@lists.fre
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided).
If it does, and I have been missing the "how to", then please enlighten
me and disregard the remainder of the mail.
The code for setting up redirection to pipes (to be read
On 09/12/2023 17:03, Martin Frb via fpc-devel wrote:
Anyway, I changed the make
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3 OPT="
-Clv16.0 " LLVM=1
Then next it fails, with the same error on
make clean
Yes, it tries to compile a file while doing "make
1 - 100 of 251 matches
Mail list logo
