If yes, would I be able to check the values of the variables then? I am using Juno in atom.
Yes, there are a number of different debugging options available for Julia that allow you to set breakpoints, step into code, and inspect values of variables. If you're using Juno, you can check the Juno Debugging documentation here: http://docs.junolab.org/stable/man/debugging/
Regardless of IDE you can also debug using Debugger.jl.
Consider this code (from Debugger.jl README):
using Debugger
function foo(n)
x = n+1
((BigInt[1 1; 1 0])^x)[2,1]
end
Now you can debug this code using #enter macro in the following way:
julia> #enter foo(20)
In foo(n) at REPL[9]:1
1 function foo(n)
>2 x = n+1
3 ((BigInt[1 1; 1 0])^x)[2,1]
4 end
About to run: (+)(20, 1)
1|debug>
Pressing n key will move the execution to the next line and all other standard debugging options are available - for the details see https://github.com/JuliaDebug/Debugger.jl
Related
I am working on a julia code where I have several files and call functions from these files to a main function called run.jl. Every time I make changes to any one of these files I need to restart the julia REPL which is a bit annoying. Anyway to work around this.
For example
# --------------------------------- run.jl
include("agent_types.jl")
include("resc_funcs.jl")
using .AgentTypes: Cas, Resc
using .RescFuncs: update_rescuers_at_pma!, travel_to_loc
# ... some code
for i = 1:500
update_rescuers_at_pma!(model)
travel_to_loc(model)
end
# ------------------------------ resc_funcs.jl
function travel_to_loc(model)
println(get_resc_by_prop(model, :on_way_to_iz))
for resc_id in get_resc_by_prop(model,:on_way_to_iz)
push!(model[resc_id].dist_traject, model[resc_id].dist_to_agent) #This is just for checking purposes
model[resc_id].dist_to_agent -= model.dist_per_step
push!(model[resc_id].loc_traject, "on_way_to_iz")
end
#If we add new print statement here and execute run.jl it wont print
println(model[resc_id].loc_traject) #new amendment to code
end
But now when I go and update travel_to_loc function for example. I need to restart the julia repl before those changes are reflected. I am wondering if there is a way after you save the file (resc_funcs.jl in this case) those amendments are reflected when you execute run.jl.
The simplest workflow could be the following:
Select some folder to be your current working folder in Julia (eg. by using cd() command from Julia)
Create sample file MyMod.jl
module MyMod
export f1
function f1(x)
x+1
end
end
Add the current folder to LOAD_PATH and load Revise.jl
push!(LOAD_PATH, ".")
using Revise
Load the module and test it:
julia> using MyMod
[ Info: Precompiling MyMod [top-level]
julia> f1(3)
4
Try to edit the file eg. change x+1 to x+3
Run again
julia> f1(3)
6
Notes:
you will still need to restart REPL when your data structures change (you modify a definition of a struct object)
you could generate a full module package using Pkg.generate but I wanted to make things simplified.
I'm a new user of PARI/GP, and after writing my script, I wanted to make a graph of it. As my function take an integer and return a number, it's closer to a sequence. Actually, I didn't know how to do it, so I read the documentation of PARI/GP, and after that I made some test in order to obtain a graph from a list.
After reading an answer in stackoverflow (Plotting multiple lists in Pari), I wanted to test with the following code:
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
But when I do it, it tries to open something on latexit, but then it crash and give me a problem report.
I didn't even know that I had an app named latextit, maybe it was install during the installation of PARI/GP. Anyway, how can I fix this?
PARI/GP definitely doesn't install latexit.
The way hi-res graphics work on the Win32 version of PARI/GP is to write down an Enhanced Metafile (.EMF) in a temp directory and ask the system to
"open" it. When you installed latexit it probably created an association in the registry to let it open .EMF files
i3Pi does not mean what you think, it just creates a new variable with that name. You want i * 3 * Pi instead.
The following constructions both work in my setup
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 1);
(the second one being more readable because a red line is drawn between successive points; I have trouble seeing the few tiny blue dots)
Instead of apply, you can use a direct constructor as in
vector(201, i, cos((i-1) * 3 * Pi / 200))
which of course can be computed more efficiently as
real( powers(exp(3*I*Pi/200), 200) )
(of course, it doesn't matter here, but compare both commands at precision \p10000 or so ...)
To check the code quality of my package I am using the package lintr using the command
lintr::lint_package()
and get one result that I want to ignore:
functions should have cyclomatic complexity of less than 15
How can I ignore this single "false positive" lintr result of a single lintr (cyclocomp_linter)
for a file (line number range)?
Edit 1: Currently I am using this .lintr config file as a workaround (by disabling the lintr completely):
linters: with_defaults(
cyclocomp_linter = NULL # instead of NULL I could use: cyclocomp_linter(16)
)
Although it doesn't solve your problem exactly, you can wrap that function with # nolint start then # nolint end to prevent any linter from flagging that function.
The syntax for preventing a specific linter from flagging a specific set of lines is currently under development - see https://github.com/jimhester/lintr/pull/660 . This will be present in the next major lintr release (3.0.0).
function foo(x)
n = 0
t = time()
while n < x
n += 1
end
sec = time() - t
println("done in $sec seconds $(x / sec) operations/sec")
end
foo(1e7)
I'm on Windows using Atom latest version of everything. I run the above code and it prints fine for 1e1,..., 1e7
But for foo(1e8) and above, it prints the line, and then the line DISAPPEARS. I'm completely baffled by that.
It only happens in Atom (VS Code works fine). I use control-enter on the foo(1e8) line to evaluate it and I can see it printing the line and then the line erases by itself. For foo(1e7) and below, it prints fine.
Here's the video of this with 1e8 then 1e7 and it happens on Linux too. As you can see from one of the attempts the video was able to capture the printing and erasing (see at 5 second mark in the video). When I changed to 1e7, it prints fine every single time.
everything is up-to-date: Julia 1.4.1, Atom 1.46, Juno 0.8.1 and I did a complete Julia package update as well.
github.com/JunoLab/Juno.jl/issues/560.
(credit to pfitzseb )
Sometimes my Ipython notebooks crash because I left a print statement in a big loop or in a recursive function. The kernel shows busy and the stop button is usually unresponsive. Eventually Chrome asks me if I want to kill the page or wait.
Is there a way to limit the number of output lines in a given cell? Or any other way to avoid this problem?
You can suppress output using this command:
‘;’ at the end of a line
Perhaps create a condition in your loop to suppress output past a certain threshold.
For anyone else stumbling across:
If you want to see some of the output rather than suppress the output entirely, there is an extension called limit-output.
You'll have to follow the installation instructions for the extensions at the first link. Then I ran the following code to update the maximum number of characters output by each cell:
from notebook.services.config import ConfigManager
cm = ConfigManager().update('notebook', {'limit_output': 10})
Note: you'll need to run the block of code, then restart your notebook server entirely (not just the kernel) for the change to take effect.
Results on jupyter v4.0.6 running a Python 2.7.12 kernel
for i in range(0,100):
print i
0
1
2
3
4
limit_output extension: Maximum message size exceeded