Vincent Parrett

Strange. I am logged in, and can view issues, but clicking on create redirects me to that page.

Actually they can't

My experience over the last 20 years is that many new devs just do not want to learn delphi. I lost count of how many times people I was interviewing had either never heard of Delphi, or were surprised to hear it was still arround. People want to learn languages which they see a future in, which are modern and supports modern development targets. These days that is the web or mobile.

looks interesting - but for historical reasons I'll probably not use anything from them (currently working on replacing SBB).

Tokens are not free - so vendors will pass on the costs of the token (probably with a nice margin built in) - so in 3yrs time that 5yr cert you paid for will end up costing again, unless they charge you up front for a token now. If you really want to, you can read the info here : https://cabforum.org/wp-content/uploads/Baseline-Requirements-for-the-Issuance-and-Management-of-Code-Signing.v3.2.pdf Not an easy document to read though.

When it comes to certificates, there really is no such thing as a renewal process - you are effective buying a new one each time. I would love to think that once you have bought one from a vendor before, the renewal process (the validation part) would be a little smoother but that has not been my experience in the last 20 yrs. The change to hardware only based keys is fast approaching. Since I blogged about his last year the date was extended to 1 June 2023 - a lot of the vendors had already stopped selling software keys, but with the extension they opened up again. Our standard certificate expires in Oct - I'm half tempted to renew for 3yrs before June 1 just to kick the can down the road a for a while.

Rebuilt all my third party libs and my main project - so far so good. LSP seems a bit better, navigation between projects in a group seems to be working better than before.

Using conditionals compilation in a dpk or dpr is problematic - the IDE does not handle it well.

That's intersting, I tried it today and it didn't work, not sure what I did wrong but will try it again. There is another property for dll's - OutputExt (in the dproj) - in the IDE it's called "Target file extension" - for dcc32 it needs a command line option. Not sure when it was introduced, need to investigate for finalbuilder. Thanks.

DLL projects do not support LibSuffix, so if you want to generate dll's with a different naming convention (with the default being the same for every dproj) - how do you do that if you are just copying a single dproj. Sure you can do that during the copy/generation of the projects if you code it, but where do you configure that (rather than hard coded in the generator)? BTW, I can no longer see UweRaabe/PackageMagician on github?

ok, perhaps it's just me that needs that.

looking through my projects on github - I found one example so far - I need to change the name of the project and output dll for expert dll's - if I'm just rehashing a single dproj then where do I configure that?

I don't have a concrete example to hand. So perhaps it is just a gut feeling.

Simply adding or changing the units or resources that need to be included in a dproj for specific compiler versions. Or compiler options for that matter - delphi is not without it's issues that needs work arounds.

My issue with this is that it's not uncommon for the units etc to differ between platforms. If we use the latest version and just copy that then any customisations you need to make to a particular version would be lost each time you generate the packages.

Yeah I understand! I really wasn't planning on working on this, but I realised after reading this thread that it was a major pain point on my OS projects. Thanks, that's useful to know. I've only gone as far back as XE2 as that's the earliest version I have installed or support in my projects.

@Uwe Raabe are you interested in helping out with this project (since you are the dproj wizard!) - https://github.com/VSoftTechnologies/DPackGen The idea is to create a definition file which can be used with the tool to generate dpk/dpr/dproj files for the supported delphi versions - something that pretty much all delphi library authors struggle with (add one file, edit 50 files to add that one file!). I have the basics working - dproj generation is somewhat iffy as I need to figure out all the differences in the various dproj versions. Also need to flesh it out with more properties etc in the definition file.

I did end up using JSON - simply because it's easier to parse I have made a start on this - https://github.com/VSoftTechnologies/DPackGen Example definition file. It's modelled on how I did the package spec files for my packag manager project (which I really need to get back to!) - so I was able to copy/pasta a lot of the code or at least borrow the design of the definition parsing and package generation. Supporting XE2-11.x I uses templates, you can define more than one if a compiler version needs different settings. I might also look at allowing templates to inherit from another template, so if a template only needs to change a few settings it can be a bit less verbose. Note that you don't have to use the template, you can define all the settings on the targetPlatform - just remove the template property and fill in the rest of the props like in the template - but using templates reduces verbosity. { definitionSchemaVersion: 0, name : "VSoft.MessagingR", packagesFolder: ".\\packages", projectGUID: "{8FF7EA44-009F-4370-BDA2-3C30D26F6FC9}", frameworkType : "VCL", packageType : "Runtime", targetPlatforms : [ { compiler : "XE2", platforms : "Win32, Win64", template : "default" }, { compiler : "XE3", platforms : "Win32, Win64", template : "default" }, { compiler : "XE4", platforms : "Win32, Win64", template : "default" }, { compiler : "XE5", platforms : "Win32, Win64", template : "default" }, { compiler : "XE6", platforms : "Win32, Win64", template : "default" }, { compiler : "XE7", platforms : "Win32, Win64", template : "default" }, { compiler : "XE8", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.0", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.1", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.2", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.3", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.4", platforms : "Win32, Win64", template : "default" }, { compiler : "D11", platforms : "Win32, Win64", template : "default", libSuffix : "%compilerVersion%" } ], templates : [ { name : "default", libSuffix : "%compilerVersion%", folderNameTemplate: "Rad Studio %Compiler% %CompilerCodeName%", descriptionTemplate: "VSoft.Messaging Runtime for Delphi %Compiler%", files : [ ".\\src\\VSoft.Messaging.pas", ".\\src\\VSoft.Messaging.Internal.pas", ".\\src\\VSoft.Messaging.Dispatchers.pas", ".\\src\\VSoft.Messaging.Channel.pas" ], requires : [ "rtl" ], dpkOptions: [ "{$R *.res}", "{$IFDEF IMPLICITBUILDING This IFDEF should not be used by users}", "{$ALIGN 8}", "{$ASSERTIONS ON}", "{$BOOLEVAL OFF}", "{$DEBUGINFO ON}", "{$EXTENDEDSYNTAX ON}", "{$IMPORTEDDATA ON}", "{$IOCHECKS ON}", "{$LOCALSYMBOLS ON}", "{$LONGSTRINGS ON}", "{$OPENSTRINGS ON}", "{$OPTIMIZATION OFF}", "{$OVERFLOWCHECKS OFF}", "{$RANGECHECKS OFF}", "{$REFERENCEINFO ON}", "{$SAFEDIVIDE OFF}", "{$STACKFRAMES ON}", "{$TYPEDADDRESS OFF}", "{$VARSTRINGCHECKS ON}", "{$WRITEABLECONST OFF}", "{$MINENUMSIZE 1}", "{$IMAGEBASE $400000}", "{$DEFINE DEBUG}", "{$ENDIF IMPLICITBUILDING}", "{$DESCRIPTION '%description%'}", "{$LIBSUFFIX '%LIBSUFFIX%'}", "{$RUNONLY}", "{$IMPLICITBUILD OFF}" ] } ] } I used my package manager to install the dependencies (JsonDataObjects, Spring4D.Base & VSoft.CommandLineParser) so if you want to build it you would need to grab those projects from github/bitbucket and update the search paths. DPK generation mostly works - need to figure out how to deal with forms/frames. DPROJ generation is a work in progress - not there yet - the dproj format is not trivial to generate due to config inheritance etc. Hopefully I will find some time over the weekend to work on it and get it to a usable state. I need to flesh out the properties for the TargetPlatform/Template for things like search paths, namespace prefixes, output paths etc. BTW I have not made any provisions for generating CBuilder packages - I guess that can come later if someone wants to work on it - I don't have a need for it so not likely to do it myself.

The cool thing about generating the dproj files from scratch (rather than using a template) is we don't need to generate a lot of the sh1te that rad studio does. Using templates would be tricky due to the differences between delphi releases. So I'm not keen on templates as such. More likely I will implement this in dpm itself.. as a dpm package could have more than one delphi package (dpk) in it. There is already a stubbed out dpm spec command

Actually it's probably not that much work to create a package generator - the hardest part will be creating the definition schema. Something like this (YAML) schemaVersion: 0.1 package: name: VSoft.MessagingR compilerVersions: XE2-11 libSuffix: %compilerVersion% packagesFolder: .\packages folder-template: Rad Studio %ProductVersion% %CodeName% platforms : Win32, Win64 files: - .\src\VSoft.Messaging.pas - .\src\VSoft.Messaging.Internal.pas - .\src\VSoft.Messaging.Dispatchers.pas - .\src\VSoft.Messaging.Channel.pas requires: - rtl compilerOptions : | {$R *.res} {$IFDEF IMPLICITBUILDING This IFDEF should not be used by users} {$ALIGN 8} {$ASSERTIONS ON} {$BOOLEVAL OFF} {$DEBUGINFO ON} {$EXTENDEDSYNTAX ON} {$IMPORTEDDATA ON} {$IOCHECKS ON} {$LOCALSYMBOLS ON} {$LONGSTRINGS ON} {$OPENSTRINGS ON} {$OPTIMIZATION OFF} {$OVERFLOWCHECKS OFF} {$RANGECHECKS OFF} {$REFERENCEINFO ON} {$SAFEDIVIDE OFF} {$STACKFRAMES ON} {$TYPEDADDRESS OFF} {$VARSTRINGCHECKS ON} {$WRITEABLECONST OFF} {$MINENUMSIZE 1} {$IMAGEBASE $400000} {$DEFINE DEBUG} {$ENDIF IMPLICITBUILDING} {$DESCRIPTION 'VSoft.Messaging Runtime for %ProductVersion%'} {$LIBSUFFIX '%LIBSUFFIX%'} {$RUNONLY} {$IMPLICITBUILD OFF} The idea being there would be a bunch of built in variables like CompilerVersion, ProductVersion etc that can be sprinkled in the template and then replaced when the dproj/dpk files are generated. Obviously there is more to add to the above, like output folders, configs etc.. but it should be pretty simple to build on it. I'll make a start and chuck it up on github, open to suggestions on the definition schema. I'll probably use https://github.com/neslib/Neslib.Yaml for the yaml parser (haven't tried it yet though).

This is something I have thought about doing - managing package files for multiple compiler versions is really tiresome. The dproj format has evolved a bit over the years.. but it shoud still be doable. A command line tool that takes in a definition file and spits out the dpk and dproj would be pretty awesome. I should have some free time in 2036 to actually do it🙄

Ah ok, I misread their site - was looking at this page - https://about.gitlab.com/solutions/open-source/join/ Didn't realise that was for the full version of gitlab.

Much simpler to switch to github, for gitlab you have to apply for free hosting of open source.

I use generics a lot in non container/collection scenarios - for example Delphi Mocks fluent api uses the generic type to allow a type safe definition of the mock. Without generics we would be using strings - which is not typesafe and would not survive refactoring. Another example - I have lexer/parser library (used in FinalBuilder) //NOTE : T MUST be an Enumerated Type (need better constraints!) TTokenRec<T> = record private ..... end; ILexer<T> = interface function Next : TTokenRec<T>; ... TBaseLexer<T> = class(TInterfacedObject,ILexer<T>) //concrete usages TDSLLexer = class(TBaseLexer<TDSLTokenKind>,IDSLLexer) TVariableSenseLexer = class(TBaseLexer<TTokenKind>) //parsers built on top of the lexers IParser<TAstNodeType,TParseErrorType> = interface TBaseParser<TTokenType,TAstNodeType,TParseErrorType> = class(TInterfacedObject,IParser<TAstNodeType,TParseErrorType>) TDSLParser = class(TBaseParser<TDSLTokenKind,TDSLASTNodeType,TDSLParserErrorType>) TVariableSenseParser = class (TBaseParser<TTokenKind, TVariableSenseASTNodeType, TVariableSenseParserErrorType>) Generics allows you to avoid copying and pasting tons of boilerplate code, changing types etc, or doing having to do tons of nasty type casting. If Delphi's generics were better there would be many more uses for them, but when you attempt anything complex you run into limitations. If you really want to know what else can be done with generics, you would have to look at other languages that have better generics implementations (like c#).

Hi All I recently did a presentation to the Australian Delphi User Group (ADUG) over zoom - the presentation was recorded and uploaded to youtube - thought it might be worth sharing here 😉 I talked a bit about devops in general, then Continuous Integration and Automated Builds, before showing Continua CI using MSBuild (and a bit of FinalBuilder), running a build, running unit tests etc.