How to add load libraries, change directory, etc. on startup? - modelica

Is there a way to automatically load libraries, change to a certain working directory, etc. when launching Dymola?

The question is slightly ambiguous - the other answer is quite good for one scenario. (The openModel call in Step 2 can be modified.)
However, if you always want to launch Dymola in a specific directory etc it is possible using the GUI. How depends on version.
Dymola 2020 x (and later)
Allows changing start-up directory through File>Working Directory
And has Tools>Library Management>Modelica Path where you can add the directory containing your external libraries.
To make libraries appear preloaded you have to add a libraryInfo.mos script in the corresponding library; you can look at Modelica Standard Library in the Dymola installation for inspiration.
The latter is described in more detail in the section "More about libraries and the building of menus of libraries and demo" (somewhere in the User Manual).
Dymola 2017 FD01 (and slightly differently from Dymola 2016 FD01):
Change Directory (File>Change Directory)
Add to Modelica Path (File>Modelica Path)
Save those settings (Edit>Options>Settings: Select Startup and Modelica Path)
If you want to "preload" libraries there are some options:
In a startup script you can use import MyPackage; or openModel("...\\MyPackage.mo"); alternatively if you are administrator you could modify Dymola/insert/dymodraw.ini and add a line: Dymola5LibraryMenu "MyPackage" (technically it doesn't "load" - it just shows the library in the package browser).
An important difference is that changing dymodraw.ini keeps the library "loaded" even after "Clear All".

In recent years there are two options that might help you.
File>Library Management>Install This dialog allows you to open a
zip-file or something similar of a distributed library, install it,
update MODELICAPATH to find it again, and even update the File>Libraries
menu to include it for future use. All in one operation.
Simulation>Edit startup.mos If you prefer to edit the startup
script, this is the convenient way to find it end open it for
editing.

Here is a procedure which allows to load a set of libraries with one click.
It makes use of the fact that the dymola.exe can be started with a .mos script as first argument.
It is designed for situations such as
You are using Windows
You are working on one or more projects
Where every project requires a set of libraries to be loaded
Every project uses it's own working directory
Other users might collaborate, so they need the very same setup
Requirements
The setup is a bit of work the first time, but very quickly done for further projects. You need:
a start.mos file in your library
the environment variables DYMOLA_WD and MODELICA_LIBS
(This is only required to allow other users to use different paths for their libraries and working directories)
a file short-cut to dymola.exe
This is how start.mos looks like for a specific project (usually you only change the first two lines):
// user setup
libs = {"Buildings 6.0.0", "PhotoVoltaics", "MyProject"}
wd = "myproject"
// open all libs
lib_dir = Modelica.Utilities.System.getEnvironmentVariable("MODELICA_LIBS");
lib_dir = Modelica.Utilities.Strings.replace(lib_dir, "\\", "/")
for l in libs loop
openModel(lib_dir + "/" + l + "/package.mo");
end for;
// change to wd
wd = Modelica.Utilities.System.getEnvironmentVariable("DYMOLA_WD") + "/" + wd;
wd = Modelica.Utilities.Strings.replace(wd, "\\", "/")
Modelica.Utilities.Files.createDirectory(wd)
cd(wd)
Now you create a shortcut to dymola.exe in the windows file explorer. In the field Target you set
"C:\Program Files\Dymola 2020\bin64\Dymola.exe" "%MODELICA_LIBS%\MyProject\Resources\scripts\start.mos"
Example
Assuming a user has set the environment variables
MODELICA_LIBS = E:\modelica
DYMOLA_WD = E:\dymola_wds
the folder structure on the users hard disk must look as follows for the script above to work:
E:\modelica
|- Buildings 6.0.0
|- package.mo
|- ...
|- PhotoVoltaics
|- package.mo
|- ...
|- MyProject
|- package.mo
|- ...
|- Resources
| |- scripts
| |- start.mos
|- ...
Now the dymola.exe-shortcut is used to start Dymola, which will automatically load the required libraries for the project and change the working directory.
For another project a new shortcut is required, along with a new start.mos script.

This method has been tested for Dymola 2017FD01. Prior versions used a different method via a setup.mos script that is no longer available. As of this posting, there is no option to perform this actions via the Dymola GUI.
It can be easily accomplished via a .mos file with the steps shown below:
Create a .mos file in a location that makes sense. For example, C:\Users\USERNAME\Documents\Dymola\startup.mos
Add the actions desired to .mos file. For example, to load a library add openModel("C:\\Users\\USERNAME\\Documents\\ModelicaLibrary\\package.mo");
Dymola always puts its auto-generated files in the current working directory. It's often a good idea to have that location be the same location so there is no need to hunt down the location of output files. Therefore, at the end of the .mos file change the current directory: cd("C:\\Users\\USERNAME\\Documents\\Dymola");
If no shortcut exists to the Dymola.exe file, then create one.
Right click the shortcut and go to Properties. Under Shortcut>Target append "C:\Users\USERNAME\Documents\Dymola\startup.mos"at the end. The contents of that cell should now look something like this: "C:\Program Files (x86)\Dymola 2017 FD01\bin64\Dymola.exe" "C:\Users\vmg\Documents\Dymola\startup.mos"
That's it. When Dymola is launched from that shortcut the actions specified in the .mos file should be carried out.

Another suggestion where you don't need to hardcode your package into an environment variable of your operating system (and maybe more safe for inexperienced programmers):
Go to the folder where Dymola is installed (e.g. C:\Program Files\Dymola 2020).
Search for the Dymola.mos file in the insert-folder. 'insert' folder
Open the script (e.g., in notepad++)
Add the link(s) to your Dymola-library-package.mo file(s) here with the openModel statement
e.g., openModel("C:/IDEAS/package.mo"); Dymola.mos script
Save the script. Now, every time you open Dymola, your libraries will be loaded automatically.

Related

opening vscode to latest directory in specified path

Is it possible to have vscode automatically open the newest folder within a specific path?
For example, with this configuration:
{
"folders": [
{
"path": "\\\\FromABC\\Archive",
"name":"From ABC"
},
{
"path": "\\\\FromXYZ\\Archive",
"name":"From XYZ"
}
]
}
I would expect these folders in the workspace to be pointing to \07\07 because those were created today:
\\\\FromABC\\Archive\\2021\\07\\07
\\\\FromXYZ\\Archive\\2021\\07\\07
Is it possible to create a workspace where the folders are opened to the latest folder within each configured path?
There's not enough information in the original question to fully answer it, however, I can suggest a few avenues of attack
Custom Command (error-prone and picky)
Modify Upstream Process (likely the best overall)
Combining Both (perhaps the best for your immediate case)
Creating a Custom Command
Create a new command per https://code.visualstudio.com/api/extension-guides/command#creating-new-commands
VSCode Commands Listing: https://code.visualstudio.com/api/references/commands
new command
detect latest folder through whatever logic you like
call vscode.openFolder to navigate to it
call your custom command through Activation Events (activationEvents) at either onStartupFinished or * (Start Up; less-preferable, but may be required to avoid confusing the editor)
https://code.visualstudio.com/api/references/activation-events#Start-up
Check out Start app when opening project in VS Code? for a few answers related to this
Modifying the Upstream Process
Cutting the gordian knot, it's likely some process (perhaps a human) is creating the directories for you
Change the upstream process so when it creates the directories, it also creates/updates a link to the directory labeled something like latest
/FromABC/Archive/2021/06/03
/FromABC/Archive/2021/07/05
/FromABC/Archive/2021/07/07
/FromABC/Archive/latest --> /FromABC/Archive/2021/07/07
/FromXYZ/Archive/2020/04/12
/FromXYZ/Archive/2021/08/18
/FromXYZ/Archive/latest --> /FromXYZ/Archive/2021/08/18
Then you can always refer to the latest directory and it will always be correct
This is quite common when something can change frequently, but another process is expecting a static path and/or has no way to know the schedule of change
I don't have any Windows systems to try this out with and you may be able to create a regular shortcut for this .. however, you may need a Junction (soft-link) or Hard Link to convince VSCode that the directory is a real directory
https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
This also provides an opportunity to include more files, such a beta versions of some software, which it's desirable to package into the same directory structure, but not truly the latest stable!
Combining Both
If your upstream process is either not modifiable (or some manual process it's annoying or error-prone to add extras steps to) you can likely combine both solutions to get what you really want
Use the * Action Event to call a script to detect and create the new directory - create a binary or PowerShell script to make your link
In this and with the upstream change, just point VS Code to the latest directory and it shouldn't mind
Not sure on which platform you are, I assume windows, but essentially similar.
Instead of trying to get VSCode to open the latest folder, I would create a script that updates a softlink for each folder to the latest subfolder in it. Then you can point VSCode to the softlink, which can be updated whenever needed to the latest subfolders.

Netbeans, phpdocumentor, and custom phpdoc.dist.xml by project

I am using Netbeans 8.0.2 and phpdocumentor 2.8.2 on a windows 7 platform.
I would like to use custom phpdoc.dist.xml config files by project so I can specify framework directories and etc. to exclude from the generated doc. I also want to keep my Netbeans PHPDOC plugin config as generic as possible, without specific output directories, ignore options, config path parameters, etc., so on, so that that the config will apply to all my projects.
The phpdoc.dist.xml file works great. The doc generated is exactly what I want.
The problem or feature, and it seems to be a phpdocumentor one as it also applies from plain command line, is that the phpdoc.bat command (without a specific config parm) has to be run from the same root directory as the phpdoc.dist.xml file, or it ignores it. No problem if I'm using command line as I can change into that directory first, but I would like to use Netbeans. I have searched on this extensively and cannot find an answer.
I considered whether to modify the phpdocumentor files to insert cd /D path/to/myproject/dir to change the directory using some Netbeans variable to represent myproject/dir, but I could not find the right place in the code or the variable to use. Plus, then I'm supporting a custom mod to phpdocumentor.
I did find these directions for a PHPStorm setup, where the author specified a PHPStorm variable for the --config command line option to point to his custom phpdoc.dist.xml.
--config="$ProjectFileDir$/phpdoc.dist.xml"
If I could do the same in Netbeans like maybe "${BASE_DIR}/phpdoc.dist.xml" it would be great, but so far I haven't hit on anything Netbeans will recognize/pay attention to in the PhpDoc script: box.
I have also tried writing a wrapper .bat file to capture my own command line variable %1 and do the directory change to that before calling phpdoc.bat, but Netbeans throws and error and says that's not a valid .bat file. I cannot find any phpdocumentor parameter to configure by specific Netbeans project but the output directory. And I would prefer not to be defining a bunch of projects on subdirectories in Netbeans, just to address phpdocumentor.
Now I am out of ideas. Can anyone point me to a solution?

Run node-webkit project in Netbeans 7.4

I am trying to configure Netbeans IDE 7.4 for node-webkit development.
It is excellent IDE but I want to run my projects with F6 button. To do this I added NW.EXE as additional browser (executable is located outside project folder).
After this I have a problem with execution arguments. NW.EXE expects a folder path to be specified as an argument, but I cannot leave empty field of Start File in project settings and the Project URL has to start with either http:// or file:// while Node-webkit needs a path like C:/path_to_app
Does any method exist to deal with this feature?
In short, you can work this around by creating a batch program and let it strip the file name down to the path name part, to be fed to nw.exe, as it requires.
Unfortunately, as you said, we don't have full control over the way the main file of the project is passed to the browser, hence some further actions (in addition to the creation of the batch file) are needed.
This is how I got it working after a bit of struggle:
added nw.exe to the system %PATH% variable (optional, just for ease of access)
created nw.bat in the same folder as nw.exe, and filled it with this content:
#echo %1
start nw.exe %~d1%~p1
The first line of this batch file is just to inspect the actual parameter that is getting passed to the batch file.
The second line uses start to invoke nw.exe without having to wait for its return (you may need to specify the full path to nw.exe, if you didn't add it to the system %PATH% variable).
The second line also passes to nw.exe the drive part of the parameter (extracted from %1 by %~d1) concatenating it to the path of the parameter (extracted from %1 by %~p1).
For instance, my last run from within NetBeans gave this output:
D:\node\test\index.html
D:\node\test>start nw.exe D:\node\test\
Then I needed something to tie the NetBeans run button to an arbitrary executable, and luckily I found a perfect fit.
So here is how I went on:
installed the Node.js Projects plugin from Timboudreau Update Center
went to Options > Miscellaneous > Node.js and set the Node.js Binary field to point to my nw.bat file
In my project, I've also taken care to put package.json in the same folder of index.html (being that that's the main file of my package, and that's what will be fed to the batch file).
Now pressing F6 on my NetBeans installation happily runs my node-webkit project without any further ado :-)

run pydev project from file-system (with imports from different packages)

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.

How do I "source" something in my .vimrc file?

I've been working on expanding my vim-foo lately and I've run across a couple of plugins (autotag.vim for example) that require them to be "sourced" in my .vimrc file. What exactly does this mean and how do I do it?
Sourcing a file is 'executing' it. Essentially, each line of the file is considered a command. Sourcing it is the same as typing each command in order. You source with the command :source (usually shortened to :so).
So if you source myStuff.vim
:so myStuff.vim
and if myStuff.vim contained these lines
set xx iI just intersted this<C-]>
set yy bbbb4dw
It's the same as if you typed those commands into Vim
:set xx iI just intersted this<C-]>
:set yy bbbb4dw
The only file sourced by default is the .vimrc(_vimrc on windows) so that's a place you can keep all the commands you use to set up Vim every time.
Where it gets interesting is the fact that since a sourced file is just a series of commands, and sourcing is a command, you can source files from your source files. So plugins you use every time could be sourced when you start up Vim by adding a line to your .vimrc like this
so myPlugin.vim
Files in your .vim/plugin directory are sourced (loaded) automatically.
There is always the :source file command. I usually write .vimrc that contains custom commands and what not for the console application and then a .gvimrc that contains additional goodies that are appropriate for a windowed version. My .gvimrc starts with source $HOME/.vimrc to pick up everything from the console version before adding in new stuff.
There are normally two vimrc files, one is _vimrc and the other _gvimrc (in the first one are the things for vim, and in the second for gvim - graphical things) - although most people I know just put everything in _vimrc.
A good practice is to keep all your extra files (plugins, colorschemes, snippets ...) in a separate (your own) vimfiles directory (which you can take with you).
If you do
:help vimfiles
vim will tell your vimfiles directory should be located. It depends somewhat on the platform (win, unix). On windows the usual is in your user folder (documents and settings, then user ...).
In vimfiles directory there are a couple of subdirectories. Amongst them is the "plugin" subdirectory. Plugins put in that dir will be loaded automatically (also plugins put in subdirectories of "plugin").
If you do not wish to load it automatically, just put it in your "vimfiles", or some other directory, and
:so plugin_name.vim (with the appropriate path)
(you can use the $vim, $vimfiles, and $home as shortcuts when defining path to plugin)