Vincent Parrett

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

It suffers the same issues as FixInsight.. a lot of noise produced too. Bothe FixInsight and Pascal Analyser both do a good job of finding simple things and enforcing best practice but they don't do flow analysis. https://blog.sonarsource.com/kill-the-noise-to-change-gear-in-our-code-analyzers Something like SonarQube would be good, there is a delphi plugin, this appears to be the most up to date fork - https://github.com/JAM-Software/SonarDelphi - it doesn't do flow analysis either (like the built in language support in sonarqube does for C# etc). Note I haven't tried it (yet), just peeked at the source code.

https://www.finalbuilder.com/resources/blogs/dpm-package-manager-progress-update

Thanks. It's taking shape quite nicely now.. still plenty to do, but I hope to have a fully working release this year. Once I get the design time stuff working I'll ping you to give it a try with your libraries.

I like this plan. I ran FixInsight over the code and there are lots of opportunities to clean up the code. Unfortunately fixinsight also produces a lot of 'noise' because there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?) - but it's still a worthwhile exercise. I look forward to the day I can install Delphi, chose not to install the bundled Indy and install Indy via DPM, choosing which particular version I want, and not having to modify my projects as Libsuffix will be set on the packages 😉

Umm.... probably not

Umm.. Getit solves very little of anything I'm afraid.

LIBSUFFIX doesn't affect the dcp file names, only the bpl. I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product. Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship).

If the library is just a simple few pas files and doesn't have any design time components then yes, packages are not needed. That said, there are still benefits to providing packages, as it allows the libraries to be compiled and you can then just reference the compiled library files (dcu's) instead of compiling the library every time you build. I recently implemented this in my package manager project and it cut the build time (for 12 delphi versions) from 13 minutes down to 1 or 2 minutes for the package manager projects (command line tool plus ide plugins).

Well I am talking mostly about packages in the post, so in that context it makes sense. Relative paths are fine, until one of the files moves around. I had that issue yesterday with a well known third party package that wouldn't compile.. the relative paths on the includes were wrong.

Agreed, that's what gave me the idea to write the post 😉

Yes, I forgot about that feature. I have updated the post to mention it.

Never mind, I deleted my local copy an checked out again, and it builds fine. No idea why as svn wasn't showing any changes to the source (apart from GXIcons.res which happens during the build).

I just used the build script, which has worked fine for me until this error recently (a few weeks ago I think). The file is there in my local copy too.. so must be a path issue?

I tried building GExperts for 10.4 from source but svn appears to be missing a file I:\GExperts\source\framework\GX_UnitExportsParser.pas(13): error F2613: Unit 'GX_UnitExportList' not found. [I:\GExpert s\Projects\DelphiXx104\GExpertsRS104.dproj] This is after running svn update.

Hi All I have been steadily working away on my package manager project - the latest update includes compile on install support. https://github.com/DelphiPackageManager/DPM When a package is first installed, it is automatically compiled (if the package spec has that support enabled) and then the project references the compiled version of the package. This speeds up builds on your own projects, since you are not compiling the dpm package sources each time. As an extreme example of this, the DPM build process (building for 12 versions of delphi!) previously took 13 minutes on my build server, after installing the latest dpm and running 2 builds (the first one compiled the packages), the build time is down to 2 minutes! Much of that speed up comes from the fact that older versions of delphi are quite slow at building Spring4D. I encourage everyone to check it out and provide feedback where possible. To get started using DPM, download the latest release from here : You will need to configure a package feed (folder) and download some packages - see the Getting started page Most of my open source projects have package files available under the releases tab on github - https://github.com/vsoftTechnologies/ I have also added a mirror project for Spring4D on github so that I could publish packages (bitbucket doesn't support that) - https://github.com/VSoftTechnologies/Spring4DMirror Same for JsonDataObjects - Andreas ignored my pull request for over a year so I closed it and just forked the project - https://github.com/VSoftTechnologies/JsonDataObjects I'm still working on getting design time packages loaded.. need to get proper project group support going first. Previous updates here :

Nice work @Carlo Barazzetta 👍

The simplest option here is to produce 2 versions for the dll, one for internal users, one for external. Any fancy trickery might stop casual users from getting access to the internal functionality, but it won't stop anyone who has the skills to dig in and figure out what is needed to expose it.

I would suggest that if you want everything synchronous then don't use messaging, there's no point and you are just adding overhead for very little gain. We use asynchronous messaging extensively in FinalBuilder, yes it takes a bit of thought but then that's what programming is about. We use our own messaging library which is thread safe. Under the hood we also use omnithread library for some of the more complex threading.

@Dalija Prasnikar something for the second edition 😉 - https://github.com/VSoftTechnologies/VSoft.Messaging It's the messaging system we use in FinalBuilder - uses TObject.Dispatch and unlike System.Messaging, it's threadsafe. Works with VCL and FMX, although I have not tested on mobile as I don't do mobile dev.

Nick doesn't seem to be active with Delphi much these days, doing web stuff last I looked (angular etc).

Nick Hodges did start a project to do this many years ago, but it never got much interest or contributions - I guess we were all too busy testing our own code to bother testing embarcadero's code (which they should be doing). That project was on bitbucket using mercurial, so it's no longer there (bitbucket dropped mercurial support).

I have had good results with Vector Magic - https://vectormagic.com/ The key though is having larger png's to work with. Converting a 16x16px png/bmp to svg is next to impossible as there just isn't enough detail to work with. FWIW, I'm slowly making my way through converting thousands of images to svg (either by converting or finding alternatives), it's mind numbingly boring and am losing the will to live..... 😒

Likewise, and I for interfaces. As for the RTL/VCL inconsistencies - well any 20+ year old large code base will have those, people come and go, with different ideas, eventually adherence to the initial standard will wane or evolve. My code is no different. These days I use camelCase naming for parameters and variable, with occasional lapses into the old style.

We use ssh from our dev machines (we're all working from home in Canberra) to the server (in Sydney, 300km away) over vpn's and have not had any issues with large files. We do have some issues with mercurial and filename encoding on windows as it doesn't fully handle unicode properly on windows - there has been a frustrating lack of urgency to fix this, since the main devs don't use windows.