I find that I keep reverting to MobyGames
for game-related links, searches etc. Trixter's baby project is an
awesome resource for the sort of info I often look for, and I figured
that it would be really great if I could do a MobyGames search directly
I constantly do with eBay, Amazon etc.). I spent a couple of minutes
looking through MobyGames' prominent navigation links for a solution
with none to be found, so I figured I'll just add it to Firefox myself.
The browser linked me to Firefox's "add engines"
web page, but as luck would have it, the Mozilla servers were down at
that exact moment. I figured that since I can't do it myself at the
moment I might as well have a look if someone else'd already done it -
which apparently they did; if you click through the Friends of Moby page in MobyGames you'd get a very improperly-positioned link to their Firefox search button. I happily clicked it, it works like a charm and dead useful.
This only goes to show that even the most useful tool, application
or whatever will be completely ignored if it's not prominently
showcased! I'll be sending an e-mail to the great guys at MobyGames
New ReSharper 2.0 beta (via Roy Osherove
), available via JetBrains early public access
Will report on features, stability etc. soon.
Update (17:41 GMT+2): I've been using ReSharper 2.0 build 201 for a few hours now, and have come to the following conclusions:
- It is drastically slower than 1.5 (build 162) I've been using for a while now.
- Despite claims to the contrary,
the preprocessor still sucks big-time; large parts of the codebase I'm
currently working on heavily depend on preprocessor directives (mostly #if, #else, #elif) and ReSharper goes haywire parsing them. This also leads to:
- Extremely buggy autocompletion behavior, to the point where it
completely fails to display some superclass members, where in 1.5
(despite preprocessing issues) it worked perfectly.
- Takes an inordinate amount of memory.
- Crashes repeatedly.
- Bottom line, removed in favor of 1.51 (beta build 165); I'll try updated builds as they come out and report.
Update (August 1st, 10:42 GMT+2):
I've been using the newer build 202 for a few hours now, and it does
seem quite a bit faster and certainly more stable; it's still not as
fast as 165 (particularly as far as initialization time is concerned)
and I've encountered a few quirks here and there (at one time ReSharper
quite simply refused to recognize the referenced assemblies - even
.NET-intrinsic ones) and some minor usability issues,
but it's a major improvement over 202. Some of the improvements over
165 are also marked, in particular the 'error/warning bar' on the right
feels more robust and the code formatting template is far more
customizable (although admittedly I haven't looked at this since 152, I
could be wrong - and anyway it's not yet as impressive as Eclipse's). Can't wait for 203, I've no idea where I would be
Update (August 3rd, 17:43 GMT+2):
Tried installing build 203; the RFE I filed
has apparently been taken seriously and sorted out, however the new
completely screwed up the intrinsic Visual Studio shortcuts; Ctrl+Tab
and Ctrl+F4, for example, wouldn't work with 203. I tried removing
ReSharper and installing anew, created a new keyboard profile from the
defaults etc., but it was all in vain and the absolutely necessary
shortcuts I mentioned would not function. Eventually in desperation I
went back to 202 and filed a bug report (which doesn't seem to show up,
but nevermind that). Hope this gets sorted out quickly. I've also found
that the default Shift+F6 shortcut for renaming items has been changed
to F2; I'm not sure which was the first version to feature this change
(202 does though), but changing default key bindings suddenly after
years of sticking with the same profile is a nasty thing to do.
Update (August 11th, 15:37 GMT+2):
During the last few days I've been working intensely with three
seperate development machines. The main machine at work had ReSharper
build 202 on it, the other two build 165, so basically for a couple of
days I went back to 1.5. My conclusions? 2.0 is much better
feature-wise (better refactoring capabilities, improved UI, parsing and
code reformatting), but it is currently dramatically slower in both
boot and runtime performance. Also, at some point build 202 simply went
haywire, refusing to recognize namespaces in referenced assemblies even
for new Visual Studio-generated WinForm applications. In frustration I
removed it and went back to 165. In the meanwhile the shortcut bug I
reported for build 203 was fixed (although 204 isn't out yet...), and I've also reported a usability issue.
Update (August 12th, 15:21 GMT+2):
I've been using build 204 for a couple of hours now. It seem to have
solved the keyboard issue and is also a bit faster, however the problem
I reported with 202 going haywire is even more pronounced in this
build. I've filed a bug report and hope to see it resolved soon
(because currently it's almost impossible to work with it for new
projects where you keep adding/changing references).
Update (August 16th, 15:41 GMT+2):
After using build 204 intensely for a couple of days I've come to the
conclusion that it simply isn't fast/stable enough for proper
development and am revering to 165. I'll keep testing 204 at home (and
include, at JetBrains' request, Visual Studio 2005 in my tests),
hopefully I'll be able to help them track down the external reference
bug. That said, a usability bug
I've filed a week or so ago remains open; if you have anything to add
it might help the ReSharper guys reach a better/quicker decision about
Update (August 21st, 11:30 GMT+2): Build 205 is out. They've fixed a couple of bugs I filed (including public ovveride and immediate window autocompletion issues). No news about the external references issue
(partially my fault because I still haven't tested VS2005, but I still
don't see what 2005 has to do with it...). I'll try it out this morning
and post updates.
Update (September 8th, 16:56 GMT+2):
I've been testing build 206 for a few hours now. For the first couple
of hours it felt a lot faster and more solid than any of the earlier
builds, and the inclusion of a multiple-entry clipboard handler (Ilan Asayag's RFE)
should be very useful although I haven't tested it; however, there is a
major bug in the new parser which completely barfs on one of the
projects I work on and simply hangs Visual Studio 2003 on 100% CPU
utilization endlessly. I've filed a bug and we'll see what happens; in
the meantime I'm reverting back to 165 (in whose parsing engine I've
also found and filed a bug - it does not process lock statements properly).
Update (September 26th, 12:13 GMT+2):
Initial impressions from build 207: it is a lot faster and a lot more robust than the previous builds, however it still barfs on the source file I mentioned on 206. I'll get in touch with JetBrains and try to find out what's up.
Update (November 2nd, 16:49 GMT+2):
I've been working with 208 for a while now but couldn't find the time to post anything about it. Let's skip to 209 then: I've replaced 208 in a production environment with 209. Yes, 208 has already been stable enough to work on real code with; in fact it's so far been a pleasure. The guys at JetBrains are doing very impressive work on this product. Now that most of the bugs are squashed, though, they should get to work on optimizing the codebase a little bit; VS2003 startup times are noticeably slower with ReSharper 2.0 installed (not that they aren't horrible to begin with) but text editing can at times grind to a crawl even on a decent system. I'll try to find a way to shout out so that this request is heard. Please do the same; Eugene and the other guys at JetBrains really do listen to customers, so if enough people request it I reckon they'll get the hint.
Update (December 7th, 18:24 GMT+2):
210 has been out for a couple of weeks now and seems quite stable. I do have a couple of issues with it, though: first, performance hasn't improved at all since 208, and I have a bizarre issue where R# hogs the Ctrl+D shortcut (which I have permanently assigned to GhostDoc), and reassigning it to GhostDoc doesn't seem to work. R# is worth more to me (productivity-wise) than GhostDoc so I'm willing to suck it up for now in hopes that the guys at JetBrains sort it out by the next release.
Update (December 25th, 18:02 GMT+2):
Skipped right to build 213. It seems that there are few differences between versions on VS2003, because although Ayende reports it to be horribly buggy with VB.NET (presumably with VS2005), I've encountered no new issues. R# doesn't seem to handle source control providers properly though - we use Vault at work and R# chokes whenever I edit a file that hasn't been checked out yet (update December 28th, 12:40: apparently JetBrains fixed the bug for build 214, I'm looking forward to it).
Update (January 3rd, 20:42 GMT+2):
Lost some more work when my ISP went down and Firefox's bizarre clipboard issues popped up again. I'll have to file a bugreport on that as well. Anyways a quick recap of what was in the earlier (lost) update: bug #14980: Problematic integration with source-control not yet solved (was supposed to have been fixed but I reopened it). Bug #15702: Highlighting options not retained vanished in the new build, although it's not officially fixed. Bug #13866: ReSharper does not relinquish keyboard shortcuts? appears not to have been a bug (see link for explanation) but bug #10851: Can't use Enter on "override" autocomplete popped up again. The asynchronous startup doesn't seem to work (either that or it's not supported in VS2003) although I'm not sure what to look for, so it's not a bug per se. Finally I've filed a few feature requests, go ahead and vote.
Update (January 4th, 12:39 GMT+2):
Build 214 is off my machine. It has way too many bugs to be really useful; at some point the project I was working on started exhibiting odd static code errors which didn't seem to make sense; after a while the build 214 parser went completely haywire and refused to recognize namespaces even local to the project. Deleting the caches etc. didn't do any good so I eventually reinstalled 213. Additionally I've finally started using VS2005 at work, hopefully I'll have more insight into R# now (I'll start a new post regarding R# on VS2005 when I have something to report).
Update (January 29th, 19:38 GMT+2): Been using build 215 for a little while now. It's a great deal more stable than 214 and also fixes a few bugs, but isn't nearly as stable as 213; exceptions are in abundance and sometimes it just seems to "flip out", requiring a restart of the IDE to return to normality. I'm not sure what's changed since 210, but since there are no major new features obviously some rewrite or another caused some severe regression issues. I'm this close to going back to 213, I'll give it a few more days and if 216 isn't out by then I'll do just that.
Update (February 12th, 16:42 GMT+2): Skipped 216 and went right to build 217. It fixes a lot of issues I had with 215 (far less exceptions, for starters, but there are still issues and bug #15702 still isn't fixed). It also feels a lot more responsive, but it's difficult to judge since I changed to a considerably faster workstation at work. I've also started using VS2005 along with VS2003, which makes these reports a little more useful (I think?).
Update (February 12th, 19:52 GMT+2): The initial impression of stability was apparently misplaced. A certain exception keeps popping up all over the place after an hour or so of use (a parser bug by the look of it); I would rate this as a show-stopper bug and recommend you keep away from this build. I'll try downgrading to 216, and if all else fails 215, but I do hope they fix this as soon as possible because this is an otherwise excellent version.
Update (March 2nd, 2006, 22:13 GMT+2): While builds 217 and 218 were disappointing, 219 is so far a pleasure to work with. It's very stable and seems to have got rid of most of the annoying bugs (in particular #14980). Also, feel free to vote or comment on any of the open issues I posted (#16662, #10855 , #18447,
Update (March 2nd, 2006, 22:23 GMT+2): Bah, as usual, I spoke to soon. Be very careful with 219 if you do any editing on XML schemas; for me it went haywire with exceptions all over the place and eventually crashed Visual Studio 2003 entirely.
Update (March 7th, 2006, 17:10 GMT+2): Tested build 220 for about two hours. It's riddled with bugs; I've filed at least four different exception reports in that period of time. Back to 219 for the moment.
Update (March 9th, 2006, 15:32 GMT+2): Build 221 is not perfect, but for the most part is very usable. I've encountered a couple of odd exceptions (in fringe cases); generally speaking it's not as stable nor as fast as 219, so if you have that installed I suggest you stick with it.
Update (March 12th, 2006, 14:46 GMT+2): I've been heavily developing with 222 for a few hours now and it's very buggy. I've been getting random exceptions (and even exceptions from the bug submission service!) and although it feels faster than 221 stability is lackluster. I would recommend to stick with 219 for now.
Update (March 14th, 2006, 11:39 GMT+2): Build 223 is quite usable, although a far cry from the stability of build 219. I've already encountered numerous exceptions and there's a certain source file which throws the parser into an infinite loop. JetBrains could use some more regression testing, but I guess that's what the EAP's all about.
Update (April 10th, 2006, 17:02 GMT+2): Been a while and ten builds since my last update. I'm happy to say that I've been working with 232 with both Visual Studio 2003 and 2005 and it's been almost rock stable so far (I've only encountered one bug with an intermittent "can't edit read-only file" issue I've already reported to JetBrains). I'll update to 233 and post my experiences with that build soon.
ToastyTech has images, descriptions and miscallenous trivia for most popular microcomputer GUIs
. Seems to lack a few (NeXT etc.) but is still a really terrific read. Also, you can now read scans
of the 1971 and 1979 versions of "'How It Works': The Computer" books, intended as an ease-into guide for the computer-illiterate.
As a history buff I've always found older computers fascinating, both the computers themselves and the social phenomena they represent. If you're also interested in such things, make sure to read Fire in the Valley: the making of the personal computer, which is an astounding read which delves (in interviews, pictures and background stories) into the various aspects of the early PC era. Another interesting read is Steven Levy's Hackers: Heroes of the Computer Revolution (which my brother Mickey bought me as a birthday present couple of years back. Thanks, man!)
Usually I don't mind HTML one bit, but posting the code bits today made me realize something: HTML sucks
for pre-indented text. Apparently there are only three options
for white-space preservation in HTML/CSS: pre
- This value directs user agents to collapse sequences
of whitespace, and break lines as necessary to fill line boxes.
Additional line breaks may be created by occurrences of "\A" in
generated content (e.g., for the BR element in HTML).
- This value prevents user agents from collapsing sequences
of whitespace. Lines are only broken at newlines in the source, or
at occurrences of "\A" in generated content.
- This value collapses whitespace as for 'normal', but suppresses
line breaks within text except for those created by "\A" in generated
content (e.g., for the BR element in HTML).
normal certainly isn't appropriate, because that would not preserve the indentation. pre is almost appropriate, however it disallowes the rendering engine to insert line-breaks, which means the div section the code is in may extend in width arbitrarily. nowrap is obviously inappropriate as well.
What I really need is something close to pre but which allows automatic line-breaks; problem is, to my knowledge there simply isn't anything of the sort!
If anyone has some good advice on how to add indented, syntax-highlit code blocks to my blog painlessly I would be much obliged. I know there are tools out there - I've tried one or two - but none gave me the sort of flexibility I require. I may just break up and write a parser/colorizer with a bit more customizability than what Drazen did (impressive though it is).
I was reading through a bunch of documents I had lying around, and
found one that might be of interest to developers out there. A team in
a previous workplace encountered a strange issue: they were trying to
authenticate against a Windows domain (Active Directory-based domain
server) using ADSI via .NET's System.DirectoryServices, and in some
cases (particular users and particular machines) their login code would
bomb with a "Domain Not Found" error or somesuch.
Turns out they were trying to bind to ldap://domain_name, where domain name was programmatically derived from System.Environment.UserDomainName;
in some cases said property would return, instead of the logged on
user's domain name, the local computer name. Thing is, you would expect
a property in System.Environment to return the value of an evironment variable, presumably USERDOMAIN, which we verified contained the appropriate value.
Digging around in the documentation didn't help, so I turned to ye olde Reflector:
public static string get_UserDomainName()
new EnvironmentPermission(1, "UserDomainName").Demand();
array1 = new byte;
num1 = array1.Length;
builder1 = new StringBuilder(1024);
num2 = builder1.Capacity;
flag1 = Win32Native.LookupAccountName
(null, Environment.UserName, array1, &(num1), builder1, &(num2), &(num3));
num4 = Marshal.GetLastWin32Error();
if (num4 == 120)
throw new PlatformNotSupportedException(Environment.GetResourceString("PlatformNotSupported_Win9x"));
throw new InvalidOperationException(Environment.GetResourceString("InvalidOperation_UserDomainName"));
Note the function call in bold; a quick look in MSDN revealed the following information:
- [in] Pointer to a null-terminated character string that specifies the
name of the system. This string can be the name of a remote computer.
If this string is NULL, the account name translation
begins on the local system. If the name cannot be resolved on the local
system, this function will try to resolve the name using domain controllers
trusted by the local system. Generally, specify a value for
lpSystemName only when the account is in an untrusted domain and the
name of a computer in that domain is known.
- [in] Pointer to a null-terminated string that specifies the account
Use a fully qualified string in the domain_name\user_name format to
ensure that LookupAccountName finds the account in the desired
Note the part marked in red: Environment.UserDomainName does indeed pass null for lpSystemName,
so if the machine contains a local user by the same name as the domain
user, the local machine name will be returned instead of the domain.
This behavior is apparently by design, although I can't figure out how that makes any sense what-so-ever.
There are two easy ways to avoid this issue:
string userDomain = Environment.GetEnvironmentVariable( "USERDOMAIN" );
string userDomain = System.Security.Principal.WindowsIdentity.GetCurrent().Name.Split( @'\' )[ 0 ];
I was reading some API documentation and came upon the following sentence: "... and is necessary to successfully login... before envoquing
the other components.".
Damned if I know why, but the GTK+ installation that comes with the Win32 version of GAIM
doesn't handle Hebrew properly (mismatched parentheses, problematic handling of hyphens etc.). I've already mentioned that installing the Glade compilation of GTK+
solves the issue, however I attributed it to a particular broken version of the GAIM installer, which seems not to be the case. I should probably file a bug report about this.
Senthil Kumar found out another interesting bit
of C# trivia: apparently C# does not do compile-time type safetly checks for interface casts! C# is usually very strict in the kind of stuff it allows you to do (unless you use object
s all the time, in which case you deserve to die anyway). This has to be one of the very few cases I've found C++ (as a language) to be superiour to C# - I prefer simplicity and strictness, and while C# certainly provides the former, C++ evidently provides better compile-time checks.
We need to be
able to plan food quantities etc., so it's imperative that we know
who/how many are coming. If you haven't already, please send in
confirmation (preferably along with contact information for yourself
and sceners you know). Also, we still haven't been able to get a hold
of a video projector, so if you can help let us know!
After the flash success of June's IGDA/demo-scene gathering,
we've decided to, er, implement our own: a proper demo-scene gathering,
complete with BBQ, showing of new as well as old demos, and whatever
the hell else we feel like doing! So, without further ado:
Thursday, July 28th 2005 at 20:00, give or take. Being late only means you get to spend less time here
The psuedo-demoparty will be held on the lawn outside Monfort Software
building in Kibbutz Sa'ar. The kibbutz is located just north of
Nahariya and here's how to get here:
- Driving here is easy, though I suggest you use eMap or Walla Maps
for reference: basically just get to Acco junction (the northest
section of road 4), proceed north to Nahariya junction, proceed north
still until you're just north of Nahariya - there'll be a "Sa'ar"
signpost where you turn right to enter the kibbutz. Immediately after
the gate turn left and you'll arrive at a fork; take the right road,
proceed until you see a basketball court on your right. Turn right
immediately after it, right again - we're the second building (the one
with the parking lot). If you have any trouble or need more detailed
instructions get in touch.
- Take a train or bus to Nahariya (the central bus station is located
50 meters from the train station); take bus number 3, 24, 27 or any
number of other busses and just ask the driver to drop you off near
Sa'ar. It's an 8-minute walk from the bus station.
Well we hope most of the oldsk00l demosceners in Israel will show up,
but obviously aspiring Israeli sceners and visiting sceners from abroad
are welcome too! Just get in touch and let us know you're coming so we
can have enough food and drink ready.
The main event is a big-ass BBQ for everyone, cold drinks and beer:
this is a mostly social gathering. However we will have a retromachine
available to play classic demos (P166, 64mb, Tseng E6000/ATi Rage II,
SB AWE64 Gold + GUS GF1 1mb) as well as a copy of the MindCandy demo DVD;
we'll probably have a decent machine to run newer demos on as well. If
anyone intends to make a demo, go for it - it'll definitely be shown!
Other than that, just let us know what you think is good. There are
terrific beaches minutes away from the partyplace; we can have classic
cola-drinking, diskette/disc/hard-drive tossing competitions etc. If
you have any ideas let us know!
We have most of the basics (including food, audio system, demo machine
and general organization covered). We could really use your help in the
- We are in need of a projector. Do you have, or know someone who has, a projector we can have on loan for a couple of days?
- Help us spread the word! Send us any contact information you have
for past and present Israeli sceners, and forward the invite to sceners
you have contact with.
- We're collecting Israeli scene media: pictures, videos,
productions and any other relevant material. All that stuff will be
inserted into an Israeli demo-scene wiki, so if you have anything make
sure to send it out way!
- Good ideas are absolutely welcome!
If any of this applies to you, make sure to get in touch
as soon as possible!
The event is hosted and sponsored by Monfort Software Ltd.
which is where us organizers work; consider this a shameless plug:
we're looking for great programmers to join our team! Want to work in a
dynamic environment with a bunch of other demosceners? Want to work on
realtime 3D engines, .NET applications ranging from enterprise systems
to compilers to a huge variety of software products? Come have a look.
You can contact us in one of many ways. Being the primary contact you can just use my contact page
, or call me directly (0x209E1F5A). If needs be feel free to contact Scroll Lock (0x207994A4, 0x1F38899A). Can't read hex?
The following sceners have confirmed their attendance: Scroll-Lock,
Crunch, MMX, Thalja, Jonny (YOE); Kombat, Rage (Immortals); Dark Spirit
(TTOM); Civax (Moon
Hunters); Borzom, Sticky Baboon (Tatoo); Holograph, Protopad, Vandal
(Pulse, BSP); Nyarlothotep (Kult); Silvatar, Diffuse (Flood); Fizz,
TheMage, Mutant, Blutz. Nyc
Kid (Moon Hunters) will probably be there as well.
Thinking of coming? Let us know!
Been busy doing absolutely nothing of value over the last few days including, but not limited, to: going to the kinneret
for a Saturday afternoon, watching Batman Begins
(seperate post on that later), finishing Half Life 2
again (review coming up), going to a pub, watching Who Framed Roger Rabbit
and almost finishing King Rat
(will probably blog a bit on that at a later date too).
I also blogged practically nothing interesting/useful for the past
couple of weeks, so here's a collection of stuff I have in my "context"
file (sort of a geek's to-do list):
- Apparently I've managed to thoroughly miss the whole Annoying Thing revolution; I've always known the source to be DengDeng but apparently it's evolved and is now officially out of control. Here's an interesting read.
- If you have any inclination towards industrial and/or goth music, check out In Strict Confidence.
Of particular note are Zauberschloss and Engelsstaub (in German) and
the terrific Love Will Never Be The Same (English). I've also given
good listening time to Massive Attack's Mezzanine. On the web radio front I still listen to a lot of Nectarine radio.
- RMS has another thought-provoking artlce
about software patents. RMS's usually extremist opnions aside, I'm
finding what I see around me less and less to my taste, and as a
software developer for a relatively small company I occasionally feel
the results of software patents on my flesh, and it scares me. Patents
are a necessary evil, but leglislators must be extremely careful in
maintaining the balance between protecting innovators and stiffling
innovation. I'll probably write a proper post about this soon.
- Get your own, before they run out!
- Ever had trouble remembering what a toilet in a particular computer game looks like? This site should alleviate your concerns.
- These are really cool. Too bad they probably sound like crap.
- Ho-lee shit.
- Evidently the Israeli customs office does not believe in free software (Hebrew only). Fortunately the story ends happily.
And here are some development-related tidbits:
- A couple of interesting articles on the BCL team blog: this one elaborates on which language features cannot be expressed using CodeDOM (including .NET 2.0), and this one
explains why parsers aren't included with CodeDOM (which would've saved
me a hell of a lot of time on the C# to java source-level compiler I
wrote a few months ago).
- BCL team's libcheck is an immensely useful tool if your team provides public APIs to other teams or customers (via Roy Osherove's ISerializable).
- Balanced matching with regular expressions: apparently the .NET regex implementation allows you to create
"stack"-style expressions (so you can parse, for example, mathematical
expressions with parentheses, C-style comments etc.). The syntax is
somewhat convoluted and tricky to use though (via Roy Osherove's ISerializable).
- I've been asked how to create windows services in .NET on numerous occasions; it is, in fact, incredibly easy. Enter another great post from the BCL team, which will hopefully save me some hours of repeating the same explanations. Thanks, Dave!
- These seem like incredibly useful tools, though (seeing that my
development focus has changed over the last few months) I haven't yet
been able to try out: ComTrace hooks the COM system calls and gives you a filtered view, which is definitely handy for debugging COM issues. Conversely, the PINVOKE.NET add-in is a front-end for the PINVOKE.NET wiki - a respository for unmanaged API P/Invoke signatures and best practices.
- I always thought overhyped, powerful language features can be dangerous in the hands of the uninspired, but this is just ridiculous (thanks, Kuperstein).