< mari
a
a
a
a
a
a
chi >
[ Page 5 of 6 ]
From: Nicholas Clark Date: 07:36 on 09 Sep 2004 Subject: perforce integration I DO NOT FUCKING NEED THIS //depot/maint-5.8/perl/ext/B/t/f_map.t - can't branch (already opened for add) //depot/maint-5.8/perl/ext/B/t/f_sort.t - can't branch (already opened for add) Step 1: Developer on trunk adds new file WITH BUGS Step 2: Developer fixes bugs and edits file on trunk Step 3: I WANT TO FUCKING WELL INTEGRATE BOTH CHANGES TOGETHER, SO THAT MY STABLE BRANCH IS STABLE BOTH BEFORE AND AFTER MY COMMIT CAN I? FUCK NO BECAUSE YOU LITTLE SHIT, YOU IRRITATING "I KNOW BETTER THAN YOU" PILE OF CRAP, *YOU* WON'T LET ME I AM THE USER. I AM RIGHT. Apart from this REALLY REALLY REALLY ANNOYING "FEATURE" THAT I (hey, surprise, given what my role is) *KEEP HITTING*, perforce is otherwise OK. BUT THIS IS HATEFUL. Nicholas Clark PS Yes, I know I've already hated this. I've hated it again by putting the hates-software archive URL in a perl commit message. But I KEEP FUCKING HITTING IT. Bring on subversion. At least I'd then get some variety in my hate.
From: Nicholas Clark Date: 10:49 on 19 Aug 2004 Subject: (HFS+)-- $ rm parrot24/include/parrot/extend.h rm: parrot24/include/parrot/extend.h: Invalid argument Yes, it's fucked my filesystem again. At least half a dozen times now. I needs a real filesystem. Not this hateful crap. (but soon we'll be hating software that fails to work on UFS) Nicholas Clark
From: Nicholas Clark Date: 18:06 on 30 Jun 2004 Subject: format fucked I hates format fucked. Which claims it merely "flows" messages to make them look nice, and claims that it can be undone 100% by the recipient. But there is hateful culpable stupidity here. Examine the RFC closely: http://www.faqs.org/rfcs/rfc2646.html Section 4.4 - space stuffing "Other lines MAY be space-stuffed as desired" by the sender's MUA Or may not. So if my MUA receives a format fucked message, and the line starts with a space, how does it know if that space was part of the original (pre fucking) message, or a space stuffed buy the format fucker? IT CAN'T. So it has to strip it, on the assumption that it's a stuffing space. This isn't 100% reversibility. And so the grand tradition of inlining source code patches in plain text goes out of the window. I think someone had stuffing between their ears when they wrote this RFC. The flowwit. I hates all the mal user agents that uses this. Nicholas Clark
From: Nicholas Clark Date: 17:08 on 26 May 2004 Subject: Safari So I'm using Safari, and I want to look at this file, but it mangles it and treats it as HTML: http://axpoint.axkit.org/example.axp.txt So I decide to save to disk and look at it in my text editor So I click "Save linked file as" and I am presented with a dialogue with the suggested name "example.axp.html", with "example.axp" highlighted. I replace ".html" with ".txt" A modal dialogue appears: "You cannot save this document with the extension ".txt" at the end of the name. The required extension is ".html' and in smaller print "You can choose to use both, so that your file names ends in ".txt.html" Of course I fucking should be able to fucking save the fucking thing with whatever fucking name I fucking want. I'm the fucking user and the computer is my fucking tool, not my fucking master. And, oh, so smart computer, you know what I'm damn well going to do? Yes. Save the fucking file with the name you fucking insist on, and then go into the bloody finder, take advantage of the hateful default action for return, and rename the bloody thing to .txt. Which I did with no errors or warnings or nagging or swearing or V signs. I should be able to do this from the fucking start. Get that? Or do I have to re-program you with a fire axe? Nicholas Clark
From: Nicholas Clark Date: 14:53 on 17 May 2004 Subject: OS X X server $ xterm Xlib: connection to ":0.0" refused by server Xlib: No protocol specified xterm Xt error: Can't open display: :0.0 W.T.F? You have lost the authorisation to create new X sessions on the local server. Hateful thing. Bad Apple - clearly no (valid magic) cookie. Nicholas Clark
From: Nicholas Clark Date: 11:15 on 14 May 2004 Subject: keyboard or mouse - place bets now! Systems should put keyboard events and mouse events into the same queue. Anything else is a race condition, and thus hateful. Nicholas Clark
From: Nicholas Clark Date: 16:35 on 30 Mar 2004 Subject: mail.app attach window So I want to attach a public ssh key to my message. Can I? Can I hell. mail.app's "attach" window has a file browser which doesn't show . files Or in this case the . dir .ssh. So I can't open the directory containing the file I wish to attach without some extra fandango with some other application. Hateful. Mmm. detach hate and now attach hate. Symmetry. Nicholas Clark
From: Nicholas Clark
Date: 11:21 on 03 Mar 2004
Subject: mail.app and zip file attachments
So I've been forwarded a message, and it contains a zip file attachment.
However, said zipfile has been made by hateful software, which has used
backslashes instead of forward slashes as directory separators in the internal
filenames. Strictly there is nothing wrong - the legal zip file contains
files at the top level named
foo\bar
foo\baz
etc, but the intent was clearly
foo/
bar
baz
Now, I know that Infozip's unzip program is not hateful, and is smart enough
to allow compensation for this hatefulness.
However, can I get mail.app to save the attachment as a zip file? No way!
Whatever I try, it insists on "helpfully" unzipping it for me. And it
(correctly, but unhelpfully) takes a literal view on those backslashes. So
I get crappy filenames with 3 levels of directory trees flattenened
Oi! No. Stop trying to be clever, and let me detach the attachment still as
a zip file.
The only way the collective brains round here could outsmart the hateware
was by saving the message in raw form (OK. at least it lets us do that,
but hatefully it did put [] in the filename it made from the subject line)
and I used a REAL mail program (ie mutt) to save the zip attachment.
At which point unzip can do its magic:
$ unzip Localization-10-30-2003-6.22.57.PM.zip
Archive: Localization-10-30-2003-6.22.57.PM.zip
warning: Localization-10-30-2003-6.22.57.PM.zip appears to use backslashes as path separators
Wah. I think I have a solution. I could just mail Apple 42.zip as an
attachment:
$ unzip -l 42.zip
Archive: 42.zip
Length Date Time Name
------ ---- ---- ----
34902 03-28-00 21:40 lib 3.zip
34902 03-28-00 21:40 lib 1.zip
34902 03-28-00 21:40 lib 2.zip
34902 03-28-00 21:40 lib 0.zip
34902 03-28-00 21:40 lib 4.zip
34902 03-28-00 21:40 lib 5.zip
34902 03-28-00 21:40 lib 6.zip
34902 03-28-00 21:40 lib 7.zip
34902 03-28-00 21:40 lib 8.zip
34902 03-28-00 21:40 lib 9.zip
34902 03-28-00 21:40 lib a.zip
34902 03-28-00 21:40 lib b.zip
34902 03-28-00 21:40 lib c.zip
34902 03-28-00 21:40 lib d.zip
34902 03-28-00 21:40 lib e.zip
34902 03-28-00 21:40 lib f.zip
------ -------
558432 16 files
(etc, etc, etc)
That'll teach them not to trust zip files.
Nicholas Clark
From: Nicholas Clark Date: 13:52 on 07 Jan 2004 Subject: perforce on Macs I'm not even using a Mac. But I'm being adversely affected by perforce running on a Mac: nwc@faith perl$ ll t/op/glob.t -r-xr-xr-x 1 nwc users 2209 Jun 9 2006 t/op/glob.t nwc@faith perl$ rm t/op/glob.t rm: remove write-protected regular file `t/op/glob.t'? y nwc@faith perl$ p4 sync -f t/op/glob.t //depot/perl/t/op/glob.t#22 - refreshing /home/nwc/p4perl/perl/t/op/glob.t nwc@faith perl$ ll t/op/glob.t -r-xr-xr-x 1 nwc users 2209 Jun 9 2006 t/op/glob.t The bloody thing comes back with the wrong timestamp. It seems to be four years out. This would be consistent with doing calculations using an epoch of 1904, when the local timestamps are actually using an epoch of 1900. Grrr. Whatever. It caused me pain and wasted my time. Nicholas Clark
< mari
a
a
a
a
a
a
chi >
[ Page 5 of 6 ]
Generated at 10:26 on 16 Apr 2008 by mariachi