Background directives and include files?

[jeremydouglass]

What is the expected behavior of background directives in include files?

I had assumed that, like startshape, every background after the first one would be ignored. However it seems as if each one is overwriting the one before, which is unexpected, because it means you can't edit the background in the top-level design - you have to hunt through your include files. It also means that cfdg files can have their own startshape, but not their own background - if you plan on reusing them in another design, the background needs to come out.

If backgrounds behaving in this way is the intended behavior, can we always check the last-included library for its last-included library (etc.), or does the order of assembling included files ever change based on whether the library path is relative, absolute, in the default folder etc.?

Personally I'd prefer declaring the background in the top-level design and ignoring the rest. However, if you reading subsequent backgrounds, it might be more context-free-ish to make the values cumulative: e.g. background { b -1 } + background { b .5 sat 1 h 30 } + background { b .1 sat .1 h 340 } = background { b -.6 sat 1.1 h 370 } (which gives you real values of b .4, sat 1, h 10)....

[jeremydouglass]

I'm getting even more confused now, and I'm assuming I've uncovered one or several bugs. I've read repeatedly that the first startshape directive in CF is the one used, and that all others are ignored. However I just tested the following grammar in both CF 2.0 and CF 2.1b (the results were the same):

Code: Select all

  startshape blue    // first startshape
  startshape green // second startshape

  background { b -1 sat 0 } // first in-file: black
  background { b  1 sat 1 hue 60 } // last in-file: yellow

  rule blue   { SQUARE { sat 1 b 1 h 240 } }
  rule green { TRIANGLE { sat 1 b 1 h 120 } }

  include mybg.cfdg

  background { b 1 sat -1 } // last in-file: white

and

Code: Select all

  // --- mybg.cfdg --- //
  startshape red
  background { b -.5 sat .75 } // include - red
  rule red   { CIRCLE { sat 1 b 1 h 0 } }

I expect ... well, never mind. What I actually get is a green triangle on a red background.

The startshape is defined by the last directive in the top-level file. That's odd. The background is defined not by the first directive, or the last, but the last one *up to the end of the last include file*, with subsequent directives ignored ( I think - it might be more complicated than that, but I'm not going to test it ). That's bizarre.

[MtnViewJohn]

I will test this. The correct behavior is for the first startshape, background, and tile directives to be used and for all others to be ignored.

[MtnViewJohn]

Yup, the code for ignoring subsequent startshape lines is broken in exactly the way you describe and the code for ignoring subsequent background and tile lines is missing.

The background line behavior that you see is caused by the way that included cfdg files are processed. In a computer language like C or C++ include files are inserted at the point of the include statement. For cfdg files, included files are added at the end. When you say

Code: Select all

include foo.cfdg

foo.cfdg is put into a queue of files that are to be parsed after the current file is finished parsing.

[jeremydouglass]

Glad it was helpful.

Thanks also for clarifying about how include files work.