Jump to content

Bill Meyer

Members
 View Profile  See their activity

  • Content Count

    652

  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Bill Meyer

  1. Posted

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

    • Like 3

  3. Posted · Edited by Bill Meyer

    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.

  5. Posted

    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.

  6. Posted

    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.

  7. Posted

    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.

  8. Posted

    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?

  11. Posted · Edited by Bill Meyer

    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:

    image.thumb.png.e0d6a8a6c0955da010d32d1c86c50203.png

    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.

  12. Posted · Edited by Bill Meyer

    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.

  13. Posted

    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.

  14. Posted

    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.

  18. Posted

    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. 

  19. Posted

    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.

  20. Posted

    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.

  23. Posted

    1 minute ago, Uwe Raabe said:

    You may have different installation folders - perhaps caused by an admin installation followed by a user installation.

    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.

  25. Posted

    12 hours ago, Anders Melander said:

    Here you go. I've only included the stuff that directly deals with switching between SDI and MDI. The original code had a lot of logic related to positioning of the child windows, different layouts and and such.

    Thanks! Will be glad to resolve my misunderstandings of the issue. Curious, though, why the Delphi help recommends strongly against doing it.

×