I'm automating my build process, but I wasn't able to change the model_target_rtw folder to something different.
I'm not talking about CodegenFolder, but about the folder that's created inside it during compilation.
I'm currently working this around by renaming the folder after compilation, but it would be grate to remove that step.
The folder you are referring to is the RTW (Real Time Workshop) BuildDirectory.
You can get the value of BuildDirectory by running the command:
RTW.getBuildDir('MyModel')
See:
https://se.mathworks.com/matlabcentral/answers/274082-how-can-i-change-the-build-folder-of-a-model
Also look at this question:
Save generated code in a special folder in "rtwbuild"
If you run this command in MATLAB:
set_param(0, 'CodeGenFolder', 'C:\MyBuildDir')
and then run the RTW.getBuildDir command again you will see that the BuildDirectory has changed.
Related
I am working with Clingo for the first time and followed the given installation instructions using miniconda. I do have a working environment, but it only works in a single folder and I am not sure why. I am ultimately trying to get it to work in my local GitHub repository, but any file I try to run outside of a specific folder on my computer returns an error. Below is an screenshot; the first command was an attempt in a new folder while the second attempt is in the only folder that works.
I am investigating the best I can, but I am a novice. My best guess is the folder it works in is the only working directory. How to change my working directory I cannot find though.
I want to add a Run Script Phase to my Build Phases to call a swift executable that takes a plist file from my project and uses it to generate a swift file with some boilerplate code.
I figured out how to specify the input file for the Run Script Phase like this:
$(SRCROOT)/MyProject/MyData.plist
But for output files, Xcode gives me this $(DERIVED_FILE_DIR)/newOutputFile default value which, if I echo it via echo "$SCRIPT_OUTPUT_FILE_0", prints some strange path to the ....MyProject.build/DerivedSources folder. What is that? What do I do with this and how can I generate my output swift file and place it inside my project?
I don't really find much information about this $(DERIVED_FILE_DIR) (at least nothing that I understand, I've never worked with these things before).
Thanks!
Presumably the derived file directory is just a safe place to write output results to. It isn't in the project directory, but it is unique to the project.
However, you do want to write directly into the project directory (I presume), so just go ahead and do so, using the environmental variable PROJECT_DIR.
A little background
I'm working on a project that requires me to use an old (from 2006) large system of MatLab scripts. The script exists in an archive folder on a cluster but I need it to run fully from my cluster folder. I've got it mostly running from my personal folder but not entirely. It runs perfectly but there is a Python script that is called somewhere that doesn't exist in my personal directory.
What I want to do
Since the MatLab code I'm running includes many different script files, which themselves call even more script files, poring through them to find information about the Python script would be very very time consuming.
Therefore, I would like to be able to tell MatLab to not go to specific folders when calling a script, but instead, return an error. For example, if a scripted is called in the directory /notmyfolder, I want it to return an error.
Is this possible?
If I compile a script for distribution as a standalone exe, is there any way I can store settings within the exe itself, to save having to write to an external file? The main incentive for this is to save having to develop an installation process. I only need to store a few bytes.
Also, can resources such as images be compiled into the exe?
Using alternate data streams opens up a can of worms so i wouldn't go that way. Writing back config data into the exe itself won't work as the file is locked for write access during execution.
What i usually do is to store config data under %A_AppData%\%A_ScriptName%\%A_ScriptName%.ini
When the script starts i use IniRead which also provides a default value if the key isn't found - which is the case the script is executing for the first time.
The complementing IniWrite's in a OnExit subroutine/function will create the ini file if necessary.
This way no installation is needed and the config is stored in the proper, familiar place.
The autohotkey forum has dealt with this question before.
In that case, the user didn't want extra files -- period.
The method was to use the file system to save alternate data.
Unfortunately I can't find the post.
A simpler method is to use fileinstall command.
When the script is compiled, the external file is stored within the exe.
When the script executes the same command as an exe, the file is copied to the same
directory as the running script. It is a simple yet effective 'install'.
With a little testing for the config file, the fileinstall command can be skipped.
Skipping the fileinstall could allow changes to be made to the configuration after 'installation'
I have not tried saving settings within the compiled exe file, but I have included resources. I'm not sure which version of AHK you're using or how you are compiling, but I can right-click my scripts to compile. There's an option to compile with options, where you can include resources in your compiled exe.Compile with options
I want to run my working pydev project python code by double clicking the main module (outside of eclipse): xxx.py
The problem is that due to my imports being in different packages:
from src.apackage.amodule import obj
when xxx.py is double clicked it complains it doesn't know where the imports are (even though when I run xxx.py in pydev it magically knows what I'm importing).
A simple workaround is to remove all of the packages and move all of the modules into one directory (that obviously works but is very inconvenient)
How can I run my code in the file system without doing that work around?
This page answers my question excellently:
http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/
Bottom line is always execute your code from the top, highest level, root directory (e.g. using a minimal main.py file that executes the main script of your program). Then, use absolute imports always and you never have a missing module issue since you start the program from the top directory and all imports are based off that 'home' path.
The problem you encountered is the natural behavior of most languages. A programm only knows about its working path (the path it is started in), the paths which are registered in the environment variables and at least relative paths.
The "magic" of the executable you created is therefore: It collects all scripts/modules needed, and copies/combines them next to/in the executable. The Executable then runs within the directory where all other scripts also reside and voila ...
If you are not happy with your workaround of creating an executable every time you want to run your project without PyDev there are two alternatives.
First but not the one I would suggest is registering the working path into in the environment variables.
Second and the one I think is much better: Create a link to the python executable and alter the calling string of the textfield "Target:". Append the path to your script you would like to run. Then alter the textfield "Start in:" and enter the project directory. After you did this you should be able to start your project with a simple double click.
(If you rely on external libraries which are neither on the path nor in you project you could search for appending paths temporarily to the pythonpath via the sys module.)
I hope I could help a bit.