I am using Matlab's Mapping Toolbox to create and print a conically projected figure of North America. When I run the code inside the IDE the plots are printed and saved correctly, but when running the same script on the command line using -nodisplay -nodesktop -nosplash I run into a very strange problem.
During the print() function call, Matlab stops running the script without any error, warning, or crash log. Matlab does not actually crash...it just stops executing my code. Printing a figure without a display is suppose to be possible according to this.
Other people have come across a similar issue and have asked about it on the MathWorks website.
Here is some code to reproduce this problem.
So far, no one has come up with a solution. Does anyone have any suggestions? Thanks in advance!
Edit 1:
Here is some self contained code to reproduce the problem. I have tested on both R2011b and R2012a.
figure(1)
axesm eckert4; framem; gridm; axis off; tightmap
load geoid
contourfm(geoid, geoidrefvec, -120:20:100, 'LineStyle', 'none');
coast = load('coast');
geoshow(coast.lat, coast.long, 'Color', 'black')
contourcbar
print('-f1','-dpng','-r200','-painters', 'example');
The following warnings appear if you run MATLAB from scripts using, e.g.,
#!/bin/sh
nohup matlab -nodisplay -nodesktop -r myCode > myLog.log &
exit
.
[Warning: Objects of graph2d.lineseries class exist - not clearing this class or
any of its superclasses]
[Warning: Objects of scribe.legend class exist - not clearing this class or any
of its superclasses]
[Warning: Objects of graphics.panbehavior class exist - not clearing this class
or any of its superclasses]
[Warning: Objects of graphics.zoombehavior class exist - not clearing this class
or any of its superclasses]
[Warning: Objects of graphics.rotate3dbehavior class exist - not clearing this
class or any of its superclasses]
[Warning: Objects of graphics.datacursorbehavior class exist - not clearing this
class or any of its superclasses]
[Warning: Objects of graphics.ploteditbehavior class exist - not clearing this
class or any of its superclasses]
The problem is that the matlab code would like to display a figure, plot or something else, but the option -nodisplay prohibits it. I solved this problem by simply add the following lines to my code set(gcf, 'visible','off'); and at the end close gcf; clear gcf;. Now the plot legend was as in the first plot without shift and I got no warning.
I've come to the conclusion that this problem is not solvable, and is a bug.
The closest I've gotten to solving the problem is using the following code from the shell:
$ matlab -nosplash -nodisplay < makefigure.m
makefigure.m:
plot(randn(100,1));
set(gca,'Units','normalized','Position',[0.13 0.11 0.775 0.815]);
set(gcf,'Units','pixels','Position',[4 4 1200 900]); %# Modify figure size
hgexport(gcf,'myfig.png',...
hgexport('factorystyle'),'Format','png');
Which will output a png file 'myfig.png' of 1200x900 pixels. Unfortunately, while the image is the size I want, the graph itself is still the small size. I'm not certain of the cause of this, but I believe it has something to do with the fact that Matlab is object oriented and that the axes are supposed to be linked to the figure size (that's what the 'Position' variable for gca is normalized to). For whatever reason, this doesn't happen specifically when the display is turned off. I doubt this will be addressed anytime soon by Mathwoks, and I can't blame them since the vast majority of Matlab users use the GUI.
The one potential clue that could help anyone with the means to fix this is that it gives an error when running on the command line:
Warning: Objects of graph2d.lineseries class exist - not clearing this class
or any of its super-classes
I searched for a solution but just found more questions. My suspicion is that if someone can figure out what that means, you can fix this issue. For now, I will once again go back to python because with Matlab I just spend hours dealing with inconveniences instead of being productive.
Edit:
In case it helps, this is Matlab 2012a on
Linux ... 2.6.35.6-45.fc14.x86_64 #1 SMP ... x86_64 x86_64 x86_64 GNU/Linux
Related
I am using pycodestyle_magic as a linter in Jupyter. I am following the instructions at
https://github.com/mattijn/pycodestyle_magic
But I get error with 1-cell checking be it '%%pycodestyle' or '%%flake8'.
1st ERROR
# 1st CELL
%load_ext pycodestyle_magic
# 2nd CELL
%%pycodestyle
a=1
print(a)
2nd ERROR
# 1st CELL
%load_ext pycodestyle_magic
# 2nd CELL
%%flake8
a=1
print(a)
1st ERROR
I'm basing this on your image you posted for '1st error' and not the inaccurate code you posted:
Note that the error in your first error was saying line magic and not cell magic because it was not looking for cell magic anymore. You can see it will look for cell magic on the first line of a cell by putting in %%fake_magic as a first line and then 2 + 2 as a second line of cell. Running that you'll see UsageError: Cell magic %%fake_magic not found.
Hence, your first 'error' is that you are missing that the first line of the cell where you want to use cell magic becomes special. You cannot have something else on the first line where you want to use cell magic, even if it is commented out. In the image, you have #%%flake8 above %%pycodestyle. If you remove that line, it should work.
2nd ERROR
I'm basing this on your image you posted for '2nd ERROR' and not the inaccurate code you posted:
You've stumbled upon a bug currently involving flake8. (Maybe same or more bugs seem to prevent the %%flake8 magic from working at all for now, see comments.)
The solution/workaround is very similar to the '1st ERROR'. Remove the line you were trying to comment out because it being there is causing an issue.
The reasoning appears to be complex about the way the %%flake8 cell magic appears to work behind the scenes so that you cannot have comments in the code content at this time or it won't work. (And the second time it sees that comment symbol, it throws the error you see.) This bug has been reported here.
But the solution/work-around for now is straightforward. Remove the complexity you added, and see if it works.
In case of the %%flake8 magic, running the demo notebook as shown there doesn't work as shown, and so there is indeed a bug in the current version that was introduced by actually a bug in flake8 that the extension uses, see the specific comment here and the link to the underlying issue over at the flake8 repo. (In fact the extent that it doesn't work may be greater than the notebook reflects because as discussed in the comments, even cells without commented lines fail to report any formatting issues. The demo actually doesn't have any without and so I got distracted noting it only didn't show the buffer error for the first one in the demo notebook but since it had a commented line I thought it was still related.)The other way to workaround it at present is to install an older version of flake8 as pointed out here. The solution was merged though and should be available soon, and so just avoiding the triggering code in simple cases like yours is probably easier.
Note about the inaccurate code:
Post code for what gave you the issue, not what you think gave you the issue. Part of why you are asked to provide code as text the way you ran it, it is so those looking into it can run it the same way. Plus they don't have to type and can easily run it as you did. Beyond that, there's more reason behind it: you can try to see if what you observed originally matches what you are seeing now.
If you had run what you posted under the heading '1st ERROR' as the code block text, you would have seen it without the error you showed in your image. Usually you'd then discern the error/difference yourself. In other words, starball's comment was trying to point you to why you should be doing that, and sorted that 1st error out yourself. That would ultimately make your point about the fragile nature of %%flake8 magic have more impact because it isn't diluted by report of an error that isn't really an error. Plus, you may have realized what was necessary to avoid '2nd ERROR' because that code block works without error no matter how many times you run it.
Technical notes:
Anyone wishing to try out pycodestyle_magic with some of this code and the demo notebooks can click here to launch such a session served via the mybinder.org. service with most things necessary already set up. Once the session starts up in the classic Jupyter notebook interface, you need to do some further preparation to use pycodestyle_magic. As detailed here, you can install it with pip install flake8 pycodestyle_magic. So open a new notebook with the Python kernel backing it using New drop down on the upper right side and then choose the Python3 kernel. When it opens, make a cell that has %pip install flake8 pycodestyle_magic and run it. Then put %load_ext pycodestyle_magic as a cell and run that. You can now try the magic with code or pull the demo notebooks over and run those.
I'm using vegan 2.6.4 in RStudio, and have had an unusual error message pop up when I run the the following:
nmds11 = metaMDS(m_com11, distance = "bray")
data.scores11 = as.data.frame(scores(nmds11)$sites)
Error in UseMethod("scores") :
no applicable method for 'scores' applied to an object of class "c('metaMDS', 'monoMDS')
I can safely say this has never happened to me, and I was using the exact same code on a different dataset 5 minutes ago with no issues. I have also previously run this same script on at least a dozen other matrices with no errors.
I have tried calling scores.metaMDS as suggested when looking up the scores function (to help specify what type of object I'm trying to get scores from), but that function apparently does not exist. I've also tried running some old scripts that always worked in the past, with the same unfortunate results.
Any idea what I can do to address this?
Try using vegan::scores(); it could be that some other package you have loaded also has a scores() generic that is overwriting vegan::scores(). You can also try the much more specific vegan:::scores.metaMDS() if the whole S3 system has gotten clobbered.
Beyond that, restart R (in RStudio, find the Restart R option in the menus) so you get a clean session and try running your code again.
I I tried vegan:::scores.metaMDS() without restarting RStudio and it works ! Thanks !!!
When using dput (or dump) to share objects, I get output that is truncated very early. This also happens when dumping to a file.
I haven't been able to find the setting that governs this, but this didn't happen to me in the past and I'm not aware of having changed any settings. Unfortunately, I don't recall when exactly this started happening.
dput(rnorm(20))
c(0.178996565881475, -0.0979247582427519, -0.722093025014011,
0.88981201078104, 0.997508460579067, 0.416896899499781, 1.09045614607683,
...
I'm using Rstudio 1.1.442, I don't know if that is relevant. This setting in Rstudio does not affect the truncation of dput.
I must predicate this by saying that I am still quite new to RStudio/R so I hope this is not user error. However when debugging I am getting some strange results whilst in debug mode.
1) The code jumps to another part of the code without apparently being called.
2) When this happens the highlighter only partially highlights the code it jumps to but the arrow in the margin points to this partially highlighted line
3) The code then returns to place it jumped away from originally
I get the warning "Debug location is approximate because source source code is not available". Is this related to the problem?
You can replicate the results by installing the package dlm:
https://cran.r-project.org/web/packages/dlm/dlm.pdf
p<-3
G=diag(c(0.9963,0.9478,0.7740))
W=diag(c(0.0026^2,0.0027^2,0.0035^2))
C0_est=solve(diag(p)-G%*%t(G))*W
mod2<-dlm(m0=c(0.0501,-0.0251,-0.0116),C0=C0_est,FF=X,V=0.000000001*diag(m),GG=diag(c(0.9963,0.9478,0.7740)),W=diag(c(0.0026^2,0.0027^2,0.0035^2)))
debugonce(dlmForecast)
dlmForecast(mod2, nAhead=5, sampleNew=2)
When you step through using F10 you will find that the code jumps to L7 from Lines 28,32, 54 and 57 and to L4 from line 47.
Q1.) Why does this partial highlighting of the line being debugged mean?
Q2.) What causeses the code to jump backward and forwards like this with no apparent function call?
Kind Regards
Baz
Most R packages don't include copies of the package's source code (the keep.source option controls this behavior; you can read more about it here). When you debug code from this kind of package, RStudio has to guess at both what the code looked like originally and where the current execution point is in that code. This process includes some heuristics and does occasionally misinterpret the execution point. So what you're seeing is not the actual execution point jumping around, but RStudio making the wrong guess about where it is in the deparsed code.
Code from your own R scripts (and from packages with keep.source) have source references (see R journal article) which allow RStudio to line up the code and execution point precisely.
I wasn't able to reproduce this with your example (it appears to reference a variable m that it doesn't declare); if you can resolve that and send it to me (jonathan at rstudio dot com) I'll see if we can improve the heuristics so this case works better.
Today something happened (never had this problem before) when I start up Excel workbook where I use Rexcel.
And then there are some more errors... Everything worked properly before.. Does anyone have an idea about what the problem could be?
The other strange thing is that after that the Rapply and so on works.. But I get errors again when I close workbook.
So the problem appears when I startR from Rexcel meny in Excel.
EDIT:
Thanks to flodel for his answer. But is it not possible to run the Sub below now or?
Sub create_efficient_frontier()
RInterface.StartRServer
Sheets("Analys").Range("A52:K82").ClearContents
RInterface.PutDataframe "datat", Range("ChosenData!X181:AD352")
RInterface.PutArray "startdate", Range("Analys!K2")
RInterface.PutArray "enddate", Range("Analys!K3")
RInterface.RunRFile "C:/Users/Documents/EffFront.R"
RInterface.GetDataframe "hmz$pweight", Range("Analys!A51:E76")
End Sub
I get runtime error 13 ("incompatible types") at line
RInterface.GetDataframe "hmz$pweight", Range("Analys!A51:E76")
That worked yesterday, see Run macro with Rexcel
Solution:
Ctrl+Alt+Shift+F9 seems to work:)
Best Regards
Yes. I have struggled with this myself. Most likely your computations must be computed in a specific order. Typically, some of your (RApply, REval, etc.) calls create some data (e.g. x <- 10) in the R session and later calls will expect that data to exist: compute x^2.
Everything works fine when you build your spreadhseet from scratch. The problem is that when you save it and reopen it, Excel does not know in what order it needs to compute your cells: it figures out its dependency tree by firing out cell computations in a somewhat random order. So what happens is the cell supposed to compute x^2 might be run before the cell that creates x in your R environment, which triggers an error.
This is annoying but as you noticed, the errors do eventually go away after Excel is able to build its dependency tree. If you absolutely need to find a solution to that problem, it will have to involve VBA code to help Excel build its dependency tree in a very specific order.