Vincent Parrett

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.

Agreed, however you don't have to answer all of those.. most have a prefer not to say option. I really don't know why they need to ask about my sexuality etc 🙄

Ah the drop bears, those are reserved for hot Swedish tourists -

🤣 it is true there are lots of animals that could kill/injure you , giant spiders eating cows - not so much redback spiders - quite common, but once you know about them not much of an issue - just don't put your hands in places where you can't see without gloves on. kangaroos - very common, see them all the time while out walking - just give them a wide berth and they will just stare at you or hop away - the most common dangerous encounters are when they jump out in front of your car at the last second.. had several of those, as has my wife, daughter, son and brother (in my car!). Insurance is expensive here. Snakes (a few of the most venomous in the world) - common in the bush and in some parts of the country they are everywhere - I've not had any close encounters, but I'm always wary when bush walking. Salt water crocidiles - they live up north - avoid rivers and the sea past certain lattitudes (I live down south so not an issue). Fresh water crocidiles - mostly in the north/north west - they rarely attack people but can do some serious damage, so best avoided. Irukandji jellyfish - mostly in the tropics - don't swim in the sea There are others but in all of the above fatal encountes with them are easily surpassed by vehicle accidents, heart disease, diabetes etc.

I've had zero success recruiting delphi developers in the last few years - devs here in Australia do not want to work with delphi. I have found most devs also only apply for jobs that state the toolset they will be using (or they ask when applying) - advertising a job that doesn't mention that doesn't generally help. I tried doing that once and had people walk out of interviews when I told them we use Delphi - sadly most said they had never heard of it plus the odd "oh is that still around" . Younger devs want to work with what ever is the current flavour of the month (js react, go, rust etc) and I can't really blame them for that. Unfortunatly delphi suffers from many issues which are a turn off for employers and prospective employees. Poor quality - this has been an issue for a very long time (since the Inprise era). Each release improves a little, but then bring new issues, and many issues remain unresolved for years. Lack of language evolution - the language has barely changed - where other languages like C# etc have - yes there has been some tinkering around the edges, but apart from generics not much really. Lack of investment - in the early days Delphi sold like hotcakes - but that income was syphoned off to other "enterprise" products that never went anyway (Inprise era). I don't see any evidence of that ever recovering. Imho the poor quality is what has really turned many people away. TBH I would be embarrassed training a new dev on Delphi, having to explain all the work arounds etc that I use almost without thinking (like restarting the IDE many times each day), it would be just too time consuming and frustrating. Some days the frustration levels have me looking for career change! So is it any wonder that delphi jobs are few and far between. Here in Australia I see one or two a year advertised - and then those usually worded to suggest the job involves migrating their projects to other languages like C#.

Sorry I didn't see this thread back when it was originally posted. I have never used the JCL stack trace provide - and github seems to have lost the history for the file since I re-orged the repo layout - so not sure who contributed it (was a long time ago). I have used the madExcept one in the past, but generally only rare occasions when a test fails on the CI server but not on my machine. You do appear to have performed the correct steps to enable it. The stack trace is currently only reported in the NUnit and JUnit loggers. The feature isn't implemented - the value is hard coded in the output - probably to satisfy a parser somewhere. While DUnitX does count the asserts per test, it doesn't currently have a way of reporting the total number of asserts. If you are still needing this it would be worth logging an issue on github so it doesn't get forgotten.

It looks like this was never implemented. I have never used the gui test runner - I prefer TestInsight - but it should be relatively simple to implement - a quick look suggests it could be added in TGUIVCLTestRunner.ProcessMessagesForNode - follow the pattern use for messages. Happy to accept a PR for this 😉

Ok, I was using the document class to parse - didn't realise I could use the node class directly.

^ This. I looked at using the parser in a console application but the requirement for a canvas etc brings in the vcl makes it a non starter (can't use the vcl at all under docker). I've had this issue with several well known third party libraries - the lack of layering and tight coupling with the vcl in libraries really reduces their possible uses.

This ^, you shouldn't modify TDUnitXNullLogger - just create new logger (implements ITestLogger). Most of the methods would be no-ops (like the null logger).

🤣 Well that me actually laughing out loud after a day from hell, thanks 😂

This ^ is also a LOT faster than TThread.Resume