|
kitten smoothie posted:See also: the HTTP verb parser in nginx. This seems sub-optimal. While they switch on verb length, they do if-sequences within each length. They should instead find one or two operations (multiply by a constant or something, then mod) which gives an unique number between 0 and 14 for each HTTP verb, then switch on that, with a final compare in each case. Much faster! ymgve fucked around with this message at 23:52 on Jan 29, 2013 |
# ? Jan 29, 2013 23:50 |
|
|
# ? Jun 5, 2024 08:38 |
|
Join an array on a string like a boss (well, a Director of something or the other, actually).php:<? function myfunction($v1,$v2) { return $v1 . $v2 . ","; } $a=$SN; //print_r(array_reduce($a,"myfunction")); $SNarraay = (array_reduce($a,"myfunction")); ?> php:<? $info = explode(',', $SNarraay); list($a,$b,$c,$d) = $info; ?>
|
# ? Jan 30, 2013 00:37 |
|
ymgve posted:This seems sub-optimal. While they switch on verb length, they do if-sequences within each length. They should instead find one or two operations (multiply by a constant or something, then mod) which gives an unique number between 0 and 14 for each HTTP verb, then switch on that, with a final compare in each case. Much faster! Actually couldn't you bit-shift all of those verbs (minus PROPPATCH, which is 9 chars) into longs and switch on that? Think of the wasted cycles!
|
# ? Jan 30, 2013 01:15 |
|
Wheany posted:But since it is randomized between vm restarts, no non-malicious software relies on specific hash values for things, right? So they could just replace it with SipHash?
|
# ? Jan 30, 2013 01:16 |
|
Munkeymon posted:Join an array on a string like a boss (well, a Director of something or the other, actually). So am I correct in thinking the behaviour is the same as code:
Also, I'd never seen list() before. It figures the PHP devs would try to implement useful features from Python and do them in a shonky way. Also "$NSarraay"
|
# ? Jan 30, 2013 03:47 |
|
Hammerite posted:fake edit: actually no, this ignores that the elements of $a might have commas in them. That's reasonably unlikely since this is isn't a public page. We're dealing with inventory here, so it's short for stock number, not something transmorgified into PHP from an OSX codebase. This is the same guy who does this (formatting preserved): php:<? if ($valueAA=="1900"){ $a1900 ="selected='selected'"; } elseif ($valueAA=="1971"){ $a1971 ="selected='selected'"; } //snipping a shitton of hand-copied PHP because I'm not sure it'd all fit in one post elseif ($valueAA=="2013"){ $a2013 ="selected='selected'"; } if ($valueBB=="1900"){ $b1900 ="selected='selected'"; } //and on it goes... ?>
|
# ? Jan 30, 2013 16:13 |
|
I don't even know what the gently caress. I'm working on a bit of code to launch VLC with a user-configured video file on windows. All I've got to work with is os.execute (which itself is a wrapper around system), but even with windows's whackass quoting rules this shouldn't be too hard, right? code:
code:
Further investigation reveals that having forward slashes in the file path causes VLC to think it's been passed an empty command line. I don't know if this is some problem with system() (despite handling the forward slashes in the path to VLC just fine), or if VLC itself is loving up. What definitely is a VLC problem, however, is the fact that if you don't pass any valid paths to vlc --play-and-exit, it stays open forever rather than exiting immediately. Ok, so backslashes it is: code:
code:
Much googling later: code:
Yes, having double quotes later in the command line causes the double quotes surrounding the actual command to stop working. The solution is to start the command with double double quotes (yes, leaving the quotes unbalanced) and then continue as normal. Why would it work this way
|
# ? Jan 30, 2013 17:22 |
I'm guessing that it Python. Why would you use os.execute (which I can't even find in the docs?) rather than something like os.spawnl which takes each argument to the command line as a separate parameter to the function call?
|
|
# ? Jan 30, 2013 17:55 |
|
Or subprocess, which is supposed to replace all that crud because it sucks.
|
# ? Jan 30, 2013 18:02 |
|
The horror here is using the functional equivalent of system()
|
# ? Jan 30, 2013 18:09 |
|
Munkeymon posted:Join an array on a string like a boss (well, a Director of something or the other, actually). The entire if loop could also be fixed by using variable variables, which makes me wonder how this guy learned PHP as he knows array_reduce and explode, but then not other stuff like implode and $$.
|
# ? Jan 30, 2013 18:41 |
|
nielsm posted:I'm guessing that it Python. It's Lua, not Python. If it were I'd be using subprocess. KaneTW posted:The horror here is using the functional equivalent of system() Lua itself is ANSI C and thus only gets system(), and the program I'm using doesn't make bindings to anything more advanced available. This has been enough of a pain in the rear end that I'm considering patching it with my own binding to spawnv and using that instead, though. Even taking into account the fact that system() is terrible, though, it seems exceptionally terrible on windows.
|
# ? Jan 30, 2013 18:57 |
|
ToxicFrog posted:Lua itself is ANSI C and thus only gets system(), and the program I'm using doesn't make bindings to anything more advanced available. This has been enough of a pain in the rear end that I'm considering patching it with my own binding to spawnv and using that instead, though. Yeah, this sorry state of affairs prompted a coworker of mine to write low level bindings for unixy systems, since it's easier to work with fork and exec than system. http://www.rjek.com/software.html quote:
|
# ? Jan 30, 2013 19:53 |
|
It looks like trying to launch a separate process and interact with it is a horror in any language. Well, it's more a runtime/library issue, but it's still a huge pain in the rear end. There's a longstanding bug with the .NET runtime that I just ran into with their Process stuff. Basically, you're going to get burned if you use the default streams. The read calls will block even if they shouldn't. Peek will block. So you have to use the data received event handlers.
|
# ? Jan 30, 2013 19:58 |
Edison was a dick posted:I've heard this is because windows leaves argument parsing to every program, rather than everything getting an argument list, but I don't have any proof of this. Yeah, DOS passed the parameters as a single string (in a fixed size block) and Windows inherited that model, although the block is now dynamically sized. But the actual program name is a separate argument to the CreateProcess() function in Win32. Windows NT (W2k or maybe earlier) also added a CommandLineToArgvW() function that parses that command line string into an argc/argv pair for you. It only works on Unicode strings, but you should be using those anyway.
|
|
# ? Jan 30, 2013 20:03 |
|
Master_Odin posted:I'm still kind of hung up on this. How is this not just implode(",",$a)? Like, he knows that explode exists, but then just hand-rolls his own implode? Or am I being the dumb one here? You're giving him far too much credit when you assume he actually understands what he's writing/copy+pasting rather than aping examples he finds online.
|
# ? Jan 30, 2013 20:46 |
|
Rocko Bonaparte posted:It looks like trying to launch a separate process and interact with it is a horror in any language. Well, it's more a runtime/library issue, but it's still a huge pain in the rear end. There's a longstanding bug with the .NET runtime that I just ran into with their Process stuff. Basically, you're going to get burned if you use the default streams. The read calls will block even if they shouldn't. Peek will block. So you have to use the data received event handlers. The primary bug is in the documentation - the javadoc makes no mention of requiring you to call .destroy() or to close every stream (even if you didn't use them) to properly clean up a Process.
|
# ? Jan 30, 2013 20:48 |
|
Freakus posted:http://bugs.sun.com/view_bug.do?bug_id=4784692 Am I reading this right? This is a ten year old request to clarify the documentation but still not in the doc?
|
# ? Jan 30, 2013 20:59 |
|
ToxicFrog posted:I don't even know what the gently caress. Okay, so you're using Lua. These problems are somewhat understandable on a cross-platform language. But loving Windows Poweshell. How in the gently caress can executing programs from under Program Files be so loving difficult in a shell designed for Windows. I was tearing my hair out with the equivalent of "c:\Program Files\ImageMagick-6.8.2-Q16\convert.exe" "C:\Users\My Username\Pictures\some file with spaces 1.png" -resize 50% "some file with spaces 1.gif" Where the number in the file name came from a loop index variable.
|
# ? Jan 30, 2013 21:37 |
|
Admiral H. Curtiss posted:Am I reading this right? This is a ten year old request to clarify the documentation but still not in the doc? There are two other bugs referencing the same issue in the last decade, surely one of them has progress? http://bugs.sun.com/view_bug.do?bug_id=4801027 http://bugs.sun.com/view_bug.do?bug_id=6462165 ...they're not fixed either.
|
# ? Jan 30, 2013 21:46 |
|
Wheany posted:Okay, so you're using Lua. These problems are somewhat understandable on a cross-platform language. Try setting up a PS script to run as a job in the scheduler. There's so much security bullshit around it that the one time I tried it, I gave up and wrote a program in C# with notepad and compiled it with csc.exe instead. It took less time than I had wasted trying to get an already working script to run as a job and worked the first time.
|
# ? Jan 30, 2013 22:10 |
|
Wheany posted:Okay, so you're using Lua. These problems are somewhat understandable on a cross-platform language. You could try c:\'Program Files'\ImageMagick-6.8.2-Q16\convert.exe "C:\Users\My Username\Pictures\some file with spaces $i.png" -resize 50% "some file with spaces $i.gif" where i is the loop variable.
|
# ? Jan 30, 2013 22:21 |
|
Wheany posted:Okay, so you're using Lua. These problems are somewhat understandable on a cross-platform language.
|
# ? Jan 30, 2013 22:31 |
|
Munkeymon posted:Try setting up a PS script to run as a job in the scheduler. There's so much security bullshit around it that the one time I tried it, I gave up and wrote a program in C# with notepad and compiled it with csc.exe instead. It took less time than I had wasted trying to get an already working script to run as a job and worked the first time. Oh yeah, and by default, powershell won't run any scripts. Okay, I get that Microsoft was burned pretty bad in the XP/IE6 days, but still.
|
# ? Jan 30, 2013 22:51 |
|
Zhentar posted:Any browser code path that is traveled by SunSpider (and I'm guessing that one is hit quite a bit) has been profiled and thoroughly analyzed about 17,000 times. I don't know why they don't just store hashes by partially evaluating a prefix tree.
|
# ? Jan 30, 2013 23:55 |
|
Master_Odin posted:I'm still kind of hung up on this. How is this not just implode(",",$a)? Like, he knows that explode exists, but then just hand-rolls his own implode? Or am I being the dumb one here? It's not implode. His array-reduce function puts the comma after the two arguments rather than in between them. Also, yes a loop should be used, but an array is the correct approach, not variables named $a1971 through $a2070 or whatever.
|
# ? Jan 31, 2013 05:16 |
|
Wheany posted:Oh yeah, and by default, powershell won't run any scripts. Okay, I get that Microsoft was burned pretty bad in the XP/IE6 days, but still.
|
# ? Jan 31, 2013 10:10 |
|
Jethro posted:I've been using Powershell pretty heavily for about a year now. I have no idea how to call an executable that isn't in the current path, so when I have to do so, I just give up and Set-Alias. The same way as you would normally? Or have you found some problematic scenario I have not discovered yet in my mere three months? code:
|
# ? Jan 31, 2013 11:01 |
|
Jethro posted:I've been using Powershell pretty heavily for about a year now. I have no idea how to call an executable that isn't in the current path, so when I have to do so, I just give up and Set-Alias. I don't really know how that makes anything more secure since it seems like if you could dump a binary with execute rights in the local directory you could just as easily modify the script directly, but hey, I'm no security analyst.
|
# ? Jan 31, 2013 11:11 |
|
Admiral H. Curtiss posted:Am I reading this right? This is a ten year old request to clarify the documentation but still not in the doc? As a sidenote, not reading/closing Process streams caused me to spend a few hours trying to figure out why my program when hang with 0% CPU usage forever when using them. Fun.
|
# ? Jan 31, 2013 11:24 |
|
http://sourceware.org/ml/glibc-cvs/2013-q1/msg00115.html
|
# ? Jan 31, 2013 11:40 |
|
The Gripper posted:I don't really know how that makes anything more secure since it seems like if you could dump a binary with execute rights in the local directory you could just as easily modify the script directly, but hey, I'm no security analyst. I would imagine that the protection is primarily for the interactive shell, since it's relatively trivial to get someone to execute dir in a directory where you've placed a malicious dir.exe. Scripts are just subject to it for consistency.
|
# ? Jan 31, 2013 12:05 |
|
Jabor posted:I would imagine that the protection is primarily for the interactive shell, since it's relatively trivial to get someone to execute dir in a directory where you've placed a malicious dir.exe. Scripts are just subject to it for consistency.
|
# ? Jan 31, 2013 12:16 |
|
Just stumbled across this in some code a client got from some other consultant:C# code:
I can sort of forgive the throw ex;, that's a pretty common mistake. The other thing is unforgivably stupid, though. I almost want to email them and say "Hey guys, you know you can do this, right?" C# code:
|
# ? Jan 31, 2013 14:41 |
|
EssOEss posted:The same way as you would normally? Or have you found some problematic scenario I have not discovered yet in my mere three months? code:
|
# ? Jan 31, 2013 19:17 |
|
The Gripper posted:Well, for calling executables directly in the current local directory you need the .\ prefix, anything else is assumed to be on the environment path and won't search locally. I assume it's designed to prevent someone dumping malicious binaries in the local directory that override system executables. "." is usually not in the default path of lots of shells in lots of unix variants these days for the same reason.
|
# ? Jan 31, 2013 23:12 |
|
If I remember correctly, the "." in Unix is actually just an alias to your current working directory without a trailing slash. That's why you need to add the slash to it, so that you essentially pass the absolute path to the command line.
|
# ? Jan 31, 2013 23:34 |
|
This isn't a huge horror but http://www.minethings.com/app/webroot/forums/viewtopic.php?p=122960#p122960 Basically, he had his sessions set to expire in 25 years. Well, unix time + 25 years overflows MAX_INT this month. I guess these problems are going to start ramping up now.
|
# ? Jan 31, 2013 23:35 |
|
Thern posted:If I remember correctly, the "." in Unix is actually just an alias to your current working directory without a trailing slash. That's why you need to add the slash to it, so that you essentially pass the absolute path to the command line. He's saying that the current directory isn't in the path by default to prevent people dropping in malicious scripts with the name of common programs.
|
# ? Jan 31, 2013 23:36 |
|
|
# ? Jun 5, 2024 08:38 |
|
http://peej.github.com/tonic/ Annotate routes and method conditions in comments! PHP code:
|
# ? Jan 31, 2013 23:46 |