WTF Bites
-
@Benjamin-Hall
Does it hurt when your friends never stand down wind?
-
@Polygeekery said in WTF Bites:
@Zecc Maybe drink less coffee and your hands won't tremble as much.
This is where we as a forum (minus the Mormons), tell you to fuck right off.
Nah, I'll agree with the Mormons on that, as long as I get to keep my
Piña Coloadabeer.
-
Got a knock on my door. Went to check, and nobody was there. Then my phone showed me an Amazon notification for a delivery failure because nobody was home. Normally they just leave the box at the door, and this driver must have left in the 8 seconds it takes to get to my door from my computer.
-
@Benjamin-Hall said in WTF Bites:
I bet Hall effect sensors are particularly sensitive to you.
What can I say. I must have a magnetic personality.
Of course; nobody here does any work.
-
Got a knock on my door. Went to check, and nobody was there. Then my phone showed me an Amazon notification for a delivery failure because nobody was home. Normally they just leave the box at the door, and this driver must have left in the 8 seconds it takes to get to my door from my computer.
They fully expect everyone to be tracking the actual GPS of the package and open their door as the driver walks up. :youre-doing-it-wrong:
-
One of the supported image types in the ID3 spec is "A bright coloured fish"
-
One of the supported image types in the ID3 spec is "A bright coloured fish"
I wonder if this fish is the one they're talking about?
-
@Watson From searching around, most of what I found were blog posts and forums wondering about it, and the common theories were
a) the Ogg Vorbis fish, and
b) a red herring
-
Someone ought to ask this Martin Nilsson bloke what he was thinking.
-
Someone ought to ask this Martin Nilsson bloke what he was thinking.
"Imma troll these mofos..."
-
b) a red herring
That sounds believable.
(the a) does not; I am one of approximately five people in the world who actually used Ogg Vorbis)
-
One of the supported image types in the ID3 spec is "A bright coloured fish"
We're the "featured snippet" for that search!
The first actual result is King Jeff™.
-
@Polygeekery said in WTF Bites:
The newest convenience printers, by default, have no way to just install drivers and get on about your day. Out of the box they want to install "HP Smart" (which is a dumb name and an even worse application) that after it is installed will then find your printer on the network and download and install the drivers.
Bah. My HP drivers are already installed by default and it never prompts me to install anything else.
Filed Under:
-
Did you know that Doxygen 1.8.17 (the version I'm using because my release channel hasn't updated yet) believes that the return type
static voidis one that needs documenting, unlikevoid? Apparently it's now fixed in the next release, but right now I'm getting an absolute ocean of false positive warnings from my codebase…
-
Did you know that Doxygen 1.8.17 (the version I'm using because my release channel hasn't updated yet) believes that the return type
static voidis one that needs documenting, unlikevoid? Apparently it's now fixed in the next release, but right now I'm getting an absolute ocean of false positive warnings from my codebase…staticas a return type modifier?
-
Did you know that Doxygen 1.8.17 (the version I'm using because my release channel hasn't updated yet) believes that the return type
static voidis one that needs documenting, unlikevoid? Apparently it's now fixed in the next release, but right now I'm getting an absolute ocean of false positive warnings from my codebase…staticas a return type modifier?"Shitty home-grown code model" would be my guess.
Or, in other words, "C(++) tooling sucks" thread is
.
-
"Shitty home-grown code model" would be my guess.
Rough approximation of a code model would be more accurate. The tool is not really trying to actually parse C(++), just understand it enough to find declarations. It is a language agnostic tool, after all, not a C(++) one.
-
Maybe drink less coffee
NEVER!
Our coffee machine broke. You jinxed it.
-
I'm migrating some data from SQL Server into Oracle. There's a field that's 4000 characters of text. Cool. Now Oracle has that field.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is using WTF-16 encoding (inspecting the table with DBVisualizer tells me that the field has a "buffer" size of 8000) and I know that Oracle is using UTF-8.
I'll bet someone was using smart quotes. Fuck it. CLOB it is.
-
@boomzilla said in WTF Bites:
I'm migrating some data from SQL Server into Oracle. There's a field that what I assume is 4000 characters of basic ASCII English-only text. Cool. Now Oracle has that field with the same assumptions straight out of 1990s.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is a bit newer than 1990s and actually uses Unicode code points larger than 127.
I'll bet someone was using smart quotes or had to write down a foreign name for raisins. I bet they've specifically picked a foreigner with a non-English characters in their name just so the programmers have to suffer by implementing proper Unicode support. Fuck it. CLOB it is.
This is why we can't have nice things.
-
@Gąska Imagine the !!fun!! that they'll have when someone legally changes their name to include emoji…
-
@boomzilla said in WTF Bites:
I'm migrating some data from SQL Server into Oracle. There's a field that what I assume is 4000 characters of basic ASCII English-only text. Cool. Now Oracle has that field with the same assumptions straight out of 1990s.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is a bit newer than 1990s and actually uses Unicode code points larger than 127.
I'll bet someone was using smart quotes or had to write down a foreign name for raisins. I bet they've specifically picked a foreigner with a non-English characters in their name just so the programmers have to suffer by implementing proper Unicode support. Fuck it. CLOB it is.
This is why we can't have nice things.
LOLNOPE: It's non-breaking spaces. I copied it out into a text editor and then examined with a hex editor and I see a bunch of
C2 A0sequences.
-
@boomzilla let's be honest - your reaction would be the same if it was ą.
Also, I consider non-breaking spaces and non-breaking dashes to be essential part of computer text. If your software doesn't support it, it's broken, and if you deliberately ignored that it's broken in this specific way, you're part of the problem. I know it doesn't quite apply to your particular use case, but you basically just kicked the problem down the line instead of solving it (you WILL have to parse that CLOB eventually, and you WILL have to add new entries to the DB and they better have the same format or some poor dev 5 years from now will swear much more profoundly than you do now.)
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
-
@Gąska
At least in SQL Server land (and I assume it's the same in Oracle land), NVARCHAR(4000) is the max size without converting to a LOB style field. While SQL Server gives you the "sugar" of NVARCHAR(MAX), it's still actually creating a CLOB field under the hood.Fake real edit: Also, 4000 characters is 8000 bytes, because ą
-
@boomzilla let's be honest - your reaction would be the same if it was ą.
And your stupid rant would still have been stupid.
Also, I consider non-breaking spaces and non-breaking dashes to be essential part of computer text.
So fucking what? The problem is changing encodings, not that either the source or the destination was only using ASCII.
If your software doesn't support it, it's broken, and if you deliberately ignored that it's broken in this specific way, you're part of the problem.
Fuck off with this nonsense.
I know it doesn't quite apply to your particular use case, but you basically just kicked the problem down the line instead of solving it (you WILL have to parse that CLOB eventually, and you WILL have to add new entries to the DB and they better have the same format or some poor dev 5 years from now will swear much more profoundly than you do now.)
You're full of shit. What the fuck are you even talking about? Not my situation.
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field (unless you do some non-standard DB configuration, which we haven't). I also suspect that users could have used a bigger field for this and were probably pulling their hair out in cases like the one I uncovered to stay just under the maximum. So why fight a futile fight like that?
-
While SQL Server gives you the "sugar" of NVARCHAR(MAX), it's still actually creating a CLOB field under the hood.
And ODBC driver automatically converts them to a regular string client-side, right? You don't get that with explicit CLOB, right? (Serious questions. I'm only 90% sure that's true.)
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
So why fight a futile fight like that?
Dunno. Some people like to defend gun rights. I like to remind people that Unicode is a thing and that it's actually being used. Does futility really mean we should stop doing these things?
-
@boomzilla said in WTF Bites:
I'm migrating some data from SQL Server into Oracle. There's a field that's 4000 characters of text. Cool. Now Oracle has that field.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is using WTF-16 encoding (inspecting the table with DBVisualizer tells me that the field has a "buffer" size of 8000) and I know that Oracle is using UTF-8.
I'll bet someone was using smart quotes. Fuck it. CLOB it is.
nvarchar2 seems like it would solve the problem. Not that CLOB doesn't.
Oh no, wait, the underlying data structure has a max length limit of 4000 bytes, as well as the limit of 4000 characters.
oracle.
-
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
The data in my DB is UTF-8. I thought I made that clear.So why fight a futile fight like that?
Dunno. Some people like to defend gun rights. I like to remind people that Unicode is a thing and that it's actually being used. Does futility really mean we should stop doing these things?
You should stop doing whatever it is you're doing here because you're not making any sense.
-
@boomzilla said in WTF Bites:
I'm migrating some data from SQL Server into Oracle. There's a field that's 4000 characters of text. Cool. Now Oracle has that field.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is using WTF-16 encoding (inspecting the table with DBVisualizer tells me that the field has a "buffer" size of 8000) and I know that Oracle is using UTF-8.
I'll bet someone was using smart quotes. Fuck it. CLOB it is.
nvarchar2 seems like it would solve the problem. Not that CLOB doesn't.
Oh no, wait, the underlying data structure has a max length limit of 4000 bytes, as well as the limit of 4000 characters.
oracle.Yeah, I could use NVARCHAR2, but I'm not going to do that for this one field. I already have a lot of CLOBs in other tables so one more isn't a big deal, and probably better long term for the users.
-
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
The data in my DB is UTF-8. I thought I made that clear.Well, I interpreted "CLOB it is" as "I'm sick and tired of conversions, I'm just going to copy data verbatim and erase type info". Maybe I was wrong to interpret it like this but I've seen things done this way in the past. So anyway, I hope and so one but with UTF-8 instead of UTF-16.
So why fight a futile fight like that?
Dunno. Some people like to defend gun rights. I like to remind people that Unicode is a thing and that it's actually being used. Does futility really mean we should stop doing these things?
You should stop doing whatever it is you're doing here because you're not making any sense.
Never stopped you before.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
I'm migrating some data from SQL Server into Oracle. There's a field that's 4000 characters of text. Cool. Now Oracle has that field.
migrates data
E_FIELD_TOO_BIGmax size 4000, actual size 4012.I'm guessing that the SQL server data is using WTF-16 encoding (inspecting the table with DBVisualizer tells me that the field has a "buffer" size of 8000) and I know that Oracle is using UTF-8.
I'll bet someone was using smart quotes. Fuck it. CLOB it is.
nvarchar2 seems like it would solve the problem. Not that CLOB doesn't.
Oh no, wait, the underlying data structure has a max length limit of 4000 bytes, as well as the limit of 4000 characters.
oracle.Yeah, I could use NVARCHAR2, but I'm not going to do that for this one field. I already have a lot of CLOBs in other tables so one more isn't a big deal, and probably better long term for the users.
Yeah, I'd go for CLOB as well (and have done in a couple of places in the system I'm building now).
Another dev incisted on using LOB instead because SECURITY.
It's really hard to read binary data containg text yaknow.I've since changed that table to also use a CLOB instead because I man, that was more stupid than
.
-
Wait, it seems I confused CLOB with LOB. Sorry for all the idiocy I've posted today.
I should stop talking about things I've never even been in the 10 mile radius from, much less actually worked with. But then, it's TDWTF...
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
The data in my DB is UTF-8. I thought I made that clear.Well, I interpreted "CLOB it is" as "I'm sick and tired of conversions, I'm just going to copy data verbatim and erase type info". Maybe I was wrong to interpret it like this but I've seen things done this way in the past. So anyway, I hope and so one but with UTF-8 instead of UTF-16.
No, it was, "I'm sick and tired of worrying about the size of the text. Have a few gigabytes of space." The conversions happened automatically and transparently, which is how I discovered the problem.
-
Wait, it seems I confused CLOB with LOB. Sorry for all the idiocy I've posted today.
I should stop talking about things I've never even been in the 10 mile radius from, much less actually worked with. But then, it's TDWTF...
Aint Oracle great?
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
The data in my DB is UTF-8. I thought I made that clear.Well, I interpreted "CLOB it is" as "I'm sick and tired of conversions, I'm just going to copy data verbatim and erase type info". Maybe I was wrong to interpret it like this but I've seen things done this way in the past. So anyway, I hope and so one but with UTF-8 instead of UTF-16.
I think you confused BLOB (binary data, so it can be UTF-8 mixed EBCDIC for extra fun) and CLOB (string, with character encoding handled by the database and/or its client libraries).
I think that even in Oracle, you can treat CLOBs just like big VARCHARs these days. Of course, this would lead to problems, but that is kinda main reason to use Oracle in the first place, isn't it?
Edit:
, so I am going to add a little bonus: did you know that there is a UTF-EBCDIC encoding?
-
@Kamil-Podlesak said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
Also also - why not just make the field larger? Why make it 4000 bytes and not, say, 8000 like it was originally?
Implementation details. 4000 is the max size for a varchar2 field
Fair enough. I admit I wasn't aware of that. I just hope that you give the DB consumers a heads up that the data in CLOB is UTF-16 and from now on it's their responsibility, not the DB's, to ensure it's UTF-16.
The data in my DB is UTF-8. I thought I made that clear.Well, I interpreted "CLOB it is" as "I'm sick and tired of conversions, I'm just going to copy data verbatim and erase type info". Maybe I was wrong to interpret it like this but I've seen things done this way in the past. So anyway, I hope and so one but with UTF-8 instead of UTF-16.
I think you confused BLOB (binary data, so it can be UTF-8 mixed EBCDIC for extra fun) and CLOB (string, with character encoding handled by the database and/or its client libraries).
-
@Kamil-Podlesak said in WTF Bites:
Edit:
, so I am going to add a little bonus: did you know that there is a UTF-EBCDIC encoding?No, and I'm going to spend the rest of my life pretending I still don't.
-
@boomzilla said in WTF Bites:
Implementation details. 4000 is the max size for a varchar2 field (unless you do some non-standard DB configuration, which we haven't).
It's been a little while since I worked with Oracle DB but I seem to recall that you can do
varchar2(4000 char)instead of4000 bytefor all your fancy foreign spaces and Polish ą's with dingleberries
-
@Kamil-Podlesak said in WTF Bites:
I think that even in Oracle, you can treat CLOBs just like big VARCHARs these days.
Using Hibernate / JDBC you (mostly) can, yes.
-
Did you know that Doxygen 1.8.17 (the version I'm using because my release channel hasn't updated yet) believes that the return type
static voidis one that needs documenting, unlikevoid? Apparently it's now fixed in the next release, but right now I'm getting an absolute ocean of false positive warnings from my codebase…At least you're not on 1.8.16. That was completely borked (at least on Windows). And it took 4.5 months before .17 was rolled out. (.18 was just released on 4/13, so it's not like you're too far behind!)
-
@Gąska Imagine the !!fun!! that they'll have when someone legally changes their name to include emoji…
Hell, that happened before emoji came around.
-
@Kamil-Podlesak said in WTF Bites:
I think that even in Oracle, you can treat CLOBs just like big VARCHARs these days. Of course, this would lead to problems, but that is kinda main reason to use Oracle in the first place, isn't it?
I think in PL/SQL you can treat them like VARCHAR up to 32kb or so. But they're slower because they're stored separate from the table data, even if they are small.
I don't think there's a limit to how large a clob the OCI library will allow you to bind as a native string. I can't say anything about ODBC.
The nasty ones are LONGs. Their use is discouraged, but the data dictionary uses them in places and you cannot access their value in SQL. If you need to filter on one, you need to do it in the client.
@boomzilla said in WTF Bites:
Implementation details. 4000 is the max size for a varchar2 field (unless you do some non-standard DB configuration, which we haven't).
It's been a little while since I worked with Oracle DB but I seem to recall that you can do
varchar2(4000 char)instead of4000 bytefor all your fancy foreign spaces and Polish ą's with dingleberriesIt still also applies a 4000 byte limit. Though that might have changed since 11.1
-
@Gąska Imagine the !!fun!! that they'll have when someone legally changes their name to include emoji…
Hell, that happened before emoji came around.
Kind reminder that Ladasha is an urban legend.
-
@Gąska Imagine the !!fun!! that they'll have when someone legally changes their name to include emoji…
Hell, that happened before emoji came around.
Kind reminder that Ladasha is an urban legend.
Had to google that... No, "Love Symbol #2".
-
@dcon TIL. Although it was just a stage name, not legal name.
-
-
Love Symbol #2
Is that the Former Artist Still Known as Prince?
Except it's past tense now.
-
@Zecc he's definitely a former artist at this point.
-
At least in SQL Server land (and I assume it's the same in Oracle land)
I am not saying it isn't, but I don't find such assumption founded. The two things have nothing in common and sometimes differ just for the sake of it.
