Bill Meyer

And as a friend was fond of saying: The nice thing about standards is that we have so many from which to choose.

1 hour ago, Lars Fosdal said:

Yeah, it seemed a little out of place for TMS.
Do they have this for their other products as well?

No idea. Nor any idea how to discover, since the URL offers no clue. You could ask. 😉

1 hour ago, Lars Fosdal said:

Is this some sort of rip-off of the TMS components?

No, it's a lead-in to them. Seemed confusing to me at first.

3 hours ago, Uwe Raabe said:

Yeah, it doesn't look like clean BNF at all. Any BNF parser I tried has had its problems with it.

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"!

16 minutes ago, Anders Melander said:

 

Exactly - and you don't need to be an expert to come to that conclusion.

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.

2 hours ago, Stano said:

This forum works weird. I had exactly the same problem. I wrote in support. They fixed the problem. I reported a problem with cleaning uses. They don't respond. I wasn't alone.
Here you have an email at Liu Xiao liuxiao@cnpack.org

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

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.

14 hours ago, pyscripter said:

I will ask Embarcadero to update the Getit packages once the current versions is thoroughly tested and optimized, probably in a few weeks time. 

But the latency you mentioned is always going to be there, since the development is currently very active.  So if you want the latest fixes and improvements do use the Github version.

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

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.

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.

10 hours ago, David Hoyle said:

Looking at the first repository, it's 5 years old and I know the VTV has been updated extensively in those years so the DUD code may be expecting say version 5.3 of VTV or earlier. From V6.0 onwards there were significant changes. VTV is not shown as a submodule so I assume you are using a library version. You might want to make a copy and then check out an older version of VTV to see if it can compile.

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.

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.

8 hours ago, Alexander Elagin said:

As for embedded controllers - yes, plain C is the best choice.

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.

22 hours ago, Anders Melander said:

Makes sense then. The learning curve is ...um... spectacular  🙂

That curve...  like a brick wall. 😉

3 hours ago, Fr0sT.Brutal said:

OUCH!

That's really a heavy monstrous piece of petrified sh- ehm, code.

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.

1 minute ago, Fr0sT.Brutal said:

I'm always voting for code cleanup. And still insist that all that could be done automatically for this issue could be done via "comment a unit - try to build - OK: remove unit / Fail: revert unit - repeat" cycle. You don't even have to build the whole project as command line compiler, IIRC, allows building separate units. Though, any other cases still require developer's brain. When tools become so smart they could decide that SomeOldLib.i2s is the same as RTL IntToStr we all human devs will become obsolete.

Btw, (I'm sure you know that perfectly) any unit removal could potentially lead to subtle bugs even if it seems excess: unit init sections or overridden identifiers.

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. 

6 hours ago, Fr0sT.Brutal said:

So why bother this at all? Uses manipulations are no more than a cosmetic change. Of course the intention could be to remove some 3rd party deps, but that anyway requires much more brain than a mechanical purging/grouping.

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.

15 minutes ago, Fr0sT.Brutal said:

This 1) only should be done once 2) could be done by a not so genius utility

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.

On 8/27/2019 at 8:08 AM, Fr0sT.Brutal said:

AFAIU, the only truly reliable way of detecting excess uses is removing each used unit one by one and try compiling.

Impractical in large legacy projects.

Looks like the domain registration expired on 2021.10.31.