Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001045Core InformReleasing, bibliographic data, cBlorbpublic2012-11-04 16:092014-05-07 07:33
ReporterDavidG 
Assigned Tograham 
PrioritynormalSeverityseriousReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSLinuxOS VersionAny
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0001045: cblorb does not accept strings as <id> in blurb files
DescriptionWhile investigating changing over to cblorb from perlblorb for Uninvited and current work, I noticed that it refused to build a blorb file using an otherwise valid blurb file. Below is the first few lines from the Uninvited blurb. Cblorb complains like this:

! cBlorb 1.2 [executing on Sunday 4 November 2012 at 14:39.15]
! The blorb spell (safely protect a small object as though in a strong box).
uninvited.blurb, line 2: Error: not a valid blurb command: 'sound Bark "sound/dogbark.aiff"'
uninvited.blurb, line 3: Error: not a valid blurb command: 'sound Cathedral "sound/cathedral.aiff"'
uninvited.blurb, line 4: Error: not a valid blurb command: 'sound DoorClose "sound/doorclose.aiff"'

According to the cblorb manual (section 15), the grammar for a sound line is "sound <id> <filename>". "<id>" is defined in section 12 as "either nothing at all, or a number , or a sequence of up to 20 letters, digits or underscore
characters _."

This bug means that cblorb is mostly useless for building blorbs for Inform6 games.


Minimal Source Text To Reproduce
storyfile "uninvited.z5" include
sound Bark              "sound/dogbark.aiff"
sound Cathedral         "sound/cathedral.aiff"
sound DoorClose         "sound/doorclose.aiff"
TagsNo tags attached.
Effect(serious) Compiler rejects valid code
Attached Files

- Relationships

-  Notes
(0001923)
EmacsUser (manager)
2012-11-05 07:21

Confirmed, though probably as a documentation bug.
(0001942)
DavidG (reporter)
2012-12-16 19:32

When will there be a fix for this?
(0001943)
EmacsUser (manager)
2012-12-17 07:21

I suspect that this is pretty low-priority compared to the other bugs. It will probably be faster to download http://inform7.com/sources/src/inweb.tar.gz [^] and http://inform7.com/sources/src/cBlorb.tar.gz [^] and make the patches yourself.
(0002175)
DavidG (reporter)
2013-12-11 22:52

I've altered cBlorb to accept strings and numbers as IDs for sound and picture resources. Doing both at the same time is possible, but not recommended. I have a Github repo at https://github.com/DavidGriffith/cblorb [^] containing what I've done. How does it look?
(0002177)
EmacsUser (manager)
2013-12-14 12:23

I think this patch is on the right track, but I do have to repeat some of my comments from http://www.intfiction.org/forum/viewtopic.php?t=10449&p=62759#p62770: [^]

- It currently breaks support for non-sequential resource numbers.

- It mixes parsing code in with the command handlers.

- Specifying zero as a resource number leads to strange behavior.

- To match the current documentation, zero-length ids also need to be special cased.
(0002178)
DavidG (reporter)
2013-12-14 18:16

Still working on non-sequential resource numbers.

Not sure what you mean by mixing code with command handlers.

Illegal resource numbers for Snd and Pict are now rejected.

Zero-length IDs now have a separate sscanf line.

Numeric and text IDs now have separate sscanf lines.
(0002179)
EmacsUser (manager)
2013-12-15 12:27

Looks good to me once that last change is in! (By ``parsing code in with the handlers'' I meant the strtol calls, which you've taken care of.)

We'll see what Graham says.
(0002180)
DavidG (reporter)
2013-12-15 15:00
edited on: 2013-12-15 15:12

I've decided to handle non-sequential resource numbers by maintaining a linked list of resource numbers already used. If a collision is detected, a fatal error is thrown. My problem is I cannot figure out how to put the code where I want and have inweb accept it. For instance, I'm starting with this, which I put at the bottom of Blorb\ Writer.w:

@p Tracking out-of-order resource numbers.
cBlorb previously accepted resource IDs only as integers in Blurb files.
To better follow the Blorb standard, code for supporting alphanumeric
IDs was introduced. While this continued to allow integer IDs, this
broke the ability to specify IDs out of order. Here, a simple linked
list is used to keep track of all resource numbers used so far.

@c
typedef struct resource_list {
        int num;
        struct res_num *next;
} resource_list;

res_num *sound_resource;
res_num *pict_resource;

Near the top of Blorb\ Writer.w, I put "-- Owns struct resource_list (private)". That yields this:

$ inweb/Tangled/inweb.pl -weave cBlorb
inweb 4/090319 (Inform Tools Suite)
inweb: interface errors on 2/blorb (Blorb Writer.w)
Incorrect structure billing: should be...
-- Owns struct chunk_metadata (private)
-- Owns struct resource_list (public)
   !- shared with Chapter 1/Memory.w
...and not...
-- Owns struct chunk_metadata (private)
-- Owns struct resource_list (private)

If I put the code into Memory.w, it works. But that doesn't seem like a good place for the code. Why is inweb complaining?

(0002181)
EmacsUser (manager)
2013-12-17 17:01

Sorry, I've been out of commission with a nasty flu.

cBlorb's analysis of structure usage is fairly primitive; it only looks for mentions of member names after a . or ->. Consequently, you can confuse it with two structs sharing a member name, like ``next'' in memblock_header in Memory.w and ``next'' in resource_list in Blorb\ Writer.w. So your best bet is to pick something unlikely to clash, ``next_resource_node'' or some such. That Memory.w uses a nondistinctive name like ``next'' is unfortunate.
(0002182)
EmacsUser (manager)
2013-12-17 17:37
edited on: 2013-12-17 17:38

Okay, eventually it entered my head to see whether P/man mentions that issue. It doesn't, so I've filed 0001158.

(0002184)
DavidG (reporter)
2013-12-18 00:21

Here's the code to handle out-of-order numeric IDs. Perhaps that assert() call can be safely removed. Anything else?
(0002185)
EmacsUser (manager)
2013-12-18 09:00

Two things off the top of my head. One, there's no error on this blurb:

- - - -
picture 1 "foo.png"
picture 2 "foo.png"
picture 3 "foo.png"
picture 1 "foo.png"
- - - -

Two, rather than making an assert, respond to null by calling

- - - -
fatal("Run out of memory: malloc failed");
- - - -

as done in Memory.w.
(0002186)
EmacsUser (manager)
2013-12-18 09:04

Oh, and you may want to use TRUE and FALSE (|TRUE| and |FALSE| in the documentation) rather than 1 and 0, for consistency with the rest of the source code.
(0002187)
DavidG (reporter)
2013-12-18 21:58
edited on: 2013-12-18 22:00

Now that function will accept lots of numbers instead of just two. I'm embarrassed that I forgot how to correctly write something like that. One problem remains, and I think it's vaguely related to inweb. Compiling goes like this:

$ gcc -o cblorb cBlorb.c
Chapter 3/Website Maker.w:166:6: warning: conflicting types for ‘fatal’ [enabled by default]
Chapter 2/Blorb Writer.w:78:3: note: previous implicit declaration of ‘fatal’ was here

But the resulting program seems to work okay.

(0002188)
EmacsUser (manager)
2013-12-19 03:14

Ah, resource_seen is written above the bar, but per P/man §27, ``No functions should be declared here: it should be structures, definitions, global variables and arrays, commentary.'' My fault for not spotting that earlier.

Otherwise, looks good.
(0002189)
DavidG (reporter)
2013-12-19 11:13

Okay. I moved resource_seen() below the bar and now there are no complaints when compiling.
(0002539)
graham (administrator)
2014-03-09 06:38

David's patch has essentially been merged into the new cBlorb.

- Issue History
Date Modified Username Field Change
2012-11-04 16:09 DavidG New Issue
2012-11-05 07:21 EmacsUser Note Added: 0001923
2012-11-05 07:21 EmacsUser Priority high => normal
2012-11-05 07:21 EmacsUser Status new => confirmed
2012-12-16 19:32 DavidG Note Added: 0001942
2012-12-17 07:21 EmacsUser Note Added: 0001943
2013-12-11 22:52 DavidG Note Added: 0002175
2013-12-14 12:23 EmacsUser Note Added: 0002177
2013-12-14 18:16 DavidG Note Added: 0002178
2013-12-15 12:27 EmacsUser Note Added: 0002179
2013-12-15 15:00 DavidG Note Added: 0002180
2013-12-15 15:12 DavidG Note Edited: 0002180 View Revisions
2013-12-17 17:01 EmacsUser Note Added: 0002181
2013-12-17 17:37 EmacsUser Note Added: 0002182
2013-12-17 17:38 EmacsUser Note Edited: 0002182 View Revisions
2013-12-18 00:21 DavidG Note Added: 0002184
2013-12-18 09:00 EmacsUser Note Added: 0002185
2013-12-18 09:04 EmacsUser Note Added: 0002186
2013-12-18 21:58 DavidG Note Added: 0002187
2013-12-18 22:00 DavidG Note Edited: 0002187 View Revisions
2013-12-19 03:14 EmacsUser Note Added: 0002188
2013-12-19 11:13 DavidG Note Added: 0002189
2014-03-09 06:38 graham Note Added: 0002539
2014-03-09 06:38 graham Status confirmed => resolved
2014-03-09 06:38 graham Resolution open => fixed
2014-03-09 06:38 graham Assigned To => graham
2014-05-07 07:32 jmcgrew Fixed in Version => 6L02
2014-05-07 07:33 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker