With respect to external libraries and File Exchange packages, I'm trying to make my MATLAB code more compatible with the multiple systems I run it on.
For example, let's say I want to run my code on two differently setup Windows systems. The function depends on an external library not located within the current work directory, but rather as shown below:
System 1
addpath('C:/SomeFolders/Git/3rdParty/Library')
System 2
addpath('B:/Git/3rdParty/Library')
The current working folder for both would be '.../Git/ProjectFolder'
Is there a way to have MATLAB navigate ("go-up/down") the folder hierarchy levels and search for the desired library?
Cheers,
Related
Now with Sublime Text 3 and a year on from an older question, I'd like to bring this up again.
Is it possible to setup a Sublime Text project with network paths to folder resources that can be used on Mac(OSX) and Windows platforms.
We have projects which are already created in a windows dominant environment. We are looking to have these working in OSX as well. At the moment a path for a project resource would be mapped to a windows network drive for example Z. The folder setup in the project would look like this:
"path" : "/Z/Custom/Project1"
If I was to create a network mount on OSX and drag the same folder in, it might look like this for Mac:
"path" : "/Volumes/ENV/Custom/Project1"
Is there a way to get this working for both platforms specifically using absolute network paths as the project files do not exist in the same location, so relative would not be a solution here.
Network paths are simply handled differently on Windows vs. OS X. A Windows path might look like:
//server/path/to/file
or, if the server is mounted as a drive:
/R/path/to/file
whereas on OS X all network shares are mounted through /Volumes:
/Volumes/server/path/to/file
As I see it, you have two options. The first is the most obvious: separate .sublime-project files for Windows and OS X. However, depending on the complexity of your projects, this option may take some effort to keep both files in sync.
The second option is to just have both paths in the "folders" section:
"folders":
[
{
"path": "/Z/Custom/Project1"
},
{
"path": "/Volumes/ENV/Custom/Project1"
}
],
You'll have two Project1 folders show up in the side bar, but only one will expand - Sublime gracefully handles the fact that one path doesn't exist. The major issue with this solution is that you may have other project-specific settings that are platform-dependent. For example, I use the Anaconda plugin for Python that provides code completion, linting, and other features. A couple of its settings require the path to the Python interpreter you wish to use for each project, and these paths can be platform-specific, especially if you are using virtual environments.
I suppose there is a third option as well: write a custom Sublime plugin that runs on startup to determine the platform, then generate a .sublime-project file with the platform-specific settings. That would be a non-trivial amount of work and wouldn't allow for multiple users to share the same project file simultaneously (you'd have to store the generated file locally). However, depending on your priorities, it may actually be the best option.
I have a go app which relies heavily on static resources like images and jars. I want to install that go executable in different platforms like linux, mac and windows.
I first thought of bundling the resources using https://github.com/jteeuwen/go-bindata, but since the files(~100) have size ~ 20MB or so, it takes a really long time to build the executable. I thought having a single executable is an easy way for people to download the executable and run it. But seems like that is not an effective way.
I then thought of writing a installation package for each of the platform like creating a .rpm or .deb packages? So these packages contain all the resources and puts it into some platform specific pre defined locations and the go executable can reference them. But the only thing is that I have to handle that in the go code. I have to see if it is windows then load the files from say c:\go-installs or if it is linux then load the files from say /usr/local/share/go-installs. I want the go code to be as platform agnostic as it can be.
Or is there some other strategy for this?
Thanks
Possibly does not qualify as real answer but still…
As to your point №2, one way to handle this is to exploit Go's way to do conditional compilation: you might create a set of files like res_linux.go, res_windows.go etc and put a set of the same variables in each, pointing to different locations, like
var InstallsPath = `C:\go-installs`
in res_windows.go and
var InstallsPath = `/usr/share/myapp`
in res_linux.go and so on. Then in the rest of the program just reference the res.InstallsPath variable and use the path/filepath package to construct full pathnames of actual resources.
Of course, another way to go is to do a runtime switch on runtime.GOOS variable—possibly in an init() function in one of the source files.
Pack everything in a zip archive and read your resource files from it using archive/zip. This way you'll have to distribute just two files—almost "xcopy deployment".
Note that while on Windows you could just have your executable extract the directory from the pathname of itself (os.Args[0]) and assume the resource file is located in the same directory, on POSIX platforms (GNU/Linux and *BSD etc) the resource file should still be located under /usr/share/myapp or a similar place dictated by FHS (or particular distro's rules), so some logic to locate that file will still be required.
All in all, if this is supposed to be a piece of FOSS, I'd go with the first variant to let the downstream packagers tweak the pathnames. If this is a proprietary (or just niche) software the second idea appears to be rather OK as you'll play the role of downstream packagers yourself.
I would like to create an installer for a library (DLL) that can be use in multiple system including MATLAB.
For MATLAB, I have additional *.m and *.mex files to make the DLL functions easily accessible from it.
I also have an installer that modify the PATH environment variable to make my DLL visible to all potential calling system.
My problem is that MATLAB does not make use of the system PATH environment variable. Thus, I am looking for a fix that would allow users of my library to run the installer and have my library accessible from MATLAB "out of the box" (possibly after a restart or session reopen).
I currently see 2 ways to do it which I both do not like :
Write a MATLAB script that uses addpath()/savepath() functions. I don't like this because :
a. MATLAB may not always be installed.
b. This would mess with the user's MATLAB's own path variable.
c. Upon installing a new version of my library, I would have to mess even more with the MATLAB's path to delete the path to older library before adding the path to the newer library.
Look through the system PATH and search for ...\MATLAB\RXXXXn\bin path to use that to install my *.m and *.mex files in the appropriate folder inside MATLAB. I don't like this because :
a. It would mess with MATLAB's own installation.
b. Once again, installation of multiple successive versions of the library may cause some issues (currently multiple version may be installed in separate directory, and the PATH redirects to the last one installed, experts users can modify the PATH according to their needs).
Currently, I am leaning towards option 2, but I am looking for a better, cleaner solution to this installation procedure.
Can anyone give me some MATLAB's expert advice ?
Thanks in advance for your help!
I did some basic research, and it seems that there is no one standard to create these. I saw a number of code project pages that had code for building such an exe, but no reference on how to identify one, nor if it possible to extract files without actually running the application.
So the questions are:
Is there a method I can use to identify if a particular file is a self extracting exe?
Are there a few formats that are extremely common in the computing industry
If so, do these formats allow for extraction without running the packaging exe?
If not, is there a method to run such a file in some sort of sandbox environment, allowing us to see the resulting files (on Windows)?
Note I'm open to both programmatic solutions or those using third party utilities/libraries.
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...