Das eez kaput! Sometime around 2002 I spaced the entire database table that mapped individual entries to categories. Such is life. What follows is a random sampling of entries that were associated with the category. Over time, the entries will be updated and then it will be even more confusing. Wander around, though, it's still a fun way to find stuff.
Are you out of your mind?Shelby asked.There's already so much food that no one will have room!
That's what they all say,I replied.And then it arrives and, with it, The Silence.Philemon nodded knowingly.
Editor's note: it was pointed out to me, today, that I was clearly very drunk by the time the following occurred.
The problem is,I told the Princess,that I've always been very drunk by the time I get around to making these. So, I never remember what I did the last time or if I'm actually doing it right.
Both the Princess and Frances licked their plates clean.
FreeBSD Update is a system for automatically building, distributing, fetching, and applying binary security updates for FreeBSD. This makes it possible to easily track the FreeBSD security branches without the need for fetching the source tree and recompiling (except on the machine building the updates, of course). Updates are cryptographically signed.
Date: Mon, 28 Oct 2002 08:24:08 -0500 (EST) From: Aaron Straup Cope To: Bill Kearney Subject: Re: dc language in rss On Fri, 25 Oct 2002, Bill Kearney wrote: > That would indeed be a problem. You could actually mark up those sections, even > down to the paragraphs or even words with span tags. I shudder at the thought > of what most environments would DO with that data, but it's certainly possible. If I were a better person, I(would(learn(lisp))) and write an Emacs minor-mode to do that. (Sadly(,(lisp(scares(me))))). > Well, the problem is what does that element mean? What purpose is it being used > for? I daresay outside of Syndic8's listing of feeds by language, not much is > paying attention to it. So my question to you is what would you have a reader > program DO with multiple languages? The short answer is : I have no idea. The longer answer is : Who cares? There are two issues here : The first falls into the Foofy Grand Unifying Principles category - the people who invented the Internet didn't know what it was going to be used for. Why should RSS, and its tool set, presume the samething as basic and often controversial as language? The second falls into the Dueling Shakespeare category - RFC 1766 states that : "In some contexts, it is possible to have information in more than one language, or it might be possible to provide tools for assisting in the understanding of a language (like dictionaries). "A prerequisite for any such function is a means of labelling the information content with an identifier for the language in which is is written." But in the absense of multiple language tags, the correct answer when prigs like me start pussing is : <quote src = "rfc1766"> The information in the subtag may for instance be: - Country identification, such as en-US (this usage is described in ISO 639) - Dialect or variant information, such as no-nynorsk or en- cockney - Languages not listed in ISO 639 that are not variants of any listed language, which can be registered with the i- prefix, such as i-cherokee - Script variations, such as az-arabic and az-cyrillic </quote> Which doesn't solve everyone's problem, but can be adapted to deal with the problem of Quebec. I chose en-quebecois, because I like the sound of it. Sovereigntists, on the other hand will probably opt for 'en-qc' since it implies nationhood. Then, of course, there is the question of how to deal with representing a weblog written by the province's allophone population (translation: persons whose mother tongue is neither English nor French and who, in my limited experience, often speak upward of 4-6 languages). What then? qc-allophone?
While the package makes it's way on to the CPAN, you can also grap a copy over here .Keywords are flagged as being any word, or words, between double quotes which are then looked up in the glossary. If no match is found, the text is left unaltered.
If a match is located, the result is then parsed with Robert Cameron's REX shallow parsing regular expressions. Chunks of balanced markup are then re-inserted into the SAX stream via XML::Filter::Merger. Anything else, including markup not deemed well-formed, is added as character data.
<xsl:template match = "somenode"> <xsl:variable name = "anchor"> <xsl:value-of select = "generate-id()" /> </xsl:variable> <someanchor> <xsl:attribute name = "name"> <xsl:value-of select = "$anchor" /> </xsl:attribute> <someanchor> <somenode> <xsl:copy-of select = "." /> <somedivider> <someanchor> <xsl:attribute name = "href"> <xsl:value-of select = "$anchor" /> </xsl:attribute> <xsl:value-of select = "$anchor" /> </someanchor> </somedivider> </somenode> </xsl:template>via decafbad
brio n : quality of being active or spirited or vigorous [syn: {animation}, {spiritedness}] wn
>Prefs >Templates >Home page template
. And I might begin to remember what
next/prev
is supposed to mean, in any given context, in another six months but
right now it's just laughable. Both of these things should be a trivial
tasks for UserLand by now. The menus are exactly the same as building
the menubars for Radio/Frontier on the fly or building, only in HTML.
People have been beating on DHTML menus long enough that there really
is solid cross browser, cross platform, backwards compatible code
available. And the named next/prev linky widget was practically the
first thing people learned how to do in Frontier 4! 8) If the CMS
behind Radio is supposed to be
file-system based
why on earth does the file corresponding to
this page
look like this:
#flHomepage true #flArchivePage true #archiveDate "2002/01/12" <%radio.macros.viewWeblog ()%>
dude, where's my car
This document uses CSS kung-fu and a small amount of JavaScript for rendering its contents. Efforts have been made to separate the form from the content so if you are viewing this in a text-based browser it shouldn't be an issue.
On the other hand it may look funny if you are viewing it in a browser with incomplete CSS and/or JavaScript implementations. Internet Explorer 6 comes to mind.
It's not that I don't love you. However, my time is limited and I no longer feel very good about spending it working around any one browser's inconsistencies with little, or no, confidence that they will ever be fixed or otherwise made more inconsistent at some later date.
On the other hand, if something is down-right unreadable please let me know and I will endeavour to fix it.
yes, we have no bananas
This page may not validate. It's not that I don't care, it's just that I'm not aware of it yet. Part of the reason that I rewrote the entire back-end for managing this site is that the old stuff made it too easy for these kinds of mistakes to slip through the cracks.
See also : W3C::LogValidator.pm
it's the software, stupid