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.
