10
$\begingroup$

During the development of a program to process bioinformatic data, I have encountered a peculiar shadow warning:

GlobalParentList::shdw: Symbol ParentList appears in multiple contexts {Global,System}; definitions in context Global may shadow or be shadowed by other definitions. >>

Some background:

  1. No where in the program do I create a variable named ParentList.
  2. ParentList appears to be an undocumented System symbol (at least I can't find documentation on it.)
  3. When I run my program as a complete, single block of code, I do not get the shadow warning, yet when I run segments of code linearly (which I am doing because I am writing a paper on the program), then the warning appears. This behavior is consistent whether I use Mathematica v 9.0.1 or 10.0.2
  4. I have tracked the single line of code that generates the warning. Notice how the list of names in the Global context changes after the code is executed.

Before troublespot:

Names["Global`*"]

...,overlapadj,overlapcoord,passengermers,passengerpopup,...

Trouble spot & subsequent list of Global names:

Export[StringJoin[ToString[studyname], " - siRNA alignment.jpg"], 
  Pane[graphicoutput, 801], ImageResolution -> 300];

GlobalParentList::shdw: Symbol ParentList appears in multiple contexts {Global,System}; definitions in context Global may shadow or be shadowed by other definitions. >>

Names["Global`*"]

...,overlapadj,overlapcoord,Global`ParentList,passengermers,passengerpopup,...

Notice how the Global namespace has a new symbol called ParentList that wasn't there before the Export command.

  1. Even though I do not get the shadow warning when I run the entire program as one block of code, I still do get the spurious creation of the variable ParentList in the Global context.

  2. When I tried to recreate a minimal example of the bug in a new notebook I was not able to reproduce this behavior, making me think the primary issue really isn't with the Export command as shown above.

So, I am stuck.

A. Have you seen behavior like this before?

B. Would you have suggestions about how to troubleshoot this problem?

Edit (01/08/2015): Into the Heart of Darkness

Continued efforts to shed light on this peculiar behavior have failed. I have tried:

  1. Re-positioning the offending line of code to another spot within the code (to see if execution order mattered) - shadow warning still appears
  2. Re-typing the entire cell of code from scratch to see if the cell itself was corrupt - shadow warning still appears
  3. Loading a copy of the notebook into Notepad and searched for the offending symbol. The symbol does not appear anywhere before the generation of the warning itself.
  4. Changed the export format from jpg to gif - shadow warning still appears
  5. Using various permutations of Trace to shake the problem loose - all to no effect. (I admit I am not very skilled at using Trace.)

It really seems as though Mathematica is spontaneously doing something that I am unable to monitor. Exasperating to say the least.

(01/08/2015) Later in the day

  1. For some reason, I was inspired to try changing the export format from jpg to pdf, and the shadow warning disappeared. I have repeated this several times with a fresh kernel to be sure the change in behavior is real and reproducible.

Question C: Could there be a subtle "bug" in Mathematica's use of code for raster graphics vs vector graphics that causes the ParentList symbol to bleed into the global namespace?

(01/17/15) The Saga Continues ...

I sent a minimal example notebook to WRI and they were not able to reproduce the problem on their computers. They advised me to reset the system preferences by holding (CTRL-SHIFT) while loading Mathematica. Unfortunately this had no effect, as I still get the warning message.

Here is an example of the warning and new symbol that shows up in the global namespace:

enter image description here

If anyone is still interested, I have made the notebook I sent to WRI (and which causes the warning on my system) available here:

https://www.dropbox.com/s/ogspeip2ctmbahu/shadow%20testing-minimal1.nb?dl=0

I would be appreciative if others could run it (from a fresh kernel) and let me know if any warning appears. If not, I suppose I just have a corruption somewhere on my machine that I will have to live with. Certainly has me scratching my head. Thanks for reading.

(01/18/15) A peek at the solution...

StackExchange user Simon Woods found the symbol generating the shadow warning (ParentList) in the stylesheet being used to write the program. (See comment section below.) This stylesheet is the authoring template used by The Mathematica Journal.

While Simon was able to reproduce this bug (thankfully!) under Windows 7, StackExchange user ybeltukov was not able to reproduce the bug under the Linux version of Mathematica.

So, it seems that I stumbled upon a problem in a stylesheet that produces a shadow warning that is operating system dependent.

Question D: Why would a stylesheet function differently under different operating systems?

Question E: Has anyone seen a stylesheet behave this way under different operating systems?

I will alert WRI technical support about this and the editors of The Mathematica Journal.

Improve this question
$\endgroup$
17
  • 2
    $\begingroup$ Re: A – I have seen behavior like this, yes. Mathematica is a complex piece of software and some hard to detect bugs like this can often come up even in internal code. Re: B — As you say, it's hard to produce a minimal example for bugs like this (understandable), but it also makes it hard for us to try and troubleshoot. The question then becomes: Is this affecting your work? If so, how? That would give us a concrete path to proceed. If not, then I would suggest ignoring it or silencing it. $\endgroup$
    – rm -rf ♦
    Commented Jan 3, 2015 at 23:25
  • 2
    $\begingroup$ To give an example, see this discussion between me, Leonid and Rojo. In the end, the mistake was mine — I hadn't fully isolated all my private symbols and a few of them happened to get exposed only in some very specific order of internal function calls. The point I'm trying to make is that this bug (albeit minor) crept into a smallish but non-trivial package that had extensive unit-tests and was identified only a year later. It is very likely that there are hundreds if not thousands of these in the Mathematica code base. $\endgroup$
    – rm -rf ♦
    Commented Jan 3, 2015 at 23:36
  • 1
    $\begingroup$ It is quite likely that there is an evaluation-order bug here. Essentially, some part of the code is evaluating the symbol ParentList before the internal package that contains its definition is loaded (automatically). Unless this is directly affecting your work, I would suggest just ignoring it. $\endgroup$
    – Stefan R
    Commented Jan 6, 2015 at 21:04
  • 1
    $\begingroup$ No warnings on Linux, V10.0.1 $\endgroup$
    – ybeltukov
    Commented Jan 18, 2015 at 2:23
  • 3
    $\begingroup$ I can reproduce the error with Mathematica 10.0.2 on Windows 7. It appears that the embedded stylesheet contains $CellContext`ParentList as a spurious entry in the InputAutoReplacements list for the style cells StandardForm and TraditionalForm in the FormatType Styles section. Removing these makes the problem go away, as does changing the stylesheet to something else. $\endgroup$
    – Simon Woods
    Commented Jan 18, 2015 at 11:27

1 Answer 1

Reset to default
6
$\begingroup$

I can reproduce the error with Mathematica 10.0.2 on Windows 7. In fact it is sufficient to open the example notebook and evaluate Rasterize[test] in a new input cell:

enter image description here

It appears that problem is due to the embedded stylesheet, which contains $CellContext`ParentList as an entry in the InputAutoReplacements list for the style cells StandardForm and TraditionalForm in the FormatType Styles section. Removing this symbol makes the problem go away, as does changing the stylesheet to something else.

(Note: I found this by simply opening the notebook in a text editor and searching for ParentList)

I did a bit of googling to try to understand what $CellContext`ParentList could be:

According to John Fultz here, "ParentList represents the (input autoreplacements) which have been inherited from the notebook level". I think the idea is that you can have some autoreplacements which are global and some which are specific to a certain cell style.

Another John Fultz post here states that "$CellContext is a symbolic placeholder in cell expressions (most typically Dynamic expressions inside of Cells) which indicates that the ambient context as defined by the CellContext option should be used" and also "You'll see it a lot in cell expressions, but it's supposed to be replaced with the actual context whenever an operation goes to the kernel."

So I wonder if the error appears because at some point during rasterization $CellContext resolves to System`, and then later on to Global`. We know that rasterization uses a Front End process, so that would perhaps explain the different results for different operating systems.

Clearly this is not a full explanation of the problem, but I think it sheds some light on the situation. The Mathematica Journal may appreciate an email letting them know of this problem with their stylesheet.

If @JohnFultz is around, he may be able to explain what is going on.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.