Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Fixed TCC descriptions scrambled

Oct
73
1
Using TCC, when doing a "dir /z" on a directory containing more than about 500 files with descriptions, the description display is scrambled. That is, some or many of the files are matched with the wrong description.

The DESCRIPT.ION file is fine. Doing a "dir /z a*" displays correct descriptions for the subset, and moving some of the files to another directory transfers the correct descriptions.

I'm using TCC version 13.00.27 x64, Windows 7 x64

I don't know if this same situation exists in Take Command because I bought it but I only use TCC.
 
Thanks for the prompt response. I emailed you and attached the description file and the output of DIR /B. I also included the output of DIR /Z on 500 files and DIR /Z on 700 files.

I neglected to mention that when the descriptions become scrambled, no description at all is displayed for some of them.
 
This turned out to be an obscure edge condition triggering a very old bug that had been waiting at least 15 years for you to step in it! :eek:

I've fixed it for build 40. (The good news is after staring at the code for a while I realized there was a better way to handle reading descriptions, so in build 40 it's substantially faster for large description files.)
 
Thanks again. I actually ran into the problem a while back, but I rarely have that many files in a directory, and usually only while I'm sorting them into subs. I do an awfully lot of work from the command line -- an old habit from my CP/M and ZCPR years that I've never been able to break. :)
 
Pizzaman ( :) ), why do you consider the fact that you do "an awfully lot of work from the command line" to be any kind of a problem? As I've often observed on this forum in the past, TCC is far more powerful than any GUI could possibly be, and I wasn't using the GUI all that much before my eyesight became an issue (and pretty much never since my eyesight did become an issue), and I don't miss it in the slightest. That's one of the main reasons I have 57 aliases defined at the moment (every program that I run on an at all regular basis has an alias, and the alias also includes the path (to keep my path variable shorter) and often those parameters that I virtually always use. And If I don't remember what the alias I need is? No problem. "Alias | List" takes care of it, and most aliases are defined with names like "xxx*TheRestOfAFullyDescriptiveName", and I even have an alias for "Alias List" (Alias AL*AliasList=Alias | List", I don't always make the concatenation of the letters before the asterisk and the letters after the asterisk form a "real" (group of) words because I want the alias name to ultimately really tell me what the alias does without me really having to think about it at all). And I would guess that the needs of a "developer" (which I would assume you are and I am now mostly only because I'm almost constantly developing programs that help me overcome one or more of my disabilities (bad memory in particular) are very different from the needs of a person who does not develop programs of one kind or another, 90% of the population. (More? Much more???) And I will note that, as of this second, I have 97 .btm programs "in development" (not a guess), and that's out of 334 .btm files on my RAM disk in total, the other 237 of which are some "combination" of one or more of "previous versions" (I only "throw away" a previous version of a program when I am absolutely sure that the "current" version has everything that I want and/or need in it, because I may (possibly accidentally) remove something that I want and/or need). Each "version" of a program is a fully-working copy of the program except that it does not yet do everything that I want the program to ultimately do), "Experimental" programs where I am checking out exactly how some facet of the TCC language "operates" because I think that I might use it and I want to make sure I understand it completely, and "Test" programs whose only job is to "test" other programs. (I test things exhaustively.) And I have 3 different "versioning" schemes that I use, one pretty "religiously" for things I intend to keep (a portion of the file name that contains the sequence: ".V201y-mm-dd." (and sometimes even .V201y-mm-dd-hh-mm" if there's going to be more than one version on the same date), "somethingI.btm" and "somethingII.btm" and ..., where each number basically identifies a new "approach" I am experimenting with, "something-n.btm" ... "something-3.btm", "something-2.btm", "something-1.btm", "something+1.btm", "something+2.btm", ..., where the minuses are back versions and the pluses are potential future versions (another kind of experimentation).

- Dan

P. S. Just in case you don't quite believe me, here's the total breakdown of the .btm files on my RAM disk. The numbers are so high because I start new projects before I finish old ones, and I start them because if I don't, I will entirely forget what I wanted to do much less how I wanted to do it; and has I have often mentioned I am very (as in "glacially") slow.
Code:
334 .btm files on Z: altogether

 78 "Exper" total
  6 "Exper" and "1." versioned
  1 "Exper" and "2." versioned
  1 "Exper" and ".V201" versioned
 70 "Exper" and not "I." and not "1." and not "2." and not "3." and not ".V201"

 70 "Test" total
  2 "Test" and "1." versioned
  1 "Test" and "2." versioned 
  1 "Test" and "3." versioned
 11 "Test" and ".V201" versioned
 55 "Test"  and not "I." and not "1." and not "2." and not "3." and not ".V201"

 84 ".V201" total
  1 "Exper"
 11 "Test"
 72 not "Exper" or "Test"

250 Not ".V201"

 77 Not ".V201" and "Exper" in total
  6 Not ".V201" and "Exper" and "1." versioned
  1 Not ".V201" and "Exper" and "2." versioned
 70 Not ".V201" and "Exper" and not "n." versioned

 59 Not ".V201" and "Test" in total
  2 Not ".V201" and "Test"  and "1." versioned
  1 Not ".V201" and "Test"  and "2." versioned
  1 Not ".V201" and "Test"  and "3." versioned
 55 "Test"  and not "n." versioned

114 Not ".V201" and not "Exper" and not "Test"
 12 Not ".V201" and not "Exper" and not "Test" and "II."
  3 Not ".V201" and not "Exper" and not "Test" and "I."
 99 Not ".V201" and not "Exper" and not "Test" and not "I." and not "II."
  2 Not ".V201" and not "Exper" and not "Test" and just "1." versioned
 97 Not ".V201" and not "Exper" and not "Test" and not numerically versioned

 97 Not "Exper" and not "Test" and not versioned in any way

And "coming up" with these numbers only took a few minutes (which was actually the amount of time it took the batch file to run) because it is automated with both that batch file (with an alias) and a "find" program I wrote years ago that basically allow me to do things like (in words, not syntax): "If it contains this but not that or this and that and neither this nor that...", presumably you get the idea, and the this'es and the that's can be specified as matching or ignoring case and have limited "pattern-matching" capabilities, exactly the same ones that TCC has ("*" and "?") without formally using "regular expresssions". The program is not complete (and sadly probably never will be) in that there is currently no way to "order" the matches as "this must become before that" (all of the matches are done on the entire text of the file), and this is not as slow as you might think it would be because the file is not read multiple times, strictly speaking it's not "read" even once, rather the input file is "mapped" entirely into virtual memory (a "memory-mapped" file which is effectively placed directly into virtual memory and is "read" exactly the same way that you would read any other byte in virtual memory, via a machine instruction of some kind) at the start of the program (via a C++ macro I wrote many years ago that first "creates" a file (for read access, so the API's name ("CreateFile" is a little bit odd), gets its size (GetFileSize API function), creates a file "mapping" ("CreateFileMapping" API function, not too surprisingly), maps a "view" of the file into virtual memory ("MapViewOfFile"), and "unmaps" it when done.) And if the input is coming in from standard input (not really very often the case the way I typically use the program), the program first reads the file and writes it to a temporary file in my "Temp" directory (which it then deletes when done, of course), which is actually on my RAM disk and so is very fast.
 
I used to live and breathe ZCPR and NZCOM. :)

Me too. No Internet. We used RCPMs as our means of communication. Most of them ran ARUNZ. I programmed in Z80 assembly back then and wrote and/or updated a number of ZCPR utilities. I was pretty active. I loved the intimacy of a relatively small group of people doing their own thing. The Internet is too big for that, so I'm mostly a lone wolf nowadays. :)
 
I programmed in Z80 assembly back...
I bought a 4MB memory board for my Z80-based S100-system(accessed by port transfers), and used Z80 assembler to write a device driver to make it a CP/M BDOS-compatible virtual disk, detecting during system start (when nobody has yet gone back to the medieval fairy stories to call it "pulling yourself out of the swamp by your own bootstraps as the Baron Münchhausen did" -> bootstrapping -> booting), whether or not the board contained valid data so that it did not needed to be reloaded from 8.5-in diskettes.
 
Thanks Rex! The descriptions are now flawlessly accurate on directories with a large number of files. AND they're displayed much faster -- instantly. No more long pause before the file listing starts. I'm very appreciative.
 

Similar threads

Back
Top