I have a folder for Octave M-files in C:\\Users\Dropbox\Octave, under which are various subfolders by function categories (normal distribution, chisq...). I just started making those subfolders and they will keep changing (adding, removing, reshuffling) as time goes on.
I would just like to set that folder as root and have Octave search for functions recursively there, just like you set a classpath in Java and JVM searches all folders there.
I used addpath(genpath('C:\\Users\Dropbox\Octave')), but the paths generated are then fixed, not reflecting subsequent subfolder changes.
Shall I add addpath(genpath('C:\\Users\Dropbox\Octave')) to the .octaverc file?
I think there is some confusion here. There are several ways to interact with the path, but for the most part these do not result in permanent changes, unless you save this somehow.
Simply adding a path for an existing octave session will not result in any permanent changes to the usual path that octave initialises at startup. Therefore when you say:
I used addpath(genpath('C:\Users\Dropbox\Octave')), but the paths generated are then fixed, not reflecting subsequent subfolder changes.
this makes no sense, because as soon as you exit your octave session, those added paths should have been gone altogether, and not appear in later octave sessions.
It is more likely that at some point you added these paths, and then used the savepath command, which resulted in your custom paths being added to your .octaverc file.
If that is the case, then yes, you can expect that octave will not "update" what was written in your .octaverc file, unless you call savepath again with an updated path definition.
If you would like the addpath(genpath('C:\Users\Dropbox\Octave')) command you mentioned to be called every time octave starts, so that the current/updated directory structure is loaded, then yes, the best way to do it would be to add that command to your .octaverc file. Make sure you remove the lines in your .octaverc that refer to the previous changes made by savepath. Note that there may be several levels of octaverc files that you need to check (see the relevant page in the manual)
Alternatively, you could simply make sure that this line appears in every script you want to call which intends to make use of those files.
While you may consider this last approach tedious, programmatically it is the most recommended one, since it makes dependencies clear in your code. This is especially important if you ever plan to share your code (and doubly so if you'd like it to be matlab compatible).
PS. All the above mostly applies to matlab too, with the exception that a) matlab's savepath saves path information in a file called pathdef.m, rather than directly in your startup files, and b) matlab uses startup.m instead of .octaverc as startup files. Also, if you don't care about doing this programmatically, matlab provides pathtool, which is a graphical interface for adding / saving directories to the matlab path.
Related
Is there a symlink equivalent for IPFS's Mutable File System? For example, if I have a file:
/source/file.txt
and I copy it another folder:
ipfs files cp /source/file.txt /reference/file.txt
the two files will refer to the same object. If I make a change to /source/file.txt the copy in /reference/file.txt will still point to the old version. Is there a good way to make it point to the current version of the file in /source/?
I could keep track of all the copies and update them whenever I change the original, but that doesn't sound fun. I could also store the string "/source/file.txt" in /reference/file.txt and manually dereference each time I want to access the file. Better, but still cumbersome. Are there any other options?
For the time being, there is no support for symnlinks in MFS: you need to track and update them manually in userland. Current MFS implementation uses immutable identifiers (CID) and each directory's CID is based on hashes of its children, so storing string in a file sounds like the most optimal way, as it does not trigger DAG recalculation every time you update the target file.
In short: I am trying to load a csv file but the program always overwrites the existing file as an empty new file.
Longer: I am pretty new to Fortran, so bear with me. I am trying to read data from a csv file into a fortran program. Now I didn't write the program and it is pretty big, so I can't post the whole thing here. The program consists of a whole bunch of .f90 files and everything is compiled using a makefile. Now since I am loading the gcc module before compiling, I am assuming that it is compiled using GNU Fortran, because it is part of gcc. (idk how to find out if that is correct)
The compiler returns an executable in a different directory. When I execute the program in that directory it apparently overwrites the existing .csv file with a new blank one, so the program only reads "End of File". I don't know why it always creates a new file, how do I stop it from doing so?
As a side note, the csv file I am trying to read simply consists of a single column of floats, e.g.
"0.01, 0.13, 0.041,..." etc.
The code that I inserted into a subroutine of one of the .f90 files is the following:
real*8, dimension(nz) :: Nsq
integer :: i
open(10, file='Nsq.csv')
do i=1,20
read(10, *) Nsq(i)
enddo
close(10)
I have also tried to write a small test program, essentially running the same code as above. That one works just fine and outputs the contents of the csv file without any issues. For that one I use gfortran to compile it.
I have no experience in Fortran at all, so I am completely stumped, why this happens. I know the chances are slim that you guys can help me with this, since I can't provide the whole source code. But maybe someone has an idea why this occurs. Maybe you know an alternate way of reading csv files?
Thanks for your time.
The open-statement in Fortran OPEN(connect-spec-list), has a lot of connection specifications which define how an external file should be managed (see. Fortran 2018 Standard sec 12.5.6).
When you open a file using the simplest form of the open-statement:
OPEN(unit=unitid,file="filename")
A lot of default assumptions are made such as: ACCESS="SEQUENTIAL", ASYNCHRONOUS="NO", BLANK="NULL", .... The most important ones, however, are ACTION and STATUS which define the purpose of the file. The action specification states if you want to use the file for reading, writing or both, while the status essentially defines if we work on an existing file or not, and what we should do with it (replace it, keep it, ...)
Both these specifications have a default compiler dependent state.
In the Intel compiler suit, the default is action="readwrite", status="unknown" (see here and here)
Intel defines the status="unknown" as :Indicates the file may or may not exist. If the file does not exist, a new file is created and its status changes to 'OLD'.
The Gnu compiler suit has a different take on this. The default action is defined by a set of rules which depend on its accessibility if the file exists (+rw,+r-w,-r+w) (see here). The behaviour for the default action="unknown" is not documented but seems to be REWRITE (see Default Status of "Unknown" in Open)
It is advised to use a proper method if you know what you want to do with the file:
OPEN(newunit=unitid, file="filename", action="read", status="old")
In PhpStorm (as well as other JetBrains IDEs, I'm sure), I'm setting up a File Watcher. In the Watcher Settings section, it asks me to specify the path to the program to be executed.
I want to use the executable file within the node_modules/.bin directory of my project. I don't want it installed globally because I may have other projects that use the same program, but may require a different version.
I could simply specify the absolute path to my project's node_modules/.bin directory, but then if I move the project, the file watcher will break.
In the Arguments and Output paths to refresh fields just below the Program field, it allows you to insert a macro, like $Projectpath$. This is exactly what I need, but it doesn't look like the Program field allows that.
Is there a way to specify a relative path for the Program field?
Here is a screenshot of the File Watcher setup window:
I could simply specify the absolute path to my project's node_modules/.bin directory, but then if I move the project, the file watcher will break.
That's not true -- at very least it does not break anything here -- got 3 projects that use local stuff.
Is there a way to specify a relative path for the Program field?
Sure. Use full path to the program :)
Internally (in config file) it will be stored using $PROJECT_DIR$ (AFAIK) special macro/variable but in actual field (in that dialog window) you will always see full path. Such conversion is done automatically.
You can read a bit more here (in comments): https://youtrack.jetbrains.com/issue/WEB-24376
If you are using the same project on different computers ... where path to the same program will be different but outside of the project (e.g. stored inside user-specific folder and user logins/names are different on such computers) ... you could use Path Variables functionality (Settings/Preferences | Appearance & Behavior | Path Variables) and specify the same variable on all of such computers that would point to correct path on that computer. IDE will automatically use that path variable to store the path.
So .. on one computer MY_TOOL_PATH will be pointing to /Users/Joe/MyTool and on another it could be /Users/Sam/AnotherTool.
So I have an AIR app that runs an simple command-line program. The program basically takes in a file, decompresses it, and outputs the results. The only arguments I can give it are the input file, and it automatically outputs the results in the folder it's in. Naturally, I'm running the program using the NativeProcess class, which in turn needs a NativeProcessStartupInfo object to start.
Anyway, the NativeProcessStartupInfo's workingDirectory property is set to the folder of the file I'm going to put into the program, so that the decompressed results are put into that folder. However, the thing is that the program requires an additional file (a .dat) in the same directory as it to run. Which means that wherever workingDirectory is, that .dat needs to be there as well.
For the time being, I'm copying over the .dat and deleting it after the decompression is done. I was wondering though if there's a better way to do this? Is there a value in NativeProcess or NativeProcessStartupInfo that can help that I don't know about?
I'm currently looking for a way to add data to an already compiled ELF executable, i.e. embedding a file into the executable without recompiling it.
I could easily do that by using cat myexe mydata > myexe_with_mydata, but I couldn't access the data from the executable because I don't know the size of the original executable.
Does anyone have an idea of how I could implement this ? I thought of adding a section to the executable or using a special marker (0xBADBEEFC0FFEE for example) to detect the beginning of the data in the executable, but I do not know if there is a more beautiful way to do it.
Thanks in advance.
You could add the file to the elf file as a special section with objcopy(1):
objcopy --add-section sname=file oldelf newelf
will add the file to oldelf and write the results to newelf (oldelf won't be modified)
You can then use libbfd to read the elf file and extract the section by name, or just roll your own code that reads the section table and finds you section. Make sure to use a section name that doesn't collide with anything the system is expecting -- as long as your name doesn't start with a ., you should be fine.
I've created a small library called elfdataembed which provides a simple interface for extracting/referencing sections embedded using objcopy. This allows you to pass the offset/size to another tool, or reference it directly from the runtime using file descriptors. Hopefully this will help someone in the future.
It's worth mentioning this approach is more efficient than compiling to a symbol, as it allows external tools to reference the data without needing to be extracted, and it also doesn't require the entire binary to be loaded into memory in order to extract/reference it.