Hi everyone,
As has been discussed a little bit on here in the past, I've done a bit
more work on my XML node dumping feature. If the compiler is built with
the "DEBUG_NODE_DUMP" define, all source files compiled with it will have
their intermediate nodes dumped to an XML file (they have .ppx
e
I can only reproduce this with peephole optimization turned on (O2). Can
you share more code that reproduces it?
Either way here's a patch that might fix it?
Best Regards,
Jeppe
On 2/3/19 5:31 PM, Michael Ring wrote:
Forgot to mention I am using Trunk compiler from today revision 41187
ond o
On Mon, Feb 4, 2019 at 9:53 AM Martok wrote:
> the first-ever fppkg.exe invocation on a machine
>
Do people actually use fppkg for anything? More specifically what is the
point of integrating it with Lazarus, which already has the OPM?
___
fpc-devel ma
On Tue, Feb 5, 2019 at 3:55 PM Ben Grasset wrote:
> Do people actually use fppkg for anything?
>
I've also been a bit confused about the recent Lazarus FPPKG work. As far
as I can tell all FPPKG itself actually does is connect to a repository
that contains roughly five outdated packages? Is ther
> Do people actually use fppkg for anything?
Well, *I* dont't know anyone, and the recent stuffs certainly isn't any form of
incentive.
But apparently, fppkg is required to discover fpmake packages that fpc already
knows about, because... reasons?
(Disclaimer: I detest any form of package manag
This might prove quite complicated to implement. Writing a similar test
function and modifying my node dump to get what I need (the node dump tool
does its work before the second pass, so inlined functions aren't
expanded), I get a very complicated node tree for a single inlined function
call to
Hi everyone,
So there's a few limitations with the XML dump. Firstly it does its work
before the second pass, so things like inlined functions are not yet
expanded. There are still some minor bugs to work out, like if a string
literal contains < and >, for example, it can cause the XML file to
