I am trying to run a previously validated C mex file on a new system. It worked correctly, with no errors, in MATLAB R2014a on Mac OS X 10.8. I am now trying to get it to run in R2015a on Mac OS X 10.10.
At first it wouldn't run because it couldn't find the MPFR library which my C code requires, so I re-installed MPFR and re-compiled the mex file with an appropriate link. The mex file compiled without any errors or warnings, but it does not run. The program doesn't throw errors either - it just hangs. I cannot ctrl-C it either, I have to force quit MATLAB.
I generally try to post more specific questions, but to be honest I have no clue as to what the problem could be here. Thanks in advance for any help.
EDIT 7-12-15 at 12:15 AM EST
This question is NOT a duplicate of the one referenced by rayryeng. My code is not crashing or generating a segmentation fault (or any error at all), unlike the referenced case. Moreover, since the code ran correctly and stably (in my own hands) on the older machine, I suspect some kind of platform- or version-dependent issue rather than bad code that needs to be debugged.
Related
I have downloaded Scilab 6.1.1 and I'm trying to install the Mingw compiler that it's on the ATOMS section, specifically in Windows Tools, but the compiler is not detected and I don't know why.
I installed the compiler (the window of the installation says everything was correctly installed) and when I re-open scilab, it says
Mingw Compiler support for Scilab
Load macros
WARNING: MinGW Compiler not detected.
Load help
also I run the code
haveacompiler
but it returns as
haveacompiler
ans = F
I unistall everything, and tried everything from the top and it's the same. I don't know what to change or do because is my first time dealing with this kind of programs, and I don't want to do something that might affect my laptop.
pic of my scilab
p.s. I have Windows 10 Pro
I also had this scilab-compiler error and after some hacks i solved it. What to do:
get the value of windows-variable %%EQ_LIBRARY_PATH%%
Copy mingw-gcc into the folder denoted by %%EQ_LIBRARY_PATH%%
Deinstall Scilab completely and reinstall it or
install a new version.
Open scilab and install atoms(mingw)
Close scilab
Clear windows folder protection
Reopen scilab,perhaps on console
Now scilab compiles some libs needed to work with mingw
and xcos. On console one can see libs-compile
perhaps an easier way is possible. but i dont know it.
I like folder protection, so I reactivated it.
Good luck
"dos: Memory allocation error" occurs while loading 'mingw-0.9.3-0' on Scilab 5.5.2.
How can I get rid of these messages?
ATOMS (Scilab's Module Manager) prompted me to install MinGW because some Scilab demos are available only when gcc is installed.
My Machine is 64-bit Windows10 and my Scilab is also a 64-bit version, so I chose a 64-bit version of MinGW.
After that, I installed the interface between them through ATOMS, and restarted Scilab. Then, I got this message:
Startup execution:
loading initial environment
Mingw Compiler support for Scilab
Load macros
Warning !!!
Scilab has found a critical error (EXCEPTION_ACCESS_VIOLATION)
with "stacksize" function.
Save your data and restart Scilab.
Converting Libraries.
Build libblasplus.a
atomsLoad: An error occurred while loading 'mingw-0.9.3-0':
dos: Memory allocation error.
... I searched a solution and all I found is this thread:
https://atoms.scilab.org/toolboxes/mingw
Although their error messages (Undefined operation) are different from mine (Memory allocation error), this seems to be a bug which has not been fixed yet. Incidentally, I already started Scilab with "Run as Administrator" option and no luck. Is there any solution?
I'm also fighting with this problem for a while. Seems to be a incompatibility of the stacksize function on win10 machines.
This fix is working for me:
Find the mingw.start file, it is probably in the directory "scilab-5.5.2\contrib\mingw\0.9.3-0\etc".
Comment out the row #49 with the stacksize('max') order by placing "//" in front of the row
Start scilab, at the first run scilab builds up some libs with mingw so it needs more time than usual
Current Python Version 2.7.10 - I have tried a straight download from python.org and the Anaconda distribution.
Previous Python Version was 2.7.x (don't remember) - I know it was an Enthought Canopy distribution.
I just 'upgraded' windows from 7 to 10pro. I reinstalled everything on my computer for a fresh start. I installed the most recent version of Python 2.7.10. I am now running a script that I was running just yesterday on my Windows 7 OS, and it is running incomprehensibly slow now, and I have no idea why. It is a script that is based on the code from a tutorial found here:
http://pythonprogramming.net/sentiment-analysis-module-nltk-tutorial/
It has a lot of data that is loaded, and it wasn't running super fast before, but now it takes so long, it looks like it's frozen. Any thoughts? I thought that it had something to do with packages that I had installed on my previous Python environment, like a C-compiler or something. The output is nothing, because it just hangs for a long time and slowly moves through the script. It isn't broken, there isn't a loop it's stuck in. If I wait long enough, it will start showing me the correct output. When I hit 'Ctrl-C' this is what I get.
python -mcProfile MAIN_Tutorial_2.py
forrtl: error (200): program aborting due to control-C event
Image PC Routine Line Source
KERNELBASE.dll 00007FFB485B5674 Unknown Unknown Unknown
KERNEL32.DLL 00007FFB49412D92 Unknown Unknown Unknown
ntdll.dll 00007FFB4B819F64 Unknown Unknown Unknown
Don't think that helps, but just in case.
I've been struggling for a while with similar topic - long start up time of python scripts.
This is what I've found on python documentation site:
Why does Python sometimes take so long to start?
The problem may be caused by a misconfiguration of virus checking software on the problem machine. Some virus scanners have been known to introduce startup overhead of two orders of magnitude when the scanner is configured to monitor all reads from the filesystem. Try checking the configuration of virus scanning software on your systems to ensure that they are indeed configured identically. McAfee, when configured to scan all file system read activity, is a particular offender.
Unfortunately, I don't have a quick way to test whether disabling file system protection will help, so I hope it will solve your problem and will be glad to hear from you.
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help
I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.