Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000100Core InformReleasing, bibliographic data, cBlorbpublic2010-06-22 03:372010-10-28 00:30
Assigned Tograham 
Platformx86OSWindowsOS VersionVista
Product Version6E59 
Target VersionFixed in Version6F95 
Summary0000100: Releasing source text causes the "heading" span tags to be misplaced.
DescriptionTry to release a game that has headings and make sure to release it with source text available on a web site. The actual text-based version looks just fine. But if you look at the Web based version, click on a few heading sections: you'll find that all the headings are "off" a bit. It doesn't seem entirely regular in terms of how off it is.

How you'll notice this is that text from the previous section (before a heading) appears as the heading one page down.

It's largely impossible to miss so steps to reproduce are just that you release with source text and check the web-based version of that text.
Minimal Source Text To Reproduce
Release along with a website and source text.

Bedroom is a room.

Chapter 1

Kitchen is a room.

Chapter 2

Foyer is a room.
Additional InformationThere wasn't really an appropriate "effect" for this because it's not the game that's misbehaving. It's the released material.
Effect(serious/mild) Game compiles but misbehaves
Attached Fileszip file icon [^] (45,930 bytes) 2010-08-30 17:09

- Relationships
related to 0000258closedgraham Released web source had duplicated index when a footnote occurs in the prefatory lines (with solution) 

-  Notes
jmcgrew (administrator)
2010-06-22 11:03

The "complete text" on the generated website is correct, but the styled pages are wrong. The first page contains:

Release along with a website and source text.

Bedroom is a room.

(The "Release" line is formatted like a heading.)

Chapter 1 contains:


Chapter 1

("oom." is formatted like a heading.)

And Chapter 2 contains:

Chapter 2

Foyer is a room.

(No special formatting.)

The definition of Kitchen does not appear in any of the chapter pages.
graham (administrator)
2010-06-22 14:48

This works fine for me, which makes me suspect that it may be a platform issue, e.g. to do with the Windows representation of text files? The one point where I can duplicate the reported behaviour is that cBlorb does always set the very top line of the source in bold - whether or not it is actually the title. (It almost always is, because people tend not to release unnamed stories with a website and source. But in any case this is documented behaviour for cBlorb.)

The incorrect splitting issue is serious, but as I say, I'm not seeing it. Perhaps Jesse could investigate a little?
jmcgrew (administrator)
2010-06-22 23:15

Well, it's probably not the line endings - on OS X it works even with converted to use CRLF.
johndillard (reporter)
2010-07-02 12:58
edited on: 2010-07-02 13:01

Would it be easier and quicker for me to just try to fix this myself? If this is just a Windows issue, then presumably it's only with the Windows IDE, right? I know the source is available for that, so I can just take a look at it myself if that's the problem area. If this is in the compiler, then I presume I'm out of luck.

jmcgrew (administrator)
2010-07-02 13:06

Couldn't hurt. This is presumably a bug in cBlorb, which is at [^] (you'll need inweb to compile it). You'll also need to compile it with GCC unless you use the patch at 0000156 - my efforts so far have been focused on just getting it to compile in Visual Studio.
jmcgrew (administrator)
2010-07-02 13:08

Actually, you can use the pre-tangled source at [^] if you don't have inweb installed. Not sure if that's the same version I have, but hopefully the patch will still work.
johndillard (reporter)
2010-07-03 16:03

Yeah -- this code is sort of a huge mess. :) I don't know. I finally got it compiling and working. I'll keep playing around with it but given that no one has brought this up before, I'm betting this isn't a huge issue for anyone. I'm spending more time on this than I am just playing around with Inform. Is there a way for us to just close our own issues or is it preferred to keep them open?
jmcgrew (administrator)
2010-07-03 16:10

Well, I'd prefer to keep it open. This is a genuine bug with no apparent workaround other than to release on a different OS. I might take another look at it after I finish updating my extensions.
johndillard (reporter)
2010-07-24 02:47

Okay, I've tried playing around with this a lot. And I'm just not seeing how to fix it. Granted, though, I'm not even sure I've got everything compiling right and I can't really step through anything so I can watch what happens as it executes. I couldn't get Visual Studio 2010 to work with everything and I'm not familiar with debuggers in different environments.

With all that, this is still really annoying. One of the cool features of Inform seems to be the ability to release readable source and this bug prevents that, at least on Windows. Sorry I can't be more help in resolving the issue; but I'm hoping some solution can be found. I find that the generated documentation can be a good resource particularly because I don't like to use the provided widgets that let me collapse bits of the source based on headings.
dchapes (reporter)
2010-08-19 14:25

To counter johndillard's July 3rd comment, I can confirm that this is a issue that's been annoying me for some time; I just wasn't sure if it was something particular to my setup so I hadn't gotten around to reporting it yet.

I'm running Windows XP.
johndillard (reporter)
2010-08-20 10:56

Yeah, it's insane that this hasn't been fixed yet since I have to believe that someone who knows the code could probably isolate this quick. (What's slightly even more insane is that this glaringly obvious problem wasn't found during the "testing" that was allegedly done.) This "release source in a web site" is a really cool feature of Inform, making it all the more a pity that it doesn't work. I tried to look at the source code, but it's a mess in terms of getting it set up where you can fully compile and debug. I did look at the source for the Windows Inform IDE in case that was the problem, but it's using MFC and that's not something I'm familar enough with to jump into.
dchapes (reporter)
2010-08-20 11:59

I appreciate all your efforts to try and track this down. (And I understand not wanting to deal with the horror that is MFC).

This probably isn't the place to get into the details of how I7 is tested (we could probably discuss it on the intfiction forum if you like) but I do know there is a vast suite of (semi?-fully?)-automated tests that every build gets run through; I think those may focus on source input + command input = expected transcript/error output, however. [I don't speak for the Inform team of course.]
dchapes (reporter)
2010-08-20 15:33

I looked into this some more and found out that it is indeed due to line breaks.

The windows IDE forces the file into unix format (NL, 0x0A) and cBlorb fails on those. If the source is first translated to either dos (CR+LF, 0x0D0A) or old-mac (CR, 0x0D) and cblorb.exe run by hand then it produces the correct output.

In the case where the only change is NL to CR (i.e. file length and all other bytes remain in the same places) debugging printf's indictate that ftell() gives different values for these cases.

So, recompiling cblorb (with mingw32 gcc-4.4 if it matters) and only changing the fopen() mode from "r" to "rb" within file_read() fixes the problem completely for me.
dchapes (reporter)
2010-08-25 03:55
edited on: 2010-08-25 03:57

For anyone interested, a patch for this as well as a half dozen other minor issues with cBlorb is linked to in comment 0000431 of issue 0000258 (sorry, I don't know how to make links in mantis notes to other issues/notes).

jmcgrew (administrator)
2010-08-26 12:05

I've attached the patch to issue 0000258 as well.

(For the record, you can make links by prefixing an issue number with # or prefixing a comment number with ~.)
johndillard (reporter)
2010-08-27 04:10

This is very cool that there's a fix. Is there a chance someone can just put up a compiled .c file so that it's relatively easy for anyone to grab the fix without having to install a comipler, compiling it, and so on?

I did download the mingw32 gcc compiler but there was just one executable and I'm not entirely sure how to get something effectively compiled with that. I don't mind having to read up on how to do something, but since it seems like others have already got this compiled (and since I'm not the only one having the problem), can we just share the file directly?

Thanks for your work on this.
jmcgrew (administrator)
2010-08-30 17:10
edited on: 2010-08-30 22:52

I've attached a compiled version, courtesy of EmacsUser.

graham (administrator)
2010-09-02 02:28

Since I've accepted Dave's patch for cblorb, which includes his "rb" vs "r" fix, which apparently fixes this problem, I'm marking this issue as resolved. Many thanks.

- Issue History
Date Modified Username Field Change
2010-06-22 03:37 johndillard New Issue
2010-06-22 11:03 jmcgrew Note Added: 0000120
2010-06-22 11:03 jmcgrew Status new => confirmed
2010-06-22 11:03 jmcgrew Category Source text and punctuation => Releasing, bibliographic data, cBlorb
2010-06-22 11:03 jmcgrew Product Version => 6E59
2010-06-22 11:03 jmcgrew Steps to Reproduce Updated View Revisions
2010-06-22 14:48 graham Note Added: 0000127
2010-06-22 14:51 jmcgrew Status confirmed => assigned
2010-06-22 14:51 jmcgrew Assigned To => jmcgrew
2010-06-22 23:15 jmcgrew Note Added: 0000135
2010-07-02 01:56 jmcgrew Tag Attached: wrongeffect
2010-07-02 12:58 johndillard Note Added: 0000228
2010-07-02 13:01 johndillard Note Edited: 0000228 View Revisions
2010-07-02 13:06 jmcgrew Note Added: 0000229
2010-07-02 13:08 jmcgrew Note Added: 0000230
2010-07-03 09:44 jmcgrew Status assigned => confirmed
2010-07-03 16:03 johndillard Note Added: 0000232
2010-07-03 16:10 jmcgrew Note Added: 0000233
2010-07-24 02:47 johndillard Note Added: 0000343
2010-07-24 03:16 jmcgrew Assigned To jmcgrew => DavidK
2010-07-24 03:16 jmcgrew Status confirmed => assigned
2010-08-19 14:16 dchapes Issue Monitored: dchapes
2010-08-19 14:25 dchapes Note Added: 0000399
2010-08-20 10:56 johndillard Note Added: 0000404
2010-08-20 11:59 dchapes Note Added: 0000405
2010-08-20 15:33 dchapes Note Added: 0000406
2010-08-22 02:01 DavidK Assigned To DavidK => graham
2010-08-25 03:55 dchapes Note Added: 0000432
2010-08-25 03:55 dchapes Note Edited: 0000432 View Revisions
2010-08-25 03:56 dchapes Note Edited: 0000432 View Revisions
2010-08-25 03:57 dchapes Note Edited: 0000432 View Revisions
2010-08-25 08:23 curiousdannii Relationship added related to 0000258
2010-08-26 12:05 jmcgrew Note Added: 0000441
2010-08-27 04:10 johndillard Note Added: 0000445
2010-08-30 17:09 jmcgrew File Added:
2010-08-30 17:10 jmcgrew Note Added: 0000461
2010-08-30 22:52 jmcgrew Note Edited: 0000461 View Revisions
2010-08-30 22:52 jmcgrew Note Revision Dropped: 461: 0000232
2010-09-02 02:28 graham Note Added: 0000487
2010-09-02 02:28 graham Status assigned => resolved
2010-09-02 02:28 graham Resolution open => fixed
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:30 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker