Last year I posted a bug report about how cBlorb doesn’t accept strings as an ID in blurb files (inform7.com/mantis/view.php?id=1045). This means that cBlorb is mostly useless for use with Inform6 games. I would like to remedy this. According to the Blorb documentation, this is a valid blurb file:
perlBlorb will build this, but it lacks many of the extras that are in cBlorb. I would therefore like to add cBlorb to the Inform6 compiler and library package that I maintain for Unix users. I could alter perlBlorb, but I also want to let Windows users of Inform6 enjoy this flexibility. Here’s the problem: cBlorb thinks this blurb file is invalid. It does not accept that the ID can be a string. Can I get some help from someone who knows how cBlorb works to get this implemented? I think I have inweb figured out, but I’m lost when it comes to figuring out what cBlorb is doing.
I also need to get cBlorb to optionally emit a bit of Inform6 code like this just as perlBlorb does:
What you’ve changed is a good start, but you’ll have to modify that line’s sscanf prototype also, or else the format and the varargs won’t match. After that, you’ll need to tweak the sound_chunk call on line 293 of the parser to send both texts, and then you can go about associating names and numbers in sound_chunk itself. That should just be straightforward C coding, not needing to interact much with the rest of cBlorb. Code to dump I6 belongs in Releaser.w, where there are lots of examples to follow.
There’s some more code. For the sscanf prototypes, I see %d for the integer parameters, but I can’t figure out what’s going on with “%[^”]". What would I do to specify a text field that’s not surrounded by quotes?
The " at the beginning and the " at the end just match the delimiting quotes. [^"] after % means any number of non-quote characters; the syntax mimics a regexp with an implicit star. (See the scanf format documentation for more detail.) For an unquoted string, drop the delimiters and change the character set in the brackets to whatever characters can constitute an .
Edit to add: I should’ve mentioned this earlier: you can leave the Sound N line in just above the Sound ID line to have cBlorb try the existing syntax first. This will save you from having to check whether the id you get is actually a number, since the new code will only be called when that parse fails.
Thanks. I think leaving the Sound N line in there won’t work because I still need to keep track of resource numbers. Checking if the ID is a number or not turns out to be very easy. A caveat that should be obvious is that the programmer should choose to use constants xor integers to refer to resources. Mixing the two might be legal, but is prone to error. I therefore added some code to catch the use of the same nonzero resource number more than once and warn the user Let me know what you think and I’ll generalize it to the other commands.
In case anyone’s interested, here’s a repo for perlBlorb: github.com/DavidGriffith/pblorb. I’ve added some OGG and MOD fixes.
The 2001 Blorb spec (see the DM4) dealt with the name/number issue by requiring resource numbers to always increase, which, in your code, would mean allowing the number form to up resource_num by more than one. I think, if only for consistency’s sake, that that would be a better way to go.
I would still recommend putting in two parsing lines, although they can share a subroutine for most of their implementation. Keeping the parsing code separate from the handlers is good architecture, will give your patches a better chance of being rolled into the upstream code, and helps prevent edge-case bugs on inputs like sound 0 ....'' (Though maybe I'm not getting what you mean bywon’t work because I still need to keep track of resource numbers’’?)
Remember that empty strings as ids are special cased: they should advance the resource number but not emit any I6.
And—sorry to throw so much nitpicking in one post—don’t forget to modify your scanf specifier with a width specifier and a narrower character set to match the spec: ``a sequence of up to 20 letters, digits, or underscore characters’’ (safeguards which help ensure validly named I6 constants).
I discarded the idea of using a function to return the next resource number. Now it’s advanced simply by incrementing the number in sound_chunk() or picture_chunk().
On using two parsing lines, and keeping parsing code seperate from handlers – are you saying that it’s not a good idea to convert a ‘1’ character into an integer in sound_chunk()? Suppose I have one parsing line go to sound_chunk_num() and the other to sound_chunk_string(). Would that be better? On keeping track of resource numbers, I meant that the resource_num global is necessary because with alphanumeric IDs, I’ve lost the means of determining resource numbers from the blurb file alone.
Empty string for an ID: fixed.
The scanf specifier has been fixed.
Please don’t worry about offending me with nitpicking. I want to get this right.