Re: [fpc-devel] Unicode RTL
Hi, A "unicode" RTL is of course great for targeting legacy Windows platforms, but for those of us on Linux, UTF-8 is the way. To this end, it would be helpful to add a paragraph on the wiki page underlining how to retain the single-byte RTL; or, if no user action is necessary, mention that, to set minds at ease. Thank you for this hard work! ~Kirinn On Mon, 24 Jul 2023 21:49:39 +0200 (CEST) Michael Van Canneyt via fpc-devel wrote: > Hello, > > I have just completed phase one of the "Unicode RTL" effort. > > The 'Unicode RTL' is an effort to be more Delphi compatible: > - Char = Unicode Char and String = UnicodeString > - Provide dotted filenames. > Basically closer to the RTL as it exists in more recent versions of Delphi > (essentially post - Delphi 2009) > > This RTL will co-exist with the current RTL (single-byte char, no dotted > names), but will share the same codebase. > > More explanations can be found here: > > https://wiki.freepascal.org/FPC_Unicode_RTL > > This coexistence of 2 RTLs is accomplished with 'Subtarget support'. > > Subtarget support is a means to consistently apply a set of Free Pascal > compiler settings to everything that you compile. > > Subtarget support is explained in more detail here: > https://wiki.freepascal.org/FPC_Subtarget_Support > > While it is now used to create a unicode rtl, it could also be used to > > * create a llvm-compiled RTL. > * create an rtl with debug info and one without. > * compile the various Lazarus widgetsets into different directories > * ... any other things you may think of ... > > all with a single installation of FPC. > > For the second part of the effort, 'provide dotted filenames', the actual > work is finished, but still needs merging to trunk. > > This second part is expected to be merged in the next days/weeks. > > But today, using FPC trunk, you can now recompile the Free Pascal RTL, > Packages and Utils (but not the compiler itself!) into a set of units where > > Char = UnicodeChar > String = UnicodeString > > To compile (and install) the unicode rtl, all you need to do is follow the > steps outlined in > > https://wiki.freepascal.org/FPC_Unicode_RTL > > Basically, this means creating a 2-line configuration file for the > unicodertl subtarget, and compiling the RTL, packages and utils with > > make SUB_TARGET=unicodertl > > For those that need/want more delphi-compatible code, I would love to hear > of your experience with the unicode rtl. I have done extensive testing, but > as practice shows, there will always be cases which defy ordinary test > cases... > > If the 2 wiki pages need more explanations, please let me know and I will do > my best to improve the explanations. > > Hopefully, in the near future the compiler settings dialog in Lazarus will > also allow you to specify a subtarget. > > Michael. > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Division nodes
I didn't see a mention of it in this discussion thread, but dividing the largest negative integer by -1 does cause an overflow error of some sort, because of two's complement. Just to make sure, do (min_int div -1) and (min_int mod -1) behave the same way before and after this proposed change? And, what min_int is of course depends on whether targeting a 32-bit or 64-bit system, so best check both cases. ~Kirinn On Mon, 15 May 2023 17:21:30 +0100 "J. Gareth Moreton via fpc-devel" wrote: > I made a merge request that removes the comparison against -1. > x86_64-win64 and i386-win32 pass without any regressions, so the reason > behind the change still eludes me. Maybe my fix for #39646 removes the > need for it? > > https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/418 > > Kit > > On 11/05/2023 23:04, J. Gareth Moreton via fpc-devel wrote: > > Fair enough, but I would like an explanation as to why it's necessary, > > because the reason for testing -1 in particular is very unclear, and I > > wonder if there's a known misbehaviour with a particular division > > function with -1. > > > > Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question to developers
On Fri, 17 Sep 2021 16:55:05 +0100 "J. Gareth Moreton via fpc-devel" wrote: > Hi everyone, > > I have a question for third-party developers, especially mathematical, > scientific and games programmers... > > How often would you use a construct akin to "case x mod n of", where n > is a constant and not a power of 2? I ask because while I wait for my > "(x mod n) = 0" optimisation to be approved, I've discovered that it > could be extended to cover remainders other than 0. > ... > > Gareth aka. Kit As a kind of game programmer, I don't think I've ever used a case something mod something. I'm not sure in what situation this construct would be useful... ~Kirinn ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.2-RC1 release, now with working link!
> >> We have placed the first release candidate of the Free Pascal > >> Compiler version 3.2.2 on our ftp servers. > >> > >> You can help improve the upcoming 3.2.2 release by downloading and > >> testing this release. If you want you can report what you have done > >> here: http://wiki.freepascal.org/Testers_3.2.2 or in the maillist. > >> > > > > Test step 11 is "Run testsuite". The last time we were testing a > > relese candidate, the test suite had a small number of failures, > > but to a casual tester it was not clear what to do about it; which > > tests are expected to be failing, which are dealbreakers, etc. > > Should the test step offer more detail on how to react to or report > > test suite results? > > Those are regression tests, so test against the results of the latest > releases. ___ Great, thanks. Testing ongoing. I'm seeing frequent Access Violations when running programs of any complexity that have been compiled with "-B -O- -Oodfa,deadstore"... but this seems to have been happening already in 3.2.0, so not a regression. I don't see a bug for this yet, so I'll try to come up with a minimal reproducible. We'll need to warn users about this if it can't be fixed for 3.2.2. ~Kirinn ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.2-RC1 release, now with working link!
On Wed, 24 Mar 2021 12:24:12 +0100 Marco van de Voort via fpc-devel wrote: > Hello, > > We have placed the first release candidate of the Free Pascal Compiler > version 3.2.2 on our ftp servers. > > You can help improve the upcoming 3.2.2 release by downloading and > testing this release. If you want you can report what you have done > here: http://wiki.freepascal.org/Testers_3.2.2 or in the maillist. Test step 11 is "Run testsuite". The last time we were testing a relese candidate, the test suite had a small number of failures, but to a casual tester it was not clear what to do about it; which tests are expected to be failing, which are dealbreakers, etc. Should the test step offer more detail on how to react to or report test suite results? ~Kirinn ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
The feature request was here: https://bugs.freepascal.org/view.php?id=37331 It's magenta because GCC etc use magenta for warnings too. Actually, for those of us with white terminal backgrounds, yellow text would be hard to see, while green, red, and magenta appear quite well against both a black and a white background. I hope a new FPC release happens sooner rather than later; colored output is really nice to have. ~Kirinn On 11/22/20 2:59 PM, J. Gareth Moreton via fpc-devel wrote: Hi everyone, This might be me being a little bit picky, but I noticed the new colouring scheme for words like "Warning" and "Error" in the output logs. Is there any particular reason why "Warning" is in magenta? Normally the convention is that it's yellow (and "Error" in red). Granted, it's purely cosmetic. Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exact details for RTLeventWaitFor and related ?
When I researched synchronisation behavior and wrote the wiki page "Threads", I found that RTL events behave like this: - When the event is set, a single waiting thread is released (in FIFO order), and the event is automatically immediately reset. - The event can only be in a set or unset state; multiple sets do not stack. Even if the event is set twice or ten times, a single WaitFor or Reset will change it to unset. This is a likely cause for deadlocks. - Because the event is automatically reset when a waiting thread is released, calling ResetEvent is generally unnecessary. For set/reset counting we'd need a semaphore instead of an RTL event, but I don't think we have an actively supported semaphore implementation at this time. Caveat: The above was true for FPC 3.0.4 on Windows and Linux. 3.2.0 or trunk may have changed something, and I can't vouch for other platforms. ~Kirinn On 8/22/20 1:44 AM, Martin via fpc-devel wrote: I am tracing a race condition in lazCollections TLazThreadedQueue on win-64 What is supposed to happen in the following case: 2 or more threads are waiting on the some event RTLeventWaitFor(UniqueEvent) 1 thread sets it RTLeventSetEvent(UniqueEvent) I expect that wakes up exactly ONE thread (never mind wich)? Or ALL? If no one resets the event (NO call to RTLeventResetEvent), then that does not change anything? It is still just the one thread that got woken up? Thanks for any feedback Martin p.s. Background TLazThreadedQueue.PopItem works like this EnterCritical If item avail then return item ExitCritical // race condition between those lines. RTLeventWaitFor(itemAdded) EnterCritical If item avail then return ExitCritical If 2 or more reading (popping) threads are both at the indicated location, and if during this time 2 or more items are added then there is a problem (I believe) adding (pushing) an item does RTLeventSet(itemAdded) adding 2 items (with no pop in between) calls Set twice => https://lazarus-ccr.sourceforge.io/docs/rtl/system/rtleventsetevent.html It is unclear if the 2nd RTLeventSet has any effect ? According to my tests: - I "sleep()" 2 listeners at the critical line, so they both will WaitFor after the sleep - while they sleep I add 2 items (2 calls to RTLeventSet, no one listening yet) - Both start RTLeventWaitFor => only one listener wakes up. Is that the expected behaviour? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] vtCardinal in TVarRec
I'd like to ask for some clarification on this issue: https://bugs.freepascal.org/view.php?id=32135 Dwords can't be passed into an array of const, because TVarRec doesn't have an unsigned 32-bit integer type. Adding any kind of handling for it would be Delphi-incompatible. But isn't the point of the ObjPas mode to be able to fix regrettable oversights that Delphi has? Can't a special case be added for accepting Dwords in ObjPas mode only? Note, that vtQWord and vtUnicodeString are already extensions going beyond Delphi. Why not Dword? The reason I ask is that arrays of const are very powerful, and work beautifully, except for lacking support for one of the most common variable types. And because an array of const is a compiler-level construct, I can't even override it. This feels frustrating. :( ~Kirinn ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case else allows multiple statements
Thanks, I've added a minor doc bug for it.
https://bugs.freepascal.org/view.php?id=36090
On 9/19/19 8:40 PM, Alexander Grotewohl wrote:
I'm assuming that's what the 'statementlist' means in the
documentation (rather than just 'statement')
On 9/19/2019 3:33 PM, Sven Barth via fpc-devel wrote:
Am 19.09.2019 um 21:07 schrieb Kirinn:
I've stumbled on a situation where a case statement compiles when I
wouldn't expect it to. I would expect the below code to produce a
compile error:
program test;
var i : byte = 5;
begin
case i of
0..4: writeln('value is ', i);
else writeln('Else!');
i := 3;
writeln(i);
end;
end.
This compiles without errors or warnings on FPC 3.0.4 and produces
the output:
Else!
3
None of the documentation I've looked at suggests that a case-else
is implicitly a block. All examples in the documentation show only a
single statement in any else clause, or an explicit begin-end block.
Is this expected behavior? If yes, the reference guide (13.2.2)
would benefit from mentioning this.
That is indeed by design (at least Delphi compiles it as well). You
can file a bug report against the documentation so that it isn't
forgotten.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Case else allows multiple statements
I've stumbled on a situation where a case statement compiles when I
wouldn't expect it to. I would expect the below code to produce a
compile error:
program test;
var i : byte = 5;
begin
case i of
0..4: writeln('value is ', i);
else writeln('Else!');
i := 3;
writeln(i);
end;
end.
This compiles without errors or warnings on FPC 3.0.4 and produces the
output:
Else!
3
None of the documentation I've looked at suggests that a case-else is
implicitly a block. All examples in the documentation show only a single
statement in any else clause, or an explicit begin-end block.
Is this expected behavior? If yes, the reference guide (13.2.2) would
benefit from mentioning this.
~Kirinn
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about Word128
To be clear, 128-bit octawords and the like are not natively supported on most consumer-oriented processors. To support 128-bit operations, an extensive emulation layer would need to be set up, not an easy task within the scope of a compiler and the RTL. If you need 128-bit integer maths in the near future, your best bet would be to write a quick and dirty implementation yourself with records and operator overloading, as Sven described. Has anyone done that yet? It might make an interesting unit for the Free Component Library or something. I note that SysUtils includes an "Int128Rec", which is a record type for holding a 128-bit int. Looks like it's currently used only by InterlockedCompareExchange128. Someone brave could expand upon that. ~Kirinn On 08/07/2018 03:11 PM, J. Gareth Moreton wrote: I think there was talk at one point about implementing Float128 (or "Quadruple") for Free Pascal, mostly for internal compiler purposes. For OWords though (or is it EWords or DQWords?) I think a library or package will be better initially. Still, it might be something to consider if Intel or another processor manufacturer introduce 128-bit number functions for XMM registers and equivalent. Gareth aka. Kit On Tue 07/08/18 10:09 , Sven Barth via fpc-devel fpc-devel@lists.freepascal.org sent: Aelita mailto:aelit...@narod.ru>> schrieb am Di., 7. Aug. 2018, 09:53: Hello! My name is Aelita and for many years I have been fruitfully using your wonderful freepascal for my research in algebra, geometry and physics. Thank you for your inspirational work! I'm very interested in seeing the numbers Word128 and Int128 appear in freepascal (with natural operations A*B, A div B, A mod B, A xor B, A shl N, etc.)! Is there a chance that this will happen in the near future? Using records and operator overloading you can implement them yourself. No need to burden the compiler with it. The only disadvantage would be the inability to use that large literals... but that could be helped a bit with conversions from floating points,at least if full accuracy isn't required. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org <mailto:fpc-devel@lists.freepascal.org> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel <%3Ca%20href=>">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Exceptions on wiki
Hi all, Inspired by Gareth aka. Kit's infectious enthusiasm, and the recent long discussion on exceptions on this list, I wrote up an article on Exceptions on the FPC wiki. (Strangely enough we didn't have one before.) http://wiki.freepascal.org/Exceptions I hope it'll be useful, and not entirely inaccurate! Particularly the part about performance. If a programmer knows exactly what each exception statement inserts in the code, that should help in deciding when to worry about the performance, and when to embrace the convenience. ~Kirinn ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
