Jump to content

Anders Melander

Members
 View Profile  See their activity

  • Content Count

    2297

  • Joined

  • Last visited

  • Days Won

    119

Posts posted by Anders Melander

  2. Posted

    1 hour ago, Uwe Raabe said:

    And before someone claims that could have been found during the beta: Most of the GetIt stuff is not available during beta until almost the last day and the majority of beta testers install in a dedicated environment without any prior Delphi version present. Also, not everyone makes use of all what is available in GetIt.

    If only there was a way to solve that problem...

  5. Posted

    57 minutes ago, David Heffernan said:

    Anyway, if you really care about performance you'd surely not be using delphi, literally the worst compiler for performance.

    It's possible to care about more than one single thing.

    Personally, I care a lot about performance but I also care about code readability, ease of UI design, and TBH, the amount of fun I have writing the code. If I only cared about performance then I probably wouldn't use Delphi.

    • Like 3

  6. Posted

    2 minutes ago, Uwe Raabe said:

    Indeed, for me the biggest enhancement is the handling of font sizes regarding dpi changes. This eliminates a plethora of workarounds where fonts are adjusted in height, color or style and thus cannot rely on the ParentFont mechanism.

    Yes, that ParentFont thing was what has kept me from making my application DPI aware. I do hope they got it right this time.

    I can imagine that the 3rd party suppliers, which have to support older versions too, won't enjoy having to adapt to the new way of scaling and maintain compatibility with the old way.

     

    7 minutes ago, Uwe Raabe said:

    Besides that, there are currently 15 issues I reported in Quality Portal marked fixed in this release. Not that bad.

    Yes, from the list of compiler and RTL fixes and improvements alone, this looks to be one of the better releases. Not so much in terms of new gimmicks but I don't really need those (or the bugs that come with them) anyway.

    Now if I only had time to actually install it and try it out 😞

    • Like 1

  7. Posted

    16 minutes ago, David Heffernan said:

    there's not much there in my opinion.

    I'm guessing all the people who have already implemented workarounds to handle HighDPI font scaling will think there's a bit too much 🙂

     

    14 minutes ago, Stefan Glienke said:

    TBH IMO using years is kinda ok and a version number where the number after the dot means "update to that version".

    Hmm. As a developer, the year tells me nothing; I can't trust that the value actually specifies the year the product was released (because: marketing) or how far there are between versions (because: D2008).

    Anyway, the damage is done. I just hope they now stick with the sequential numbering.

  9. Posted

    15 hours ago, JohnLM said:

    By the way, I do like the name they gave this one. 

    Then please stop using it.

     

    Referring to a release by name instead of the version number which everybody recognizes, is just confusing, and everyone, Embarcadero in particular, should just stop doing it. It's pretty annoying having to Google it when someone refers to the name instead of the version number. I haven't bothered with the names since Ivory (see what I mean?).

    It's bad enough that the version number and build number haven't been in sync since marketing took over and made the numbers "hip" with D2xxx and later XE*

    • Like 7
    • Thanks 4

  11. Posted

    2 hours ago, Rafael Dipold said:

    A note to anyone looking at this thread: 

    https://stackoverflow.com/questions/74164165/is-there-a-way-to-setup-a-shortcut-to-re-run-the-delphi-lsp-instances

    I can confirm that Uwe's solution works. I've been using it for a long time without any problems. The IDE automatically restarts the LSP if/when it dies (apparently they expected it to crash occasionally).

  15. Posted

    1 hour ago, Clément said:

    Is there any known limit I should be aware of?

    No; I think our scorn for this design choice will be limitless 🙂

     

    4 minutes ago, Attila Kovacs said:

    Nevertheless, I would rewrite the generator to produce 16 (0-F first byte) array constants, sorted by the MAC address rather than the vendor. Additionally, I would substitute the vendor string with a lookup table to eliminate the redundant entries. 

    https://en.wikipedia.org/wiki/Trie

    And store the data in a resource.

    • Like 1
    • Haha 1

  16. Posted

    Here's a quick update on the two issues @Allen@Grijjy encountered:

    • The problem with the overlapping segments has been worked around in code by ignoring conflicts caused by the .tls segment.
      Incidentally, Allen found an old QC report about a similar issue (RSP-12824). Unfortunately, that issue was closed by someone who apparently doesn't understand what the map file segment offset values signify.
      Regardless, an overlapping .tls segment now only produces a warning message.
       
    • The filter problem turned out to be a copy/paste problem.
      Allen had copied his map2pdb parameter list from a post here, and somewhere along the way, two invisible zero-width no-break space characters (#$F0FF) got inserted into the string he pasted. So what looked like '-include:0001' was actually '-include:000'#$F0FF#$F0FF'1'.
      I've been bitten by that one myself a few times when I've copied code from a browser.
    • Like 2
    • Thanks 1

  17. Posted

    9 minutes ago, Allen@Grijjy said:

    Notice (2) things.  First I get all the sources lines, but before I did not.  Also I get a Range Check Error (at the bottom).  I am really using the syntax correctly?

    The syntax is correct. I fixed the Range Check Error yesterday. Pull the latest source.

     

    10 minutes ago, Allen@Grijjy said:

    I guess I don't understand the benefit of generating a PDB without line information? 

    There's no point in having a PDB without line information and, given the parameters you use, you should get a usable PDB.

     

    You can mail the map file to anders🍥melander.dk

     

    16 minutes ago, Allen@Grijjy said:

    I grabbed to PE information for it.  It does seem quite different from Delphi's output:

    Actually, apart from the .tls problem, they look fine to me.

    You have to take into account that the PE Tools segment offsets are relative to the image base (see the Optional Header dialog) while the map file offsets are absolute assuming an image base of $00400000.

     

  18. Posted

    22 minutes ago, Allen@Grijjy said:

    This is where I am confused (and I have read all the existing documentation).  You recommend configuring a tool in Delphi with these parameters:

    -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001

    Yes. This is the exact default setup that I use.

     

    I have an additional two setups; One that includes everything (without the -include filter) and one that excludes a bunch of units (-exclude:dx*;cx*;winapi.*;vcl.*;data.*;firedac.*;soap.*;web.*;datasnap.*;id*;vcltee.*) to keep the size of the pdb down.

    On a related note, I've been considering making a GUI for this so that the filters can be specified visually (I believe AQTime does this). Often you know exactly what part of the code you want to profile and having PDB info generated for the rest is just overhead.

     

    32 minutes ago, Allen@Grijjy said:

    Is my syntax correct or am I supposed to be doing this:

    -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001;0002;*

    so I am indicating both filenames and segments to include?

    No, that's not necessary.

    By default, everything is included. It's only when you specify an inclusion filter that everything by default becomes excluded.

     

    36 minutes ago, Allen@Grijjy said:

    I think it's a great tool and would love to do an Embarcadero Coderage MVP session on how to use some of the industry standard profilers with your utility in the future, if that's okay.

    Yes, of course it is. We really need more awareness among Delphi developers of the tools available to them.

     

    40 minutes ago, Allen@Grijjy said:

    I noticed other people have encountered the same issue with consuming overlapping segments.   In my case I modified the code to skip the overlapping segments instead of raising an exception and stopping.

    That was my initial way of dealing with overlaps but the problem with that is that you don't know if the segment you're skipping is the "correct" one. And you might need the segment later on if there are references to it elsewhere in the map file.

    So far I don't have enough test cases of map files with these overlapping segments to be able to make a decision on how best to handle them, so if I could get my hand on the one you have that would be great.

    Also, if you could examine the corresponding exe file (I recommend using PE Tools) to find out what the actual segment offsets and sizes are (because they're obviously not what the map file states) that would be a big help.

     

    1 hour ago, Allen@Grijjy said:

    Start                 Length     Name                   Class
     0001:0000000000401000 006CD7B8H .text                   CODE
     0002:0000000000ACF000 000A9208H .data                   DATA
     0003:0000000000B79000 00011F20H .bss                    BSS
     0004:0000000000400000 00008260H .tls                    TLS
     0005:0000000000BDE000 0004FF5CH .pdata                  PDATA

    The .tls segment does seem to be a common factor among the various segment-related problems. For example:

    image.thumb.png.7340e6b353af393be9781b6f914d2e0e.png

    Again, I could just ignore segments with Offset=0 but then I would get errors later on as there are symbols referencing it. Another solution would be to hardcode handling of the .tls segment but I would really like to avoid a fragile workaround like that and keep the handling generic.

     

    Right now I'm mostly leaning toward marking segments causing overlap, or with offset=0, as invalid and then simply ignore all later references to them.

     

    The best would of course be if Embarcadero fixed the map file but I'm not holding my breath for that, and I still need to be able to handle what's already out there.

  19. Posted · Edited by Anders Melander

    4 hours ago, chkaufmann said:

    Should I care about these errors when creating the pdb file? How to understand the error and how to solve it?

    They are not errors.

    The "debug" prefix tells you that they are diagnostic messages produced because you specified the -debug switch.

     

    4 hours ago, chkaufmann said:

    Where can I find a good tutorial for VTune in order to get the info I used before with AQTime?

    I have no idea. I guess there's probably something on the VTune site or maybe some help installed with VTune.

     

    2 hours ago, Allen@Grijjy said:

    I figured out that -include:0001 (or whatever code segments you are analyzing) doesn't actually load the source lines.

    -include and -exclude are filters that are applied after the map file has been parsed.

    • If neither is specified, everything is included.
    • If -include is specified, everything that doesn't satisfy the include filter is ignored.
    • If -exclude is specified, everything that does satisfies the exclude filter is ignored.

     

    2 hours ago, Allen@Grijjy said:

    if I switch to -include:* (using a filename wildcard instead) it works.

    -include:* does nothing since it just includes everything - which is the default.

     

    2 hours ago, Allen@Grijjy said:

    Also, it has some issue with overlapping segments from the map files, so I had to make a source code change to work around it, but that issue may be project specific.

    Well, overlapping segments should never occur so that would be a bug in Delphi if you have that in the map file.

    In the first version of your your other message, you stated that you encountered some exceptions but were able to work around them by modifying the source. I'll of course be interested to know exactly what the problem was and what you changed, so I can get it merged into the source if there really is a problem.

     

    I'll probably also need to see the map files to get to the bottom of this. You can either create a (public) issue at Bitbucket or PM them to me here.

  21. Posted

    6 minutes ago, Anders Melander said:
    On 10/19/2023 at 8:39 PM, Renate Schaaf said:

    It will pass the uniform color tests now. But it will fail the Gauss-RMS, since I changed to RadiusToSigma back.

    Okay, but why?

    Oh, I think I see what you are doing.

     

    Is it correct that...

    Quote

    2 * Ceil(Sigma * Sqrt(-2 * Ln(1/255)))

    ...gives you the smallest size of a kernel containing all values >= 1/255?

     

  22. Posted

    On 10/19/2023 at 8:39 PM, Renate Schaaf said:

    It will pass the uniform color tests now. But it will fail the Gauss-RMS, since I changed to RadiusToSigma back.

    Okay, but why?

     

    As you know, my calculation is based on FWHM:

    Quote

    Ratio between Radius and Sigma
    Calculated as:
       Ratio = 1 / FWHM (Full Width at Half Maximum)
             = 1 / (2 * Sqrt(2 * Ln(2)))
             = 0.424660891294479
    Note: Gimp uses the value 0.30038663 (1 / 3,329042969) = 1 / Sqrt(-2 * Ln(1/255)).
    The Gimp value is quoted in a lot of places - most often with a comment that it's incorrect...

    and the value you use now is the same as Gimp's but I don't understand the rationale for that calculation.

     

    Of course, one can use any radius/sigma factor one chooses since it's kind of an abstract value (for some algorithms) but it makes it a bit difficult to compare blurs if they don't use the same scale.

     

    The Gaussian RMS test isn't that important, BTW. AFAIR, it does a blur of a single-pixel vertical line and then compares the horizontal pixel values to the ideal Gaussian curve. If your Sigma/Radius differs from the one I use for the test curve it will show in the RMS. For example, a single pass box filter will have a high RMS. Two passes will produce a lower RMS, and three passes even lower, etc., as the filter approximates closer and closer to the Gaussian.

     

    The more important test is the Gaussian signal loss. In that, I sum the blurred pixel values and compare that against the summed Gaussian values. I.e. I compare the integral of the filter and the integral of the ideal curve. In theory, they should both equal 255. In practice, rounding errors make this difficult to test precisely. For example, the sum of the ideal curve is 252 for a radius of 10.
    Your algorithm has a loss of zero against the theoretical ideal curve (i.e. you have a sum of 255). This test should not be affected by the Sigma/Radius value.

     

    FWIW:

  23. Posted

    19 minutes ago, Yaron said:

    Since whatever string that needed to support unicode is already defined as "WideString", I thought of doing a blind search and replace from "String" to "AnsiString".

    Don't do that; I don't know your code but I would think that very few strings actually need to be AnsiString.

    And even if your code already supports Unicode there can still be places that assume that SizeOf(Char)=SizeOf(Byte) and SizeOf(PChar^)=SizeOf(PByte^).

     

    Also, WideString is not the same as UnicodeString. WideString should generally only be used with COM.

    https://docwiki.embarcadero.com/RADStudio/Sydney/en/String_Types_(Delphi)

    Quote

    UnicodeString variables are reference counted, and two or more of them can reference the same value without consuming additional memory.

    Quote

    WideString is appropriate for use in COM applications. However, WideString is not reference counted, and so UnicodeString is more flexible and efficient in other types of applications.

     

    • Like 2

  24. Posted

    51 minutes ago, Fr0sT.Brutal said:

    Compiler will give lots of hints and warnings from which you can start

    And so will the users if he just ships it 🙂

     

    But seriously; There's already lots of good advice here. If I should add anything it would be to make sure that you do all this under version control (re: Git). That relieves some of the pressure of changing something that works into something that might potentially be full of bugs. It also makes it easy to see what you've changed so far.

×