dummzeuch

No, this would mean that somebody could create a plugin for a commercial program (of a third party) and release it under the GPL. And then this would force that commercial program to also fall under the GPL. But we degress, this is about the MPL, which is a lot less strict.

The MPL only requires you to provide the sources that are licensed under the MPL, unless you modify the original. In that case you must also make those modifications available. It does not require you to make the sources of your program available. It also doesn't matter whether or is linked into the executable or called as a DLL, so no need to isolate it as a DLL. (Disclaimer: I'm not a lawyer. This is how I understood the license text.)

No, it wasn't removed, it works for me. No idea why it doesn't work for you though. If i remember correctly there is a setting to turn it off, but the default is turned on.

Maybe one of the first things somebody could contribute, are English translations of the comments then. 😉

That "Python project" is PyScripter, one of the most popular IDEs for Python developments. GitHub makes branching so easy, everybody and his brother seems to create his private branch of basically every library in existence, which makes it difficult to see if there is such a thing as an "official" repository. So, welcome to branching hell. 😉 Which version you chose might depend on how much you need / value backwards compatibility. Last time I looked, SynEdit was backwards compatible to at least Delphi 6, SynEdit-2 only to some XE version. SynEdit-2 focuses more on keeping up with the latest Delphi versions.

It's probably just a matter of adding a conditional define to some include file. Maybe - probably at some time in the far future - I fill find the time to future proof the include file to not require an update every time a new Delphi version is released.

The Help has the following to say about System.GetMemory: From that description, I assumed that this function raises an EOutOfMemory if it cannot allocate a block and so I don't need to check whether it returns NIL. Apparently that's wrong. My program just requested a block of 35880960 bytes (for the 50th time, yes that makes 1.7 gigabytes and it's quite possible that it run out of memory) and the function returned NIL on this call any any subsequent calls with that size. Am I missing something here?

No, it's not. There are at least two actively developed forks on GitHub: https://github.com/SynEdit/SynEdit https://github.com/pyscripter/SynEdit-2 The first one is the "Original". I use it GExperts for all Delphi versions from 6 upwards.

The nineties called and wanted their sort indicator back. I'm sure I must have code for that somewhere. It was pretty common back then.

Please file a bug report on sourceforge if you have not already done so.

I'm not aware of any tool that allows this. And I don't know the mechanism behind it. Is there a menu entry that does the same? If yes, you could assign a keyboard shortcut to it.

Definitely the way to go. Trying to clean up an infected system is way more dangerous than rebuilding from scratch. And you could never be certain you removed everything.

Do you mean you had your Windows computer directly connected to the internet and RDP activated? In my eyes that's disaster waiting to happen. There apparently is a big market for RDP addressee and accounts and they are even cheap (Heise online had an article on that today (in. German).)

Why do you use .pas as the file extension? I have never seen anything else but .inc for include files (OK, there is also .tpl but that's a very special case) Regarding the use of the search path: The IDE uses it for include files and also in the given order. But beware: It also uses the library search path configured in Tools -> Options. (And there is a very outdated jedi.inc file in some (or all?) Delphi installations. I don't exactly remember where because I deleted it when I stumbled upon it.)

I have now switched to GetMem.

Because according to the OLH there is no functional difference between GetMem and GetMemory, so I thought I had free choice. And I prefer a function over a procedure when a single value is returned. It makes the code easier to read.

Why not? FastMM should be able to handle that and the overhead should be negligible, since I am not calling it too often. In case you are wondering what I need those memory blocks for: It's a buffer for receiving pictures from a camera which are 5120x1168 pixels in BayerRG10 format. That format uses 6 bytes per pixel. The camera sends 30 pictures per second, so I played is safe and allocated "enough" buffers to last for more than 1.5 seconds. I am still experimenting with the GenICam interface. I didn't think about the required memory, I have to admit, That's what EOutOfMemory is for. 😉

So, what I'm missing is, that the help is wrong: _GetMem calls MemoryManager.GetMemory, checks for NIL and raises EOutOfMemory. System.GetMem simply calls MemoryManager.GetMemory. (That's Delphi 10.2.3) Great! 😞 Now I have to go through the whole program and change the code to either call GetMem or check the result.

I'm just suggesting things to check. What do you mean by "the second Delphi"? Just to make sure You have got two instances of the IDE running: The instance you used to compile and run your expert, which I would call "the first instance". That's the one that is doing the debugging. The instance you started as the host application for your expert, which I would call "the second instance". You should place breakpoints and look at the source code in the first instance. You must always be sure that the expert loaded in the second instance is the one you just compiled. Ideally the expert should not be loaded at all in the first instance. If it's a package based expert that's easy to do by only manually installing the package in the second instance. For dll base experts it's more complicated. For GExperts I am using a pre-build script that renames the existing DLL GExpertsXX.dll to GexpertsXX.dll~ so the second instance will always load the new dll while the first instance will keep on using the old one. Also: Always make sure you are building in debug mode. If you simply compile, some or your units may still be compiled without debug information. As I said: I'm trying to suggest what to check. You probably have done some of it already.

Are you sure you run the project with debugging? One of the first things I always do in fresh install, is removing that "run without debugging" button from the toolbar, because I keep clicking it accidentally.

Those startup errors are normal. It's the IDE that uses these sockets for internal purposes. I also get a few errors for accessing the license file. (That's mostly the reason I added the Filter Exception expert.)

I'm not quite sure and can't look it up right now, but if that's the project i tried, it's for an older version and is dangerous to use with the later ones: Because of changes to the command line parameters, it will overwrite your changes if not fixed! I wrote a fix back then, be should also be on GitHub, but that was a long time ago and I lost interest in it too, so I can't guarantee that it will still work. EDIT: Yes it's the one. Here is the bug report: https://github.com/andremussche/SemanticMergeDelphi/issues/4 And here is my fix: https://github.com/dummzeuch/pas2yaml I also suggested to the developers of SemanticMerge to have an API version number passed to the filters so these can determine whether they support it or not. No idea whether they adopted this, I lost interest since Beyond Compare does most of what I need and I already have a license of it.

Hold the mouse over the profile picture of the person you want to ignore. You will get additional information on him/her. On that panel there is a "Ignore User" button.

Install my Delphi IDE Explorer and have a look around. You will find plenty that does not have a purpose (any more). And if this panel annoys you so much, write yourself a plugin that hides it.

Did you know that this is possible: type TImageConvertOuputConfigEnum = ( IMAGE_CONVERT_OUTPUT_CONFIG_IMAGE_ID = $02, //(1 << 1), //**< output pixels points to a ImageId */ IMAGE_CONVERT_OUTPUT_CONFIG_O0 = $04, //(1 << 2), //**< disable CPU optimizations such as SSSE3 */ IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_1 = $10, //(1 << 4), //**< select bayer decoding method 1 (3x3 interpolation, a.k.a. legacy method) */ IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_2 = $20, //(2 << 4), //**< select bayer decoding method 2 (3x3 median-based interpolation, a.k.a. advanced method) */ IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_3 = $30, //(3 << 4), //**< select bayer decoding method 3 (5x5 gradient-based interpolation) */ IMAGE_CONVERT_OUTPUT_CONFIG_DEFAULT = IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_1, IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_ADVANCED = IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_2 ); This is a translation of a C header file. I only now noticed that the enum contains duplicate values which I until now thought was impossible. IMAGE_CONVERT_OUTPUT_CONFIG_DEFAULT is a duplicate of IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_1, both having the ordinal value $10, and IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_ADVANCED is a duplicate of IMAGE_CONVERT_OUTPUT_CONFIG_BAYER_METHOD_2, both having the ordinal value $20. The Tokyo Docwiki actually has such an example: It compiles with Delphi 2007 so it must have been possible for a long time. "Man wird alt wie 'ne Kuh und lernt immernoch dazu." -- my mother