guys,
I just finished a particular code in MATLAB R2014a that reads and write into multiple text files and saves an image inside the same folder of the script. The script runs perfectly, but the compilation executable does not, so I believe that it has something to do with the PATH that the executable is trying to use to run, I don't really know.
The error was the folllowing:
That's the second read function in the code that tries to read a file and it's possible to see that the code was already successful doing a read/write operation, since a .txt is created.
Just to keep it simple, I didn't use any global paths to the files and tried to keep them inside of the script and executable folder.
I don't have a lot of experience compiling stuff, so I just used deploytool and hit run to test it, so I would love to hear some insights about the possible cause of the problem.
Thank you in advance for the help!
MATLAB doesn't include every file on your PATH when it compiles. It tries to detect additional files that may be accessed when running the code in your application's main file, and include those in the compilation, but it isn't always 100% successful (I'm not sure exactly what conditions it's unable to detect).
After you have run the deploytool once, the full list of files it has detected in this way will be listed under Files required for your application to run. You can add files to this list (whether or not your project has already been compiled) using the "+" icon in the corner of that section.
Related
I have a .py file, defining a custom magic, in the /.ipython/profile_default/startup directory, but the intended magic is not being installed. Is there a way to determine where the fault lies? Where is execution failing? Other, very simple .py files in that directory are executing fine.
The short answer appears to be 'no,' there is no way to see what is happening during ipython startup...no log file keeping track of what is happening.
But I did solve my problem.
Opened a jupyter notebook. With the %load magic, copied the code for the custom magic into a cell. Copied the code into a code cell and ran it. Found I needed to install pySerial, and did so. Voila, custom magic now available. (Still have to find out if it works as intended.)
I've written a simple script that has multiple custom functions stored as modules. I have done it this way because I was always been told that if your function can be reused by other things then it should be a module and not a .\ source include. I'm starting to think that mantra isn't right in my current scenario. I am trying to convert the script to an single .exe so that I can install it as a windows service.
Probably should acknowledge that I understand why you wouldn't want to include system modules like Active Directory or IIS management for the obvious issue that could lead to but I'm only trying to include custom functions in a single disputable non editable way.
I have used PowerGUI in the past but can't find any valid exe's for that since DELL have removed it and from memory, I don't think I've ever used it with a module.
I've tried PS2EXE-GUI and PS2EXE. Both of these make the exe and everything works fine while the modules exist. However, as soon as I put the exe on a server that hasn't got the Modules deployed to it, it fails to run. I thought the compile followed all the dependencies and included them as part of the build into the single exe? That appears to not be the case.
I've also tried the PowerShell Studio 2018 by Sapien, but based on their forums you can't include modules into the complied exe. Which again feels wrong if they are actually just custom functions, but it's the way they've written it.
I see https://poshtools.com/docs/posh-pro-tools/merge-script/ would possibly do what I need but that's chargeable and it looks like it actually merges all the content back into a single file. Given the time pressure I'm starting to think I'll have to pay if there are really no other better options. I just don't have time to join everything together manually and I can't help thinking there is a better way I'm missing!
Can anybody please suggest other options?
Could I also get clarification around my original mantra (functions go in modules...)?
"No, never!" or "Yes, always!" or "It's just wrong in this scenario."
I am developing a windows stand alone application in MATLAB 2012b .
In the code I am writing some files in two folders images and dump which are both accessible to the user. I want those two folders to be in the same folder as the final executable. I can create those folders manually. However, when I run the compiled application, it does not seem to access those folders. For example, the following line of code works perfectly when run from inside MATLAB,
save(fullfile('./images/camp.mat'),'camp','-v7.3');
however it does not seem to work in GUI as it seems to stop working at that point only and nothing is created in the images folder.
I have searched through the internet and found things like ctfroot() and MCR_ROOT etc but I am not able to solve my problem.
I'm making a Lua game using the 2D framework 'LÖVE'.
I needed to know HOW to make a .exe file with it! I've done the command line, sucessfully zipped up my main.lua and the image, I've renamed the file extension to .exe!! When I run the .exe, I get a file extracting application coming up. This is not supposed to happen, right? I want it to be run as a game, not as a self-extracting application. Help?
From the sounds of it, you are trying to save your 'lovechive' with an .exe extension; your archiver is probably 'helpfully' assuming you meant to create a self extractor, which you didn't.
Okay, lets start by talking about how runable 'lovechives' work:
When love.exe starts up, it first checks its own name, if its called something other than love or love.exe it immediately checks to see if there is somethng stuck to its end. if there is, then it tries to interpret it as if it were a 'lovechive'.
So basically, we want to stick a zip-file to love's bottom (don't worry, it likes it).
Start by creating an ordinary zip archive of you game directory.
Remember to check for anything you don't actually mean to ship; plenty of love games have gone out containing backup copies of the source code, test artwork, and peoples' shopping lists. Don't be a statistic.
The filename is irrelevant for what were are doing here, so don't worry about the usual step of renaming it to a .love. just make sure that what you have is an plain-ol' ordinary zip.
The next step depends on your host platform, but basically you now need to do the whole "stick it to love's bottom' part now, generally this is done from the command-line:
On windows, the command is:
copy /b love.exe+YourGame.zip TheGame.exe
Where love.exe is the name of the main 'love' executable YourGame.zip is the name of zip file containing your game, and TheGame.exe is what you want the final game executable to be named.
On Linux or OSX, the command is:
cat love YourGame.zip > TheGame
Where love is the name of the main 'love' executable, YourGame.zip is the name of zip file containing your game, and TheGame is what you want the final game executable to be named.
These substituting the relevant filenames should let you produce versions for Linux, and Windows
(All I know about making 'merged' OSX Apps is that its more complicated.)
For the record, it is utterly trivial to extract files from the 'merged' game. Usually nothing more than changing the file extension, sometimes not even that.
And no, zip encryption doesn't help here; it won't run because love can't read the archive. (quite sensibly, really.)
Finally, If you are distributing to the Love community, they generally prefer that you just give them the 'lovechive.'
From https://love2d.org/wiki/Game_Distribution :
Here's how to do it on Windows. In a console, type this:
copy /b love.exe+game.love game.exe
Then, all you have to do is zip game.exe and required DLLs, and distribute them. Yes; this does mean that the game will have a private copy of LÖVE, but there's nothing wrong with that. It also means that you will have to create one package for each platform you would like to support, or simply offer the .love alone for the other platforms.
I'm attempting to profile my code using the iPhone simulator. I've enabled Generate Test Coverage File and Instrument Program Flow and added -lgcov to the linker flags. According to everything I've read that should be all I need to do in terms of setup.
Update: Generate Test Coverage File triggers the -ftest-coverage flag and Instrument Program Flow triggers the -fprofile-arcs flag. I've checked the build logs and they are being set when compiling.
Executing the program I can see the .gcno files appearing along side the .o compiled code in the build/.build/Debug-iphonesimulator/.build/Objects-normal/i386 directory.
But when I run the app in the simulator I do not get any *.gcda files appearing.
My understanding is that these files contain the data from the instrumentation. But I cannot find them anywhere on the computer.
I know they can be produced and appear along side the *.gcno files because I have an old trashed buil directory which does have them. I just cannot figure out what I have to do to get them to appear and record the run.
Any help appreciated.
I hope this link would give you some idea. Exploring the link I found
The .gcno file is generated when the
source file is compiled with the GCC
-ftest-coverage option. It contains information to reconstruct the basic
block graphs and assign source line
numbers to blocks.
The .gcda file is generated when a
program containing object files built
with the GCC -fprofile-arcs option is
executed. A separate .gcda file is
created for each object file compiled
with this option. It contains arc
transition counts, and some summary
information.
So may be you are building with some wrong settings. The information is mentioned on http://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html#Gcov-Data-Files
This link may have the answer, basically gcda files are not generated until your app exits properly. It gives two possible solutions:
completely quit the simulator
add this to your plist (but not for release builds):
<key>UIApplicationExitsOnSuspend</key>
<true/>