Blog

Sitemap

Home Blog Forums FAQ YouTube Email
Feeeed Me
Blog RSS Blog
Releases RSS Releases
Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 33 34 35 36 37 38 39 40 41 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70
Scribe/Mac Lack Of Progress
Date: 18/7/2007
Since the recent Win32 releases of Scribe I've been working hard on the Mac port in an attempt to make a similar release. Currently there are a number of really nasty issues in the codebase that I'm struggling to fix. The sort of things that make using the software really annoying. Btw I only have access to my Mac at the moment. So PC dev work is not happening till next week.

The first major issue I've got is that the PostEventToQueue function doesn't always deliver a message. Sometimes it silently fails. This causes the message download code to never get the mail from the worker thread and then the worker thread hangs waiting for the GUI thread to process the downloaded email. It's so dumb. I really hope it's not a bug in Carbon.

Then there is the locking issue, where somewhere in my code I lock the semaphore controlling the options structure and then fail to unlock it at which point things go downhill. I'm slowly getting closer to finding the cause of the issue but it's hard to reproduce so I just have to wait for it to happen... look at the logging then re-instrument the code and re-run it. Wait for it to happen (hours/days?) and then repeat. It's slow and annoying.

So in the name of quality I can't release a Mac build just yet. :(
(0) Comments | Add Comment

Scribe
Date: 11/7/2007
3 Scribe releases in 2 days. I guess I'm trying to make up for no releases in 4 months. Anyway hopefully this "Test19" will be a good one.

Also I fixed the broken release RSS feed, if you were wondering.
(0) Comments | Add Comment

DOS?
Date: 20/6/2007
Just recently the traffic pattern to this site has changed. Every ten seconds, on average, someone/something loads the i.Disk page. The requests come from lots of different IP's sometimes more than once, they never have a referrer and always have the same user agent: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)". I'm not sure why a whole heap of machines all over the internet need to load idisk.php so much; 8000 hits a day. This is on top of the 2-3 thousand hits I get normally. These are the actual live hits on that page since I wrote this post.

Do you think this is a DOS or just some piece of software gone AWOL?
(1) Comment | Add Comment

Switching between the VC6 and VC7 JIT debuggers
Date: 20/6/2007
You can switch between debuggers using the following settings:

Set VC6 as the default JIT debugger:
Tools | Options | Debug | "Just-in-time debugging" (in VC6 IDE)


Set VS.NET as the default JIT debugger:
Tools | Options | Debugging | Just-in-time | "Native" (in VS.NET IDE)


Also usful for fixing the "jit debugging component registration is incorrect" error.
(0) Comments | Add Comment

Citarum River
Date: 7/6/2007
Citarum River in Indonesia (via kottke)

In light of my previous post about plastic... words fail me. *deep sigh*
(1) Comment | Add Comment

Translating Script Names
Date: 7/6/2007
So Scribe has script files stored in the "Scripts" sub-folder and at the moment they show up in the tools menu. There are several problems to be addressed. First of all the name of the command is currently just the file name. But then means it can't be translated into all the different languages that Scribe supports. Currently translations for the existing commands are in the Scribe.lr8 file which gets loaded at runtime. However there needs to be a mechanism that associates a given string resource with the Script file.

I'm considering several possibilies. None of which are particularly palettable.
  • Embed the translation ID in a header of the script. Pros: nothing specific, Cons: You have to read the file at startup. Lots of scripts could be slow. Bit fragile if the ID number changes (rare but possible).
  • Embed the translation ID in the filename of the script. Better than the first option but still can break if the ID changes.
  • Embed the symbol define in the filename. Pros: very unlikely to break, the symbol doesn't change. Cons: Current resource runtime code doesn't store the define symbol, so I'd have to store that and it'd take up memory.
  • Embed the translation directly into the script file. Pro: nice and self contained, never breaks. Con: Will get overlooked by translators and never updated.
  • Something else?


I'd like some feedback or ideas. The translation has a reference number (int), an ID (int) and a define (string name). The ref is unique, the ID is the same for all strings with the same define.
(1) Comment | Add Comment