|
uncleTomOfFinland posted:In a way that has happened already. If only anything ever used it, rfc822 is far more popular.
|
# ? Jan 8, 2012 15:14 |
|
|
# ? May 21, 2024 01:54 |
|
uncleTomOfFinland posted:In a way that has happened already. sup iso datetime format buddy
|
# ? Jan 9, 2012 17:13 |
|
quote:Patch-tag is now https safe, so you can access your projects with cryptographic security. Just use https style urls when interacting with patch-tag.
|
# ? Jan 12, 2012 07:55 |
|
That quote reminds me of people who almost exhibit common sense, but make a sharp turn into a wall. For example, it really is possible to pull off a man-in-the-middle attack, but... not quite like the way he's showing. The bit about trying to foil keyloggers is hilarious, though, and really comes out of nowhere as completely silly advice.
|
# ? Jan 12, 2012 08:41 |
|
Nicked from the daily wtf comments. A workaround for sometimes broken XML from a third party:code:
|
# ? Jan 12, 2012 14:36 |
|
Zamujasa posted:That quote reminds me of people who almost exhibit common sense, but make a sharp turn into a wall. For example, it really is possible to pull off a man-in-the-middle attack, but... not quite like the way he's showing. Lol: L=Alto Palo
|
# ? Jan 12, 2012 15:28 |
|
Zamujasa posted:That quote reminds me of people who almost exhibit common sense, but make a sharp turn into a wall. For example, it really is possible to pull off a man-in-the-middle attack, but... not quite like the way he's showing. There's also the possibility that the author is giving that advice to give "security experts" who don't know what they're really talking about something to cling on to so that they'll allow employees to get their work done (so long as they type gibberish while typing in their password). I mean, sometimes it's easier to throw them a stupid bone rather than ignoring them (even if the bone doesn't actually help things, so long as it doesn't harm things). What's worse: having to type some gibberish while entering your password in an naive attempt at foiling key loggers, or not being able to use a tool for work because some jackass "security expert" has decided that SSL isn't secure enough? bobthecheese fucked around with this message at 16:56 on Jan 12, 2012 |
# ? Jan 12, 2012 16:53 |
|
Zombywuf posted:A workaround for sometimes broken XML from a third party
|
# ? Jan 12, 2012 19:03 |
|
Crosscontaminant posted:You should probably specify you're catching an XmlException - naked catch blocks are discouraged in Python (which I'm familiar with) and I can't imagine the same not being true for Visual Basic.
|
# ? Jan 12, 2012 23:10 |
|
The project I just signed on to work was developed using the Jenga method -- start with a stable Wordpress base, then bring on coder after coder to add new layers by pulling blocks out of the foundation.code:
|
# ? Jan 13, 2012 00:24 |
|
While we're still talking about timezones... https://www.eff.org/press/releases/eff-demands-withdrawal-bogus-time-zone-database-lawsuit Large Hardon Collider posted:I'm convinced these redirects are the web development version of the speed-up loop.
|
# ? Jan 13, 2012 01:47 |
|
Strong Sauce posted:It took me a while to figure out they save the zip (to a cookie? session?) and then eliminate the query string. Or at least try to because he has too many parameters to str_replace. It appears to pass the correct number of arguments to str_replace()? The inefficiency of it comes because it redirects them unnecessarily. If they submit the GET variable 'zip' then a cookie is saved, then they get redirected. If they submit the GET variable 'latlng' they get redirected, then a cookie is saved, then they get redirected a second time. All of these redirects would appear to be unnecessary.
|
# ? Jan 13, 2012 06:14 |
|
Hammerite posted:It appears to pass the correct number of arguments to str_replace()? You're right I missed the nested str_replace in there. I knew it was doing extra redirects. While I could see why he would redirect a lat/long query to one that redirected to whatever zipcode it was, that became irrelevant when he just redirected the zipcode after saving it into a cookie or session. So essentially what you just said...
|
# ? Jan 13, 2012 06:28 |
|
Scaevolus posted:Did you read the thread title?
|
# ? Jan 13, 2012 06:58 |
|
code:
This was committed to SVN four years ago.
|
# ? Jan 13, 2012 11:28 |
|
php:<? function ClearMSSQLResultSet($rs) { while (odbc_fetch_array($rs)) { /* Do nothing */ } } ?> Apparently, on certain 'free' ODBC drivers, you can't open a new result set (i.e. execute a new query) unless the previous result set has been spooled entirely to the end. #EDIT: turns out that I don't need to do this after all. odbc_free_result() does the job. bobthecheese fucked around with this message at 18:31 on Jan 13, 2012 |
# ? Jan 13, 2012 17:26 |
|
Crosscontaminant posted:Yes, but I thought that was related to a recent WTF about a customer refusing to escape their own ampersands and not supposed to be a WTF in itself. Think about it this way: what happens if the XML passed in already has an escaped character in it?
|
# ? Jan 13, 2012 18:12 |
|
bobthecheese posted:
I was thinking: does using cursors solve that? But that seems like overkill. Then again, I went looking for odbc_free_result too, but only found the PHP method which - when I looked at the implementation of it - didn't actually seem to clear the resultset, but memory allocations per column. Then again, I'm a bad coder so I might have totally misread it in my haste.
|
# ? Jan 13, 2012 18:44 |
|
If people haven't written a polyglot yet, it's quite fun. Here's a Python and C polyglot I wrote a little bit earlier:code:
|
# ? Jan 15, 2012 05:27 |
|
Oh good lord. The site was querying the google geocode service about 20 times per page load. Launched the site officially and it instantly maxed out the limit (2,500/day).
|
# ? Jan 15, 2012 07:14 |
|
Large Hardon Collider posted:Oh good lord. The site was querying the google geocode service about 20 times per page load. Launched the site officially and it instantly maxed out the limit (2,500/day). Put it live, hit the rate limit in about 8 seconds. Luckily it's hourly and not daily. code:
|
# ? Jan 15, 2012 07:59 |
|
code:
|
# ? Jan 15, 2012 09:47 |
|
Those look like direct-indexed accesses to me, not immediate ones. What's typically in the Y register at that point?
|
# ? Jan 15, 2012 12:13 |
|
Zamujasa posted:
Placeholders in the table? But still, why would you use a jump table for just two options?
|
# ? Jan 15, 2012 13:08 |
|
Jabor posted:Those look like direct-indexed accesses to me, not immediate ones. What's typically in the Y register at that point? Nothing out of the ordinary. This kind of code is repeated in multiple places (there are a lot of jump tables laying around for some reason) and this one just happens to be completely pointless, I guess. My guess is that there were supposed to be other possible functions it'd jump to, but it looks like they either were never implemented or were replaced with a simple RTS. (Though why not just remove the whole thing instead of jumping around more?)
|
# ? Jan 15, 2012 14:41 |
|
This isn't a PLT thunk, is it?
|
# ? Jan 15, 2012 15:44 |
|
Not on the NES, no.
|
# ? Jan 15, 2012 18:45 |
|
Zamujasa posted:Nothing out of the ordinary. This kind of code is repeated in multiple places (there are a lot of jump tables laying around for some reason) and this one just happens to be completely pointless, I guess. Unless the Y register is zero at that point, those two reads aren't actually retrieving $87A5 and $87A7. In any case, if this is hand-rolled asm it's probably a potential expansion point - it's nontrivial to add a jump table in if it's not already there, but expanding a no-op jump table is fairly easy.
|
# ? Jan 16, 2012 00:17 |
|
Hoooly gently caress. So after some discussion(starting there and going till the end of the thread right now) in the General Programming thread about why a guy had to put eval(input(prompt)) instead of input(prompt), I looked it up in the docs. Apparently in python 2.x (including the current version, 2.7.2), input() is is the same as eval(raw_input()). This was fixed for python 3.x but still holy poo poo. And the worst part is that pretty much every tutorial has you use input with it's implicit eval and even relying on it to convert the results without a second thought (and without even mentioning it). I have no idea how they thought a built in function named input should automatically and implicitly do an eval on the raw stuff it gets. Like god drat.
|
# ? Jan 17, 2012 07:41 |
|
Cross posting my post too.
|
# ? Jan 17, 2012 08:10 |
|
Doesn't Python have a read()? Didn't Guido learn anything from SICP ... oh wait, this is one of those examples why he should have, right?
|
# ? Jan 17, 2012 09:38 |
|
The Python 2 way of reading user input from stdin is raw_input() which always returns a string. The Python 3 name for the same thing is input(). As I said over in the other thread I suspect the reason for the input() definition in Python 2 is some sort of compatibility between the two Pythons, but why it's specifically implemented as eval(raw_input()) is nothing but a WTF.
|
# ? Jan 17, 2012 17:49 |
|
Python should finally catch up and release their docs on youtube! Seriously, does no one read any documentation anymore? I mean you know that you don't know what a thing does but do it anyway. And then you bitch when something goes wrong?
|
# ? Jan 18, 2012 01:24 |
|
Crosscontaminant posted:The Python 2 way of reading user input from stdin is raw_input() which always returns a string. The Python 3 name for the same thing is input(). As I said over in the other thread I suspect the reason for the input() definition in Python 2 is some sort of compatibility between the two Pythons, but why it's specifically implemented as eval(raw_input()) is nothing but a WTF. It's implemented in Python 2 as eval(raw_input()) because that's how it worked in Python 1. Why did it work like that in Python 1? I have no idea why this would ever be considered a good idea, especially given an innocuous name like input. xf86enodev posted:Seriously, does no one read any documentation anymore? I mean you know that you don't know what a thing does but do it anyway. And then you bitch when something goes wrong? In this case, the bitch is that the documentation aimed at beginners says to use input(), without explaining what it actually does under the hood or why it might be dangerous.
|
# ? Jan 18, 2012 01:45 |
|
xf86enodev posted:Python should finally catch up and release their docs on youtube! I mean I could see that with more obscure api calls, but a function named input should probably be a safe way of getting input. And as was said, most documentation aimed at beginners says to use input, not raw_input. I just have no idea why they thought that a function just named input should eval what it gets implicitly. It's loving stupid.
|
# ? Jan 18, 2012 01:50 |
|
Yup, there's lovely books out there but that's no coding horror.Jewel posted:I know a lot of people who used raw_input for strings and input for ints.
|
# ? Jan 18, 2012 06:24 |
|
Sorry, but input is right up there with mysql_escape_string as a complete horror of a function name given what it actually does. Actually, the mere existence of a function which does that is a complete horror.
|
# ? Jan 18, 2012 06:34 |
|
Vaguely on the subject of "input" in Python: One time a coworker of mine wrote code that essentially did this:code:
|
# ? Jan 18, 2012 08:22 |
|
Has there ever been a published book of coding horrors and related mistakes of technology? Like a Darwin Awards of programming?
|
# ? Jan 18, 2012 08:57 |
|
|
# ? May 21, 2024 01:54 |
|
Jabor posted:Sorry, but input is right up there with mysql_escape_string as a complete horror of a function name given what it actually does. You mean myqsl_real_escape_string(), of course.
|
# ? Jan 18, 2012 11:55 |