|
Mine too. Most of my education and the first ten years of my so-called career.
|
|
|
|
|
My education was mainframe but my first six years of programming was on PDP's, MicroVAX, etc. Unfortunately it was mostly programming in DIBOL, lol.
|
|
|
|
|
That's interesting. I don't recall ever trying to do that on purpose.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Using an a asterisk (wildcard) on the command line has always generated a list of files matching the mask. And the list is passed to the command for processing. I've never used it (AFAIR) for 'type' but there is no good reason why not.
|
|
|
|
|
Well, different DOS commands have different ideas about how a parameter should be specified.
DIR is pretty lenient, FIND is pretty restrictive, TYPE may be in between. The point being that the command language interpreter is not the only arbiter of what constitutes a "correct" statement.
|
|
|
|
|
Exactly so, but my point was about what cmd does when it parses something like "foo*" on the command line itself.
|
|
|
|
|
Normally, we get the Weird features, but this is a forum for 'Weird and Wonderful', so I thought I'd let you know about a good (probably excessive to call 'Wonderful') thing I found out.
I was trying to rename a file in Windows Explorer (on Windows 10). I had accidentally selected two files (instead of just the one I wanted) so it named them 'Whatever (1)' and 'Whatever (2)'. I had no idea which extra file had been renamed, so I tried ^Z (Undo). Both files were unrenamed back to their original names (totally unrelated to each other). I had not expected that to work.
|
|
|
|
|
Yup, I discovered that a few years ago by accident too. Never actually needed the feature though.
|
|
|
|
|
I discovered that ages ago, and assumed everyone used it on a regular basis.
|
|
|
|
|
You're right!
I regularly undo File Explorer action at the frenetic pace of easily at least 1 per year!
|
|
|
|
|
I didn't know it was enabled for the explorer but ctr+z has become such an ingrained muscle memory for me that whenever I do a mistake, regardless of the software I'm using, I reflexively attempt to undo.
While not always it does work more often than one might expect
|
|
|
|
|
^Z in fedora emacs minimizes the window. Then the following keystrokes go into whatever window gets focus. Hahaha.
Dang! My '58 Renault Dauphine has another flat tire.
|
|
|
|
|
Similar experience from years ago in my college days --- in one editor, ^Y would "yank back" things I'd deleted. In another, ^Y would delete things I'd highlighted. Kept me on my toes...
|
|
|
|
|
Now if only they could work with the person who implemented the copydown feature in excel and use his brains to figure out how to make it so if I select Cute Puppy.jpg and Cute Kitten.jpg and rename the first to Cutest Puppy.jpg that it should rename the second to Cutest Kitten.jpg not Cutest Puppy (2).jpg .
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
|
Looks like that'd work. Will I remember about it 6 or 12 months from now when I next need it?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
It appears in the Windows Explorer folder context menu - even the horrible new Windows 11 one - so it's not too hard to find.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Once upon a time in a galaxy far, far away… When I was a new (less than 1 year) programmer and working on an IBM 1401 with no math co-processor, I noticed a program that took a long time to do percent calculations (divide). In those days a divide was a software subroutine (a.k.a. function) provided by the vendor to achieve desired results. I had the bright idea improving on it and figured that if you multiplied the numerator by 100 and then looped through a routine that subtracted the denominator you could get there faster. And it worked. Spectacularly. Until… When a numerator came through that was much larger than the denominator the machine virtually locked up. Lessons to new programmers, always test all use cases and never assume your data will be good – always assume the worst where data is concerned. Or as I heard somewhere: no matter how good the validation, some idiot will find a way to get bad data past it.
|
|
|
|
|
Yeah, a denominator of 0 would be quite amusing! Or a negative one.
|
|
|
|
|
You might remember that several years Intel had a problem with division with a Pentium processor. The same thing had happened - some edge cases were overlooked. That prompted them to enact a rule that the guy who writes the microcode can not write the test vectors.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: the guy who writes the microcode can not write the test vectors THAT is fundamental to all testing, certainly not limited to microcode!
|
|
|
|
|
No, is not fundamental. It is highly recommended but not fundamental. Prior to this error Intel had not required it to be done by different people and I am certain they were not alone in that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
A Row may be a record, but a (logical) Record may comprise several Rows across several tables. It's like atoms (rows) and molecules (records).
So, DataTables use DataRows, excellent.
System.Data.DataRow
System.Data.DataRowView
System.Data.DataTable.Rows
System.Data.DataTable.NewRow
System.Data.DataView.RowFilter
But why, then, is a System.Data.IDataReader a System.Data.IDataRecord ? Which is illogical. Why not System.Data.IDataRow ?
|
|
|
|
|
It has been a long time since I've touched that corner of .NET but I seem to remember that the IDataRow exists somewhere and has things like events on it or otherwise at least things that IDataRecord can't do, and maybe, if memory serves, IDataRecord accesses things closer to the metal (using raw DB types and such) than IDataRow.
To err is human. Fortune favors the monsters.
|
|
|
|
|
imho such "genomic duplication" reflects the bumpy evolution of so-called "computer languages," as language implementers seek to broaden usage by incorporating familiar semantics ... at the cost of semantic consistency.
imho, "Where" in Linq is a good example: what it actually does is select; while Linq "Select" really means transform. But, those semantic choices were consistent with what SQL users were familiar with.
If you disagree, please enlighten me: I never had any depth experience with SQL.
cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|