|
Xenogenesis posted:Behold Haml, Rails' elegant, beautiful templating solution: Fire him.
|
# ? Jan 3, 2011 06:02 |
|
|
# ? May 16, 2024 19:01 |
|
yaoi prophet posted:NSAttributedString is not a subclass of NSString, and RegexKit doesn't implement anything for NSAttributedString. So if you have one, and you want to do regex operations while preserving formatting, you have to convert it to a NSString, do your regex operations, then figure out the indices your regex matched on and then manually extract them from the original attributed string. Ugh. I mean, I guess this sucks, but you just write a wrapper for the method that takes an NSAttributedString once and never have to deal with it again.
|
# ? Jan 3, 2011 06:05 |
Xenogenesis posted:Behold Haml, Rails' elegant, beautiful templating solution: Don't blame Haml for that abomination. Did the guy work as a VBScript programmer before this?
|
|
# ? Jan 3, 2011 06:38 |
|
Ryouga Inverse posted:I mean, I guess this sucks, but you just write a wrapper for the method that takes an NSAttributedString once and never have to deal with it again. I just felt like bitching about it.
|
# ? Jan 3, 2011 06:53 |
|
My employer is a web development agency and we frequently fix projects that other agencies failed to deliver on. This means I often get to work with the dregs of the ASP.NET world. The site I'm working on now has basically one function: to let users find 'locations' and 'request' information on a convenient location. I'm trying to introduce the notion of data integrity to the database and I find that most of the requests originating in our dev environment have a location ID like "309998.asp" instead of the expected "309998". Let's ignore, for the moment, that nvarchar(6) IDs are annoying, and there's no FK constraint on that column (and I can't easily add one because there's loads of garbage in the table that won't sync up). I start to puzzle over the incorrect IDs in our dev environment. What could be different in on our development server that causes incorrect data to be inserted into the database? By chance, I notice that the URL for the request form for the page I'm on is /location-details/309998/?locationId=309998.aspx. What the hell is with the trailing .aspx? We don't have URL rewriting set up on development exactly as it's set up on production so we get some weird URLs sometimes. Apparently instead of keeping track of what location ID the user is currently viewing, the code just grabs the location ID from the query string which in this case has an extraneous .aspx in it. Imperfect URL rewriting caused our dev site to insert bad data into the database.
|
# ? Jan 3, 2011 19:06 |
|
I like this one in Python:code:
|
# ? Jan 3, 2011 20:57 |
|
Kamikaze! posted:I like this one in Python: I don't really have a problem with that because I understand it and it isn't something you're likely to do accidentally all the time. It's just a parameter with a default value that happens to be something that you'd store a reference to, so the next time you execute a(something) c is going to be pointing to the same object because it's only instantiated once.
|
# ? Jan 3, 2011 21:43 |
|
A OBLIVION MOD... posted:Don't blame Haml for that abomination. Did the guy work as a VBScript programmer before this? Seconding this. Good Haml code is pretty much as simple as it gets.
|
# ? Jan 3, 2011 21:43 |
|
Ugg boots posted:I don't really have a problem with that because I understand it and it isn't something you're likely to do accidentally all the time. It's just a parameter with a default value that happens to be something that you'd store a reference to, so the next time you execute a(something) c is going to be pointing to the same object because it's only instantiated once. Why doesn't c go out of scope at the end of the function?
|
# ? Jan 3, 2011 22:07 |
|
evensevenone posted:Why doesn't c go out of scope at the end of the function?
|
# ? Jan 3, 2011 22:20 |
|
evensevenone posted:Why doesn't c go out of scope at the end of the function? Python defaults are only evaluated once: http://docs.python.org/tutorial/controlflow.html#id1 edit: Big Red Dot posted:Because function argument defaults are created once, when the function is defined, not anew every time the function is invoked. Is the specifics of when they are evaluated an implementation detail or guaranteed to be at first evaluation time? I see the CPython interpreter does it at evaluation time but could it also be done lazily by a different implementation? edit 2: code:
Munkeymon fucked around with this message at 22:40 on Jan 3, 2011 |
# ? Jan 3, 2011 22:23 |
|
Munkeymon posted:Is the specifics of when they are evaluated an implementation detail or guaranteed to be at first evaluation time? I see the CPython interpreter does it at evaluation time but could it also be done lazily by a different implementation? Well, the default argument is actually a property on the function object, so I imagine that it must be created when the function object is made, ie at evaluation time.
|
# ? Jan 4, 2011 01:03 |
|
code:
1) this.pendingChunks averages 3000-5000 objects. 2) Collections.sort allocates a new array of the same size, copies all the elements out of the ArrayList, sorts them, then copies all the elements back. 3) The code always terminates at point 1 or 2, unless firstRun is true (i.e., it only processes the last ~3 objects in the list) This method is called every frame, and accounts for 30% of CPU time on slower systems.
|
# ? Jan 4, 2011 06:59 |
|
http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/quote:I stumbled upon a very strange bug in PHP; this statement sends it into an infinite loop:
|
# ? Jan 4, 2011 09:44 |
|
Xenogenesis posted:http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/ The real horror @rasmus posted:@Bjorn_W It's a gcc optimizer issue. Works fine with -O0 but not -O2
|
# ? Jan 4, 2011 11:22 |
|
-funroll-loops
|
# ? Jan 4, 2011 12:11 |
|
gastownlabs posted:The real horror Even worse: Rasmus posted:@AnthonySterling We still need to fix the code to make it immune to compiler switches. The bug is in the double parser that iteratively approximates the correct value which doesn't work at MAX_DOUBLE. Rasmus decides that the problem is "compiler switches".
|
# ? Jan 4, 2011 13:52 |
|
INT_MAX, MAX_DOUBLE php rocks at boundary cases
|
# ? Jan 4, 2011 16:48 |
|
Zombywuf posted:Even worse: Tiny Bug Childe... why...
|
# ? Jan 4, 2011 16:53 |
|
Scaevolus posted:
This came from Minecraft's source code, by any chance?
|
# ? Jan 4, 2011 17:35 |
|
HardDisk posted:This came from Minecraft's source code, by any chance? That was my first thought.
|
# ? Jan 4, 2011 17:40 |
|
It would explain why it's unplayable on my netbook.
|
# ? Jan 4, 2011 18:12 |
|
HardDisk posted:This came from Minecraft's source code, by any chance? Haha I was going to ask the same thing. Great minds think alike I guess.
|
# ? Jan 5, 2011 02:49 |
|
Zombywuf posted:The bug is in the double parser that iteratively approximates the correct value which doesn't work at MAX_DOUBLE. Rasmus decides that the problem is "compiler switches". And apparently they didn't think to check "can we improve this number's error any further?" instead of just while(error > 0.05) It's fixed in SVN so I'm wondering what horrifying method they used to "fix" it.
|
# ? Jan 5, 2011 02:56 |
|
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=304407&r2=307095code:
edit: goes back as far as 4.3 tef fucked around with this message at 03:36 on Jan 5, 2011 |
# ? Jan 5, 2011 03:21 |
|
Randomly sticking in volatile modifiers for a single threaded piece of code with no external IO, nice. I think Drepper would have a nice chuckle.
|
# ? Jan 5, 2011 03:44 |
|
So is volatile in php magical? I am confused as to how this "fixes" the hang-on-certain-float bug. Edit: Instead of blaming PHP programmers, they are blaming a design flaw in the x87 FPU. Malloc Voidstar fucked around with this message at 04:21 on Jan 5, 2011 |
# ? Jan 5, 2011 03:52 |
|
Slapping a volatile on those variables forces them to be stored to memory, which truncates the 80 bit x87 FPU representation down to 64-bits, nicely working around the fact their strtod is retarded, at the expense of performance and relying on the compiler's whims to get it right. Never use volatile, folks. You aren't smart enough, and neither is the compiler.
|
# ? Jan 5, 2011 04:31 |
|
pseudorandom name posted:Slapping a volatile on those variables forces them to be stored to memory, which truncates the 80 bit x87 FPU representation down to 64-bits, nicely working around the fact their strtod is retarded, at the expense of performance and relying on the compiler's whims to get it right.
|
# ? Jan 5, 2011 04:57 |
|
pseudorandom name posted:Slapping a volatile on those variables forces them to be stored to memory, which truncates the 80 bit x87 FPU representation down to 64-bits, Or rather any operation on the volatile double causes the x87 register to be copied to a x86 register causing the down conversion, without the volatile the intermediate values can be kept in the x87?
|
# ? Jan 5, 2011 04:59 |
|
x87 isn't IEEE floats. if you want ieee floats you have to ask for them. it has higher precision internally, so if you do float operations on the registers you'll get different results. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c109 volatile fixes this instance by preventing the optimizer from moving the floats out of memory, so they won't get extra precision. correct flag should be -fexcess-precision=standard i think quote:-fexcess-precision=style tef fucked around with this message at 05:12 on Jan 5, 2011 |
# ? Jan 5, 2011 05:10 |
|
to be fair to php floating point is pain and suffering
|
# ? Jan 5, 2011 05:11 |
|
I like solution 5 in that link. I wish more PHP programmers took that advice.
|
# ? Jan 5, 2011 05:17 |
|
MrMoo posted:Or rather any operation on the volatile double causes the x87 register to be copied to a x86 register causing the down conversion, without the volatile the intermediate values can be kept in the x87? Nope, volatile requires memory, not integer registers. tef posted:x87 isn't IEEE floats. if you want ieee floats you have to ask for them. The x87 is a fully conformant IEEE 754 FPU. It doesn't operate internally using IEEE 754 single or double precision floating point values, but that's allowed by the standard.
|
# ? Jan 5, 2011 06:52 |
|
pseudorandom name posted:Nope, volatile requires memory, not integer registers. But it isn't forcing software x87 emulation, so its copy from x87 registers to main memory and back to x87 registers for each op?
|
# ? Jan 5, 2011 07:51 |
|
HardDisk posted:This came from Minecraft's source code, by any chance?
|
# ? Jan 5, 2011 07:52 |
|
MrMoo posted:But it isn't forcing software x87 emulation, so its copy from x87 registers to main memory and back to x87 registers for each op? No software emulation involved, but, yes, it has to load the variable for every operation and then store it back to memory.
|
# ? Jan 5, 2011 08:00 |
|
pseudorandom name posted:No software emulation involved, but, yes, it has to load the variable for every operation and then store it back to memory. Not in the case of a local variable with no external visibility. The semantics of this are a bit weird, but it would be perfectly ok for the variable to never leave a register. Volatile is an ordering requirement. If the variable was ever referenced it would need an address and thus need to be stored in memory, then what you say would be true.
|
# ? Jan 5, 2011 13:03 |
|
Zombywuf posted:Not in the case of a local variable with no external visibility. The semantics of this are a bit weird, but it would be perfectly ok for the variable to never leave a register. Volatile is an ordering requirement. If the variable was ever referenced it would need an address and thus need to be stored in memory, then what you say would be true. I don't think that's true, but if it is, than the compiler could just keep the variables in the x87 FPU register stack for the duration. Which would also be amusing.
|
# ? Jan 5, 2011 17:36 |
|
|
# ? May 16, 2024 19:01 |
|
pseudorandom name posted:I don't think that's true, but if it is, than the compiler could just keep the variables in the x87 FPU register stack for the duration. It would almost result in a swath of complaints about compiler optimisations breaking backwards compatibility.
|
# ? Jan 5, 2011 17:59 |