Vincent Parrett

Not so - they used helpers to avoid breaking dcu compatibility between the other 11.x releases - those helper methods will be merged into the classes in the next major release. Without the binary compatibility, third party vendors would find it next to impossible to support the varions .x releases.

If that were the case, then you wouln't need to change anything at all in SynEdit - but you do as it cannot see SetAdditionalPCREOptions. True, but with the regex they have created 2 helpers, and the TPerlRegex helper is the one causing the issue.

FWIW, the helpers embarcadero introduces in an update should disappear in the next major version, as those helpers were only used to avoid breaking dcu compatibility - so their methods will be rolled into the classes. At least that's the plan.

The one that embarcadero created will be used first, the synedit one will be ignored. Which helper is used is dependant on where they are decleared, since embarcadero declared theirs closest to the actual class declaration theirs will be seen first rather than the one on synedit.

Not sure you can.. the best option would be to change SetAdditionalPCREOptions to AddRawOptions - then it will compile in all supported versions.

Unfortunately they were implemented using a class helper, which now breaks Turbopack/SynEdit https://github.com/TurboPack/SynEdit/issues/229

I had the same issue, we closed our office and went full remote - the address with our DUNS number was still the old office/phone - so I wasn't able to verify via phone call - getting the DUNS details updated outside the US was a nightmare - we eventually got our new certficate a day or so before the old one expired. I won't leave it so late next time. The whole process is very unsatisfactory to say the least - they really need to find a (secure) way to streamline the process. Renewing should not be as hard as getting an entirely new certificate.

This is going to be a nightmare for us. Our CI servers are in a data center in another city (3hr drive) in a shared cage - so there is absolutely no way I can leave a dongle plugged into a server that other companies might have access to. Then there is the issue of sharing the dongle amongst multiple vm's - any of our CI agent vm's can do code signing at the moment - there is also the hassle involved in automating signing with the EV certificates We're currently investigating how this will impact us and our customers.

Does it stop working when you stop paying?

I'm too cheap, Fork is $50, gitraken is a subscription tool.

Yeah I know, pretty sure I was one of them. I've used a lot of version control systems over the years in my day job and git is certainly not my favourite - like it or not it has won the version control wars (for now). FWIW inhouse we use Mercurial (with tortoisehg) - which while similar to git, is simpler - with real error messages! I chose to learn enough git to get by, and with good tools like Fork I get by ok. The days of developers only needing to know one version control systems are long gone, just like the days of only needing to know one programming language.

99% of people working on open source are volunteers, none of us really have the time. I have a day job just like everyone else - I try to fit in my open source in evenings and weekends, in between spending time with family, football (I coach), home renovations etc. If something is going to take hours of research and more hours to develop, then it will likely have to wait until a gap in my schedule opens up. I'm sure I'm not alone in this. So yes projects might look abandonded, and maybe they are, but mostly the contributors are just busy. I don't know what the solutions are, but perhaps the jedi maintainers might enable issues on the github repositories, it makes much more sense to have the issues on the same site as the source code and pull requests (github links nicely between them all). That might spur on some contributions.

Why is this too complicated for people? Pull requests make a lot more sense for open source projects, as they make doing code reviews etc simple - where as with direct commit access there is always more risk that something get's broken, or that the committer takes the project in a different direction than what the project owner wants. I always tell people, before contributing to a project 1) create an issue and discuss with the other contributors/owners - then when everyone is on the same page 2) create a pull request 3) owner and other contributors review and approve/merge. Usually after step 1, if I do not have the time to implement it myself, I tag the issue as "PR Invited" meaning the issue is well understood and deemed worthy of implementation - and a PR that implements the feature/fix etc will have a good chance of being accepted. Sadly most of the time people ask/want but are not prepared to help/contribute. Github is not the barrier.

Yeah there are just too many issues/barriers with XE that made it too hard to support - for all my libraries now XE2 is the minimum I will support.

Before nuget and npm, there were not nearly as many libraries, and those that were out therre were hard to find. It was just like Delphi. Those tutorials you found would not have worked without the ability to restore the packages those projects referenced. If you mean having every third party library you use all installed at the same time - then no. The idea is you open a project in the IDE, DPM ensures that any libraries that project (or project group) uses will be installed. Not just any version of the libraries - the specific version that the project references (this is an important feature that Getit doesn't.. get). If the package has been installed before, it would available in your local package cache and the install takes ms - if not then it will download that package and it's dependencies (another feature Getit is missing) and install them. Sure, but Indy is just one of many open source delphi projects out there. Currrently they all have different instructions for installing.. go and look at the issues tab on github for most of them and there will be loads of people struggling to install them - expecially if they depend on other libraries. Delphi is absolutely being held back as legacy tool because of it's lack of a real package manager (well that and it's poor quality and lack of modern language features). GetIt is a toy, a tightly controlled black box with a curated list of packages (only ones embarcadero likes). Most of those are constantly out dated.. and if you install from there you always get the latest version that they decide on - what happens when that latest version breaks your project - how do you roll back. Being able to control the version of packages used by a project is an absolute must. Add automated builds/CI into the mix - do you really want a random version installed when you run a production build? Anyway, I'll shut up now.. I just get frustrated when I see or read about yet another way to install a single library 😞

Do you use GetIt? Or a package manager on other dev platforms - like nuget for .net, npm for javascript, Gem for ruby, Crate for rust etc. The idea is to provide a standard way to deliver and install libraries. GetIt doesn't meet the expectations of anyone who has used a real package manager. There is quite a lot done - but still plenty more to make it production ready. IDE integration looks like this - installing components into the pallete isn't working yet as it requires more work on the project group support (dealing with conflicts etc). I have also made some good progress on a package server (not a public repo yet). I have so far not managed to get the community interersted in helping out - so progress is painfully slow.

Or you could help working towards an automation tool for all libraries 😉 - I haven't had much time to work on it lately (too busy working on FinalBuilder) but I'm still keen to get it going.. I use it every day with my own packages.

With GDI Scaling - controls don't really do anything special - the OS is doing the scaling - it's not really the best option here. VST uses small bitmaps - which when scaled will look pretty poor - VST has no idea the OS is scaling things. I would go with Per Monitor V2 - which VST does support quite well (I use it and did some of the work on VST high dpi support) - it knows when scaling happens and it can redraw things like the arrow bitmaps rather than scale them.

More like a FinalBuilder script since we are in a dev environment (although either tool can do it).

I have this issue every time I install Delphi. I never use the bundled version, because I have no idea what version it is (usually outdated, they are terrible at keeping third party libs up to date). I cannot look at github and figure out what commit it is and see what has changed. So after install I manually delete all Id*.dcu, Indy*.dcp etc - it's annoying and tedious (have to do it for each platform).

The freeandnil call was on a TStringList, which was owned/instantiated by an interfaced object.

Zero, I know it's not thread safe. It wasn't just freeandnil that solved the issue (if only). Just another tool in the box, which I used then removed. I still don't get why people get upset about FreeAndNil - I have much bigger and more important issues with delphi to deal with (like actual bugs in the ide/compiler/rtl/vcl) rather than worry about something so minor.

I did use that, and it got me closer, but not close enough.

I saw that, but I'm not using the built in Weak stuff - this is in XE7 Win32 before weak was available - I'm using my own weak reference library - it's not as convenient (need to use a base class) but has worked well for me for the last 12 years or so. I still take a hard reference from the weak and check that for nil rather than relying on the .IsAlive property when using it in threads.

I recently spent an entire week trying to fix a bug where in heavily threaded situations customers were seeing random av's. The av's and the stack traces were very random, which made it very difficult to pin down. Debugging threads in delphi is painful at best - any changes to timing can completely mask bugs so using breakpoints was not going to work (and the bug would occur in around 4 out of 40 identical threads). After spending days adding even more (pointless as it turned out) locks all over the show I wasnt' much closer to figuring it out. I suspected it could be a reference counting issue (since I use interfaces a lot), so started sprinkling some FreeAndNils around the code (in destructors) - suddenly those random av's turned into nil pointer exceptions that were much less random. That confirmed to me that the issue was with accessing objects already free'd. The problem turned out to be that I was using weak references where I really needed strong references - a 70hr week of frustration turned into a 4 line change 🤦‍♂️ I really don't understand all the angst and debate about FreeAndNil - use it where it makes sense, or don't - just like any other RTL function or language feature.