Is there currently a way in Deno to evaluate a value? If I had a long string with a compacted script, could I evaluate and initialize its logic into say a function? This would be helpful for more dynamic scripting. If an eval specifically isn't possible is there a preferred way? I don't want to have to use the CLI or pipe values into the program.
There is an eval() function available in Deno though I could not find it in the documentation.
Try this:
deno run "console.log(eval('1 + 1'))"
I believe it behaves like its JavaScript counterpart, and here is the TypeScript definition I could fine:
/**
* Evaluates JavaScript code and executes it.
* #param x A String value that contains valid JavaScript code.
*/
declare function eval(x: string): any;
Related
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
What can I do within a file "example.jl" to exit/return from a call to include() in the command line
julia> include("example.jl")
without existing julia itself. quit() will just terminate julia itself.
Edit: For me this would be useful while interactively developing code, for example to include a test file and return from the execution to the julia prompt when a certain condition is met or do only compile the tests I am currently working on without reorganizing the code to much.
I'm not quite sure what you're looking to do, but it sounds like you might be better off writing your code as a function, and use a return to exit. You could even call the function in the include.
Kristoffer will not love it, but
stop(text="Stop.") = throw(StopException(text))
struct StopException{T}
S::T
end
function Base.showerror(io::IO, ex::StopException, bt; backtrace=true)
Base.with_output_color(get(io, :color, false) ? :green : :nothing, io) do io
showerror(io, ex.S)
end
end
will give a nice, less alarming message than just throwing an error.
julia> stop("Stopped. Reason: Converged.")
ERROR: "Stopped. Reason: Converged."
Source: https://discourse.julialang.org/t/a-julia-equivalent-to-rs-stop/36568/12
You have a latent need for a debugging workflow in Julia. If you use Revise.jl and Rebugger.jl you can do exactly what you are asking for.
You can put in a breakpoint and step into code that is in an included file.
If you include a file from the julia prompt that you want tracked by Revise.jl, you need to use includet(.
The keyboard shortcuts in Rebugger let you iterate and inspect variables and modify code and rerun it from within an included file with real values.
Revise lets you reload functions and modules without needing to restart a julia session to pick up the changes.
https://timholy.github.io/Rebugger.jl/stable/
https://timholy.github.io/Revise.jl/stable/
The combination is very powerful and is described deeply by Tim Holy.
https://www.youtube.com/watch?v=SU0SmQnnGys
https://youtu.be/KuM0AGaN09s?t=515
Note that there are some limitations with Revise, such as it doesn't reset global variables, so if you are using some global count or something, it won't reset it for the next run through or when you go back into it. Also it isn't great with runtests.jl and the Test package. So as you develop with Revise, when you are done, you move it into your runtests.jl.
Also the Juno IDE (Atom + uber-juno package) has good support for code inspection and running line by line and the debugging has gotten some good support lately. I've used Rebugger from the julia prompt more than from the Juno IDE.
Hope that helps.
#DanielArndt is right.
It's just create a dummy function in your include file and put all the code inside (except other functions and variable declaration part that will be place before). So you can use return where you wish. The variables that only are used in the local context can stay inside dummy function. Then it's just call the new function in the end.
Suppose that the previous code is:
function func1(...)
....
end
function func2(...)
....
end
var1 = valor1
var2 = valor2
localVar = valor3
1st code part
# I want exit here!
2nd code part
Your code will look like this:
var1 = valor1
var2 = valor2
function func1(...)
....
end
function func2(...)
....
end
function dummy()
localVar = valor3
1st code part
return # it's the last running line!
2nd code part
end
dummy()
Other possibility is placing the top variables inside a function with a global prefix.
function dummy()
global var1 = valor1
global var2 = valor2
...
end
That global variables can be used inside auxiliary function (static scope) and outside in the REPL
Another variant only declares the variables and its posterior use is free
function dummy()
global var1, var2
...
end
I'd like to fancy up my embedding of Julia in a MATLAB mex function by hooking up Julia's STDIN, STDOUT, and STDERR to the MATLAB terminal. The documentation for redirect_std[in|out|err] says that the stream that I pass in as the argument needs to be a TTY or a Pipe (or a TcpSocket, which wouldn't seem to apply).
I know how I will define the right callbacks for each stream (basically, wrappers around calls to MATLAB's input and fprintf), but I'm not sure how to construct the required stream.
Pipe was renamed PipeEndpoint in https://github.com/JuliaLang/julia/pull/12739, but the corresponding documentation was not updated and PipeEndpoint is now considered internal. Even so, creating the pipe up front is still doable:
pipe = Pipe()
Base.link_pipe(pipe)
redirect_stdout(pipe.in)
#async while !eof(pipe)
data = readavailable(pipe)
# Pass data to whatever function handles display here
end
Furthermore, the no-argument version of these functions already create a pipe object, so the recommended way to do this would be:
(rd,wr) = redirect_stdout()
#async while !eof(rd)
data = readavailable(rd)
# Pass data to whatever function handles display here
end
Nevertheless, all of this is less clear than it could be, so I have created a pull request to clean up this API: https://github.com/JuliaLang/julia/pull/18253. Once that pull request is merged, the link_pipe call will become unnecessary and pipe can be passed directly into redirect_stdout. Further, the return value from the no-argument version will become a regular Pipe.
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.
In a RUnit test I have this snippet:
checkTrue(!file.exists(fname))
doSomething()
#cat(fname);print(file.info(fname))
checkTrue(file.exists(fname))
The second call to checkTrue() is failing, even though doSomething() creates a file. I've confirmed the file is there with the commented out line, shown above.
So, I'm wondering if the second call to file.exists is using cached data? In PHP there is a function called clearstatcache that stops this happening. Is there an R equivalent? (Or, perhaps, someone knows that R never caches results of stat calls?)
file.exists does not cache the result of the stat call, so there is no equivalent of PHP's clearstatcache. (Aside: that also means excessive use of calling file.exists, or any stat function, might degrade performance.)
As of R 3.0.1, file.exists uses an internal method. If you follow it through the source you will eventually end up with a call to R_FileExists, in sysutils.c:
Rboolean R_FileExists(const char *path)
{
struct stat sb;
return stat(R_ExpandFileName(path), &sb) == 0;
}
(On Windows it instead uses a call to _stat64 which I've just confirmed also does not do caching.)