Re: [fpc-pascal] Very vague gettickcount64 description?
> If you're going to be insulting and personal, you might consider > unsubscribing yourself from the mailing list: this is a technical > discussion mailing list, not a tabloid where such things are permissible. Oh, given that I've been called various things worse than a simple "that's not how this works" on this here list already, one may have thought differently. It's just that for all I keep saying I've given up on this *project*, I still love the *language*, and certain attempts to fix what isn't broken still tick me off more than they should. After all, someone somewhere down the line will have to undo them... And one final thought-- since I've been persona non grata for years anyway, I'm genuinely surprised you don't have my address in a client-side killfile. Preempting Tomas: yes, I'll shut up now. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
Am 08.09.2019 um 13:17 schrieb Yuriy Sydorov: > Sure, measurements using GetTickCount is not precise (+-20ms on Windows). On any reasonably recent kernel, it has 16ms granularity and even before that was always guaranteed to be a monotonically incrementing (except for the rollover) number of milliseconds. You would assume that `a physicist by education` is aware of the difference between precision, resolution, granularity, and the concept of units... Take a multimeter. If I take my cheap 3 1/2 digit one and set it to the 20V range, it can display a number like '19.99'. That's 10mV granularity, probably not even that in actual resolution (depending on the ADC they used), but the precision appears high since it is too blind to see any noise. The unit is Volt. A "slightly more expensive" one from our lab could be a 4 1/2 digits Fluke, displaying '19.999' in the same setting. That's 1mV granularity, it actually has that resolution, and you start to see random noise in your signal so the precision looks worse. The unit is also Volt. And you're saying since everybody measures with a different device, there's no point in specifying that we're talking about Volts and might as well write down a number in centiVolts or something and not tell anyone. Sure. Oh, and difference vs absolute measurements has fuckall to do with that. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
Am 07.09.2019 um 21:42 schrieb Zoe Peterson: > GetTickCount and GetTickCount64 are Windows API functions that are > explicitly documented as returning milliseconds, [...] > As an FPC user, this seems like an astoundingly bad decision to even > be considering. But it perfectly fits the "recent" trend to invisibly break Delphi compatibility wherever possible. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so > except for using a temp to avoid duplicate calculation of "a" in how far is > this > not the long form? No, I meant it doesn't re-parse as its long form, which is why it has some limitations. In this case for example handle_propertysym does not know it is actually seeing an assignment. I don't think the compiler can do this? Macros are expanded on the scanner level, token stream injection is not a thing in FPC, AFAICS? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt: > > This question pops up from time to time since 15 years if not more. Fun fact: questions asking why this doesn't work have a higher Google ranking than the manual for "COPERATORS" ;-) @Ryan: as with all things FPC, ignore the manual, read the parser: <https://github.com/graemeg/freepascal/blob/4e6c609/compiler/pexpr.pas#L221> Turns out c-operators do not actually translate to their long form but instead have special, duplicated handling. Because of course they do. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Heavy heap fragmentation issue
>>> Try compiling the heap manager with "-dBESTMATCH". This makes it a >>> bit slower but greatly reduces fragmentation. > I think so. I usually set it when I "make all OPT=-dBESTMATCH" the compiler. Thanks. BESTMATCH is only marginally better for the test case, but is much slower (i.e. fully bootstrapping takes 50% longer). I guess there is something fundamentally not very well suited to this type of workload in the RTL MM. But it was worth a shot... Best, Sebastian ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Heavy heap fragmentation issue
Am 13.07.2019 um 08:36 schrieb Burkhard Carstens: > Try compiling the heap manager with "-dBESTMATCH". This makes it a bit > slower but greatly reduces fragmentation. Thanks, I'll give that a try! Just to be clear, that needs to be set when compiling the RTL, right? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String conversions
> Yes indeed. FPC already has an overwhelming amount of string types. As I said > though a SetCapacity option for growing would be nice (for dynamic arrays > also) because += is such a common operation. As it stands I often don’t use > dynamic arrays (and now ansistring) because of growing limitations, which is > a shame really. Just chiming in: this should be handled by the memory manager. "A chunk of memory gets grown repeatedly" is actually a fairly common workload, not just for arrays, but also things like MemoryStreams or List classes. So, I would expect (and FastMM has codepaths for that), that repeated reallocations cause some form of "over-allocating" growth and most of the individual "+1" reallocs will be essentially no-ops. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Heavy heap fragmentation issue
Am 03.06.2019 um 14:49 schrieb Marco van de Voort: > Note that it is fairly typical that also frustrated pre fastmm D7. Back > then I wrote a simple pool-factory combo class for it, and with D2009 I > upgraded it to generics,so that I can easily create pools for many such > objects. Well, there is a general-purpose pooled allocator already. It's called the heap manager ;-) Jokes aside, I did a bunch of counting. The only thing that sticks around are 50kB TLazIntfImage instances. Everything else gets freed right after processing. Just from the order of alloc/frees, there shouldn't even be gaps, so I would expect the next iteration to just find those allocations to be empty and reuse them. But for some reason, that doesn't happen. I've compiled with FastMM for now, but it turns out this is in fact a bit slower than the RTL MM, and I don't really trust my port yet... -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Heavy heap fragmentation issue
>> can you break it down into a test program and post?
>
> I should probably put the project on Github anyway, it's rather small, and it
> shouldn't have any dependencies. Give me an hour to clean it up a bit.
This should be good enough. It's been only used by like four people so the UI is
a bit of a mess, but you'll only need one button to see the problem.
So, here are the steps to reproduce:
- Get the code from
<https://github.com/martok/ImageHash/tree/bug-fpcmm-fragment>
- Compile (originally written with FPC trunk >= late 2017, best use
current trunk; LCL version shouldn't matter much)
- The default mode puts the exe in bin_i386, right next to the DLLs
- Run
- Provide data (~10 3MB JPEGs should do, or just paste one 10 times), either:
- paste the full path to a directory containing a number of images
in the top-center memo (no, there's no SelectDirectory dialog)
- put the images in a folder 'data', that gets auto-added in this version
- Click 'Read'
- Wait for it to find visually similar images in your input
- Compare memory as reported by task manager or ProcExp to HeapStatus
that is printed in the bottom-left log memo.
Note that the number of threads used (defaults to HostCPUs-1) doesn't matter
(can be changed down to 1), so it's not a concurrent alloc problem. You can also
apply the attached patch to even run the comparator in serial, but that doesn't
change anything either.
--
Regards,
Martok
diff --git a/uFrmMain.pas b/uFrmMain.pas
index a4425da..8d89f14 100644
--- a/uFrmMain.pas
+++ b/uFrmMain.pas
@@ -253,6 +253,7 @@ begin
SetLength(loaders, seThreads.Value);
t1:= GetTickCount64;
btnRecompare.Click;
+fClassifier.Suspend;
lbStatus.Caption:= 'Setup loader...';
for i:= 0 to High(loaders) do begin
loaders[i]:= TImageHashThread.Create;
@@ -286,6 +287,7 @@ begin
loaders[0].Start;
end;
WaitForMultipleThreads(@loaders[0], length(loaders),
@Application.ProcessMessages, @fAbortFlag);
+fClassifier.Resume;
WaitForMultipleThreads(@fClassifier, 1, @Application.ProcessMessages,
@fAbortFlag);
t2:= GetTickCount64;
meLog.Lines.Add('time: %dms',[t2-t1]);
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Heavy heap fragmentation issue
> can you break it down into a test program and post? I should probably put the project on Github anyway, it's rather small, and it shouldn't have any dependencies. Give me an hour to clean it up a bit. You'll have to supply your own images though (just copy one 10 times or something), as I don't own the copyright to anything in my test dataset. In the mean time, here's an overlay of Process Explorer for two test runs: http://puu.sh/DAHMA/d83bfe7215.png Red/Left axis is FastMM, Green/Right axis is the RTL MM. So the high memory use occurs at the same time, only the RTLMM rarely returns memory so it builds up. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Heavy heap fragmentation issue
Hi all, I'm having a problem here in a sequential image processing application that seems to test a particularly bad operation mode for the RTL heap manager (on Windows, but I don't think this matters here). The work load looks like this: load "normal sized" image, do some processing, calculate a few values, create thumbnail in memory, next. By "normal sized" I mean something like 35MB uncompressed (regular DSLR resolution) and smaller. It's threaded code, but I'm describing the single worker operation here. This appears to trigger insane memory fragmentation: after execution on 40 test files, I'm left with 250MB working set, while GetHeapStatus only reports 600k used (which seems correct, my data structures add up to 500k). This is never released to the OS. In fact, I've had to set the LAA flag just so that the program can work on the real data at all, with some 2.6GB working set for 1.07MB of used memory. Is there any tuning option that could use maybe fix that? Some growing or reallocating flag or something? As a quick test, I've tried my partial port of FastMM4 which works just fine, no fragmentation and peaks at 40MB used memory, which fits with the largest image. But this is such a reproducible test case, maybe there is something that can be done to improve the RTL MM? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert codepages back to UTF8
> Although be advised that if your SystemCodePage is not a Unicode > codepage, there > will be data loss due to (sometimes unexpected) internal conversions, > regardless > of the current dynamic string code page. > > > As Graeme wrote that shouldn't be the case when converting to UTF-8. And for > everything else you need to either use string variables with the correct > static > encoding or RawByteString to avoid conversions. As I wrote: "if your SystemCodePage is not a Unicode codepage". If it is, everything mostly works. And even RawByteString gets unexpected roundtrip-conversions on some operations, which breaks in funny ways if the SystemCodePage can't represent some characters in the RBS. I once spent most of a day debugging seemingly random data corruption until I realized the corrupted bytes were #$81, #$90 etc and the non-LCL program used CP 1252. More interesting for Alexey regarding the followup question: the result of any string operation is in the DefaultSystemCodepage, such as: s:= 'abc'; SetCodePage(RawByteString(s), CP_UTF8, true); WriteLn(s, ' ',StringCodePage(s)); // abc 65001 s:= s + 'd'; WriteLn(s, ' ',StringCodePage(s)); // abcd 1252 -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert codepages back to UTF8
Am 27.05.2019 um 14:30 schrieb Sven Barth via fpc-pascal: > Alexey Tor. <mailto:aaa5...@ya.ru>> schrieb am Mo., 27. Mai 2019, 13:15: > > LazUtils.LConvEncoding can convert utf8 to codepage (not many codepages) > and vice versa. > > FPC 3 can convert utf8 to codepage - via SetCodePage(s, codepage, true). > But how can FPC convert back - codepage to utf8? Does such way exist? > > > Use CP_UTF8 as code page for SetCodePage or assign the string to a UTF8String > variable. Although be advised that if your SystemCodePage is not a Unicode codepage, there will be data loss due to (sometimes unexpected) internal conversions, regardless of the current dynamic string code page. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpPDF and support of Latin2 charset
> Tell them how much money (£2000+) they save per developer by using FPC > versus Delphi. A small money contribution to get something they need is > a small price to pay. I showed my company the price saving for a 5 > person development team. They couldn’t believe the savings, and allowed > me to develop the open source fpGUI and others during company time, Not to retroactively rain on your parade, but either you cost them less than 30k a year, or that was a lucky case of departmental politics of invest vs. payroll. Especially for tiny teams, the decision of spending 6k€ or hiring a new developer to maintain the toolchain is, sadly, a no-brainer. Unless you already have a strong commitment to open source tools, of course, but then it's more policy and publicity. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementation through interface delegation not pass to descendant
Am 17.03.2019 um 15:21 schrieb Zamrony P. Juhara via fpc-pascal: > I repost my question that I post on StackOverflow here in case anyone can > answer it. This is my question about implementation > > of interface through delegation. Parent class is concrete class which > implement an interface through delegation but descendant of this class is not > considered as concrete class of the interface. I've answered on SO. Don't think it's solvable, because this would need partial delegation on TBClass' implementation of IIntfB from knowledge of the inherited IIntfA, which sounds a bit complex for the compiler... As a compiler suggestion: this could be made clearer if E5042 would print the interface type name it is missing, such as: `Error: (5042) No matching implementation for interface method "IIntfB.writeA" found` -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CLI argument parsers
> I have archived this mail list via GMANE News so I have *everything* > from about Sept 2003. Very handy for local searches of issues and > content. I do the exact same thing, and I know how much bad threading can ruin the usefulness of a group. You may want to examine whose message was the first one in the recent tree that did not directly relate to progress reports on the resource compiler, and if that still bothers you, take it up with Tomas. > I just wanted to make you aware of the readability issue, sorry if I > have upset you. Don't worry, *you* haven't. And, given that this was something of my last attempt to contribute something useful anyway, there won't be any more messages from my side that could upset you (or anyone else), at least for a long while. Cheers, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CLI argument parsers
Am 14.01.2019 um 18:05 schrieb Bo Berglund: > By changing the subject of an existing (very old thread) and post new > content you have screwed up the message handling of threads so this > conversation now gets stuffed into the "Resource compilation" thread > dating back a year and 3 months... > > Please start new threads from scratch instead. I just changed the title for my reply to an already off-topic reply - but apparently people don't do that old newsgroup convention anymore. My original reply post was very much supposed to be in this thread. But as nobody seems to care about that post's content anyway and instead latches on to the smallest of notes... well. Whatever. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CLI argument parsers
I was 100% expecting that sort of answer. Cheers, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] CLI argument parsers (was: Resource compilation)
Am 13.01.2019 um 18:43 schrieb Michael Van Canneyt: > Assuming you mean the command-line arguments: > > What's wrong/missing with the functionality in TCustomApplication ? Other than that nobody in the wild seems to fully use it? ;-) Even most of the examples in the compiler tree use homegrown parsers, or look like [1]. I'm a fan of getopts and use it (with a small wrapper) for almost everything (i. [2]), but it seems that many people are not aware it even exists. It's even POSIX compliant, so the program's users won't be surprised by some implementation particulars. But even that is nowhere near as elegant as argparse. I just don't like retyping usage statements when they could be autogenerated ;-) And Subparsers are, while possible, always quite hacky. Of course, if someone was to implement something now, we'd be in the https://xkcd.com/927/ situation... [1] https://github.com/graemeg/freepascal/blob/master/utils/svn2cvs/svn2cvs.pp#L494 [2] https://github.com/martok/buildtools/blob/master/buildutil.lpr -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Update time!
<https://github.com/martok/freepascal/compare/master...fpcres-rc>
> - UnicodeString Strings (L"foo")Done
> - various forms of escape sequences for strings
Done
> - Concatenated adjacent strings ("ABC" "DEF")
This is weird: windres, brcc and rc all do something different when
concatenating mixed Unicode and CP strings, as in `L"a" "b"`, `"a" L"b"`.
I have no idea what the correct action would be.
> - complex resources: ACCELERATORS DIALOG/EX MENU/EX STRINGTABLE VERSIONINFO
Probably going to leave out the Dialog-Related stuff, since it's not super
relevant for us anyway. Windows users can just use RC ;-)
> It's also leaking memory like a rusty bucket, I have so far completely ignored
> what transfers object ownership in fcl-res classes. Heaptrc will hopefully
> help
> here.
Fixed
All of windres's tests pass now, except for the Dialog related ones. I would
consider it more or less finished. Any more things to do? Otherwise, I'll stack
it into some patches.
A few lessons learned:
Using TStringList as a key-value-store (#define) is SLOW. Replacing it with a
TFPStringHashTable brought processing time for windows.h down from 4 seconds to
some 10ms. That's just insert operations.
Codepage Strings are weird if more than one CP is involved. There is almost no
way to carry a specific codepage anywhere: AnsiString[850] + Char =
AnsiString[CP_UTF8]... Also, ShortStrings are often converted to AnsiStrings, so
that doesn't reliably work either. Same for array of char. That made working
with plex awfully complicated, and I still think it's wrong in some cases. But
at least it works for most now.
Having a reentrant version of plex would be nice. Flex and Bison can do it
these days.
To a lesser degree: something like Python's argparse would be nice. Everyone
builds their own argument parser, usually with very different concepts and
varying amounts of code duplication.
--
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetLength warnings - request
Am 29.12.2018 um 22:35 schrieb Jonas Maebe:
> You don't need to typecast dynamic arrays to pointer to initialise them
> with nil. Simply "arr:=nil;" works. Ideally, the compiler would remove
> this extra initialisation if you add it before it got a different value,
> but it does not yet do that.
Something I just found out, while changing some old code: why does that not
work?
var
u: UnicodeString = nil;
// Incompatible types: got "Pointer" expected "UnicodeString"
a: AnsiString = nil;
// Illegal Expression
c: TCharArray = '';
// Syntax error, "(" expected but "const string" found
Simply using '' as an initializer for Strings and nil for arrays solves it, so
it's no big deal. I'm just curious why Strings do not have the niln typeconv and
why the TCharArray can't be initialized (but assigned at runtime) with ''. And
why only the UnicodeString message actually relates what is wrong... ?
--
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetLength warnings - request
Am 02.01.2019 um 17:23 schrieb Sven Barth via fpc-pascal: > Even in Delphi situations can occur where a dynamic array Result variable is > non-Nil already upon entry and then SetLength will simply manipulate that > preexisting array instead of working on a new array. In most cases that > probably > won't have a real effect as the array is either set to empty anyway or all > it's > elements are initialized by the function. That doesn't change the fact however > that the behavior *is* there and can potentially lead to hard to debug > problems. > Anything else can potentially be a bug lying in wait. Again, why is this not changed? Clearly we can't change Delphi, but there is no real reason not to be better than them. And it *is* undocumented for them, so we'd still be compatible, just compatible-on-the-safe-side. Document that managed variables are initialized (this also means calling operator Initialize) regardless of global/local, make sure that they always are (which is currently only missing the Result pseudovariable), and bam - problem solved. Shouldn't even cause any extra code to be emitted since it's either already there or could be eliminated as a dead store. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetLength warnings - request
First, I agree clearing dynarrays with :=nil is somewhat cleaner than Setlength(0). (Small issue: I only learned that this is even a thing from the compiler implementation of it when I was debugging #0031215! From the reactions of other Delphi developers I showed it to, it is _very_ uncommon.) Initializing to any number other than 0 can only be done with Setlength, and I'm going to be honest, this bit from compiler/symtable.pas looks just ridiculous. begin newbuiltdefderefs:=nil; builtdefderefs:=nil; builtsymderefs:=nil; setlength(builtdefderefs,deflist.count); setlength(newbuiltdefderefs,deflist.count); setlength(builtsymderefs,symlist.count); > I'm 100% serious about the above. Code should be explicit, not implicit. > It's up to the compiler to remove unnecessary code based on what it > knows is implicitly guaranteed. The programmer should only have to focus > on the algorithms and on making their code as explicit/clear as > possible. The question then is: what is explicit? How does one tell apart "filler" code the compiler is supposed to remove and "relevant" code the compiler is not supposed to remove? Why even write code we hope will not be in the final binary? Incidentally, this was the topic of a talk at this (well, last!) year's CCC [1]. Compilers doing overly clever optimisation are sometimes a real-world *problem*, not a solution. The compiler should at least tell the programmer about security relevant optimizations and offer ways to fix it if necessary. [1] https://media.ccc.de/v/35c3-9788-memsad > In that sense, the optimisation capabilities of a compiler are quite > important for the quality of the code that people write, because a > better optimiser means that (some) people are less inclined to mangle > their code and "tune" it to implementation details in order to coax the > compiler into generating the code they want to see. Strongly agree. Before I had to bury the project because of the whole enum portability fiasco, I rewrote large parts of the DEC routines in pure pascal, and it turned out that while being more readable and more portable, it was also *faster*, because FPC generates better instructions these days. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetLength warnings - request
Happy new year, everyone! Am 31.12.2018 um 10:22 schrieb Michael Van Canneyt: > Cultural note: > For native english speakers the above may be somewhat farfetched: But in Dutch > and French, spelling and grammar are not ruled by custom, but are strictly > managed > by official language committees... That is an extremely fitting example! In my view, modern Pascal is ruled by custom, not by committee. The last time a committee wrote a Pascal standard, the result was technologically somewhat obsolete by the time it was published... But that would be off-topic here. > I'm curious to see them, because all 'issues' reported here can be perfectly > repeated (possibly with some modifications) in Delphi. > The non-initialization of 'Result' has bitten me more than once in Delphi. Aye. But it's rather rare in Delphi and very common in FPC, so not everyone might have encountered it (that's how I'm justifying to myself putting it on the Portability List instead of starting a Common Mistakes set ;-) ). > I can't explain things better than Jonas did. I intend to rework his > arguments and introduce them in the language reference manual. Feel free to use any of the examples here: <http://wiki.freepascal.org/User:Martok/Portability_Issues#Managed_Variable_Intialization> As you said, Delphi makes some of the same mistakes, but at least it doesn't emit warnings where the code-as-written is interpreted exactly-as-written, therefore, doing what the programmer told it to do in the first place. The problem I see is that these bogus warnings drown out the actual programmer errors signified by the same message. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetLength warnings - request
> There is a hint for such parameters even though the compiler knows they > always contain a valid value, because valid in the sense of "won't crash > the program" is not the same as "this is what the programmer intended". Are you baiting me, or was that accidental? ;-) > 1) Dynamic arrays are initialised with nil, but that is an > implementation detail Is it, though? Global variables and instance fields are zero-filled, local variables as if the local variable block was a record passed to Initialize() (so, recursively zeroing managed fields). Although it is never spelled out, the Delphi manual heavily implies this. I would guess most if not all pascal programmers wrote code that relies on that at some point. @MvC: I'll come up with some examples and add it to the Portability page, since the different result variable initialization rules already are a bit of an issue. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Candidate for crowd-funding
Am 19.12.2018 um 14:22 schrieb Sven Barth via fpc-pascal: > Maybe we could add your changes to trunk? Ah, I may have made that sound better than it was ;-) I didn't actually solve the problem. Can't seem to find my branch anyway (I may have amended that when the focus changed to the pure modifier), but IIRC it was just a matter of changing the inline info check to allow assembler blocks when they have a register list and the correct procoptions are set, because notstackframe already implies the body is a single asm block and that there is no interfering prolog/epilog. Parameters are difficult because they either need something like extra temps *in memory* (like cdecl) or some extra registers need to be pushed/popped, which brings us back to the register allocator issue. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Candidate for crowd-funding
> The main problem here is to model what registers an instruction uses and > modifies so that the register allocator of the surrounding function can take > that into account accordingly... Maybe as a first step we could allow in > lining > for funcrions that have a register clause with the touched registers... > But yes, in the long term this would definitely be nice. I actually did that a few months ago (when intrinsics came up on this list), and it does work as you expect. The actual difficult problem is argument location remapping. Other than that, inline-nostackframe-asm[registers] needs almost no changes. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit generic specializations
Am 03.12.2018 um 14:01 schrieb Ryan Joseph: > I believe I managed to solve the problem and now non-generic procedures take > precedence. I guess it’s possible that you could opt out of an implicit > specialization now but declaring and overload which the specific type you > were interested in. This is probably a good fallback to have so it’s good > it’s like this now. What happens when there are implicit conversion operators defined? I.e.: operator := (x: integer): string; // with and without this more specific overload: procedure DoThis(msg:integer);overload; generic procedure DoThis(msg:T);overload; DoThis(42); I'd normally say it should take the integer one (or specialize using integer) and ignore the overloads, but now that I think about it, overloads should be checked if they are required to satisfy type constraints on the generic, such as: operator :=(x: integer): TObject; // whatever that might do generic procedure DoThis(inst: T); DoThis(42); -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics question
Am 03.12.2018 um 10:53 schrieb Martok: > I'll have to check the real-world code again, might be able to close this bug > as > "fixed in the mean time". Checked, works also in real code. I have added a note saying so on the bug. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics question
Am 03.12.2018 um 08:00 schrieb Sven Barth via fpc-pascal: > Because Delphi does not allow that either. We relaxed that however in 3.1.1 > and > it should be part of 3.2.0. You can test the corresponding branch of you > want. Is this related to <https://bugs.freepascal.org/view.php?id=33013> ? The example I provided then doesn't crash anymore, but it sounds like that is the sort of code that would not be accepted at all in Delphi? I'll have to check the real-world code again, might be able to close this bug as "fixed in the mean time". -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Default record const values
Am 10.11.2018 um 12:17 schrieb Ryan Joseph: > This also fails. I personally find this case much more limiting. Another implication is that you can't build up consts from other record consts, such as: -- type TMyRecord = record a: integer; b: string; end; const TMyRecord_Default: TMyRecord = (a: 100; b: 'foo'); TMyRecord_Another: TMyRecord = (a: 200; b: 'bar'); SomeRecords: array[0..1] of TMyRecord = ( TMyRecord_Default, TMyRecord_Another); -- There is a pointer hack to get around that, but it would be really useful if this worked out of the box. And yes, I know this is because record consts are (writeable, at worst) typed consts and as such are only preinitialized global variables, not true consts, but it still bothers me... -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
Am 16.09.2018 um 14:31 schrieb Jonas Maebe: > [...snip...] Thank you very much for this explanation! One for the bookmarks. It just seems very odd to me to have the incredibly powerful and useful dynamic codepage concept... and then trash it on every assignment. But if that was an Emba-invention, that explains a few things... Concrete example: the MS RC script format allows changing the input codepage at runtime (#pragma code_page), meaning the next #include must be interpreted in that CP, and output generated from this input must be in that CP (unless it is written in widestring format, but that is decided very late in the process). This would be super easy to do if one could just pass around a string with the correct dynamic code page (one could even use the CP_UTF16 codepage for L"foo" widestrings). But as fcl-res uses AnsiStrings everywhere, this cannot work, as the only lossless setting would be to use DefaultSystemCodePage=UTF8 for the entire program, completely ignoring the user, which might cause MUI problems. Windres gets this wrong as well, but somehow that doesn't really make me feel any better ;-) -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
Am 16.09.2018 um 12:35 schrieb Sven Barth via fpc-pascal: > If you want the content to *be* in code page 866 without any tricks then > you need to declare a AnsiString with that code page and use that: > > === code begin === > > type > TCP866String = type AnsiString(866); That only works if the codepage is known at compile time. Let's say the user directs a program to "treat this file as $codepage". Therefore, I need to read it as this codepage and fill internal data structures with strings in that codepage, while keeping other operations in the system codepage (so I can't just change DefaultSystemCodepage). Does that mean that there is no way to do this with native strings? > TL;DR: "AnsiString"/"String" is a type that has the code page that was > determined at startup, not one that turns itself into whatever code page > gets thrown at it Actually, there is a String type that is just that (at least according to the wiki): RawByteString. Supposedly, it just accepts any dynamic codepage without conversion. But it doesn't work for either of the cases here? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
> Setting the code page of a file tells the RTL about the encoding of the > strings in the file. The string's static code page (which maps to > DefaultSystemCodePage if none is specified) tells the compiler to which > encoding this string data should be converted. I know! That doesn't make it any more *useful*. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
Gah, accidentally removed the comment that said what the actual problem is ;-) > ReadLn(f, s); > WriteLn(StringCodePage(s)); That prints 1252, which is the DefaultSystemCodePage. At that point, information loss has already occured, there is no way to fix the CP in user code. I would expect reading from a file whose codepage I have just set to return strings in that codepage. Instead, I get the declared codepage of the string. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
And another one: var f: TextFile; s: string; begin AssignFile(f, 'a_file.txt'); SetTextCodePage(f, 866); Reset(f); ReadLn(f, s); WriteLn(StringCodePage(s)); readln; end. That is rather useless... Writing anything into the specified codepage works perfectly fine. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concatenating CP Strings
Am 15.09.2018 um 07:34 schrieb Mattias Gaertner via fpc-pascal: > To have the result in a specific codepage use > SetCodePage(result,NeededCP,true); As I wrote, doing this by hand works, but I don't want to believe somebody thought that was how it should be. Why would "CP_UTF16 + CP_UTF8(literal) = cp1252" be the desired outcome? operator >< (a, b: RawByteString): RawByteString; var t: RawByteString; la, lt: Integer; begin t:= b; SetCodePage(t, StringCodePage(a), True); la:= Length(a); lt:= Length(t); result:= a; SetLength(Result, la + lt); Move(t[1], Result[la+1], lt); end; With that, one can write "foo:= bar >< x" and it just works. > Only on ancient Windows it was UCS2. In that case, fpwidestring is wrong as well, see fpwidestring.pp:262. MSDN is slightly unclear: "1200utf-16 Unicode UTF-16, little endian byte order (BMP of ISO 10646); available only to managed applications" The "managed applications" part is why WideCharToMultiByte simply returns an empty string when asked to convert anything to cp1200, instead of just doing the plain memcpy. "only the BMP" would be UCS2. In other places, surrogate pairs are mentioned, making it a true UTF encoding. In any case, I think the RTL should be consistent across platforms? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Concatenating CP Strings
Hi all, concatenating codepage strings is documented to be a bit weird: <http://wiki.freepascal.org/FPC_Unicode_support#String_concatenations> Knowing this, how does one achieve the following? - have a string in any dynamic codepage - append another string (possibly from different CP), or a literal - have the result in the same dynamic codepage as before Literally, "transcode the new part and plop it at the end"? Using AnsiStrings does not work, as the declared CP is CP_ACP, which is not the dynamic CP, and loss of data is likely. Using RawByteStrings does not work, as they get converted to CP_ACP regardless of their current dynamic CP, and loss of data is likely. Insert() does not work, because it doesn't care about characters at all and just moves bytes. Doing the entire thing manually with a temp string does work, but such a simple task can't be that difficult, can it? Thank you, Martok PS: Also, somewhat related: how compatible are the different widestring managers supposed to be? Windows doesn't support CP_UTF16(BE) (which really is UCS2 - aka the MBCS alias of WideString), but fpwidestring has correct handling for it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hint converting to int64
Am 11.09.2018 um 12:11 schrieb Santiago A.: > -- var Entity:Longword;FullParagraph:string; pIni:Integer; begin > Entity:=Entity*10+ord(FullParagraph[pIni])-48; // <=== Hint end; > --- Compiling with -vp shows that the result of the subtraction is a signed Longint. That makes this an expression mixing Longword and Longint, which is always computed in Int64 and because of that causes this hint. The thing I'm missing is the "Mixing signed expressions and longwords gives a 64bit result" hint. Is that because something detects that this was an internal typeconvn? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
> I happened to have an old win8 sdk around (vs community edition didn't seem > to have "RC"). Anyway: > > http://www.stack.nl/~marcov/funkyres.res Thank you! Funky indeed, I'll mark that down as a Reshacker bug then. Off to String stuff then. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
More Progress! I've since finished STRINGTABLE and VERSIONINFO as well as mathematical expressions. However, there's an issue I hope somebody can help with. Binutils has this test case: <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/testsuite/binutils-all/windres/version_mlang.rc;hb=HEAD> Every Resource compiler I have tried compiles this slightly differently, and Resource Hacker doesn't understand one of them. Could somebody test this with MS RC and share the res file? Independently, TVersionResource emits one Translation block per translation instead of one containing all translations. I take it that isn't formally wrong, but it's also not optimal? Was this intentional? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Hi again,
a quick update: I have a somewhat-working version, but many things are still
missing.
We have: a preprocessor, full support for BITMAP, ICON, CURSOR, resource
attributes (LANGUAGE etc.), all RCDATA-like resources, including their
definition from inline literal statements.
What's missing:
- UnicodeString Strings (L"foo")
- various forms of escape sequences for strings
- Concatenated adjacent strings ("ABC" "DEF")
- numeric expressions (used for things like computing flags).
- complex resources: ACCELERATORS DIALOG/EX MENU/EX STRINGTABLE VERSIONINFO
The first two are not that difficult, just awkward (as all encoding-aware
stringhandling is), adjacent strings are more of an issue: turns out this
creates a problem in the language:
FOO BITMAP "900.bmp"
"A NAME" TEXT BEGIN "A String" END
This can't parse right: the filename and resid get concatenated to "900.bmpA
NAME". While entirely correct, that's not very useful. I might leave that out
until someone needs it.
Of the complex resources, STRINGTABLE and VERSIONINFO are probably the more
important ones. Luckily, both already have resource types implemented, so that
shouldn't be too hard either.
It's also leaking memory like a rusty bucket, I have so far completely ignored
what transfers object ownership in fcl-res classes. Heaptrc will hopefully help
here.
I only get to work on this on about one day a week and spend half of that trying
to keep the grammar somewhat readable and with no bad reduce conflicts, but if
anyone wants to play along:
<https://github.com/martok/freepascal/compare/master...fpcres-rc>
--
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: portability differences between Borland/FPC
Am 19.08.2018 um 14:55 schrieb Florian Klämpfl: > Please note again: in general, there are no defined rules for FPC as soon as > range check errors would occur. For FPC, > you are just documenting random *behavior* which might change even with the > next minor release. I know. And I have given up trying to change your mind about that ;-) Even if the takeaway lesson in the future will be just "it used to be like this, better check what is current", then that is still better than the state today. I know this is consistent for you, you've been at this for "a few" years. Coming from Borland, that is a major unseen difference. The other way around is far easier. > Well, you have to as you give people the wrong impression that they can > control what happens if they suppress/ignore run > time errors. Okay, I've moved that paragraph to it's own section. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: portability differences between Borland/FPC
Am 18.08.2018 um 23:25 schrieb Marco van de Voort:
> Summary: behaviour with range checks off is implementation defined?
No. "implementation different", but not really "implementation defined".
TP and Delphi are fully defined without range checks. In fact, TP is defined as
*having no runtime range checks at all* (TP7LG, Chapter 21), except for
Succ/Pred (and Inc/Dec by extension), which explicitly react to $R (TP7LG,
Chapter 4) . One might imagine:
function Succ(X: T): T; inline;
begin
Result:= T(Ord(X) + 1);
{$IFOPT RANGECHECKS}
if Result > High(T) then
RuntimeError(201);
{$ENDIF}
end;
{Mentioned for completeness: method checks (our -CR) are also handled by $R}
ISO 7185 has mandatory range checks (as "dynamic violations"), but whether
adhering to a 30-year-old incredibly badly written standard that was obsolete at
publication (while at the same time implementing features of a far better
language) is a good idea I would seriously consider debatable.
But I don't actually want to debate that here, just collect information for
users.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: portability differences between Borland/FPC
Am 19.08.2018 um 10:08 schrieb Florian Klämpfl: > Not really, you have also to fix the comments below because as soon as the > range is 0..127 and the test is against 127, > Delphi shows exactly the same behavior as FPC. Not really. You don't have to change the range, there is a warning emitted for the Host Type (I>127 in this case), but codegen works on the worst-case scenario for the Storage Type, so the expression is never removed. In other words, W1021 is never treated as the same as an actual False constant. > as soon as [something changes], Delphi shows exactly the same behavior as FPC. But that's kind of the point of this collection: sometimes the rules intersect, but for most cases, they don't. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Docs: portability differences between Borland/FPC
Am 18.08.2018 um 23:39 schrieb Florian Klämpfl: >> This is plainly wrong, at least for the older delphis, the host type in >> delphi will be Byte (or even Shortint). > > It is actually shortint ... Correct, I was thinking of the default PackEnum. Which of course has absolutely nothing to do with that example. Fixed, thanks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Docs: portability differences between Borland/FPC
Hi all, There is the old "Porting TP" document at <https://www.freepascal.org/port.var>, but it is rather incomplete (and probably on an older language level). It also covers mostly syntactic differences - things a programmer will notice because of the error messages. Since #34140 was again someone tripping over an obscure difference between what is documented for the Borland compilers and what is not actually documented in FPC (there's a reason #16006 has so many dupes), I've started writing up some of these things that I could think of right away on the wiki, for now as a draft under my user namespace: <http://wiki.freepascal.org/User:Martok/Portability_Issues> Feel free to suggest more non-obvious topics (or make additions directly, it's a wiki). The general pattern for each topic is "short summary"-"example"-"contrast"-"links". Include citations if possible, especially for the Borland side of things. FPC is easy enough to reproduce for everybody. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] tply: start conditions
Am 10.08.2018 um 12:14 schrieb Martok: > What is really missing then is %x for exclusive start conditions, which would > solve all of that. Things I never wanted to be able to do: run scanner state machines in my head. But: turns out adding %x was less work than finding an alternative solution, once it was clear how the DFA is actually built. It currently lives on my work-in-progress-branch for fpcres: https://github.com/martok/freepascal/commit/79873cd1c8 Proper patches will follow once things settle. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] tply: start conditions
> This is a bit awkward if one has to write the prefix every time...PS - plex > doesn't define a name for the builtin default state, so even that would not > actually be possible. What is really missing then is %x for exclusive start conditions, which would solve all of that. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] tply: start conditions
Hi all, this is more of a generic lex question, but since plex doesn't support the flex extension that could easily fix it, I'm asking here. Take these lex rules: -- %start INCOMLINE %% "//"start(INCOMLINE); \n start(0); .yymore; [a-zA-Z_]([a-zA-Z0-9_])* return(ID); -- The idea is that the comment start sequence "//" puts the lexer in the INCOMLINE state, which eats everything until the next newline, then goes back into the start state. This works for lines like that: Foo// But because lex picks the longest matching rule first, it won't work here: Foo//Bar "Bar" still gets parsed as an ID token, because the identifier rule is valid for any state and considered longer. Flex has Condition Scopes (see http://dinosaur.compilertools.net/flex/flex_11.html near the end), where one could just put all generic rules in a "INITIAL only" scope. This is a bit awkward if one has to write the prefix every time... I have solved this in the past by including a mini scanner in the action because comments are easy, but still... does anyone have a better idea to do this right in the lexer? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Am 25.09.2017 um 14:24 schrieb Sven Barth via fpc-pascal: > The RC language itself isn't *that* difficult. Main difficulty would be to > essentially implement a C-preprocessor-compatible > preprocessor. Just "a few" months later, I finally got around to checking this out. You were completely right, the language itself is not very difficult, and can be processed into a TResource in one pass in a tply-generated parser. The preprocessor is also just a subset of C's (i.e.: no macros), so it would not be too complicated (I've done the same for idlproc before). There are dialect issues between windres and Microsoft RC, but they are minor. The more difficult part is implementing the remaining resource access classes for fcl-res. Well, not difficult per se, but the copy-on-write-sharing thing done there adds a lot of complexity for (IMHO) very little benefit and makes it a bit awkward to work with. There's also a lot of endian conversions that could probably be factored out. That sounds challenging. How much interest would there be in having a full resource compiler, with the appropriate changes/extensions to fcl-res? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] No type info available for this type (Enumerated type with constant assignment)
Am 23.07.2018 um 19:47 schrieb Sven Barth via fpc-pascal:
> Though you'll get an access violation if you use a value that's not part of
> the
> enum (in the example this will happen when the loop reaches the value 3).
Not an AV - an IOError, so it's easy and safe to catch.
I use stuff like this, with aValue being of a generic type:
{$IOChecks OFF}
WriteStr(Result, aValue);
if IOResult = 107 then
Result:= '';
ReadStr(aStr, a);
Result:= IOResult <> 106;
if Result then
aValue:= a;
Turns out this is currently also the *only* typesafe way to check if an
arbitrary ordinal is a valid member of an enum type. But that's a different
story ;-)
--
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] No type info available for this type (Enumerated type with constant assignment)
Am 23.07.2018 um 17:05 schrieb Sven Barth via fpc-pascal: > Is this kind of enumerated type with constant assignment not supported > by FPC 3.0.4? > > TMonthType = (January=1, February, May=5,June, July); > > > The enumeration type itself is supported, however TypeInfo() and thus > GetEnumName() and friends are not. Instead of GetEnumName, you may use ReadStr and WriteStr - the IO functions use their separate tables, which are generated correctly even for enums with assignments. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
Am 14.07.2018 um 13:42 schrieb Florian Klämpfl: >> Still, the Delphi(32) compiler always works with Extended precision at >> compile >> time. See >> <http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declared_Constants#True_Constants>: >> "If constantExpression is a real, its type is Extended" - that type then >> propagates. > > Yes, this is for sure x87 inheritance. On x87 it is in practice always the > case that operations are carried out with > extended precision. Probably. All their current compilers are still pure win32 applications... I have a suspicion that the fact that they put many x87 specific things in the reference might be part of the reason. This is impossible to replicate on FPC (without using the same softfloat on all platforms), so the current situation is the only consistent solution. It is missing documentation however: AFAICS, there is currently no reference for real literal types, and a user inferring from Delphi will have the wrong expectation. Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
Am 12.07.2018 um 23:38 schrieb Florian Klämpfl: > This will result in different results for runtime and compile time calculated > expressions => bad idea. Aye, doing the same at runtime and compile time would be the sane idea. Still, the Delphi(32) compiler always works with Extended precision at compile time. See <http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declared_Constants#True_Constants>: "If constantExpression is a real, its type is Extended" - that type then propagates. So Real literal minimisation (Jonas' original change only exposed it) is another one for the portability notes. Speaking of which, who is admin for the wiki (I couldn't find any contact information)? It would be really useful to have the "Cite" extension available. It should be bundled, just needs to be enabled. The other links were about intermediates of runtime calculations, so this change is correct: > I have added support for the directive $EXCESSPRECISION: it forces that all > binary float operations are executed with > the highest available precision available for the currently selected FPU On that commit, am I blind or is this the same expression twice? <https://github.com/graemeg/freepascal/blob/340c0b3b/compiler/nadd.pas#L159> -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
>> I seem to remember that this was once documented somewhere for Delphi. Can't
>> seem to find it though, so maybe it was a 3rd-party book? There is
>> no hint of it
>> in the FPC documentation, anyway.
> As already noted, it is not necessary in DelphiAh sorry, I was wrong:
> misremembered Integer const evaluation, where you should
cast the first part of the expression to Int64 if you want your expression to be
evaluated as that instead of Integer. Completely different issue.
The fix for #25121 doesn't seem like the best solution. The reported issue was
with explicit casts, I think the truncation should rather be in
ttypeconvnode.{typecheck_int_to_real, typecheck_real_to_real,
typecheck_real_to_currency} ?
That would give bestreal-precision back to const evaluation *unless* the
programmer explicitly casts to a lower precision? During Codegen, casting down
happens anyway because of the storage requirements.
--
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
Am 03.07.2018 um 23:10 schrieb Florian Klämpfl:
>> OK, then two questions remain: Why does is occur/apply only for (newer?)
>> 3.1.1 versions?
> I dug a little bit deeper, the reason is:
> https://bugs.freepascal.org/view.php?id=25121I tried figuring this out,
> sharing what I found here for reference and a workaround.
In the example of 1.0 / 3.0, both numbers are represented exactly in IEEE-754,
so there is no difference caused by this "range-rounding". Typedef passing has
not changed, and the "minimal" types found in the parser at
compiler/pexpr.pas:1711 have not changed for years either.
So the expression is s32real(1.0) / s32real(3.0) {as before}, which then gets
evaluated by taddnode(typ=slashn) at bestreal precision {as before}, and
returned at s32real precision {as before} and "range rounded" to single {this is
new}. It is then stored in a typed const of whatever type was specified {as
before}.
To make sure this works, one has to manually make the const expression be of the
type required:
const
e: Extended = Extended(1.0) / 3.0;
I seem to remember that this was once documented somewhere for Delphi. Can't
seem to find it though, so maybe it was a 3rd-party book? There is no hint of it
in the FPC documentation, anyway.
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
No official answer? Well, that's an answer too I guess. Am 03.07.2018 um 22:25 schrieb Ralf Quint: > However, too many people > just turn all the checks off, because they feel bothered by the all > warnings that the compiler gives them where they are programming in a > very ambiguous and possibly dangerous way. You do realize runtime checks are done at runtime? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Loss of precision when using math.Max()
>> If you compile with range checks on, you get a runtime error. > why are so many folks NOT developing with all the checks (range, heap, stack, > etc) turned ON and then turning them off for production builds??? Actually, while we're at it - it seems to me that for FPC, "all runtime checks enabled" is the "defined" way to use the language, and disabling them is more of an optimization that the programmer may choose? In books about TP and Delphi, it is usually presented the other way around, the checks being a debugging tool for edge cases and not essential. If so, that'd explain some of the issues people have. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPGObjectList error
Am 02.07.2018 um 11:46 schrieb Michael Van Canneyt: > The CHM manual generation is as problematic as the indexing itself. > And the CHM search index is generated by Windows on first use, as far as I > know. Hm, okay. Not really helping then, sorry. > They never were designed to be interlinked: > The programmer's guide contains advanced topics, which the beginning > programmer does not need at all. There are a few exceptions (i.e. "prog:8.2.1 Integer types" links to the ref), but yes, I'm aware this was intentional. Just wanted to suggest that sometimes it would be nice for newcomers to be reminded that these advanced sections exist in the first place. Especially when things are different from TP and Delphi (or even the C equivalents of an expression), one might not find this information at first, even if it's there: take Willibald's recent question about managed Result vars, the recurring question of what precludes inlining, or my confusion about the subtly different range type system. The information is there, but next to impossible to find unless one already knows where it is. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPGObjectList error
> Without a good search feature these are really hard to use. Searching should > be the first priority. Can’t we just make a little script to put on the > server which searches the original indexed format which the HTML is derived > from? It would be so easy to make something that’s cheap but at least works. Un4seen have a pretty good documentation browser: http://www.un4seen.com/doc/ From what it looks like, this is built on the CHM format files? If one could figure out what they use, maybe that would be a step in the right direction? Am 01.07.2018 um 10:03 schrieb Michael Van Canneyt: > Can you explain what you think is wrong with or missing in the official > documentation ? > (apart from a search mechanism) Some sort of interlinking between the manuals would be nice (see how it works for the different BASS libraries, for example). I have still not figured out where exactly the dividing line between the Reference and Programmer's Guide is, and there are many places where they provide information on related topics (formal and implementation aspects, for example) and there is no way to know. I suspect it would help with some confusion around implementation-defined features, if one could simply see "here's a language construct, check out this section to see how FPC handles it". Emba's docwiki is fairly good in that regard. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous. Writing a preallocating wrapper *where needed* for heavily grown arrays is fairly simple. The thing is: it's rarely worth it ;-) I recently did that for a wavefront mesh loader that appends vertices one-by-one to an array, and for a scene with some 400k vertices, the difference was just some milliseconds out of several seconds overall. Turns out the allocator usually finds a spot where the array doesn't need to actually be copied around for a while, and the pure bookkeeping of realloc is very cheap. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C header to Pascal , what is the type of ENUM?
Am 23.02.2018 um 16:06 schrieb Dennis: > In C > ENUM_BEGIN( RetCode ) TA-Lib has very weird macros. It should expand to "enum class RetCode" (so it's actually C++), making this an int or unsigned int (depending on the compiler). Should be a Longword on >32bit compilers then. And (MvC will be disappointed if I wouldn't say it): don't translate as a Pascal enum unless you know what you're doing. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Scoped enums and inferred types
Am 21.02.2018 um 10:45 schrieb Michael Van Canneyt: > I was waiting for this reply from you. You didn't disappoint ;) Got an image to maintain ;-) Took me long enough to come up with that actually fairly simple workaround, might as well save others the trouble. That stuff is like "bad keming", I just can't un-see it. In related news: the example program for #32743 is undefined with more than 10 arguments in fpc and does, in fact, generate slightly wonky code that falls apart at 255 arguments. Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Scoped enums and inferred types
> I doubt that many would be using scopedenums for that.
Isn't that what they're for?
{$SCOPEDENUMS ON}
type
TTileSortingFlag = (Static,
Ramp,
Ignore,
Particle,
Floor,
Flat,
Container,
OnRamp,
BufferStatic,
BufferDynamic
);
As a side note, Ryan: if you need to interoperate with other languages, using
enums is dangerous. FPC has different enum storage semantics from most other
compilers, and will happily drop you into "undefined" behaviour.
Example from C# syntax:
enum Day : byte {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};
is _not_ translated as
{$PACKENUM 1}
Day = (Sat=1, Sun, Mon, Tue, Wed, Thu, Fri);
Instead, write
{$PACKENUM 1}
Day = (_low=low(Byte), Sat=1, Sun, Mon, Tue, Wed, Thu, Fri, _hi=high(Byte));
Regards,
Martok
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Operator overload resolution with arrays
Am 05.02.2018 um 15:49 schrieb Maciej Izak: > for example final code for TFoo< TSomeArray> will be different than for > TFoo declared in other module (!). Crap. True. Now I see why it is how it is. The maximum extent would be to accept overloads (and helpers) that are visible at the parameter type's declaration, because they would necessarily be visible in all specializations as well. That would be pretty much the same as how it currently accepts operators defined on the type, just one symtable up. It would also solve the "implementation restriction" from the manual - and only that. I think? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Operator overload resolution with arrays
Am 05.02.2018 um 15:26 schrieb Martok: > Ah sorry, hadn't seen your message before my last. > >> While specializing the compiler only uses operator overloads (and helpers) >> that >> have been in scope during the declaration of the generic or those that are >> part >> of the types that are used for the specialization. This is definitely >> consistent. > Unintuitive, but consistent, okay. I only just noticed (and I read that page before writing the first message here...): the documentation says this is indeed not intentional? <https://www.freepascal.org/docs-html/ref/refse57.html> """ Currently, due to an implementation restriction, it will not work using a global operator, i.e. the following does not work yet: ... Support for this construct is expected in a future version of Free Pascal.""" ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Operator overload resolution with arrays
Ah sorry, hadn't seen your message before my last. > While specializing the compiler only uses operator overloads (and helpers) > that > have been in scope during the declaration of the generic or those that are > part > of the types that are used for the specialization. This is definitely > consistent. Unintuitive, but consistent, okay. Type helpers for the used type that are in scope at the time of specialization are also not applied. But I guess they don't count as "part of the type", so that's technically true. I may have missed something important about how generics are specialized internally. That would explain what I wrote in my answer to Maciej. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Operator overload resolution with arrays
> Hi, I believe https://bugs.freepascal.org/view.php?id=27690 > <https://bugs.freepascal.org/view.php?id=27690> is all about it. Looks like it. > IMHO this code shouldn't ever work. Any fix means really mess and hell and > more > problems. Why? As the specialized interface gets "inserted" into the specializing unit at that point, so should the implementation be - and at that point, the operator *is* overloaded. Instead, the overload has to be available in the implementation section of the generic type, /unless/ it is a class or record. That seems odd. You know I generally prefer consistency over obscure formal differences ;-) And it's not like we don't already have absurd operator chains without that, see 31215. > * use Generics.Collections I'd like to stick with fcl units, and rtl-generics seems pretty outdated compared to your repo? Of course, the issue itself also occurs with any user code, not just containers. That kind of lookup means *no* overload on non-object types is available to generics declared in other units: arithmetic, Implicit, Explicit etc. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Operator overload resolution with arrays
Hi all, I'm having some logical problems with fgl generic lists and operator overloads. This is essentially the same issue as discussed last year on the forum as <http://forum.lazarus.freepascal.org/index.php?topic=36089.0>. I know how to work around it, just... it doesn't seem very consistent. Take the following simple declaration: type TTriangleIndex = array[0..2] of Integer; TFacetList = specialize TFPGList; operator = (A, B: TTriangleIndex): boolean; This will not work: fgl.pp(948,50) Error: Operator is not overloaded: "TTriangleIndex" = "TTriangleIndex" So, for arrays, the overloaded operator is not found, even though it is in the same interface section. However, this arcane beast would work (although Codetools bail on the double specialization): TTriangleIndex = array[0..2] of Integer; generic TArrayContainer = record x: T; class operator = (A, B: specialize TArrayContainer): boolean; // mimic 'default' attribute on x class operator := (A: T): specialize TArrayContainer; inline; class operator := (A: specialize TArrayContainer): T; inline; end; TFacetList = specialize TFPGList>; Class operators defined on the used type itself are taken into account. That feels a bit inconsistent, given that their scope is equivalent in any other use? I know it's been like that forever, but... should it be? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Register Allocation on x86_64
Hi,
> variables in the same routine. Unlike in e.g. gcc, there are no
> annotations for assembly routines that they expect certain variables to
> be in memory and/or registers, that the block may touch arbitrary memory
> locations, etc. Hence, the compiler is as conservative as possible.
This took me a while to understand, but what you're saying is that the issue is
not so much about what registers might be modified (we could just say that if
the annotation exists, it is assumed to be complete), but that the assembler
code might try to take the address of a variable (possibly with indirections),
which must therefore not be a regvar?
That makes sense. Unfortunately...
> Afaik there are only two limitations:
> * routines containing assembly blocks (including pure assembly routines)
> cannot be inlined> * regular procedures that contain assembly blocks will
> never use regvars
Somehow I have a feeling that the fix for one would also fix the other...
I'd add the manual RIP addressing that was mentioned on the bugtracker recently
(OT: is -Cg supposed to work on platforms where it is not set by default?).
For the original issue, since manually using assembler blocks makes things
complicated, is there a way to "strongly suggest" to the compiler that a
variable should become a regvar if the entire routine is pure Pascal? Something
like the (purely decorative) {register} comments in
/packages/pasjpeg/src/jdcolor.pas?
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Register Allocation on x86_64
Hi all, is it possible that the register allocation on x86_64 is a bit inefficient? No matter the optimization settings, I can never get FPC to use more than the rax and rdx registers. Especially $Optimization REGVAR does nothing (not even for loop variables). Instead, two nested loops are enough to get FPC to constantly do memory load/stores on the loop variables. If an assembler block is marked as using ['rdx', 'rax'] (i.e.: rdtsc), instead of using some other general-purpose registers, FPC stores them to memory before and reloads after the block. That doesn't seem very efficient... Is there anything else that needs to be switched on? I have the target arch set to -CpCOREAVX2. Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why win64 program are considerably bigger in exe size than win 32?
Am 31.12.2017 um 11:15 schrieb Sven Barth via fpc-pascal: > Could/would you provide that tool as open source? Sure! <https://github.com/martok/linkermap> I have attached the win32 binary as a release. > Does it only work with PE/COFF or also ELF?Since I only very crudely parse > the linker map file, I think it should work regardless of executable format? Wouldn't bet on embedded targets though, they might have a different format. Happy to accept pull requests ;) Borland Map files are something entirely different (and inconsistent between versions and frontends!), so no easy comparison for now. > .xdata and .pdata are both used for SEH related data on the non-i386 Windows > platforms (x84_64 and ARM as well as the obsolete MIPS and PowerPC targets). Ah, so they're both exception handling. Interesting to see that is almost as large as the actual code, at least for the "useless" test case. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why win64 program are considerably bigger in exe size than win 32?
Am 22.12.2017 um 09:30 schrieb Dennis: > I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8. > I discovered my program exe size increased from 6M to 9M. Just for fun, I wrote a small program to parse Linker Map files and show the image occupation by source object file (~unit). First lesson: FPC's internal linker is *a lot* better than the GNU linker when it comes to discarding unused parts. Good job there! <http://puu.sh/yR3WX/780bcea8f1.png> Second lesson: the RTL's system and classes are large, compared to Delphi (at least older versions). They can do more as well, so I'll call that a draw. And now the on-topic part: this compares an "empty" project (Lazarus: Project->New->Program), compiled for win32 and win64 <http://puu.sh/yR0Qs/6e26a74cc9.png> As you can see, the win64 image is about a third larger - but not so much because of the code segments (they end shortly after the cyan "bar" for typinfo, before the second occurrence of classes), but more so because of the data sections following. A lot of that is unwind info (.xdata), I'm afraid I don't know what .pdata usually is. Oh, and I finally know why even simple LCL applications are so large: graphics drags in fcl-image, which includes full support for JPEG, TIFF, PNG and requires pasjpeg, paszlib and others. The widgetset indirection is surprisingly small. Just though I'd share that. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.4 released!
>> SourceForge gives checksums, too: > > true, clicking on the 'i' in the rightmost column shows a popup with md5 > and sha1 hashes. Of course, that doesn't prove nobody has tampered with the files as present on SF.net, which is the entire point of signed releases. I take it there's also no Debian reproducible build? Not of particular use to me personally, but I like the idea, especially for a compiler. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC install on windows with limited rights
Am 02.11.2017 um 21:00 schrieb Graeme Geldenhuys: > The FPC team really should consider releasing a Windows binary zip > release too. It really wouldn't be any extra effort as they already prep > everything for Inno Setup, so a simply ZIP command is all that would be > needed. In case you don't need a release version (or the other way around, want a trunk version), you may also want to have a look at my ~weekly snapshots at <http://projects.martoks-place.de/lazarus/>. They're all just plain 7zip archives, and a .cmd to create the fpc.cfg. The directory structure is the same as from the installer, so you can mix & match. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Am 11.10.2017 um 11:24 schrieb Sven Barth via fpc-pascal: > The point of our own resource compiler would be to avoid external > dependencies. True. And having a general-purpose preprocessor would come in useful anyway. Fun fact: windres also just calls gcc, which is probably why we deploy it: #define DEFAULT_PREPROCESSOR "gcc -E -xc -DRC_INVOKED" But it would be a replacement of a somewhat obscure dependency (windres seems to be a crossbinutils thing) with just keeping a standard one. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Am 25.09.2017 um 14:24 schrieb Sven Barth via fpc-pascal: > The RC language itself isn't *that* difficult. Main difficulty would be to > essentially implement a C-preprocessor-compatible preprocessor. As I have just discovered, the installer provides a (rather antique) gcc on Windows and depends on build-essential on (all?) *nix platforms, so we don't even need to do that - piping through "gcc -E -xc" should be all we need. That just leaves a reader for fcl-res. Hm. -- Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] For ..in GetEnumerator Allocation
Am 04.10.2017 um 11:26 schrieb Michael Van Canneyt: > As an alternative you can create an object enumeator. > It's simply allocated on the stack, and you can reset it in the enumerator > operator. That is by far the easiest solution (records need $modeswitch advancedrecords, but are otherwise equivalent). As an example, here's how I iterate over at TNodeSet returned by fcl-xml's XPath engine: <https://pastebin.com/Zj2CLRbX> The object is allocated on the stack and simply cleared/reset every time the operator is executed. -- Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Am 25.09.2017 um 09:12 schrieb Graeme Geldenhuys: > The same could be said about implementing a competing (alternatives to > C/C++ or Delphi) compiler. ;-) Not really though ;-) Rewriting a resource compiler with the same input and output files as the existing one is a bit different than writing a compiler for a new language and targets... However, it seems that for example in Debian, windres is only in the crossbinutils package? That's not quite what I expected... What we really need then is "only" a parser frontend for fpcres, fcl-res already can do all the writing we might ever need. Could someone please check if there exists an issue for it and if not, report it? Might have a poke at it, but I'll probably forget before having the time ;-) -- Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
Am 24.09.2017 um 14:50 schrieb Sven Barth via fpc-pascal: > Please report a bug. Well this is awkward - I tried to provide a test project for the report, and couldn't get it to *not* work. The real-world project that has this issue for me has the resource included from a file in a package, and it seems like this is somehow significant. Might be more of a Lazarus issue then. There is still a bug in that the RES is not recompiled if the PPU is present but the RES is not (causes error 9029), but I'll report that separately, after figuring out what is going on here... -- Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compilation
> Also note that that is only true for Windows. FPC doesn't include a > resource compiler for any other platforms. So if no resource compiler > exists, you will get a compilation error until you make other plans. AFAIK, windres is available for lots of other platforms. If you have to install some package, that shoud not really surprise a developer? I would assume that FPC just tries to call a resource compiler on all platforms and fails with some error message if it isn't available? If so, I wouldn't worry too much about having our own resource compiler. The RC script language is actually quite complex, and there'd be next to no benefit to reinventing the wheel. -- Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Resource compilation
Hi all, the $R directive accepts resource scripts (RC) and compiles the RES file from it on demand. However, that only happens if the RES file does not exist - if it does, the resource compiler is never invoked. Even clean-building the unit from source does not recompile the resource file. This is a bit awkward when the resource script (or any of the linked files) is changed: the only way to recreate the resource unit appears to be removing both the compiled unit and resource file. Is there some sort of flag for this? I'd be fine with just recompiling the resource file every time the unit is compiled, windres is fast enough... Thanks, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] H2pas tool vs others, C header translation
> It is perfectly predictable. Just do not store invalid values in enumeration > variables. And invalid > is everything not being declared. This is how FPC works and will work. Aye. The point being, if the store operation is in a library (a getter, such as mpfr_get_default_rounding_mode), there is just no way of absolutely enforcing that - so the FPC side must be defensive. As you say, enums already contain typing assumptions and are not meant to be defensive, so they can't be used here. That's all I wanted to point out. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] H2pas tool vs others, C header translation
If your header looks enough like IDL (which is essentially C++ with annotations), you may also be able to use one of the available IDL compilers. There are a few dialect issues though, so YMMV. I'd say MPFR has a few defines too many for my idlproc (https://github.com/martok/idlproc), but may come closer for others. As a heads-up: whatever tool you end up using, make sure you do NOT translate the C enums in mpfr.h as enumerations. It will work, but create unpredictable codegen on the FPC side. Use plain constants. -- Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?
> Ideally the function should be portable between FPC and Delphi XE5... You'd only need your own functions for Delphi, FPC's intrinsics such as Insert() can already work with arrays: var b, c: TBytes; begin b:= TBytes.Create(1,2,3); c:= TBytes.Create(10,11); Insert(c,b,2); -> b is now [1,2,10,11,3] -- Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
