# Define the first two Fibonacci numbers
a, b = 0, 1
# Print the first two numbers
println(a)
println(b)
# Loop until the current number is greater than 50
while b <= 50
# Calculate the next Fibonacci number
c = a + b
# Print the current number
println(c)
# Update the previous values
a, b = b, c
end
LINUX MINT
The above program runs fine when pasted into Julia REPL, but when exiting
REPL and running the same file as .jl and using cmd -
‘julia julia_fibonacci.jl’ it throws the error:
(Warning: Assignment to ‘a’ and ‘b’ in soft scope are
ambiguous because global variables by the same names exist).
As I understand, this is due to the fact that when code is pasted
into the REPL, each line is executed immediately. When running
the same code in the terminal, the entire file is loaded and
compiled at once. I understand the error and some fixes - but
my QUESTION is - in the ‘real world’ where programs get more
complex and are actually used - isn’t running the .jl file in the
terminal a better test of the program? Is the REPL mainly a tool
for Julia programmers or maybe an actual environment that
might be packaged with and used in the final package / application?
The REPL actually have slightly different scoping rules, see Scope of Variables · The Julia Language. In Julia versions 1.0 - 1.4 the same rules applied also in the REPL, but people found it too annoying/strict for interactive use (which the REPL is used for).
Yes, nobody would code up a “real application” in the REPL. Instead you would put the code in a file, and you would use functions instead of running in global scope.
Note that even if you use the REPL to run your application the “strict” scoping rules apply:
shell> cat test.jl
s = 0
for i = 1:10
s += i
end
julia> include("test.jl")
ERROR: LoadError: UndefVarError: `s` not defined
Taking this topic further for my own education please.
(on Linux Mint) -
It doesn’t ultimately matter if a program works in REPL only.
It of course must run as a script in CLI - ie - as it would be in the wild.
My plot (for ex - parabola function) displays in REPL but does not
open backend to display when used with CLI - I’ve tried gr / plotly, etc
So I alter the program to generate a .png or .htlml file which is saved.
Again, isn’t this really how it would be done by a true developer? It
seems that the generated plot (as a file) would be preferable, if not
necessary, compared to REPL simply displaying it for a first check?
Executing code statement by statement in a REPL is indeed quite a different frontend compared to executing a full file – I don’t really understand what you are asking though.
The REPL displays the result from executing each prompt. Most stuff display as text (text/plain mime) but e.g. plots may display in different ways. If you want the plot saved you have to save it, whether you run in the REPL or execute a file (I don’t believe any plot packages save by default).
Actually, you did answer my question. Coming from C language, so new to using a REPL.
Appears that REPL is really for line by line checking of code. And it will display plot to show that code works. But real test is running the whole file in CLI. And I wanted to confirm that generating the plot by saving was normal procedure. Makes sense, really. Thanks!
I was thinking that your experience might be a Plots specific one. I have often used scripts to display plots on screen (and I consider myself a true developer ), but this requires a little bit of extra code as explained in Output · Plots
A couple of weeks have gone by and I have indeed starting using Pluto - I’m graphing and plotting and also using Latexify and learning Symbolics.jl - I guess I needed to get out of my terminal after all. I had been using Jupyter a bit, but I like Pluto’s dynamic adjustment - it sure makes everything a lot easier!
), but this requires a little bit of extra code as explained in