Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

-> 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

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

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

[fpc-pascal] Resource compilation

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] Resource compilation

he 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

Re: [fpc-pascal] Resource compilation

, 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.

Re: [fpc-pascal] Resource compilation

ng 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 h

Re: [fpc-pascal] For ..in GetEnumerator Allocation

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 Ceter

Re: [fpc-pascal] Resource compilation

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. ___ f

Re: [fpc-pascal] Resource compilation

loy 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 b320

Re: [fpc-pascal] FPC install on windows with limited rights

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] FPC 3.0.4 released!

es. 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 - f

Re: [fpc-pascal] Why win64 program are considerably bigger in exe size than win 32?

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

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 >

[fpc-pascal] Register Allocation on x86_64

eem 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] Register Allocation on x86_64

central? -- 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

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?

[fpc-pascal] Operator overload resolution with arrays

pecialize 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? --

Re: [fpc-pascal] Operator overload resolution with arrays

mpared 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. --

Re: [fpc-pascal] Operator overload resolution with arrays

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

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 >>

Re: [fpc-pascal] Operator overload resolution with arrays

e 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] Scoped enums and inferred types

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] Scoped enums and inferred types

ad 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-

Re: [fpc-pascal] C header to Pascal , what is the type of ENUM?

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.

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

me 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

Re: [fpc-pascal] TFPGObjectList error

und 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 mai

Re: [fpc-pascal] TFPGObjectList error

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 ___

Re: [fpc-pascal] Loss of precision when using math.Max()

ntial. 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] Loss of precision when using math.Max()

uous 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()

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()

gen, 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()

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()

g 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] No type info available for this type (Enumerated type with constant assignment)

r 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 ___

Re: [fpc-pascal] No type info available for this type (Enumerated type with constant assignment)

afe 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] Resource compilation

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/exte

[fpc-pascal] Resource compilation

e DIALOG or MENU have a custom format in their RawData, but that should be fairly straightforward, basically doing the same as the ACCELERATOR resource and tutorial. -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lis

[fpc-pascal] tply: start conditions

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] 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.

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 so

[fpc-pascal] Docs: portability differences between Borland/FPC

;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] 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

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 f

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

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

Re: [fpc-pascal] Resource compilation

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] Resource compilation

ranslation 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.freepasc

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

Re: [fpc-pascal] Hint converting to int64

s was an internal typeconvn? -- 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

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 fpwidestr

Re: [fpc-pascal] Concatenating CP Strings

"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@l

Re: [fpc-pascal] Concatenating CP Strings

- 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

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.o

Re: [fpc-pascal] Concatenating CP Strings

t 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

e 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 ___

Re: [fpc-pascal] Concatenating CP Strings

, 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 ;-)

Re: [fpc-pascal] Default record const values

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] Generics question

ew.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". -- Regar

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 cen

Re: [fpc-pascal] Implicit generic specializations

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] Candidate for crowd-funding

rame-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] Candidate for crowd-funding

arameters 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

Re: [fpc-pascal] SetLength warnings - request

lization 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] SetLength warnings - request

erpreted 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 ma

Re: [fpc-pascal] SetLength warnings - request

ortability 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-pas

Re: [fpc-pascal] SetLength warnings - request

x27;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

ay 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] 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

[fpc-pascal] CLI argument parsers (was: Resource compilation)

/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

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

Re: [fpc-pascal] CLI argument parsers

s 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

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-

Re: [fpc-pascal] Implementation through interface delegation not pass to descendant

ted 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 "

Re: [fpc-pascal] fpPDF and support of Latin2 charset

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 mai

Re: [fpc-pascal] Convert codepages back to UTF8

code 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] Convert codepages back to UTF8

ngCodePage(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

[fpc-pascal] Heavy heap fragmentation issue

MB 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] Heavy heap fragmentation issue

nly 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

Re: [fpc-pascal] Heavy heap fragmentation issue

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

Re: [fpc-pascal] Heavy heap fragmentation issue

ly 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] String conversions

(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. _

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?

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 boot

Re: [fpc-pascal] += property bug?

nore 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 the

Re: [fpc-pascal] += property bug?

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

Re: [fpc-pascal] Very vague gettickcount64 description?

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] Very vague gettickcount64 description?

ying 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 - fp

Re: [fpc-pascal] Very vague gettickcount64 description?

hould. 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. --