Lots of generic crap for today. Without further ado:
- What in the bleeding hell.
I have to admit that this whole "code/hacker-caffeine" trend is
starting to get on my nerves. After years and years of caffeine
addiction (I could probably have won the world record for most coke
drank in a day) a couple of years ago I decided to let go of it -
almost completely. I now enjoy the occasional coke and, if I'm
genuinely tired and need a pick-me-up, a coffee always helps. Back in
the day I could've drowned a triple espresso without any effect. Bottom
line, it never ceases to amaze me how dependant people allow themselves
to become.
- Joku posted a worthy comment on Mike Stall's blog:
Not really related, but it would be good if technical
bloggers writing about X,Y & Z would also mention what is the
closest public release they are using. Now if you go google and find
some older blog entry it maybe the stuff being talked about was in
relation to for example VS Beta 1 and might be completely wrong today.
I don't think everyone who come to blogs.msdn from google will figure
out that many of the blog entries that talk about say VS2005 are
actually talking about something that's specific to non-RTM build. If
there were tags for every public build and they were visible and easy
to put on the blog entry... Well some day perhaps.
It is a valid point, and I shall endeavour to do that from now on.
- RMS never ceases to amaze me in how he takes theories (conspiratorial, political or otherwise) and treats them like facts. "Israel's real nuclear weapons",
says he. It is commonly accepted that Israel does have a nuclear
arsenal, but no-one knows for sure, myself included. Admittedly RMS's
never purported to be unbiased or politically-correct, but it bothers
me never-the-less.
- Fellow Israeli developer-blogger Oren Ellenbogen mentioned a few weeks ago a subtlety in the usage of interfaces
in C# I was not aware of. I've since used explicit interface
declarations with great success, however one caveat is that you can't
use the interface members even from a private scope (i.e. from a member
method within the class implementing the interface). So use this
feature with caution - it can reduce messiness (particularly where
intellisense is concerned), but often at the cost of forcing you to add
lots of unnecessary casts.
- Software patents are taking an increasingly alarming foothold in
common business practice. Litigation has always been part of business,
but when Creative sues Apple
for patent infringement over the iPod's navigation interface, to me it
means things have gotten completely out of hand. Face it, people:
one-click shopping, song navigation in menus etc. should not be patentable.
It's ridiculous, any UI-designer with more than 3 IQ could've come up
with that concept. Yes, Creative went to market first, but that is
completely irrelevant; just imagine if someone patented the "ability to
close a user interface component by clicking a button" - none of us
would be able to close windows. Does that make sense to you?
- This little hard-drive hack is really damn cool.
- The Blizzard vs BnetD
case is worrisome to say the least. I'm not versed in the particulars
of the case, but assuming the BnetD programers did not actually
reverse-engineer Blizzard proprietary code they should not have had a
case. I wonder how this case compares to the Microsoft vs Samba
litigation - I reckon I should do some further reading.
- I've been playing with Total Commander for several days now. Originally I couldn't stand the software, but admittedly it gives Servant Salamander a serious run for its money, and has quite a few features SS does not.
- I promised Oran (one of my colleagues) that if he found an IBM Model M keyboard
for me I would try it out for a week. He managed to find one and I've
spend a couple of hours on Sunday cleaning it up, and have been using
it since. It's a very nice keyboard; the buckling spring key design has
terrific tactile response and typing on it feels great. There are
several things I do not like about it, though: for one, it's missing
the Windows keys which I've grown accustomed to using (Left Windows key
+ D or L two dozen times a day...); the right shift occasionally gets
stuck; finally, it's a little big for my hands so certain keypresses
are far less convenient than they were with the trusty Microsoft
Natural Elite. It doesn't seem that the new keyboard has improved my
errors/character rate any, but it is a little early to tell. That said,
it's amazing that a keyboard manufactured in 1991 can favorably compare
to a modern, ergonomic keyboard. My model is a 1391408, in case you
were wondering. All in all, I still miss the old Microsoft Natural
classic (I've used one from 1996 to about 2001 when it crashed on the
floor one too many times. It's still working, by the way, just missing
some keys.)
- I came home from a pub last night and made the mistake of turning on the TV. Twelve Kingdoms
episodes 14 and 15 were on. No sleep for me tonight. Do yourself a
favour and watch that show; I own it in its entirety on DVD and it was
some of the finest money I've ever spent. Other anime favorites include
Trigun, Full Metal Alchemist and Cowboy Bebop. If you're curious about anime, NGE might be a good primer, although I have my gripes with it.
- Finally, I've made a list of all my DVD movies on IMDB, but unfortunately there is no way to link to it externally. I'll find some other catalogue, or write one on my own.
I was writing a relatively small GUI application (more on that later) and was looking for an easy way to add wizards to the application. A quick Google search brought me several options, but eventually I settled for Al Gardner's excellent " Designer centric Wizard control" on The Code Project; it is combination useful, solid and open-source. I highly recommend it, however I did find two caveats:
For starters, this isn't actually the wizard designer's fault, rather Visual Studio's. I designed a moderately complex, 5-step wizard. The way the wizard designer works, all controls on all pages are thrown into the same class file. Since this is parsed and modified by the designer itself this wouldn't be an issue, however the wizard was also localizable. This meant that whenever I saved the wizard or moved from code view to design view and vice versa, the machine would chug for several seconds on regenerating the code. Add to that the usually-tolerable ReSharper parsing phase (I use build 165) and you've got 10-second stalls every couple of minutes, which makes development extremely tedious.
The other issue is that the Cancel event does not work as planned, and I can't figure out way. I added my own handler to the cancellation event with an "are you sure"-type messagebox, but whenever I answered no the wizard would still close. I tracked this down to the cancellation button on the wizard (btnCancel) having its DialogResult property set to DialogResult.Cancel (since I'm running the form instance with ShowDialog this would cause the form to close), however nothing in the application has ever set it to that value. Worse still, when I added the line:
this.btnCancel.DialogResult = DialogResult.None;
To the InitializeComponent method on Wizard, a breakpoint on the cancellation event handler would show that Wizard.btnCancel_Click:
this.FindForm().DialogResult = DialogResult.None;
I tried contacting Al to let him know about this issue, but there is no obvious way to get contact info from The Code Project. Any ideas?
So here I am, banging my head against the table repeatedly (quite
literally, feel free to ask my colleagues) because of a bug so idiotic
I can't even begin to describe it.
I wasted 20 minutes tracking down a bug just to find what Rik Hemsley says best:
?productlistview.Items(0).Selected
True
?productlistview.SelectedItems.Count
0
Hmm?
Apparently, though no-one will tell you this, the selection could fail if you don't have the focus. Make sure you add a call to lstWhatever.Focus() before you mess with selections.
Eli Ofek has published a
5-part (well, 4-part really) series about migrating an actual project
from the classic triad of VS2003/.NET 1.1/VSS to VS2005/.NET 2.0/Team
Foundation Server. I used to be a developer on the "sister team" of the
project he's talking about, and I can tell you that it's a huge project
with an extremely talented and devoted team of developers, so if you're
going to be doing any migration work in the nearby future I highly
recommend you go ahead and do some serious reading on his blog. The
bottom line is that Beta 2 servers aren't stable enough, nor the IDE
performant enough, to do any proper work on. The little experience I
had with the VS2005 was that it was actually very good and the
performance just fine (on my 1.7GHz Dothan laptop w/1GB memory), but I
can't argue with server stability issues.
Regardless, I particularly recommend reading phase 3, which discusses critical language/library differences.
I've updated the article about events and .NET remoting with some source code. Let me know if
you find it useful. That said, I haven't been active on the 'net for
the last few days so I have quite a bit of catching up to do.
A colleague was writing a bit of image processing code in C# while
working under the assumption that a bitwise shift operation by a
negative count (i.e. lvalue >> -2) would result in the opposite shift ( lvalue << 2
in our example). Nevermind the logic behind that assumption, while
helping doing some research I've stumbled upon what might be a
portability issue in the C# language design.
Apprently C# defines the left/right-shift operators as, for example:
int operator >> ( int x, int count );
It goes on to specify the behavioural differences between 32-bit and
64-bit code but gives no indication of what happens if you shift by a
negative value (which is possible given that count is of type int); this is left undefined. This leaves certain behavioural aspects of applications up to the VM; what probably happens is (for Intel processors anyway) that the JIT compiler generates something which looks like:
mov ecx,[count]
and ecx,0x1f
shl [eval],ecx ; or sal, if x is uint...
If count is negative, this will result in a mask of the two's complement, so for -2 this would be 11110
- or a shift-left by 30. I'm not sure what prompted Tal to make the
assumption regarding negative shifts, but the fact of the matter is
that his code compiled without warning. If the default operators were
declared with uint count,
at the very least we'd get a "possible signed-unsigned mismatch"
compiler warning. Most people would slap themselves and correct their
erroneous code.
I couldn't find any reference of this with a Google search and would
be more than interested in hearing corrections, explanations or just
opinions...
Update (September 7th, 10:16): As per Eli Ofek's advice I started a discussion thread
on the MSDN forums which already proved useful. A guy calling himself
TAG suggested that the reason why the operators are defined with signed
shift count is that unsigned types are not CLS- (common language
specification-) compliant. This could very well be the case, however I
am adamant that the language specification should reflect this; also,
the fact that the CLS does not support unsigned types is nontrivial
(and not easily found), which could potentially mean a lot of projects,
open source and commercial, are in fact nonportable because they make
use of unsigned types.
The game reviews I promised are still in the pipeline (it takes a lot of effort to get myself in the "reviewer state"), but I did post other stuff instead (mostly software- and development-related). Now it's time for tidbits:
- I've been sorely lacking a "navigation" submenu in Microsoft Word. I use a lot of internal hyperlinks in my documents (and have been reading and writing quite a few of those for the past few weeks), and it's a pain in the ass not to be able to navigate back and forth. Apparently it's just hidden in the Web toolbar and is readily accessible using Alt+Left and Alt+Right keyboard shortcuts. Oddly enough the keyboard customization dialog shows a GoBack function as well as the WebGoBack-WebGoForward duo; I'm not entirely clear on the difference yet. Anyways it's amazing how much better life is all of a sudden.
- There are numerous updates to the ReSharper 2.0 beta post.
- Thanks to Ofer for introducing me to the kickass bugmenot.com. It's basically a user-contributed database of registration information for any and all websites (there's even an entry for Nectarine!) which should prove amazingly useful, particularly when complemented by services like DodgeIt. They also have a petition asking content providers to stop with the pointless mandatory registration procedures. Not sure if I'll sign or not, but the site itself is damn useful.
- DevBoi seems to be a very useful development tool: it is a sidebar extension for Mozilla browsers offering easy access to online/offline documentation repositories for standards such as HTML, CSS and more.
- Apparently them christian preachers weren't kidding around: pr0n can indeed make you blind. Consider yourself, er, warned.
Light load this time. More to come.
I always enjoy researching languages (a passion that's only intensified since I cowrote our internal C#->java source-level compiler), so when a colleague approached me with an issue he had while creating a design in C# I was immediately intrigued.
Consider the following scenario:
class a1
{
public virtual int ret()
{
return 1;
}
}
class a2 : a1
{
public override int ret()
{
return 2;
}
}
Now, suppose I want to create another class, a3, which overrides ret but instead of implementing it on its own, it calls the a1 implementation - effectively skipping two generations of inheritence. If I wanted to call a2's implementation I could write a simple base.ret() call, so for a1 it's a simple case of base.base.ret(), right?
Quite wrong. Apparently the C# language specification defines the base keyword in a way that simply does not allow this. I was curious of this is the case with java as well, and lo and behold: java doesn't support super.super.member constructs either.
While researching the issue, I've come across two particularly interesting notes: Mads Torgersen, the new Microsoft program manager on C# Compiler and Language, has this to say in an interview:
Q: why only the first immediate base class is allowed in c#? e.g. cant do base.base.ToString()
A: The behaviour of your base class is determined by the writer of that class. It would open up a hole for breach of contract if you could bypass this and access something that this writer has decided to hide from you.
I'm not sure I'm convinced by this; it assumes the person who writes the instance class is not the same person who wrote the base class, which is not always the case. Other people around the 'net have said that this is a sort of "OOP no-no"; I can't say I've ever thought about this particular issue very deeply so I'll have to do some more thinking. If anyone has any references (no books, please - they're expensive and difficult to get) I would be very interested in hearing about it.
Brian Maso, posting to a similar discussion regarding java, suggests that this limitation derives from the java virtual machine design:
"super" is not an object reference. It's a Java language fiction. It
basically indicates to the compiler that the target method call uses the
"invokespecial" bytecode, not the usual method invocation bytecode
"invokevirtual". This is as opposed to "this", which is an actual object
reference variable.
If that is indeed the case, I can imagine the CLR shares similar design limitations, however this is research I'll leave for another time. For the time being suffice to say that the only way to do this is to use reflection, which is a sloppy solution which hinders performance, readability and safety. Imagine accessing runtime information, creating class instances (generating additional work for the GC in the process) etc. instead of a simple vtable indirection - it's not even funny!
I was implementing a watchdog system over a certain system's XML configuration repository using System.IO.FileSystemWatcher. Annoyingly, changes to the file (such as saving it with Notepad) would often result in the change event being fired twice. The system is designed so that whenever the file is changed, it is reloaded and several parts of the system are suspended (via thread synchronization) while the information is being re-cached. This in itself wouldn't be a problem since changes to the XML files are manual and rare, the XML schemas and serialization metadata are already cached etc. so the reloading operation shouldn't take more than 100-200ms (and the lock itself is only obtained at the very end of said process) - however there is a drain on CPU time and memory resources which I certainly wouldn't want doubled.
While it seems I wasn't the only one to encounter this behaviour, I've yet to see a proper solution to it; in the meanwhile I settled for a small hack where an update to the XML file are only processed if n seconds (2 in my case) have elapsed since the last update. Does anyone know of a cleaner way to solve this?
I came across a fairly unusual situation today, where a referenced
assembly contained XML schemas as embedded resources. The schemas may
(and do) contain <xs:include> and <xs:import>
directives, which could not be resolved when I was trying to compile
the schema: the schemas were including other schemas by relative URI
(for example, SystemConfig.xsd has an <xs:include schemaLocation="Base.xsd" /> directive), and when the schemas are loaded from a resource there are no URIs to speak of.
After a bit of reading I settled down to write a custom implementation of XmlResolver. It's used like so:
Assembly container = typeof( anyTypeFromTheResourceAssembly ).Assembly;
XmlResourceResolver resolver = new XmlResourceResolver( container );
schema = XmlSchema.Read( stream, new ValidationEventHandler( schemaValidationEventHandler ) );
schema.Compile( new ValidationEventHandler( schemaValidationEventHandler ), resolver );
Grab it here, and do let me know if you find this useful or have any comments/questions!
Update (18:58 GMT+2): Interesting. Apparently a developer called Jay Harlow wrote a similar class
a while ago; his is VB.NET, mine is C#, but the similarity is
staggering. So if you're looking for a VB.NET version of the class,
there you are 
|