Bill Meyer

My own casual survey leads me to offer this summary: BNF seems to be considered too limiting, and generally not for new work EBNF, though better, suffers from the extensions being numerous and undisciplined, so there seems to be no "standard" EBNF ABNF appears to be more useful than BNF, and better managed than EBNF -- see IETF RFC 5234 Don't shoot me, I didn't mention "right" and "wrong"!

No, of course not, but it would not be that difficult for this to become contentious. 😉

In the Wikipedia page on EBNF, it does not appear to support ::= as a symbol for definition -- it specifies =. I would think that for the project to have value, it needs to adhere fully to EBNF. That said, I claim no expertise in language specification. UPDATE: I note that there is a link on the Wikipedia page for EBNF which offers a zipped PDF of the ISO variant of EBNF: http://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996(E).zip Unfortunately, the file I received in two separate attempts can't be opened as a zip, but provokes an error saying the file is corrupt.

Have you used a profiler yet? There really is little point to reworking your code until you know where the time is consumed.

The current release of CnPack has a problem, and it was apparently reported to them a few weeks ago, but not clearly. I was going to make a reply to clarify the problem description, but have waited two days so far for a verification email on my attempt to join the forum. If anyone here has access, I could post the info on where the message is, and the details of what is broken.

Saw your note on their forum. I do see that this morning they have checked in some changes in the Uses Cleaner.

I understand the process, but it's good to have some sense of the latency.

Just to clarify, the Turbopack/SynEdit page in github declares availability through GetIt. However, I am sure there is some latency between an update on GitHub, and the ripple through to GetIt. Can you give any prediction as to how long it will be before the latest version is in GetIt?

I believe you can still use this: https://www.swissdelphicenter.ch/en/showcode.php?id=1246

I am using an FDMemTable in a very simple application. I am using Alexandria, but I get the same error in Sydney. I need to ensure before loading that the dataset is empty, so, I do this: function TdMain.ProcessFileList(const FileList: TStrings): Integer; var fn: TmdFileName; s: string; sld: TStringList; begin if not fdmAllFiles.Active then fdmAllFiles.CreateDataSet else begin fdmAllFiles.Open; fdmAllFiles.EmptyDataset; // throws exception end; The FDMemTable is static on the data module, and the fields are created at design time. When I call this routine a second time, the dataset has records, and so I ensure it is open, and call EmptyDataset. I then get this error: I have tried getting a bookmark before the call, and it makes no difference. Interestingly, I have found no examples of using EmptyDataset in my searching.

Thanks for your efforts. I went to the smallest possible test program, and I get no error. As to the cause of the problem in the program where I first saw it, I am at a loss. Will come back to it later, and see whether I am able to isolate a cause.

Not sure where to turn on this one. In 10.4.2 and in 11.0, attempting to build DUDS == Delphi Unit Dependency Scanner -- fails with a collection of errors. The first of them is reporting: [dcc32 Error] duds.gui.forms.Main.pas(988): E2003 Undeclared identifier: 'Sort' On this line: Sender.Treeview.Sort(nil, Sender.SortColumn, Sender.SortDirection); Where Sender is a TVTHeader. I do see old traffic about the "built-in Sort" of VirtualTreeView's TreeView object, so this seems unexpected, at best. Also tried in Tokyo with a fresh download of VirtualTreeView, and the build fails there, with different issues. DUDS is at https://github.com/norgepaul/DUDS, and a fork which uses DelphiAST is at https://github.com/dontenwill/DUDS. the latter seems preferable, both for the use of DelphiAST, and because it appears to have had attention recently, while the original has not been updated in 5 years. In both cases, the error on Sort in: Sender.Treeview.Sort(nil, Sender.SortColumn, Sender.SortDirection); Is present. If anyone is currently using DUDS, or is practiced in the use of VirtualTreeView, I would be happy to hear from you.

Thanks! I have reached the point where the Sort error is the only think I can't easily resolve, so it may be merely a matter of exploring the implementation in an older branch, as a model for how to proceed. DUDS used the old Sort to allow a common implementation shared across more than one TreeView. I suppose I could also reduce the problem by implementing separately for each, at least as a first approach.

Often, but not always. I have done some considerable work in small AVR devices using assembly language. More than sufficient for the tasks involved, and essential in some cases, as I was dealing with some relatively fine-grained real time issues. There are times when the absolute control is a very large benefit. Embedded processors, after all, encompass a tremendous range of possibilities, from incredibly simple to things as complex as an RPi.

That curve... like a brick wall. 😉

It's a... challenge.

Going through the downloads menu, it leads to a different target: http://ww2.indyproject.org/Sockets/Docs/index.EN.aspx And that is also unreachable.

It gets to be a considerable challenge when a uses clause references >200 modules. And when the cycles reported by MMX include some in which there are 100+ modules named. Then the question is how to tell which are causing cycles, and which are simply along for the ride? And then there is the problem of initialization. I replaced all initialization/finalization clauses with explicit calls and a module to make those calls, so that I had a deterministic solution. Prior to that, changes to a uses clause could result in a different sequence of initialization, and some of the init clauses assumed other modules had already been initialized.

Multiple reasons. Legacy code collects detritus, in this case, some unneeded uses references. Moreover, in this project, there are a large number of unit dependency cycles, and those need reduction. A step on the path is moving to the implementation section those references which need not be in the interface. It would be nice if there were some tool which assisted in determining which units are the bad actors in the dependency cycles, but there are none, to my knowledge. Another aspect is that Delphi's libraries have grown over time, and now contain functions which in earlier days were written in house. Nice to reduce the home-grown little routines, where possible. And yes, another part of the process is the transition from old components which may now be orphans to others which are well supported. It seems common, in legacy code, to find many more component vendors represented than is needful. Finally, yes, much work requires more than mechanical grouping and purging. But code rot must be fought, else it continues, in the dark.

Given that the legacy code contains things badly done, it may well need to be done more than once. Also, it is not merely a question of removing those not needed, but of demoting to implementation those which are not needed in the interface section. And in the presence of 2000+ modules, and a couple of million lines of code, few things are trivial.

Impractical in large legacy projects.

Looks like the domain registration expired on 2021.10.31.

Found that the existing installation was for current user, and I was trying to install for all users. I am also finding that MMX operations sometimes do not work. Edit Entity, for one, and Format Uses Clause, for another. It appears to have something to do with the unit. Maybe. Still trying to puzzle out the misbehavior.

Downloaded 5 minutes ago, MMX_Setup_15_0_48_2480.zip Installed to Tokyo. Ran the IDE, and it reports 15.0.38, not 15.0.48. Build 2440, not 2480.

I have a substantial collection of forms which may be changed from fsNormal to fsMDIChild at runtime. Not my doing, but my inheritance. Yes, it is wrong and should not be done. But I wonder whether there is a way to minimize the unpleasant artifacts.... The right way, I suppose, is to produce from each form a frame which contains the functionality, then create two forms, one fsNormal, the other fsMDIChild, as hosts for each of these frames. Eventually, I will go down that path, but still hope for a tolerable short-term approach.