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
