I have a file where my ZSH functions are defined, and I source it from my zshrc.
There are the set of helper functions which used only in other functions from that file.
My question is how can I keep readable names for those helpers (such as 'ask', etc.) and be sure that they will not be overridden later in other sourced files.
So, for example I have two functions:
helper() {
# do something
}
function-i-want-to-use-in-shell() {
helper # call helper, I want to be sure that it is 'my' helper
# do something more
}
I want to protect helper for functions declared within that file.
It would be nice if I could wrap those functions in, for example, subshell () and then export function-i-want-to-use-in-shell to parent (I know this is impossible);
So I am looking for a convenient way to create something like their own scope for those functions, and make some of them global and some local.
[EDIT]
I think another example will give better explanation of the behaviour I want to achieve:
So, for second example I have two files: file1.sh and file2.sh.
file1.sh the same as example above, in file2.sh another function helper defined. I want you to understand that helper from file1.sh it's just function for local usage (within that file), just snippet of code. Later in shell I want only use function-i-want-to-use-in-shell from file1.sh and helper from file2.sh. I do not want helper readonly, I just want it for local usage only. Maybe I can do something like "namespace" for functions in file1.sh, or somehow achieve javascript-like scoping lookup behaviour in that file. The only way I see to do it now is to refuse the condition to keep good, readable, self-explaining names of my helper functions, and
give them names that are hardly to be invented by someone else, or use prefix for those functions. Oh, I just wanted to write something like if ask "question"; then but not if my-local-ask "question"; then in other my functions, and be sure that if someone (or I myself) will define later another function ask nothing will be broken
It's a little heavy-handed, but you can use an autoloaded function to, if not prevent overriding a function, "reset" it easily before calling. For example.
# Assumes that $func_dir is a directory in your fpath;
% echo 'print bar' > $func_dir/helper
% helper () { print 9; }
% helper
9
% unset -f helper
% autoload helper
% helper
bar
Related
I have some custom completion I've been working on and am stuck. It extends existing completion scripts with some custom options. The full file can be found here https://github.com/rothgar/k/blob/zsh-completion/completions/zsh/k
I have a custom function called __k_handle_kspace which looks at the current word and does a basic case statement and calls another function. (pasting code without comments and extra options here)
__k_handle_kspace() {
cur="${words[$CURRENT]}"
case $cur in
+* )
__k_kspace_parse_config_contexts
;;
#* )
__k_kspace_parse_config_clusters
esac
When I set compdef __k_handle_kspace k this works great and all tab completion is exactly what I want. The full __k_kspace_parse_config_* function can be found here
The completion by default uses __start_k which calls __k_handle_word which then calls my __k_handle_kspace function.
When I set compdef __start_k k I can see my functions being called (using set -x for debugging) and compadd being the last thing called but no tab completion is shown.
When I use the default completion I also have to change the cur variable to cur="${words[$(($CURRENT -1))]}" in my __k_handle_kspace function.
I cant figure out if there's a variable I need to set/return from my function or rules around when compadd can be called to return completion values.
The completion code you're extending is based on bashcompinit. As a result of this, you need to write your code as a Bash completion function. This means you should add your completion matches to the array COMPREPLY. Because that array is empty when your function returns, _bash_complete reports to Zsh's _main_complete that it has failed.
So, in short: Add your completion matches to COMPREPLY, instead of using compadd, and that should fix it.
I'm sourcing 2 files into my TCL script. Both having some variables with same name but different values. I've to use the both files and I can't modify them. How can i overcome this problem..?
The two ideas that come immediately to mind are to try namespaces or interpreters.
Separating Scripts with Namespaces
In this case, we're just doing:
namespace eval A {
source script-a.tcl
}
namespace eval B {
source script-b.tcl
}
It's not guaranteed that these won't conflict — they're not strongly separated — but they might work. It's definitely an easy first thing to try, and the variables and procedures created should be separated.
Separating Scripts with Interpreters
This method definitely walls scripts off from each other, but can be more awkward to work with since it also walls them off from the rest of your application (unless you provide appropriate cross-interp aliases):
interp create Acontext
interp eval Acontext {
source script-a.tcl
}
interp create Bcontext
interp eval Bcontext {
source script-b.tcl
}
As I noted above, this doesn't let the scripts see anything done by the main script by default; the walling off is pretty much total. To grant access to a command in the main interpreter, you need to make an alias:
proc mainContextOperation {callee args} {
puts "this is in the main context called from ${callee}: $args"
}
interp alias Acontext DoMyThing {} mainContextOperation Acontext
interp alias Bcontext DoMyThing {} mainContextOperation Bcontext
Make these aliases before you do the source calls (but after the interp create calls), and those scripts will be able to use the DoMyThing command to write a message out while the main context will have a really good idea what is going on.
Tcl uses this mechanism as a basis for safe interpreters, which are how you can evaluate untrusted Tcl code without exposing much ability to cause mischief.
I'm trying to package some code I use for data analysis so that other workers can use it. Currently, I'm stuck trying to write a simple function that imports data from a specific file type generated by a datalogger and trims it for use by other functions. Here's the code:
import<-function(filename,type="campbell",nprobes){
if (filename==TRUE){
if (type=="campbell"){
message("File import type is from Campbell CR1000")
flux.data<<-read.table(filename,sep=",",header=T,skip=1)
flux.data<<-flux.data[,-c(1,2)];flux.data<<-flux.data[-c(1,2),]
if (nprobes=="missing"){
nprobes<-32
}
flux.data<<-flux.data[,c(1:nprobes)]
flux.data.names<<-colnames(flux.data) #Saves column names
}
}
}
Ideally, the result would be a dataframe/matrix flux.data and a concomittant vector/list of the preserved column headers flux.data.names. The code runs and the function executes without errors, but the outputs aren't preserved. I usually use <<- to get around the function enclosure but its not working in this case - any suggestions?
I think the real problem is that I don't quite understand how enclosures work, despite a lot of reading... should I be using environment to assign environments within the function?
User joran answered my question in the comments above:
The critical issue was just in how the function was written: the conditional at the start (if filename==TRUE) was intended to see if filename was specified, and instead was checking to see if it literally equaled TRUE. The result was the conditional never being met, and no function output. Here's what fixed it:
import<-function(filename,type="campbell",nprobes){
if (exists(filename){
if (type=="campbell"){
#etc....
Another cool thing he pointed out was that I didn't need the <<- operator to utilize the function output and instead could write return(flux.data). This is a much more flexible approach, and helped me understand function enclosures a lot better.
One of the features of R that I've been working with lately (thanks R.cache) is the ability of functions to declare other functions. In particular, when one does this, one is able to have some variables be an inherent part of the resulting function.
For example:
functionBuilder <- function(wordToSay) {
function() {
print(wordToSay)
}
}
Can build a function like so:
functionToRun <- functionBuilder("hello nested world")
Then functionToRun() will result in "hello nested world". But if you just look at functionToRun (i.e., print it), you will see code that matches functionBuilder. What you will also see is that functionToRun has an environment. How can one access the value of wordToSay that is stored inside of functionToRun?
At first I tried:
get("wordToSay",env=functionToRun)
... but functionToRun isn't an environment and can't be transformed into an environment via as.environment. Similarly, because functionToRun isn't an environment, you can't attach to it or use with.
I found that environment was the accessor function to get and set environments, in an analgous way to how names gets and sets name attributes. Therefore, the code to get functionToRun's environment is environment(functionToRun) and therefore, we can access wordToSay with the line get("wordToSay",environment(functionToRun)).
I am new to Julia, so this might be trivial.
I have a function definition within a module that looks like (using URIParser):
function add!(graph::Graph,
subject::URI,
predicate::URI,
object::URI)
...
end
Outside of the module, I call:
add!(g, URIParser.URI("http://test.org/1"), URIParser.URI("http://test.org/2"), URIParser.URI("http://test.org/1"))
Which gives me this error:
ERROR: no method add!(Graph,URI,URI,URI)
in include at boot.jl:238
in include_from_node1 at loading.jl:114
at /Users/jbaran/src/RDF/src/RDF.jl:79
Weird. Because when I can see a matching signature:
julia> methods(RDF.add!)
# 4 methods for generic function "add!":
add!(graph::Graph,subject::URI,predicate::URI,object::Number) at /Users/jbaran/src/RDF/src/RDF.jl:29
add!(graph::Graph,subject::URI,predicate::URI,object::String) at /Users/jbaran/src/RDF/src/RDF.jl:36
add!(graph::Graph,subject::URI,predicate::URI,object::URI) at /Users/jbaran/src/RDF/src/RDF.jl:43
add!(graph::Graph,statement::Statement) at /Users/jbaran/src/RDF/src/RDF.jl:68
At first I thought it was my use of object::Union(...), but even when I define three functions with Number, String, and URI, I get this error.
Is there something obvious that I am missing? I am using Julia 0.2.1 x86_64-apple-darwin12.5.0, by the way.
Thanks,
Kim
This looks like you may be getting bit by the very slight difference between method extension and function shadowing.
Here's the short of it. When you write function add!(::Graph, ...); …; end;, Julia looks at just your local scope and sees if add! is defined. If it is, then it will extend that function with this new method signature. But if it's not already defined locally, then Julia creates a new local variable add! for that function.
As JMW's comment suggests, I bet that you have two independent add! functions. Base.add! and RDF.add!. In your RDF module, you're shadowing the definition of Base.add!. This is similar to how you can name a local variable pi = 3 without affecting the real Base.pi in other scopes. But in this case, you want to merge your methods with the Base.add! function and let multiple dispatch take care of the resolution.
There are two ways to get the method extension behavior:
Within your module RDF scope, say import Base: add!. This explicitly brings Base.add! into your local scope as add!, allowing method extension.
Explicitly define your methods as function Base.add!(graph::Graph, …). I like this form as it more explicitly documents your intentions to extend the Base function at the definition site.
This could definitely be better documented. There's a short reference to this in the Modules section, and there's currently a pull request that should be merged soon that will help.