x264の連中と言い争ってきたが、POSIXの連中とは話がかみ合わない

POSIXがすべてであると思っている連中とは、話が成立しない。はっきり言う。POSIXは独自規格である。Win32 APIとなんら変わらないのだ。hitoとは私の事。

00:08 (hito) when VC's project file are up to date?
00:10 (marnik) pengvado: so in a 720 25 fps progressive stream
00:10 (marnik) time_scale should be 50 and tick 1?
00:10 (marnik) because 25 fps progressive is 50 fields per second?
00:17 *T_RAY join #x264 (n=T_RAY@66.195.171.51)
00:17 (Gabriel_B) VC projects for win32 should be up to date, once you apply this: http://mailman.videolan.org/pipermail/x264-devel/2008-April/004361.html
00:18 (hito) still using nasm?
00:20 (hito) has anyone actually using nasm? it couldn't build x264's asm file.
00:21 (Quazgaa) you have to use yasm
00:21 (hito) i agree with that.
00:22 (hito) but if so, why they don't change project file to use yasm?
00:22 (Quazgaa) oh, you are talking win32 stuff, who cares about that ;)
00:23 (hito) me :(
00:23 (pengvado) nasm Works For Us
00:23 (pengvado) you need a recent version, but then old yasm doesn't work either
00:24 (pengvado) Gabriel_B: of course I haven't tried it, but I can tell just by looking that the patch breaks Release64
00:24 (pengvado) not that it was working before the patch
00:24 (Gabriel_B) really?
00:25 (Gabriel_B) hummm....was win64 supposed to work?
00:25 (Dark_Shikari) lol
00:25 (JEEB) lol
00:25 (marnik) anyone on my last question?
00:25 (pengvado) not really, last I heard of it was maybe a year ago when squid_80 was updating
00:26 (pengvado) marnik: yes
00:26 (Gabriel_B) so anyhow, win64 was already further broken since you reorganised asm code
00:27 (hito) I've never build win64 since i use 32bit Vista.
00:28 *microchip_ quit (Remote closed the connection)
00:28 *microchip_ join #x264 (n=microchi@78-23-99-124.access.telenet.be)
00:28 (pengvado) hito: and you never wished your cpu was 15% faster?
00:28 (Dark_Shikari) there should be a doom9 rule that if you post a certain number of consecutive retarded threads
00:28 (Dark_Shikari) you get banned
00:28 (Dark_Shikari) "3NC0D3_Y0_A$$" seems to be working very hard at this
00:28 (iive) pengvado: what kind of error is produces when sse2 does unaligned access?
00:28 (marnik) great
00:28 (JEEB) the nickname says it all < Dark_Shikari
00:28 (marnik) thanks
00:28 (Dark_Shikari) lol
00:29 (iive) segfault or bus error
00:29 (Dark_Shikari) iive: I've gotten segfaults on Windows
00:29 (marnik) what version of x264 should i use? I am using 20070924, read through the changelog, should i update for speed/quality/stability or stick to that version?
00:30 (Dark_Shikari) you should generally update =P
00:30 (Quazgaa) update :x
00:30 *T_RAY quit (Read error: 104 (Connection reset by peer))
00:30 (Dark_Shikari) speed has gone up probably over 20% in the past month
00:30 (hito) pengvado: maybe i ll use 64bit Windows 7.
00:30 (marnik) cool
00:30 (Quazgaa) i update every time i rip something ;)
00:30 (JEEB) I try to keep up with jarod's builds <_<
00:30 (marnik) and when using x264 with vlc to encode, does it matter what version of vlc i use?
00:31 (marnik) i mean, 0.8.6f vlc, should work with the latest x264?
00:31 (Dark_Shikari) well, I wouldn't encode with VLC unless I absolutely had to do streaming
00:31 (Dark_Shikari) but I assume it would work
00:32 (marnik) i absolutely have to do streaming :)
00:32 (JEEB) How do you encode via CLI x264 via VLC o_O
00:32 (Dark_Shikari) you use libx264 in vlc
00:32 (JEEB) ah
00:32 (JEEB) alrighty
00:38 (Gabriel_B) pengvado: here it is: http://pastebin.com/m4385fd34
00:39 (Gabriel_B) it doesn't fix win64, but doesn't break it further
00:41 (hito) speaking of win32. i really want rename fix for win32.
00:42 (Dark_Shikari) it already works fine on win32
00:42 (Dark_Shikari) what you want is rename fix for *MSVC*
00:42 (hito) no it doesn't
00:42 (Dark_Shikari) I know it does, because I'm using it right now
00:42 (Dark_Shikari) and I already proved that it works fine
00:42 (hito) C99 spec say it "implementation-defined"
00:42 (Dark_Shikari) Yes, and when compiled with gcc, it works fine
00:42 (Dark_Shikari) Since MSVC support has been broken for over a month now and nobody has really cared
00:43 (Dark_Shikari) I don't think its that important
00:43 (Gabriel_B) What's the problem with msvc?
00:43 (Gabriel_B) I am using it right now
00:43 (Quazgaa) its the devil
00:43 (Dark_Shikari) Its rename function does not overwrite the target file
00:43 (Dark_Shikari) apparently
00:43 (JEEB) does mingw have speed problems with the win32 build?
00:43 (Dark_Shikari) (according to hito)
00:43 (Dark_Shikari) if by "Speed problems" you mean "its too fast", maybe
00:43 (JEEB) alrighty then
00:44 (JEEB) I was thinking why people want to build a certain app "native to win32" with MSVC
00:44 (Gabriel_B) well, if someone could explain me what is the faulty behavior, it could perhaps fix it
00:44 (pengvado) mingw is native win32
00:44 (JEEB) ah
00:44 (pengvado) cygwin is what's non-native
00:44 (JEEB) alright, I stand corrected then
00:44 (Dark_Shikari) and x264 uses mingw even under cygwin
00:45 (hito) according to ANSI C and C99 spec, whether rename() overwrite file or not is "implementation-defined"
00:45 (hito) POSIX spec says it overwite.
00:45 (Dark_Shikari) that's one reason we like POSIX.
00:45 (hito) MSVC's rename function doesn't overwite file.
00:46 (Gabriel_B) hito: and what is the erroneous behavior that the user would notice?
00:46 (pengvado) and x264 defines rename to be unlink,rename
00:46 (Dark_Shikari) it doesn't overwrite the second pass file
00:46 (pengvado) what's the problem?
00:46 (Dark_Shikari) e.g. if you have a twopass file in the directory
00:46 (Dark_Shikari) and run another encode
00:46 (Dark_Shikari) or a third pass
00:46 (hito) if i want to multi pass encode, it doesnt overwrite log file
00:46 (JEEB) now why would POSIX be against the ANSI C specs <_<
00:46 (Dark_Shikari) JEEB: it isn't
00:46 (pengvado) does C99 also say it's implementation-defined whether unlink unlinks its file?!
00:46 (Dark_Shikari) lol
00:46 *herrwaldo join #x264 (n=waldo@ip-81-11-224-63.dsl.scarlet.be)
00:46 (Dark_Shikari) I would think its far more likely that MSVC breaks the specs ;)
00:47 (Gabriel_B) this is starting to look like a friday afternoon discussion
00:48 (pengvado) or not. man 2 unlink says it isn't even in c99, only posix. so if msvc is known to not be posix, yes, it probably does not unlink the target of unlink.
00:49 (pengvado) JEEB: what's against what?
00:49 (Gabriel_B) I think that msvc is said to be posix, but is known to not be posix
00:49 (pengvado) if c says implementation define, and posix defines something, it's just being an implementation
00:53 (hito) The question is whether x264 rely on POSIX(sadly standard doesn't mention about thread and such) or standard C spec.
00:53 (pengvado) x264 relies on the intersection of gcc, mingw, and linux
00:54 (pengvado) standards compliance and other compilers is just gravy
00:56 (hito) so i must modify rename function every time i build...
00:57 (pengvado) I'm still interested to know what msvc does with unlink() other than delete something
00:59 (Gabriel_B) want a good laugh? Here is the msvc doc for unlink: "This POSIX function is deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _unlink instead."
01:00 (pengvado) oh, right. every since standard compliant function in msvc is preceded by one or more _.
01:01 (hito) i think unlink is a posix function
01:01 *myrdred quit ("KVIrc 3.2.6 Anomalies")
01:01 (pengvado) and msvc says posix is deprecated
01:01 (hito) i can't find it in C99 spec.
01:01 (pengvado) so yes, you can edit it every time you want to compile
01:05 (hito) there are standard C library and POSIX C library. POSIX is NOT a standard C and vice versa.
01:05 (Gabriel_B) hito: do you mean that you noticed an unwanted behavior when using msvc, you know how to fix it, but did not reported your fix??
01:12 *Bombo_ join #x264 (n=bombo@dslb-084-060-235-183.pools.arcor-ip.net)
01:12 *backgroundman quit ("Leaving")
01:13 (Gabriel_B) I just tried --pass 3, and it works fine, even with msvc
01:14 (Gabriel_B) and unlink really removes the file
01:15 (Dark_Shikari) maybe its only the most recent versions of their compilers?
01:15 (hito) there is unlink in msvc for backward-compatibility.
01:15 (Gabriel_B) I'm using vc8, since this is the freely available version
01:16 *emtee quit (Read error: 104 (Connection reset by peer))
01:16 (Gabriel_B) anyhow, here it works fine
01:16 (Gabriel_B) hito: which compiler are you using?
01:16 (hito) VC8 and VC9
01:16 (hito) Express
01:18 (Gabriel_B) and on your side, the "stock" x264 version doesn't properly unlink ?
01:18 (Gabriel_B) with vc8??
01:19 (Gabriel_B) wondering how you fixed it to also work on your side...
01:20 (hito) thats weird.
01:21 *Bombo quit (Read error: 110 (Connection timed out))
01:21 *nick Bombo_ → Bombo
01:22 (Gabriel_B) paste your fix, that might give us indications regarding what is happening
01:22 (hito) i just use MoveFileEx
01:23 (hito) its not portable
01:24 (Gabriel_B) that's definitively a win32 function
01:24 (hito) yes.
01:24 (hito) in your windows. MSVC rename overwrite file?
01:26 (Gabriel_B) no, as mentionned within the doc
01:26 (Gabriel_B) but x264 is using unlink in win32 case
01:27 (Gabriel_B) #define rename(src,dst) (unlink(dst), rename(src,dst)) // POSIX says that rename() removes the destination, but win32 doesn't.
01:27 (Gabriel_B) perhaps, for a yet unknown reason, you don't get that define?
01:28 (hito) i ll write it.
01:28 (hito) but in that code which runs first?
01:28 (Gabriel_B) unlink, then rename
01:29 (hito) unlink? or rename?
01:29 (Gabriel_B) I tried it under the debugger
01:29 (Gabriel_B) and witnessed the stat file vanishing upon unlink
01:31 *Gabriel_B quit (Read error: 104 (Connection reset by peer))
01:32 (hito) oh uh
01:33 (hito) i wonder does he come back.
01:36 (JEEB) I guess as soon as he resets
01:47 *moonwatcher join #x264 (n=lg@89-138-180-132.bb.netvision.net.il)
01:50 (hito) its 1:49 AM in japan. perhaps i should take a nap.
01:50 (hito) #define rename(src,dst) !MoveFileEx( src, dst, MOVEFILE_REPLACE_EXISTING )

unlinkはPOSIXの独自規格だ。それにしてもいまだにプリプロセッサのマクロを多用するとは、なんだかなぁ。

まあそれでも、英語は実に便利な言語だと思う。敬語だとか言うわけの分からない文法がないからだ。