|
|
GKP1992 wrote: Me: But won't a square room have 8 corners?
I might be extra dense today, but how do you get 8 sides to a quadrilateral?
|
|
|
|
|
We do not, although a room is a 3D structure and is generally a cuboid.
|
|
|
|
|
May confuse it further by asking:
"If each of the cats gives birth to alternately 2 and 3 kitten simultaneously, then how many (cats + kittens) will be in the room".
Alternately means that if one cat gives birth to 2 kitten, its neighbouring cat gives birth to 3 kitten, and vice versa. Maybe ChatGPT needs this clarification also.
|
|
|
|
|
I've just painfully (while developing an app) stumbled upon this terrible little bug in the HTML5 Date control.
TLDR;
If you set the value of your HTML5 date input control to today's date, it will display that date.
However, when you go to read the date using the same property of the input control that you used to set it, you __may__ get a date that is one day less than the date you set!!!!
Code and snapshots below...
If you add the basic Date input control to your page:
<input type="date" id="mainDate">
You'll see something like what is shown in this snapshot[^].
Notice that the date is not set.
To set the Date to the current date you need JavaScript (of course).
So do something like the following:
document.querySelector("#mainDate").valueAsDate = new Date();
Now the Date control will be set to the current date for you, based upon your local date/time.
The control looks like the following snapshot for me now[^].
Let's Read the Value Back, Shall We?
Let's add some code to read the value back -- even though it is obvious that the value will be 03-12-2023, right? Right? Right!?! Insert maniacal laughter here!!!
Here's the Extremely Simple JavaScript Code
function showDate(){
alert(document.querySelector("#mainDate").valueAsDate);
}
The Date Reported is One Day Behind
You can see in this snapshot that my system actually[^] reports that it is not 03-12-2023 (it actually is IRL (In Real Life), but it reports it as a time on 03-11-2023.
Inspect My Simple Code At JSFiddle
If you can't believe my snapshots, take a look at the code[^] and you can see that I simply read the valueAsDate from the date input control and pop up the value in the alert() box.
You can also see my code at plunkr[^]. I noticed jsfiddle was down so I added the code there.
I Came, I Saw, I Searched
yes, I searched for something like, "why is my HTML5 date control one day off?"
I found this highly upvoted StackOverflow question: https://stackoverflow.com/questions/9509360/datepicker-date-off-by-one-day[^]
The Answer Is Far Deeper Than You Want
Of course there is a logical explanation, but I don't care about that when I'm attemptingn to build an app and get it working properly!!! 
There are multiple answers that state that it is related to the data format containing dashes - or slashes / but I believe the correct answer is found in a comment and it's quite terrible (as all date-related code is).
SO Commentor said This isn't a bug. When you provide the date in standard UTC format, Date assumes that you are providing a UTC time, which is independent of your local time. The reason you're off by day is because UTC time is for a timezone that is ahead of yours. (Since you didn't also provide a time, 0;0;0 was assumed.) Supplying a date in a format other than UTC indicates use of a local timezone. I happened across this problem in another context, with YAML interpreting my UTC format date off by a day.
Learned to Love The Bugs
When I was about 3 years into my career I understood that more of software development would be about debugging than actually putting the bugs in (writing code) so I gave in and I've learned to love the bugs.
I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
These kinds of things make you so angry that they remind you that you are actually alive, not just an inanimate lump of clay sitting in a cubicle for 72 hours a week. 
"I debug therefore I am."
modified 12-Mar-23 22:51pm.
|
|
|
|
|
There is no such thing as a timestamp without a timezone. Does not matter how you do it. All programming languages. All databases. Even when it is not obvious. Even when it is not defined.
Even if you just write it on a piece of paper.
Myself I am not even sure if dates (not timestamps) exist without a timezone. Certainly my birthday is just as useable here as it is halfway around the world. But if I am supposed to get a something free from a international company on my birthday every year as a swag then when does it show up?
|
|
|
|
|
raddevus wrote: I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
I agree with whoever said,Programming is the act of debugging a blank page. Maybe Knuth?
|
|
|
|
|
So I have this method ( C# , .net ), let's call it F(i) where i is an integer representing a UTF-16 character. The method determines which one of the following classes the character is a member of:
Control (ASCII control characters)
Delimiter (the caller can specify which characters are delimiters)
EOF (-1)
Escape (\)
Non-ASCII (i > 127)
Normal (ASCII characters which are not members of another classes)
Quote (")
This is implemented as an array look-up with a catch for IndexOutOfRangeException which will fire for EOF and non-ASCII characters. This has been working well for a while. The data (JSON files mostly, but not exclusively) is nearly all ASCII characters with only an occasional non-ASCII character -- maybe a few "smart-quotes" or similar, which are OK, in many cases I replace those with their ASCII versions anyway.
BUT once in a while we receive a corrupt file which (in the latest case) includes a JSON value which contains more than a million non-ASCII characters (in the file they are encoded as three-byte UTF-8).
F(i) was not performing well in this case. Apparently having the catch fire occasionally is OK, but firing a million times in rapid succession is decidedly not.
Once I tracked the issue to F(i), I could try altering it to add a test for i > 127 and avoid the exception (which I am loathe to do on principle). But unit testing did show that it improved the performance considerably for the non-ASCII characters without significantly hindering the performance of ASCII characters (EOF is still handled by a catch).
That sounds like a win, except... I just don't like having the extra test which is essentially needless given that we don't expect any/many non-ASCII characters in most files we receive.
Sooo... I named the original version Fa(i) and the new version Fn(i) and I made F(i) a delegate which starts out pointing to Fa(i) but:
If Fa(i) encounters a non_ASCII character it will re-point F(i) to Fn(i)
If Fn(i) encounters an ASCII character it will re-point F(i) to Fa(i)
Slick as snot. Unit testing shows good performance.
Time required to read the million non-ASCII characters with Fa == 12 seconds
Time required to read the million non-ASCII characters with Fn == 0.06 seconds
I have integration testing running now. The current production version times out the file read after ten seconds (a protection I had to add a while back for another corrupt file), but with the new version, it should read successfully then I should get an error when trying to stuff more than a million non-ASCII characters into a database column which is defined for 500 ASCII (CP-1252) characters.
In the meantime, the people who send us this file are trying to find out what's causing the issue. So far, it's intermittent (a dozen times in the last four years), so it hasn't become critical.
I'm pretty sure I've done this sort of thing before -- having a delegate which points to one of two slightly different implementations of a method depending on what has been encountered in the data, and flipping back and forth dynamically as required. I guess I'll be code-spelunking this afternoon to review that code.
This is the way.
|
|
|
|
|
Have you looked at the "standard" implementation of isdigit, isalpha, etc. C functions?
It uses a 128 character table in which different bits represent character class. Something like:
tab['a'] = CLASS_ALPHA | CLASS_HEXDIGIT | CLASS_LOWERCASE; For sure, you need to range limit the input.
Just a thought.
Disclaimer: Haven't looked if recent C runtime library implementations still use that "standard" implementation.
Mircea
|
|
|
|
|
Of course, but the built-in methods of System.Char (.net) don't suit my needs, so I rolled my own as is my wont.
I actually have a number of places where I have to roll my own character (or byte) classing solution to meet my requirements.
The "delimiter" class in particular depends on the type of file being read -- for JSON, the delimiters are { } [ ] : , ; for CSV they are , \r \n .
|
|
|
|
|
I was talking about the method, not the functions themselves. The basic idea is that you can assign up to 8 distinct classes to each character. Fleshing out a bit more my idea, something like:
tab['{'] = CLASS_DELIM_JSON;
tab[','] = CLASS_DELIM_JSON | CLASS_DELIM_CSV; The table would of course be statically allocated and initialized:
bool is_a (int x, char what)
{
static char tab[128] = { };
return (tab[(char)x] & what) != 0;
}
Mircea
|
|
|
|
|
Yes, and that's what I'm doing here -- but C#ishly, using an enum to define the constants and the map.
|
|
|
|
|
PIEBALDconsult wrote: BUT once in a while we receive a corrupt file...but firing a million times in rapid succession is decidedly not
Why does it continue after the first one? If firing once means it is corrupt and then you expect the rest to be corrupt then why not stop?
Or say stop after 10 or so?
PIEBALDconsult wrote: to add a test for i > 127 and avoid the exception (which I am loathe to do on principle).
Not sure I understand that statement. Unicode does not fit that range and you are getting unicode. So testing for it rather than assuming it is correct is what should be happening.
|
|
|
|
|
The reader has no clue whether what it's reading is corrupt or not, that's determined at a higher level. The reader's job is to simply read the characters and return them.
jschell wrote: Or say stop after 10 or so?
That's the issue I was running into, I had it throw an Exception after ten seconds, I needed to keep that from happening.
jschell wrote: you are getting unicode
Yes, but the reader was taking too long to read the UNICODE characters which are outside the ASCII range. It now reads them almost as quickly as UNICODE characters which are within the ASCII range.
But to do so, It's flipping between two implementations of a method -- one for ASCII and another for non-ASCII -- depending on which characters it encounters.
|
|
|
|
|
PIEBALDconsult wrote: what it's reading is corrupt or not, that's determined at a higher level.
That seems idealistic or odd. If it is or was throwing an exception then it seems like it did know it was corrupted.
Obviously the caller continued since you said it was failing a million times. Was the caller getting usable information? If so then the architecture indicates that it is not in general corrupted. But rather that some of the data is not useable so that is how it should be treated.
Conversely, to me, if I was seeing a million actual failures then I would question the need to attempt to retrieve 'valid' data. Corrupted generally would refer to some random process. That random process might create a character that passes your checks (regardless of how you check) but still represent bad data. Matter of fact the more data like this that exists the more likely that becomes. So "millions" would suggest that some other bad data would end up being accepted as good.
|
|
|
|
|
jschell wrote: seems like it did know it was corrupted.
No, the code had a bug whereby it "took too long" to read a value/token. I have fixed the bug so now the value/token gets read and returned and then the caller can determine whether or not the value is reasonable.
jschell wrote: failing a million times
No, not failing a million times, failing once.
jschell wrote: the architecture indicates that it is not in general corrupted
In general, yes, non-ASCII characters cannot be considered invalid by the reader, only the caller can determine that.
A large text value may contain a few non-ASCII characters, such as "smart quotes", and that's fine. The issue was that when a value which contains many non-ASCII characters, it took too long to read -- it also happens that the value was corrupt in this case.
jschell wrote: Corrupted generally would refer to some random process.
Yes, and we still don't know what is causing the corruption.
jschell wrote: random process might create a character that passes your checks (regardless of how you check) but still represent bad data
As is always the case, and again the reader can't determine that.
jschell wrote: some other bad data would end up being accepted as good.
As is always the case, and again the reader can't determine that.
In this particular case of corruption, the process will fail when it tries to stuff a million-plus characters into a database column which allows only two-hundred. But yes, even now there may be a file on the way which is corrupt in such a way that the bad value fits and the load won't fail. The reader won't care, the loader won't care, but some other part of the process will (probably) freak out.
|
|
|
|
|
PIEBALDconsult wrote: No, not failing a million times, failing once.
You did say in the OP the following which seemed to me to suggest that it would have failed a million times.
"Apparently having the catch fire occasionally is OK, but firing a million times in rapid succession is decidedly not."
PIEBALDconsult wrote: In general, yes, non-ASCII characters cannot be considered invalid by the reader, only the caller can determine that
Back to being too idealistic to me in terms of your original point of how the code should handle it.
The method is only part of this process. It is not part of a multi-use library (presumably.) And the problem being solved does involve characters that are not ascii. So nothing wrong with this method specifically dealing with that by using the 'if' solution.
You could, idealistically, make the caller deal with it before calling the method in the first place. To me even spending time on that consideration seems like overkill. It would not be worth my time for consideration.
|
|
|
|
|
Having the catch fire is not a failure.
jschell wrote: It is not part of a multi-use library
Yes, it is, of course it is.
jschell wrote: deal with it before calling the method
Uh, what? You can't handle characters before they've been read.
|
|
|
|
|
I think Chris will have to update the Lounge rules - no posts about what ChatGTP says!
Me: Write me a poem about programming
Chat GPT:
Programming, so complex and so hard
It can make your head spin, like a spinning top
It can be difficult to understand
But once you do, it can never be topped
From the basics of HTML to the depths of Java
Programming is a skill that's hard to master
But with enough dedication and hard work
You can be a coding master
The possibilities are endless with programming
You can create something that's truly unique
From a simple website to a complex game
You can make something that's truly one-of-a-kind
It can be frustrating and time-consuming
But the rewards can be great
You can make something that others can use
And that's a feeling that can't be beat
So don't give up when it gets tough
And don't let the obstacles stand in your way
With enough dedication and hard work
You too can be a coding master one day!
|
|
|
|
|
It bothers me that this would work as a reasonably structured song if you made a chorus about being a coding master.
Thanks,
Sean Ewington
CodeProject
|
|
|
|
|
Sean Ewington wrote: this would work as a reasonably structured song if you made a chorus about being a coding master.
Reminds me of the song: Juke Box Hero - YouTube[^]
|
|
|
|
|
One of my ultimate bands and songs!
|
|
|
|
|
DR. SEUSS EXPLAINS COMPUTERS
(Original author unknown) Extracted from A Grandchild's Guide to Using Grandpa's Computer by Gene Zeigler
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disc abort,
Then the socket packet pocket has an error to report.
If your cursor finds a menu item followed by a dash,
And the double-clicking icon puts your window in the trash,
And your data is corrupted 'cause the index does not flash,
Then your situation’s hopeless and your system’s gonna crash!
If the label on the cable on the table at your house,
Says the network is connected to the button on your mouse,
But your packets want to tunnel on another protocol,
That’s repeatedly rejected by the printer down the hall,
And your screen is all distorted by the side effects of gauss,
So your icons in the window are as wavy as a souse,
Then you may as well reboot and go out with a bang,
'cause as sure as I’m a poet, the suckers gonna hang.
When the copy of your floppy’s getting sloppy on the disc,
And the micro code instructions cause unnecessary risk,
Then you have to flash your memory, and you’ll want to RAM your ROM…
Quickly turn off your computer and go and tell your Mom.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
We are no longer allowed to appreciate Dr. Seuss in America as he has been deemed a racist. Just by reading this post I could technically, literally, and figuratively be canceled.
|
|
|
|
|
That is entirely USians' loss.
I followed the controversy as it developed in the US. All I can say is that if an author can be deemed racist for a couple of elements in one drawing out of N illustrated books, then something is very wrong in the US. I remember reading the controversial book (And to think I saw it on Mulberry Street, IIRC) as a child, and all I thought about the drawings of "foreigners" was that they certainly dress funnily in "foreign parts".
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
