perlmonger: (pete)
[Poll #1119627]

[ ETA that this is an abstract question, not an invitation for a language war, though go ahead and have one if you must ]


Sep. 18th, 2007 02:32 pm
perlmonger: (bleurgh)
It’s just occurred to me that, since I’ve had reason to start occasionally using java.util.regex in ColdFusion code, I’m now programming with five incompatible regexp engines, which is nice. That’s Perl 5.8, CFMX 7, java 1.4.2, MySQL 5 and the LCD of current browser javascript regexp implementations. Then there’s the Emacs Lisp variant in XEmacs, and grep itself, neither of which is the same as any of the preceding.

Mostly it’s not too horrific, but remembering what supports +ve/-ve lookahead/lookbehind assertions, and which combination of character class syntax definitions both work and work in the same way is… irritating. Is ‘\w’ [a-zA-Z0-9_] or [\p{L}\p{N}_]? Why doesn’t java do POSIX named entities? Why doesn’t CFMX 7, which AFAIAA actually uses the java engine under its hood, support UNICODE \p{} escapes? Why on Earth does MySQL 5 reverse the meanings of ‘\’ and ‘\\’?

I’ll shut up now.
perlmonger: (plugh)
Turns out that if you create an input control on the fly in IE6 and stuff it into the DOM tree, it gets inserted into its form’s elements array, but not into the associated hashtable. It’s there and not there all at the same time...
      if (!iewin || theForm.elements[theField])
      else // it beggars belief, really
	for (var i=0; i<theForm.elements.length; i++)
	  if (theForm.elements[i].name==theField) {

MS have been kind enough to retain backward compatibility on this “feature” in IE7.
perlmonger: (job)
bash (at least up to 3.00.16) isn’t clever enough to look past a BOM to see a shebang. This might be of interest if you have, say, a Perl script running as a cron job that you update, the replacement version being utf-8 encoded...

“cannot execute binary file” indeed.

That’s all.
perlmonger: (bleurgh)
Well, that explains why [ profile] ramtops couldn’t find Mac Jordan on Google - a buggered robots.txt file forsooth.

IIRC she got hammered by an impolite spider a while back and I bunged an explicit Crawl-delay in her robots.txt. Did it there to get it in place fast and, for some reason, redid and committed it here, rather than committing the change on the server. Turns out I put a space after the colon at one end and not the other: cue a CVS conflict on the next update at the server, and I never noticed. Mea maxima culpa.

I’m doing my small part in rectifying the cockup by confessing to it, and more importantly, linking to on this here indexed LJ to help kickstart her return from airbrushed non-site-hood.


Sep. 12th, 2006 05:23 pm
perlmonger: (bleurgh)
I’ve just had reason to hack some C, for the first time in $UNFEASIBLE_PERIOD. It’s a sign of something (mental decay, probably) that I had to look up a standard function definition; that I used a copy of K&R, first edition, as a reference is probably a sign of something else entirely.

I think I’ll dig out my Algol68R reference now, before Nurse brings the tea and pills round.
perlmonger: (gorey)
Has anyone out there any idea what could fsck routing in XP Pro such that it’ll see the LAN fine, but won’t route through its gateway? It’s running under VMware with bridged networking, but so are five other VMs (W2K, W2K/AS and XP pro, variously) all of which will happily route anywhere.

IP and routing settings look fine; it’s most odd. And irritating.

working XP Pro VM )

broken XP Pro VM )

The only difference there that I can see (apart from the IP address) is that the virtual ethernet device is 0x2 on the working box, 0x10003 on the broken one. I don’t have any idea how the interface numbers are assigned (by XP? by VMware?), let alone if they make any difference.

( is our dual WAN router, sitting outside the Sonicwall, if anyone is curious)
perlmonger: (quartic)
There is something terrifying sad in my psyche when, on reading mention of Toilet Closures in [ profile] brisingamen‘s LJ, my first thought was of functional programming...
perlmonger: (excited)
I've been cursing the change in LJ, making all in-journal use the syntax. The stylesheet for my S2 layout layer has (or had) CSS3 [href^=""] entries for links to colour in-LJ links differently and it wasn't until that stopped working (other than for me and [ profile] ramtops, coded in there as special cases) that I realised how much I'd miss it.

Anyhow, turns out that Gecko, from at least the last Firefox release, also supports the CSS3 [href*=""] attribute selector syntax, so I've got my correctly coloured links back!! OMG!!! and for all LJ links now too, without any extra work.

Needless to say, neither syntax works in any released version of IE, but I care not: it's my LJ and anybody mad enough to read it who's also (differently) mad enough to use IE6 or worse will be getting a crap looking layout anyhow. I've not got round to checking Safari yet and haven't yet got any betas of IE7 running here; I'll be interested to see how they cope.
perlmonger: (Default)

Well, what's all this flock thing then? I thought that was a system call?

ETA: well, it's part way there with LJ posting; comes up with errors but posts anyhow via the ATOM interface... we'll see how it develops.

perlmonger: (bleurgh)
I discovered yesterday that IE/Mac copes not at all with javascript resources encoded as UTF-8+BOM; it encounters the BOM, thinks "you're havin' a larf" and buggers off back to its grave in Redmond. No warnings or errors; it just ignores the file altogether.

browser stats )


perlmonger: (Default)

July 2013

14 151617181920


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Powered by Dreamwidth Studios