Skip to main content
Revert the bugs header, as the bug is currently fixed
Source Link
Jacob Akkerboom
  • 12.2k
  • 46
  • 82

Bug introduced in 10.0.0 and persisting through 12.2.0 or laterBug introduced in 10.0.0 and fixed in 10.0.1

The bug was originally correctedis also present in 1012.2.0 and resolved in 12.1, but it has been reintroduced3.0 on Mac OS X x86 (64-bit).


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

Bug introduced in 10.0.0 and persisting through 12.2.0 or later

The bug was originally corrected in 10.0.1, but it has been reintroduced.


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

Bug introduced in 10.0.0 and fixed in 10.0.1

The bug is also present in 12.2.0 and resolved in 12.3.0 on Mac OS X x86 (64-bit).


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

Updated bugs header, see https://mathematica.meta.stackexchange.com/a/1611/4330
Source Link
Jacob Akkerboom
  • 12.2k
  • 46
  • 82

Bug introduced in 10.0.0 and fixed in 10persisting through 12.02.10 or later

The bug was originally corrected in 10.0.1, but it has been reintroduced.


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

Bug introduced in 10.0.0 and fixed in 10.0.1


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

Bug introduced in 10.0.0 and persisting through 12.2.0 or later

The bug was originally corrected in 10.0.1, but it has been reintroduced.


If I evaluate, with a fresh kernel

Names["Global`*"]

I get

{"rhs", "z"}

I think this is not caused by any packages in $UserBaseDirectory or $BaseDirectory, because if I evaluate the same expression under V9.0.1, which has the same strings for these variables (directories), I get

Names["Global`*"]
{}

As expected.

I was wondering if others are getting the same result. rhs and z do not have values, but still I am a bit concerned about the safety of

Remove["Global`*"]

when certain functions may depend on the existence of these symbols in Global`. For example if I set

sys`f[Global`xxxx_] := Global`xxxx

and evaluate

Remove[Global`xxxx]

then the following looks a bit scary

 sys`f // Definition
sys`f[Removed[xxxx]:_]:=Removed[xxxx]

sys`f still works, but I still think it may lead to trouble (e.g. with Save).

Kirma came up with the nice idea of testing this on the cloud. I get

Apply[And, 
 MemberQ[CloudEvaluate[Names["Global`*"]], #] & /@ {"z", "rhs"}]
True

But there are many other symbols in the Global` context there. So, is this a bug?

edited tags
Link
Michael E2
  • 244.7k
  • 18
  • 351
  • 774
added 66 characters in body
Source Link
RunnyKine
  • 33.3k
  • 3
  • 110
  • 176
Loading
Post Merged (destination) from mathematica.stackexchange.com/questions/58276/…
edited tags
Link
Sjoerd C. de Vries
  • 66.1k
  • 15
  • 189
  • 327
Loading
Tweeted twitter.com/#!/StackMma/status/488014464193941504
Kirma's idea of testing on the cloud. Formatting
Source Link
Jacob Akkerboom
  • 12.2k
  • 46
  • 82
Loading
Source Link
Jacob Akkerboom
  • 12.2k
  • 46
  • 82
Loading