# Tag Info

## Hot answers tagged contexts

28

In version 10.1, I've built something like Spelunk into GeneralUtilities. To use it, run Needs["GeneralUtilities"] PrintDefinitions[symbol]; This will pop up a window that shows all definitions of symbol. Here is a short summary of features: The window shows code cells containing all DownValues, OwnValues, UpValues, SubValues, and Attributes of a ...

14

The definitions aren't being lost, they're being shadowed, as described in the tutorial on contexts. Mathematica doesn't warn you about this because it only warns when there is shadowing between contexts that are listed in the $ContextPath. Since Begin only changes$Context and not $ContextPath, you don't get a warning when the symbol that causes shadowing ... 9 I will make no attempt to defend the fact that Mathematica simulates scoping by means of variable renaming. However, the behaviour that we see is consistent with the principles under which Mathematica does operate. Whenever Mathematica tries to interpret a symbol name, it first checks to see whether a symbol with that name already exists in a package in ... 9 One thing that might help you when investigating in such issues is the LinkSnooper. This is a java program that can be used to set up an additional kernel configuration. When you use this kernel, you can watch all traffic between front-end and kernel. With this, you could look what happens if you evaluate a simple 1+1 FE ---> K: ... 8 Indeed confusing, but can be explained. Please read here first on how Mathematica searches contexts for symbols. In short,$Context tells it where to create symbols. It's for creation, not for lookup. $ContextPath tells it where to look for symbols but doesn't affect symbol creation. If the symbol is not found in any of the$ContextPath contexts, ...

7

There are two things you need to know: (1.) Mathematica knows about symbols, even if you only mention them: This means that in this simple example 1 /. myVar_Integer :> 0 where myVar is only a placeholder (a named pattern) or like you call it a dummy, Mathematica still sees this symbol and adds it to its symbol table Names["Global*"] (* {"myVar"} *) ...

7

The front-end-related operations are actually performed by Front End itself. According to the tutorial Executing Notebook Commands Directly in the Front End: When you execute a command like NotebookWrite[obj,data] the actual operation of inserting data into your notebook is performed in the front end. Normally, however, the kernel is needed in order to ...

6

Somehow I've overlooked this topic on MathGroup earlier: $CellContext Here's what John Fultz said:$CellContext is a symbolic placeholder in cell expressions (most typically Dynamic expressions inside of Cell) which indicates that the ambient context as defined by the CellContext option should be used (which allows you to wall off notebooks, cell ...

6

It seems that when the book appeared, the behaviour of how a symbol is resolved was different. We have two important things: the current $Context which is usually Global unless you change it with e.g. Begin as you did the$ContextPath which is a list of contexts that are searched when you type in a symbol like x without explicit context Now there seems ...

6

I think the symbols sym and $m7res are created by Information. They are not present when the kernel is started. Fresh kernel 1: Quit[] Names["Global*"] (* {} *) Fresh kernel 2: Quit[] foo = Trace[ Information["Global*"], TraceInternal -> True]; foo[[8, 3, 5, 7, 2, 9, 18, 65, 2, 1, 3, 6, 7, 5, 6, 4, 3, 3, 6, 2, 8, 12, 10, 5, 6, 2, ... 5 We can replace something, in all definitions associated with a symbol, using function like this: ClearAll[replaceExtendedDefinition] SetAttributes[replaceExtendedDefinition, HoldFirst] replaceExtendedDefinition[sym_, rules_] := Replace[ LanguageExtendedDefinition[sym] , (rule:Rule | RuleDelayed)[lhs_, rhs_] :> ... 5 From the comments: But I'm mainly worried about the warning messages that Mathematica issues when I load both packages. If the packages are properly written, and if the symbol conflict is between two packages (and not builtins and a package function), then you can safely ignore it. From the documentation of BeginPackage: BeginPackage["context"] ... 4 I have been thinking recently a lot about this mysterious$CellContext, that turns up when we convert a cell with interactivity (such as Button, Slider, DynamicModule, Dynamic) to a cell expression. Just as Kuba, I found that there is not much documentation on this topic, but in MathGroup and SE there are some very valuable comments and remarks, not in the ...

4

I reported this problem to Wolfram technical support, and I have received the following response (edited for brevity). I was able to reproduce the issue you have reported. I have forwarded an incident report to our developers with the information you provided. I have tagged the question with bugs. Update This bug appears to be fixed in V10.0.1

4

This is all covered in the documentation. To answer your specific questions: Yes, just call Needs or Get more than once. Yes, by setting up contexts correctly Yes, but in Mathematica they are called Contexts. The issue is likely to be that you did not use a standard package structure to write your packages, including the Begin["Private"]. See the ...

4

I was just digging around one day and I found appropriate function for this. FrontEndExecute@FrontEndPrivateGetUpdatedSymbolContexts[]; will help if you read a package or clear symbols from different place than the notebook interface. CreatePalette[ Button["Clear", Clear["Global*"]; FrontEndExecute@FrontEndPrivateGetUpdatedSymbolContexts[]; ...

4

Note: shown below is an answer to the first version of the OP's question Here is a simple example using scoping constructs, namely Block in this case. The idea is that you can indicate symbols to make local to Block, which implements dynamic scoping: take a look at the "Background and Context" section of its docs for a more complete explanation. Symbols ...

4

As @MarcoB states, you should probably use scoping constructs... If you're opposed to that idea, you can set the Notebooks default context to be Unique to Each Cell Group. I wouldn't recommend that, but it works. You can set that under Evaluation > Notebook's Default Context > Unique to Each Cell Group: Note, to escape this, you need to specify ...

3

This is messy and imperfect, but it will work in simple cases: Import the package contents: pack = ImportString[data, {"Package", "HeldExpressions"}] (* {HoldComplete[BeginPackage["Test"]], HoldComplete[testFunction::usage = "-";], HoldComplete[Begin["Private"]], HoldComplete[testFunction[] := {123, explicitvalue, Hold[explicitvalue]};], ...

3

I think this is a caching problem. Considering the examples in the Update documentation it certainly makes sense that this could be the case. Although Update appears to have no effect I have found something that does: Information. x = 1; Context[x] = "foo"; x foox Context[x] 1 1 "foo" ?x foox x=1 x foox Context[x] x 1 "Global" ...

3

It is a matter of having the right $ContextPath at the time n is referenced. This is slightly complicated by the fact that contexts are interpreted at parse time, so typical tricks such as Block do not work. The behavior of Begin and BeginPackage are also different with respect to$ContextPath, but this is all discussed in the documentation, so I will let ...

3

The standard way to expose a symbol which is defined within a private context is to define a usage string outside the private context, as in BeginPackage["MyPackage"]; Symbol1 = 1; Symbol2::usage = "Symbol2 is a test symbol"; Begin["MyContext"]; Symbol2 = 2; End[]; EndPackage[]; Actually, any mention of the symbol inside the package but outside the ...

3

For your second question this would define a global aContxt so that it can be used in other notebooks (to be evaluated in the notebook with the private context): GlobalaContext = $Context; Then you can define a new variable like this: SetDelayed @@ Join[Hold[varAnb], ToExpression[aContext <> "varA", InputForm, Hold]] the reason why this looks so ... 3 It is hard to answer you without you showing a minimal example of the problem. But my guess is that you are making the mistake of returning symbols from the package back to the user. The way to handle these things, is to do like all Mathematica functions do, which is pass the symbols needed in the call itself. For example, when using DSolve or Integrate, ... 2 (this is wiki answer, as just noticed it is duplicate, but will keep it here for easy reference) The result is different from Version 2.2 and version 10.1, this is just to show the difference. Something changed between 1993 and today: 2 Interpolation is a built-in function located in the System context, which is the same for all Notebooks independently of$Context, hence any changes of Options of this function will be global. But you can define your own function in the local context and set local options for it (see here for explanations): Clear[interpolation]; Options[interpolation] = ...

2

It might be that this is due to dispatch, list and doStuff being completely owned by the frontend, since you wrapped them in a DynamicModule. Frontend variables cannot be shared between kernels. When you localize them in a Module, and therefore keep them as kernel variables, it works: Module[{dispatch, list, doStuff}, list = Range[8]; doStuff[a_] := ...

1

I have exactly the same project. In my case paramList always has the same variables' names, so I defined a "structure" to handle it in the package and a way to transform it into a rule: BeginPackage["foo"] Unprotect @@ Names["foo*"]; ClearAll @@ Names["foo*"]; f::usage = "sol=f[x,plist]" Begin["Private`"] constructPData[y_, z_] := pData[y, z]; pData /: ...

1

I'm still not sure whether I understand your problem and what you are trying to achieve but I now found something which is not entirely obvious. I think you try to load a sub-package file which was encoded with a key and put its context on $ContextPath. Here is what I think will do what you want: First you need a directory TestApplication in one of the ... 1 I think you're confused about context paths, partly because your application only has one package. I assume you have a package called TestPackage.m located in a folder called TestApplication located within FileNameJoin[{$UserBaseDirectory, "Applications"}]? On my machine this folder would be ...

Only top voted, non community-wiki answers of a minimum length are eligible