Playing with Deepest Sender

I ran across Deepest Sender, a firefox extension used for posting to a blog, today and thought I'd give it a shot. It supports a small, but reasonable set of blog apps (Wordpress, LJ, ... two or three others that escape me at the moment, and I can't find the list right now..) Setup was easy, and it wasn't difficult to connect to my wordpress install , but I don't see how to add multiple blogs, or choose a blog to post to that isn't the default. I'm also a bit mystified at how it manages drafts (you can save to a local file, but that doesn't quite cut it -- I want to take advantage of the draft capabilities of the blog app, so I'm not tied to one machine).

I wonder if it will let me use code tags in the rich editor..


-- haskell?
foo :: Int -> Int
foo x = x * x



// Java test
public static int foo(int x){
return x * x;
}


...not really... (although, there is a source view, and it's just a click of a tab to switch back and forth, which is how I entered the c# sample below, although it look horrible in the rich editor.) There are some interesting fields under the options menu, including a text area to enter a stylesheet, but no indication of what it does. I may need to dig into the help docs later, but I'll probably look into emacs extensions first. For now, the jury is out. /// /// Sample c# /// public static int Foo(int x){ return x * x; }


Ah, when posting, I discovered how the draft works. There is a checkbox marked "draft" which publishes content as a draft, rather than to the site. It would be much clearer to just have two buttons: "Publish" and "Save as draft", it would take up the same amount of space, and require fewer clicks, but I suppose you could accidentally publish to the main site when you really wanted to click on draft. In any case, it ruined the formatting on the code snippet, so for my purposes it will not work.

Home is where .emacs is...

I finally found a way to quickly navigate to my home directory in windows today. Being a long-time (well, 8-10 years) Linux user, when I started working in windows 40 hours a week, I had to adapt a bit, but most of that adaptation meant installing cygwin utilities, bblean, and emacs. Unfortunately, it's most natural to put all the configuration files for these apps in my home directory -- a concept that is almost completely alien to a windows system. As you probably know, in Win XP you do have a home dir, conveniently located at c:Documents and Settingsusername which is not extremely easy to navigate to, and there are no simple shortcuts to get there as there are in Linux / unix environments.

This has been annoying me for some time. Everything goes into that directory -- I've moved firefox downloads, Visual Studio projects, symlinked My Documents to there, etc... Now before you shout out that I brought this upon my self, consider that:

• I needed everything to be in the same location, for what should be obvious reasons. (but if the reason's arent obvious, try backing up all your crap from a multi-year old windows machine where you didn't keep everything in one place)


• More things were already using this location than were not (remember, most of what I use is cygwin).


• Cygwin makes it mildly painful to access things that don't fit nicely into the cygwin virtual filesystem thing.

Today, however, I found a solution. Oddly enough, the integration between IE and Windows is why this works.

1. Open the Windows Explorer


2. Select View-Toolbars-customize


3. Add the "Home" button to the toolbar


4. Click on it. (This changes the Explorer "mode" to web-browser, and allows access to configure that button.)


5. Select Tools-Internet Options


6. Set your IE home page to c:Documents and Settingsusername


7. Voila! Click on the home button again, and there you are :)

foreach(What?)

I've been adapting to Java 1.5 and c# (and c#, with .NET 2.0), all of which feature a new construct: the foreach loop. The syntax is relatively similar to the construct in numerous other languages, such as perl's:


foreach $var (@list){
# ...
}


In c# (or java, the syntax is the same), to loop over an array or IEnumerable collection, you just do:


foreach(int x in indices){
// ....
}


Unfortunately, as I found today, the c# version shares something else with the Perl version: An absence of type checking. Despite the explicit types in the loop construct, and the presence of generics (although these are missing in .NET foreach in c# is not type safe. The end result is that you can do fun things like this with out the slightest hint of a warning:


double[] values = new double[]{....};
/* snip */
foreach(int v in values){
// guess what? v == Math.Floor(values[i]) !
}


I find this particularly vexing because if you simply re-write the foreach to be a standard for loop, then the type checker will jump in and complain about the loss of precision:


for(int i=0; i

With collections this becomes slightly more complex, and in .NET pre-2.0, Enumerators were not typed (they would simply return Objects, making it impossible to perform compile time type checking), with .NET 2.0, however these constructs could be parametrized, eg:


foreach(T id in IEnumerable){
// body
}


Why this isn't done is a mystery to me. At the very least a rewrite rule could be used to turn each foreach into an equivalent for loop. (There are plenty of ways around any performance problems this would cause at run time, and I'm happy to pay a compile-time penalty if it prevents run-time bugs!)

Edit: Just for completeness, Java 1.5 does not exhibit this behavior, either when itterating over generic collections or arrays of basic data types:

double[] values = new double[]{0.5, 0.6, 0.7};

for (int v : values){ // causes compile time error.
System.out.println("v="+v);
}

Note that it is actually an error in java, not a warning even. I would assume this has something to do with the requirements Sun placed on backwards compatability with older JREs -- much, if not all, of the java Generics changes are simply rewrite rules. C#, however, has no such constraints and can take advantage of a number of performance improvements that are not available to the java compiler. I still don't see that as an excuse for discarding type saftey. --ERC