When I create a class or a function file in octave. Is there a possibility to give the file a name that is different from the classes/functions name? (Class test is in the file test.m, but i would prefer to name the file for example test.class.m)
# test.m
classdef test
% ...
endclassdef
No. The way Octave is designed, classes and functions must be defined in files whose file names exactly match the class or function name. This is so that, given a function or class name, Octave knows where to locate its definition on disk, so it can lazily load in their definitions as they are needed by other source code, instead of having to load the entire source tree up front.
The exception is "command-line" functions, where you can define global functions inside a script, and their definition appears when the script is executed. This isn't a good way to organize code for larger projects, though, because you'd need to arrange for execution of all the scripts at the appropriate time, before those function definitions are needed.
If you want to distinguish classes from functions, you have the option of sticking them in subdirectories named #<class>, for example, #test/test.m.
Related
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.
Say for example you have a few different fish functions for scaffolding different types of projects, but within each you'd like to have a reusable block for running some git commands.
So you could create a separate function, and call it from the other functions, or you could take the separate function file, remove the function name -d "description" and end lines out of it, and then from the other functions just invoke it with source /path/to/partial.
So I'm wondering when a person should use one method instead of the other.
Using functions gives you a few advantages over sourcing a file:
You can tab-complete function names, and add custom completions to tab-complete their arguments
They can be modified using funced and funcsave
There's a standard place for them in ~/.config/fish/functions
They can be autoloaded.
The one advantage of sourcing a file is that it can introduce variables into the caller's scope. For example, set var value inside a sourced file will be scoped to the caller's function. (Of course you can make the variable explicitly global from a function or a sourced file: set -g var value).
I am new to Scheme.
I wrote a program that defines a function named "run", and I stored it as "Run.scm".
Then I have a "test.scm" file which uses this "run" function which I defined it inside "Run.scm".
I don't know how to include the "Run.scm" inside "test.scm" that I can use "run" function inside test file. Can anyone help me?
Compatible method
If you have a file with source code you can in any Scheme comforming program use load. So in your test you can do this:
% ls
test.scm Run.scm
Contents of test.scm
(load "Run.scm")
(run)
The new and better way (R6RS and later)
If you have a R6RS or a R7RS you have the ability to make a library. It is implementation specific how the library is incorporated into it but not how the source file looks. Read you documentation to how you add the library to your system.
Then, imagine you have made an awesome/utility.scm library. In R6rs/R7RS you would add it to your code like this:
(import (awesome utility))
;; start using the imported code..
(awesome-function '(1 2 3 4)) ; ==> (4 3 2 1)
Alternative by R5RS Schemes
Since R5RS and earlier just had load most implementations made their own way of loading both libraries and source files. eg. Racket has require and Chicken Scheme has import. To use these will lock you in with one supplier, but many libraries do it by building a implementation specific start file that import the other files in the special way to make out the differences between them or make a source file based on parts with gnu make or similar program.
I am trying to use SWIG to generate wrappers for some of my C++ function calls.
Also, I am trying to do build my own TCL shell so I need to static link the generated SWIG libraries. I have my own main function with a Tcl_AppInit call where I do some prior setup.
To do this what function should I include in my program's Tcl_AppInit call? I found that SWIG_init is not the right function. I even tried Cell_Init where cell is the name of the class in my code, but that doesn't help either.
How do I static link SWIG object files with my own main function and Tcl_Appinit call?
Currently when I use the following command to link my executabel I get the following error:
g++ -o bin/icde src/core/*.o src/read/*.o src/swig/*.o src/icde/*.o -ltk -ltcl
I get the following error:
src/icde/main.o: In function `AppInit(Tcl_Interp*)':
main.cpp:(.text+0xa9): undefined reference to `Cell_Init(Tcl_Interp*)'
collect2: ld returned 1 exit status
I checked the src/swig/cell.o file which has the Cell_Init function or not using objdump:
~> objdump -d src/swig/cell.o | grep Cell_Init
00006461 <Cell_Init>:
646c: 75 0a jne 6478 <Cell_Init+0x17>
I am not sure if I am doing something wrong while linking.
------------------- UPDATE ----------------------------
I found that including the swig/swig.cxx file directly in the main file which calls the Tcl_AppInit function resolves the linking issue. Is there a reason for this.
Isn't it possible to create and seprately link the swig file and the file with the main function?
In general, with SWIG you'll end up with a bunch of generated source files that you compile. The normal thing you do then is package them up into a shared library (with appropriate bound dependencies on other shared libraries) that can be imported into a Tcl runtime with the load command.
But you don't want that this time. Instead, you want the object files that you would use to make that shared lib, and you want to include them in the instructions to build an executable along with the object file that holds your main and Tcl_AppInit. You also need to make sure that when linking your main executable that you make it dependent on those external shared libraries; executable building requires that you satisfy all dependencies and make all symbols be bound to their definitions. (You can use a static library to make this easier: it combines a bunch of object files into one file. There's very little difference to just using the object files from it though; in particular, static libraries aren't bound to their dependencies.)
Finally, you do want to include a call to Cell_Init in your Tcl_AppInit. That's the right place to put it (well, as long as you're not arranging for the package to be loaded into sub-interpreters). If it was failing before, that was because you'd got your linking wrong. (Tip: linkers work best when objects and libraries on the link line only depend on things later on the link line. Getting the link order right is a bit of a black art when you've got a complex build!)
How can I put multiple functions in one file and later get access to all of them in the octave interpreter ? I don't want to have a thousand files and want to group functions together. I'd like something like 'import' in python.
Once you have saved all your function definitions in a single script file, use source("filename") to have access to these functions within the interpreter.
What you're looking for is called “script files”, defined there: http://www.gnu.org/software/octave/doc/interpreter/Script-Files.html