Suppose that I have 2 scripts:
magic_function.m:
function retval = magic(x)
retval = 12345678;
endfunction
other_script.m
#some code
X = magic(17)
What should I add to other_script.m in order to make function "magic" visible?
Judging by the documentation of Functions and Script Files, it should be sufficient to put the function in a file named magic.m in a directory specified in LOADPATH.
When Octave encounters an identifier that is undefined, it first looks
for variables or functions that are already compiled and currently
listed in its symbol table. If it fails to find a definition there, it
searches the list of directories specified by the built-in variable
LOADPATH for files ending in `.m' that have the same base name as the
undefined identifier.(4) Once Octave finds a file with a name that matches, the contents of the file are read. If it defines a single
function, it is compiled and executed.
Related
I'm writing a reusable function, so I need the argument to be as flexible as possible.
Consider a simple example:
function testf(){
print ./*.$1
}
This works. For example, with testf mp3 it lists all the files ending with .mp3 in an array, making possible the use of for loops. But this way it only allows me to work with the extension name.
Therefore, I tried:
function testf(){
print ./$1
}
However, it doesn't work. Using testf *.mp3, unlike using print *.mp3 in the terminal, it will only pass the first matching string instead of the whole array.
Any suggestion?
ists all the files ending with .mp3 in an array ... there is no array involved in your question.
But to your problem: First, you want to pass to your function a wildcard pattern, but this is not what you are actually doing. testf *.mp3 expands the pattern before the function is invoked (this process is called filename generation), and your testf gets just a list of files as parameters. You can pass a pattern, but you have to ask the shell not to expand it:
testf '*.mp3'
In this case, your $1 indeed will contain the string *.mp3. However, your print ./$1 will still not work. The reason is that filename generation occurs before parameter expansion (which is the process where $1 is replaced by the string it contains). Again, you have to ask the shell to do it the other way round:
print ./${~1}
The shell performs several types of expansions before launching the command. When you enter
testf *.mp3
the shell will expand the glob first, and pass each filename as a separate argument to the function
Your function could look like this:
function testf(){
printf './%s\n' "$#"
}
I have downloaded the "NYU Depth V2" dataset and toolbox from here. In the toolbox there is a script called get_synched_frames.m. I do not have Matlab, so I have tried running it in Octave. Unfortunately, it does not work as expected.
The line
% Faster than matlab's Dir function for big directories and slow
% distributed file systems...
files = regexp(ls(sceneDir), '(\s+|\n)', 'split');
gives only
files =
{
[1,1] = a-1300302776.479149-3987628315.dump
}
but ls(sceneDir) shows all files in the directory. Has anyone experienced this?
The difference is probably not in regexp, but in the return value of ls. ls does not behave the same way in Matlab and Octave when you capture its return value. Matlab's ls returns a char row vector (single string as char) with multiple files listed in it as a multi-line string with embedded newlines; Octave's ls returns a 2-D char array with one file per line. (IMHO Octave's format is better; it is very difficult to parse Matlab's ls output in a reliably correct manner. (That regexp code is not adequate.))
You might just want this in Octave:
files = cellstr(ls(sceneDir));
I am trying to convert some tcl script into a C++ program. I don't have much experience with tcl and am hoping someone could explain what some of the following things are actually doing in the tcl script:
1) set rtn [true_test_sfm $run_dir]
2) cd [glob $run_dir]
3) set pwd [pwd]
Is the first one just checking if true_test_sfm directory exists in run_dir?
Also, I am programming on a windows machine. Would the system function be the equivalent to exec statements in tcl? And if so how would I print the result of the system function call to stdout?
In Tcl, square brackets indicate "evaluate the code between the square brackets". The result of that evaluation is substituted for the entire square-bracketed expression. So, the first line invokes the function true_test_sfm with a single argument $run_dir; the result of that function call is then assigned to the variable rtn. Unfortunately, true_test_sfm is not a built-in Tcl function, which means it's user-defined, which means there's no way we can tell you what the effect of that function call will be based on the information you've provided here.
glob is a built-in Tcl function which takes a file pattern as an argument and then lists files that match that pattern. For example, if a directory contains files "foo", "bar" and "baz", glob b* would return a list of two files, "bar" and "baz". Therefore the second line is looking for any files that match the pattern given by $run_dir, then using the cd command (another Tcl built-in) to change to the directory found by glob. Probably $run_dir is not actually a file pattern, but an explicit file name (ie, no globbing characters like * or ? in the string), otherwise this code may break unexpectedly. On Windows, some combination of FindFirstFile/FindNextFile in C++ could be used as a substitute for glob in Tcl, and SetCurrentDirectory could substitute for cd.
pwd is another built-in Tcl function which returns the process current working directory as an absolute path. So the last line is querying the current working directory and saving the result in a variable named pwd. Here you could use GetCurrentDirectory as a substitute for pwd.
I have written a function, which does some search and replace on the file which I am editing. But for certain files (with some specific keyterms in the filename), I need to add some specific search and replace which is restricted to these files.
I need to know how to fix the following code:
function! Test()
" basic search and replace for all the files
%s/I'll /I will /ge
" if the filename starts with "blah-" the following additional search and replace needed otherwise not
if match(readfile(expand('%:t')),"^blah-")
%s/could'nt /could not /gec
endif
endfunc
And on calling the function :call Test() all these patterns will be executed. Hence, I do not need to worry about the specific instructions on certain file types.
Can anybody help me fixing this problem?
If there is no match -1 is returned from match(). Also, you probably don't need to call readfile() to check the filename. As such, change
if match(readfile(expand('%:t')),"^blah-")
...to...
if match(expand('%:t'), '^blah-') != -1
...and your blah-files (and only your blah-files) will have the extra substitution executed.
Say I have a tcl script and I want to pass some arguments to the second script file which is being sourced in the first tcl:
#first tcl file
source second.tcl
I want to control the flow of second.tcl from first.tcl and I read that tcl source does not accept arguments. I wonder how I can do then.
source does not accept any additional arguments. But you can use (global) variables to pass arguments, e.g.:
# first tcl file
set ::some_variable some_value
source second.tcl
The second TCL file can reference the variable, e.g.:
# second tcl file
puts $::some_variable
Remark:
Sourcing a file means that the content of the sourced script is executed in the current context. That means that the sourced script has access to all variables existing in that context. The above code is the same as:
# one joint tcl file
set ::some_variable some_value
puts $::some_variable
Regarding the "::" thing -- see the explanation here (sorry, I don't have enough rep. to leave comments yet).
I should also add that the original question discusses a problem which appears to be quite odd: it seems that it could be better to provide a specific procedure in your second source file that would set up a state pertaining to what is defined by that script.
Something like:
source file2.tcl
setup_state $foo $bar $baz
Making [source] behave differently based on some global variables looks too obscure to me. Of course you might have legitimate reasons to do this, but anyway...