What do you mean? like syntax styling? I use Sublime Merge as my git client
and it styles Pascal syntax.
Regards,
Ryan Joseph
On Feb 21, 2025 at 2:05:03 AM, Peter B via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Hi,
>
> I'm wondering if there is any diff tool out there,
> that c
Since I’m topic on inlines. FPC always inlines even with debug flags and
makes certain files impossible to break on. Is there a way to disable that?
I would expect inlining to be off so you can could debug. I don’t have -Si
on either which suggests it must be on to inline but I don’t see that
happe
On Jan 24, 2025 at 5:46:40 PM, Marco van de Voort via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Slightly different. LTO afaik requires multiple compiles where the later
> build uses info from the earlier build.
>
> The FPC implementation inlines if the unit-with-function-to-be-inline
On Jan 24, 2025 at 2:01:09 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> When a function has inlining enabled (either explicit with the inline
> directive or implicit through AutoInline optimization) then in addition to
> generating its code to the object file (for dir
On Jan 24, 2025 at 1:34:26 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Doesn't matter whether they're handled in the same scope or not. It's the
> same code. Usually they're not handled in the same scope, but in a very
> distant place. That's usually when except
On Jan 24, 2025 at 12:43:51 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> That's not what exceptions are meant to be used for, though. What you
> describe is called a program "defect". When you encounter a "defect" in
> your program, you terminate the program. The
On Jan 24, 2025 at 11:20:02 AM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> As you can see, it's more complicated and more error prone. You can
> simplify it a little bit with goto, but it will never be better, compared
> to try...finally
>
>
ok, I’ve never used exc
On Jan 24, 2025 at 8:38:25 AM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Maybe because there's a much better way to write it:
>
> procedure foo();
> var
> s1: TStringList = nil;
> s2: TStringList = nil;
> s3: TStringList = nil;
> begin
> try
> s1:=TStr
On Jan 24, 2025 at 2:10:53 AM, Santi via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> procedure foo()
> var
> s1: TStringList;
> s2: TStringList;
> s3: TStringList;
> begin
> s1:=TStringList.create;
> try
>s2:=TStringList.create;
>try
> s3:=TStringList.create;
> t
Is the compiler actually able to inline functions which are used from a
unit? When a unit is used it’s compiled to a .o file and linked so the
compiler doesn’t have access to the source code anymore and thus can’t
inline I would think.
I write this because I’ve recently learned of link-time optimi
Here’s what ChatGPT says. It just used the UNIX sockets API so nothing
different from what you’d see in C. Looks pretty much correct to me but I
didn’t try to build it.
program TCPClient;
uses
SysUtils, Sockets;
const
HOST = '127.0.0.1';
PORT = 12345;
var
ClientSocket: LongInt;
Addres
On Jan 11, 2025 at 10:53:36 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Set are a minimum of 4 Byte by default cause that's how Delphi does them.
> Ifets you want smaller sets then use the $PackSets directive as Martin had
> written.
>
I did not know this existed. I
On Jan 11, 2025 at 8:17:33 PM, Hairy Pixels wrote:
> I was curious, is there any practical limit on the size of a set (32 bits
> and 256 values) and why they couldn’t be 64 bit or any other arbitrary
> size? The floor seems to be 4 bytes too but why not allow smaller sizes to
> save memory? Perh
I was curious, is there any practical limit on the size of a set (32 bits
and 256 values) and why they couldn’t be 64 bit or any other arbitrary
size? The floor seems to be 4 bytes too but why not allow smaller sizes to
save memory? Perhaps just a historical artifact but I was curious.
Regards,
On Jan 5, 2025 at 6:45:49 PM, Tomas Hajny wrote:
> As you might have noticed, it's simply a more general solution allowing
> to cover all target platforms supporting dynamic libraries in a more or
> less equal way.
Yeah if DLLs have their own namepace and $LINKLIB doesn’t propagate to all
exte
On Jan 5, 2025 at 4:43:39 PM, Jonas Maebe via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> That said, Darwin also uses two-level namespaces:
>
> https://blog.darlinghq.org/2018/07/mach-o-linking-and-loading-tricks.html#two-level-symbol-namespace
> . However, it does not do this through
On Jan 5, 2025 at 11:53:36 AM, Adriaan van Os via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> This is a habit from the WIndows and Delphi world. In a one-levell
> namespace on MacOS, the dll name
> is superflouous. Note that ObjC symbols are always global ,which implies a
> one-level n
I see this pattern in C translated header often but I’ve honestly never
understood it entirely.
Why does this “cDllName" need to be added to every single function which
you could just use {$linklib }?
Furthermore, I’m not even aware that it’s possible to tell the linker that
you want to searc
On Dec 15, 2024 at 11:19:40 PM, Sven Barth
wrote:
> It's not as if it is impossible to workaround this limitation:
>
> === code begin ===
>
> program tpointerrec;
>
> {$mode objfpc}
> {$modeswitch advancedrecords}
>
> type
> generic TPointer = record
> type
> PT = ^T;
> end;
>
> gene
On Dec 15, 2024 at 6:28:25 PM, Hairy Pixels wrote:
> Also noteworthy is ISO standard can accommodate generics which Borland’s
> design can not.
Wait, I’m wrong on this, you can use generic proc types. The problem with
generics are pointers to T. For example that below is not possible.
type
On Dec 15, 2024 at 5:15:33 PM, Jonas Maebe via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> It's because unlike in Borland Pascal, procvars in ISO Pascal captured
> the stack frame and allowed you to access local variables of the caller.
> By only allowing the declaration in the procedu
On Dec 15, 2024 at 12:21:29 PM, Adriaan van Os via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> You mean the original pascal only allowed function declarations to be
> parameter types?
>
> Yes. And it is still true in the ISO 7185 Pascal standard.
>
That doesn’t make any more sense tha
On Dec 15, 2024 at 1:22:25 AM, Adriaan van Os via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Similarly, you also cannot write:
> function A(B : (one,two,three)) : double;
>
> Not really. The function type declaration is a Borland invention, not
> original Pascal.
>
> Regards,
>
> Adri
On Dec 5, 2024 at 12:27:37 AM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Yes, this is still on my todo list. The main problem is to have a really
> minimal example that demonstrates the issue. (and with minimal I mean
> something that doesn't require half the
On Dec 4, 2024 at 8:13:08 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> The likely candidate is the reworked module loading that still has its
> problems.
>
> @Michael: do you think you can take a look? I also got the feeling that it
> tries to compile more while nothi
On Dec 4, 2024 at 6:29:36 PM, Hairy Pixels wrote:
> My only thought is that my project makes extensive use of multi helpers
> and implicit function specialization both of which were causing serious
> crashes in the compiler (I think they were the cause at least). I’m talking
> you change a top
On Dec 4, 2024 at 6:29:36 PM, Hairy Pixels wrote:
> I’m going to have to rollback and use my old version because it’s not
> usable like. Event going to 4 second build times if you change a single
> line is too painful.
>
and I just tried to rollback and the compiler crashes now on a particular
On Dec 4, 2024 at 6:22:12 PM, James Richters via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I don’t know what causes this, but I have experienced the same issue.
> Just loading the IDE takes like 30 seconds on a version I installed in 2023
> and another in early 2024, and those also c
I just noticed I didn’t update my compiler since 2023/03/03 and finally did
so today. After making some required changes I noticed the compile times
went down from basically instant (after being fully built once) to taking
4+ seconds every build.
Looking at the output it looks to me like it’s not
On Dec 1, 2024 at 2:02:06 PM, Adriaan van Os via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> They call that "Unicode", which is plain nonsense. In the real world, one
> can not stuff 21-bits
> into 16-bits.
>
> For heaven's sake, let's stop talking about so-called "Unicode" and
> inste
On Dec 1, 2024 at 2:23:08 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Here's how Free Pascal types map to Unicode terminology:
>
> WideChar = UTF-16 code unit
>
> UnicodeString = UTF-16 encoded string
>
> WideString = UTF-16 encoded string. On Windows it's not r
ChatGPT is saying I can print unicode scalars like that but i don’t see it
works and no compiler warnings even. Did it make this up or did I do
something wrong?
Writeln('Unicode scalar 1F496: ', #$1F496); // 💖
Writeln('Unicode scalar 1F496: ', WideChar($1F496)); // 💖
Regards,
Ryan Josep
On Nov 30, 2024 at 11:54:21 PM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> sorry but it’s not really part of the compiler, just something that
> generates commands it feeds to the compile right?. aren’t new compilers
> doing away with this design and integratin
On Nov 30, 2024 at 3:11:10 PM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> This is very much on topic. FPC has no build system
>
> Huh ? Of course it does, it has 2. fpcmake (older) and fpmake.
>
> Please don't spread incorrect information.
>
sorry but it’s not
On Nov 29, 2024 at 8:11:11 AM, James Richters via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I'm intrigued by FPGUI, I'm trying to build FPGUI on Windows 10, and I'm
> having some difficulty. When I follow the instructions from Install.txt I
> get this:
>
This is very much on topic.
On Nov 24, 2024 at 4:21:21 PM, Michael Van Canneyt
wrote:
> Great work. This is exactly the kind of thing I was talking about. FPC team
> should take notice.
>
> We do. Well, I did :).
Request to Iwan, he have some new changes for “extended RTTI” like Delphi
has and it would be nice to have an
On Nov 24, 2024 at 4:12:03 AM, Iwan Kelaiah via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Hello,
>
> I'm not sure, but I am working on this one:
> https://ikelaiah.github.io/free-pascal-cookbook/, and it mentions how to
> install FPC and use FPC for common tasks for newcomers.
>
Gre
On Nov 17, 2024 at 7:57:07 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> - how about allowing the same AS in unit declarations so we can do
> something like [unit MyUnitWithABigName AS MyUnit] and then use
> [MyUnit.TSomeClass] — this can already be done with MACROS, s
On Nov 16, 2024 at 9:46:25 PM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> You never heard of Delphi, ElevateWeb, Smart Mobile Studio, PascalScript,
> OxyGene ?
> There are some others, can't recall the name. There is a Russian version,
> called abcpascal or som
On Nov 16, 2024 at 7:24:01 PM, Michael Van Canneyt
wrote:
> That said, the Free Pascal website is not about the pascal language.
>
> It is about the compiler. The GNU compiler or LLVM C compiler also do not
> contain code on their website. Not that I would recommend their sites, but
> these tool
On Nov 16, 2024 at 3:13:26 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> If you know nothing about the language, the main page explains to you
> quickly what's the point of the language, and gives you example code, so
> you can immediately see how it looks like. T
On Nov 15, 2024 at 9:23:41 PM, Steve Litt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> First of all, Joanna on #fpc (and other fpc related IRC channels) has
> blown off over 100 potential fpc users, including myself. I'm learning
> Ada now, and liking it a lot.
>
what authority doe
On Nov 14, 2024 at 8:11:53 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Because it wasn't deemed necessary that the compiler itself provides this
> operator.
>
You can use it to create ordinal types from bytes using a generic. I was
trying to do something like this.
On Nov 14, 2024 at 1:53:17 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> The **-operator is not *implemented* by the compiler. It's provided
> through the Math unit. Thus you can't use it in constant declarations.
>
Why is that? That means you can do powers in types o
This gives me "Error in type definition”. A bug?
type
TMyRec = record
type
T = 0..256**4;
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-p
I diagnosed a threading performance problem down to merely calling GetMem.
I did a test and it was 4x slower to call GetMem on 8 threads (my computer
core count) than one thread. Due the large amount of allocations in the
program it was actually slower to multithread the task.
I assume the problem
On Oct 21, 2024 at 7:54:22 AM, Bernd Oppolzer via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> 3. Standard Pascal has only pointers, which point to the heap and are
> created by the NEW procedure.
> I am the maintainer of another Pascal dialect (Stanford Pascal) - and,
> like many other
On Oct 19, 2024 at 9:37:49 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Counterexample 1: The growth of Rust.
>
which is the opposite of Pascal, total memory safety. Rust is one of the
reasons that show people don’t want bug prone manual memory management
anymor
On Oct 19, 2024 at 9:15:10 PM, Rainer Stratmann via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I really can not see where beginners have to struggle with memory
> management.
> If a project gets bigger you have to think about it, yes. It depends on the
> coding style. In my project I
On Oct 19, 2024 at 8:06:56 PM, Rainer Stratmann via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Sorry, but if you start then you start with a simple program and then you
> have
> to gain experience over time. That is the same case everywhere.
>
> There is a german sayword "Es ist noch
On Oct 19, 2024 at 8:06:44 PM, Martin Frb via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> NOTE: the below is NOT about ARC. It is about the implication that ARC ==
> Safety (in the environment that we have)
>
Not following "in the environment that we have”. I’m just saying manual
memo
On Oct 19, 2024 at 8:10:02 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> For a class one can override NewInstance and FreeInstance. And with
> TVirtualMethodInterceptor (I think not yet implemented in FPC) it might
> even be possible to replace these on an existing cla
On Oct 19, 2024 at 7:53:14 PM, Rainer Stratmann via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I feel very safe with freepascal. I don't know what you are talking about.
> It depends on the programmer who is in front of the computer.
>
We’re talking about new users and programmers th
On Oct 19, 2024 at 7:37:15 PM, Martin Frb via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Because if the latter, well I know some people who would shot the person
> introducing that in a high performance software...
>
yes it’s bad except for UI apps which is what FPC and new users see
On Oct 19, 2024 at 7:24:15 PM, Martin Frb via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Who is forcing *everyone* ?
>
> To the day, that person has not knocked on my door. Am I the last free
> (not forced) person on the planet?
>
I mean if there are two version of the RTL to be main
On Oct 19, 2024 at 3:35:25 PM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> You are not taking the reasoning to its logical conclusion.
>
> These "new users" will want to have some standard library - the RTL and
> packages.
>
> So the whole rtl/packages needs to
On Oct 19, 2024 at 4:26:51 PM, Martin Frb via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Which IMHO, means another (potentially drastic) downside.
>
> If it would be possible and would be done, you end up with 2
> incompatible products. That would mean you split the community into 2
>
On Oct 19, 2024 at 2:31:36 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> This would mean that a new class type or some kind of additional attribute
> would have to be introduced which would have to be incompatible to
> non-reference-counted classes as otherwise there w
On Oct 18, 2024 at 3:41:49 PM, Karoly Balogh via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Maybe it was mentioned in the thread, I just glanced through it, but how
> about ARC (Automatic Reference Counting), Objective C style? To be honest,
> I really liked that, and we already have
On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> Prease DON'T add garbage collector. IMO it isn't a good idea. I had
> very bad experiences with it. Unless somebody found a new magic
> algorithm in the last decade...
>
I used
On Oct 17, 2024 at 4:12:08 AM, Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I have proposed this to the FPC core team, after some insistance I managed
> to get a list of constraints from (if memory serves well?) 1 person.
>
> I admit I was put off by what I perce
On Oct 16, 2024 at 9:46:05 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I don't know, it could be the Nim to JS compiler, or the fact that the
> previous plugin developer didn't use the LSP protocol, but direct
> integration instead. But I don't like the whole id
On Oct 16, 2024 at 9:18:01 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I also have some experience from my day job on making a VS Code extension
> for the Nim language (you can see my commits in the Nim language server
> here https://github.com/nim-lang/langserv
On Oct 16, 2024 at 9:08:13 PM, Stefan-Iulian Alecu via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I'll revisit your extensions and give pascal-language-server yet another
> shot, but I am not too confident. If I can make it work within a CI/CD
> context, I'll send a PR. This would imp
Another point is that FPC doesn’t have an official forum except for the
mail list and that in and of itself is a problem if you ask me. Most young
people don’t use email and won’t like this. I myself don’t prefer the mail
list over some of the very nice forums that allow posting code and very
easy
On Oct 16, 2024 at 8:50:21 PM, Ștefan-Iulian Alecu via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> I don't blame someone coming at me and thinking Pascal's
> old, when we're clinging on to Lazarus with *everything*. It is a bit
> sad if you think about it: we're putting Lazarus on a pe
On Oct 16, 2024 at 8:50:21 PM, Ștefan-Iulian Alecu via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> 4. a proper VSCode extension (we can include Vim and Emacs there too,
> but the main focus is VSCode) with all the bells and whistles more
> established extensions have. I know we would a
On Oct 16, 2024 at 4:44:35 PM, Nikolay Nikolov via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> On 10/16/24 6:00 AM, Hairy Pixels via fpc-pascal wrote:
>
> FPC is not keeping up with trends in the industry which new programmings
> want despite all the older progra
FPC is not keeping up with trends in the industry which new programmings
want despite all the older programmers who are settled in their ways. Even
if there is a market for Lazarus type apps people in 2024 don’t want to use
a massive legacy IDE and prefer better tools like VSCode.
If you want to u
the heap trace must be reading the dwarf info then I guess, which makes sense.
> On Jul 1, 2024, at 4:12 PM, Sven Barth via fpc-pascal
> wrote:
>
> Hairy Pixels via fpc-pascal schrieb am Mo.,
> 1. Juli 2024, 03:49:
> oh it uses external debug symbols! Now it's
to add -Xg, or ‘Use external debug symbols file’ in Laxarus
>
>
> Van: fpc-pascal namens Hairy Pixels
> via fpc-pascal
> Verzonden: vrijdag, juni 28, 2024 5:37 PM
> Aan: FPC-Pascal users discussions
> CC: Hairy Pixels
> Onderwerp: [fpc-pascal] Heap trace on mac still not
> On Jun 29, 2024, at 5:43 PM, Adriaan van Os wrote:
>
> Hairy Pixels via fpc-pascal wrote:
>> I had a large function which I was profiling with MilliSecondsBetween but I
>> split it to be called many different times and now it's not accumulating the
>> tota
> On Jun 28, 2024, at 10:44 PM, Christo Crause wrote:
>
> It is based on TComponent from the RTL classes unit, so no dependency on LCL
> or other Lazarus units. A quick check of the source code suggests that it
> will probably call GetTickCount64
> (https://github.com/graemeg/epiktimer/blob
One more thing that's getting to me today. Heap trace on macOS still seems to
be broken, i.e. using -gh I only get addresses and no line numbers. Has been
for years it feels like. Is this is just broken forever? I see this issue from
years ago still open.
https://gitlab.com/freepascal.org/fpc/s
i, Jun 28, 2024 at 2:34 PM Hairy Pixels via fpc-pascal
> wrote:
> I had a large function which I was profiling with MilliSecondsBetween but I
> split it to be called many different times and now it's not accumulating the
> total time correctly because time is being lost to due
I had a large function which I was profiling with MilliSecondsBetween but I
split it to be called many different times and now it's not accumulating the
total time correctly because time is being lost to due millisecond precision.
Is there anything in the RTL I can use which is more accurate? I
oh, it's writeln which is doing the runtime check, thanks. Doing math on enums
is probably not a smart idea though. I wonder why a subscript like [] was never
added to enums. It would be nice to do:
f := Fruit[banana.index + 1];
instead of dealing with raw values. A runtime check for creating e
This program below crashes because the value 12 is not in the enum. I was
curious though, how does it know this? Does it have to do a linear search
through the enum to find the value? I know "succ" fails at compile time because
the enum has assignments but how this works at runtime is another qu
his implies to me it will be done by
Object somewhere higher up in the chain. It should read:
"If memory was allocated it must be initialized by a call to InitInstance"
> On Jun 4, 2024, at 7:06 PM, Sven Barth via fpc-pascal
> wrote:
>
> Hairy Pixels via fpc-pascal s
In the manual it at https://www.freepascal.org/docs-html/ref/refse38.html it
says "Calling the constructor will provoke a call to the virtual class method
NewInstance, which, in its default implementation, calls GetMem, to allocate
enough space to hold the class instance data, and then zeroes ou
> On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Of course there must be, that's the whole point of copy-on-write.
>
> As soon as one reference is changed, a copy is made if the reference count
> is larget than 1, and this copy is changed.
Oh, it does copy on wr
> On Mar 18, 2024, at 3:27 PM, Hairy Pixels wrote:
>
> Oh, it's a pointer to a pointer? I guess that explains how it can resize
> itself and not invalidate shared references, if those are even possible with
> AnsiString.
Wait, that's totally wrong. :) @s is the address of the local variable
> On Mar 18, 2024, at 1:52 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> An ansistring is a pointer to a memory block.
>
> You are printing the address of S1 and the address of S, i.e. the address of
> the pointer itself, not the address of what S (or s1) points to. Obviously
> the add
Curious, why did the address of "s" change here? Shouldn't the AnsiString be
incrementing a reference count and not actually changing the actual pointer or
copying?
Correct me if I'm wrong, AnsiString is ref counted when passing in/out
functions but copies on assignment so technically no two A
I don't think this has anything to do with the compiler. You should probably
ask on the SDL forums. They've been helpful for me before.
> On Jan 30, 2024, at 6:45 PM, Rafael Picanço via fpc-pascal
> wrote:
>
> Hi everyone, how are you doing?
>
> I am receiving an "FLT divide by zero" error wh
> On Jan 18, 2024, at 1:51 PM, Sven Barth via fpc-pascal
> wrote:
>
> There is no source for Str() in that sense, because Str() is a compiler
> intrinsic implemented in the compiler's ninl.pas.
>
Well that explains everything now! What is this an intrinsic? I was curious how
it was impleme
> On Jan 17, 2024, at 10:15 PM, Marco van de Voort via fpc-pascal
> wrote:
>
>
> Op 17-1-2024 om 15:57 schreef Hairy Pixels via fpc-pascal:
>> Can anyone show me where to find the IntToStr implementation in SysUtils?
>> There's so many level of indirection an
Can anyone show me where to find the IntToStr implementation in SysUtils?
There's so many level of indirection and macros I have no idea where to look
for it!
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
htt
I just noticed it's possible to do @Byte in FPC. Are these 2 lines even
different? It doesn't exactly make sense to take the address of a type
identifier so I'm curious what this may mean.
var
b: Byte;
p: PByte;
begin
p := @Byte(b);
p := PByte(@b);
Regards,
Ryan Joseph
__
Do sealed classes actually call virtual methods statically or are they just for
compiler warnings?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> On Jan 1, 2024, at 3:50 PM, Michael Van Canneyt
> wrote:
>
> You can't optimize that. As said, a generic is convenient but slow.
I don't know about that. Like was mentioned the enumerator needs to return a
pointer, preferable without ^ so it feels like a record and only use that in
the fo
> On Dec 30, 2023, at 3:18 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> And try to avoid "for r in data" because it will create a copy for each
> element
> in the list.
This seems more like bad compiler design than anything. From the users
perspective a for loop is a read-only operat
> On Dec 21, 2023, at 12:06 PM, Hairy Pixels wrote:
>
> Here's another example of this. If I use an array Finalize is called 4 times
> but Initialize is never called, unless you assign a record to the array and
> then it's called once.
>
> This makes even less sense. What's the idea behind
> On Dec 21, 2023, at 6:11 AM, Hairy Pixels wrote:
>
> Maybe I misunderstood but I thought they were supposed to be balanced with
> init calls. Is it the design of the compiler to allow multiple finalize calls
> and have the user keep track of it the underlying structure is really
> finalize
> On Dec 21, 2023, at 1:53 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> If you look at the generated code, you see that there is an implicit
> try/finally block
> and the finally block does a finalize.
Maybe I misunderstood but I thought they were supposed to be balanced with init
c
I feel like this was addressed but I couldn't find any references. The program
below prints the following:
Initialize
Create
Finalize
Finalize
Why is Finalize called twice? I thought those were supposed to be called in
pairs with initialize?
==
{$mode objfpc}
{$modeswi
> On Dec 15, 2023, at 8:56 PM, Adriaan van Os via fpc-pascal
> wrote:
>
> What complicates things, is that many conflicting rules have the same name in
> the Language Reference. For example, conceptually we have object-methods,
> record-methods, class-methods, interface-methods and objcclass
> On Nov 8, 2023, at 1:50 PM, Sven Barth via fpc-pascal
> wrote:
>
> Please provide example code so that one can look at it. Such messages without
> example are more often than not simply useless.
>
So this ended up being because I didn't enable the "nestedprocvars" mode switch
and you ge
What does this error mean? It's comparing a pointer to a procedure to a
procedure variable (a callback). The signature appears exactly the same
"function(TSymbol;TSymbol):LongInt is nested" so what's the problem?
error: Incompatible type for arg no. 2: Got "", expected
"TSList$1$crcCC4DE170_crc
> On Nov 4, 2023, at 4:22 PM, Sven Barth wrote:
>
> Then don't assign them every "frame". If you just keep them around then they
> aren't more expensive than a virtual method call.
> And any other mechanism would involve the heap as well, because that's how
> anonymous functions that capture
1 - 100 of 318 matches
Mail list logo