I don’t think so. Looking in the source code, there doesn’t even seem to be an environment variable for this. It can possibly be done from within julia, but it would be a highly version dependent thing, forcing a change in the immutable structure Base.JLOptions() via some unsafe_... function. I wouldn’t recommend it.
let
field = findfirst(==(:warn_overwrite), fieldnames(Base.JLOptions))
offset = fieldoffset(Base.JLOptions, field)
type = fieldtype(Base.JLOptions, field)
jlopt = cglobal(:jl_options, type) + offset
unsafe_store!(jlopt, one(type))
end
If people are writing code using workflows you mentioned which require such a feature from a language, then they should clearly discuss with themselves whether or not they are interested in learning how to code safely and expect the result they are aiming for.
I cannot think of any serious developer who wishes for such a function overwrite feature, other than students who want to quickly produce results to show them to their professor and/or write a paper, in other words, use Julia similarly to MATLAB just to get some results for finishing their PhD, without anyone checking if the results they present are correct.
A language that adapts to wrong practices of inexperienced developers will end up with so many problems, that at some point the developers of the language themselves will be fed up with so many bug reports and support questions due to wrong/unsafe coding practices that rediscovering the wheel they will decide to remove once and for all language features that promote “probability theory” after compilation and execution.
AFAIK you can’t undo the command line options used to start a Julia session, you’d have to start another one, in which case making a alias for the command is as easy as it gets. Other tools may require you to write a file to customize the Julia command, like VSCode.
Please avoid insulting people here. It is expected to always show respect to people with different perspectives or people who made mistakes out of inexperience, just as the participants of this thread have shown you. If you would like to review this forum’s community standards, here is the link. In my experience, those guidelines are helpful for preventing discussions from devolving into spats that admins have to remove and reprimand.
It is very curious though that the op continues to insist on using poor code hygiene by abusing include, ignoring modules, employing unbound globals all while avoiding the compile caching mechanism that does exactly what the ops wants.
I am not insulting anyone other than myself. In fact if you have noticed I am the one here who adopted a wrong coding practice and lost 3 days of my life because of that. I am trying to say that we should help people avoiding such coding practices like mine (since I am inexperienced in Julia, but Julia did not warn me about this).
I rephrased in case you did not like that statement.
We are trying to explain that these warnings would be detrimental to healthy coding practices. So the correct way is to educate people about healthy coding practices and not changing fundamentals of the language. However you don’t seem willing to accept you should change the way you code with Julia, which is starting to become a bit tiresome. If you want to change that, we are happy to explain it to you and/or point you to resources where you can learn it.
Help me if I am wrong, but overwriting identical function definitions is a healthy coding practice? Sorry but I am confused to which healthy practices you are referring to. Would you please give me a link to read?
Watch your language. I have 40 years of experience in system, network, scientific and technical computing in C, Pascal, Simula, C++, Fortran, java, perl, R, python, verilog, whatnot, and a host of weird languages. And a PhD in math. And I find the experimentation possibilities of julia very good, redefining methods among them. Besides, my current employer isn’t particularly known for sloppy practices.
If you have so much experience, please explain me a single case where overwriting a function definition after including 2 scripts (like I did and lost 3 days of my life trying to find why the results do not change after editing the function that was overwritten) actually is a good practice.
Other than that experience in coding comes from rewriting the same code many times adopting practices that keep perfecting code design. Experience is not a fruit of learning too many languages. You may know only a single language (Fortran for example) and the code you write is more professional than anything out there.
Note that these workflows are not as unsafe as you make them. You chose to not use modules, used global variables etc. and that made it unsafe. With only slightly better code hygiene, you’d get the warnings you wanted as also @mkitti pointed out.
You can easily convert your script into executable “module” as follows. You will benefit from precompilation caching.
julia> write("HelloWorld.jl", """
module HelloWorld
function helloworld()
println("Hello World")
# Put "script" here
end
__init__() = helloworld()
end
""")
145
julia> push!(LOAD_PATH, pwd());
julia> using HelloWorld
[ Info: Precompiling HelloWorld [top-level]
Hello World
julia> HelloWorld.__init__()
Hello World
julia> HelloWorld.helloworld()
Hello World
One great benefit of this approach is that Julia will automatically warn you when you overwrite a function.
julia> write("HelloWorld.jl", """
module HelloWorld
function helloworld()
println("Hello World")
# Put "script" here
end
helloworld(x=5) = x^2
__init__() = helloworld()
end
""")
171
julia> push!(LOAD_PATH, pwd())
4-element Vector{String}:
"@"
"@v#.#"
"@stdlib"
"/home/mkitti/src/blah"
julia> using HelloWorld
[ Info: Precompiling HelloWorld [top-level]
WARNING: Method definition helloworld() in module HelloWorld at /home/mkitti/src/blah/HelloWorld.jl:2 overwritten at /home/mkitti/src/blah/HelloWorld.jl:6.
ERROR: Method overwriting is not permitted during Module precompilation. Use `__precompile__(false)` to opt-out of precompilation.
[ Info: Skipping precompilation since __precompile__(false). Importing HelloWorld [top-level].
Thank you for your constructive comments. You are really helping me become better. I have seen the module paradigm, but I did not use it yet, because I am constantly changing the code until I incorporate all the Julia “goodies” I would like it to have. Once I am satisfied I will definitely adopt your advice. Thank you again!
After a second thought, it might be better to use this style from the very beginning in order to avoid the problems we mentioned with overwriting until Julia realizes that this should be the default and not a hidden option. Thank you very much.
So, you sit there in julia. You have computed something which took an hour or so, during lunch. You’re doing science, so you’re not entirly certain how to process what has been computed. You try to define a postfun(x) = ... and run your post-processing step with this function. Doesn’t work. You try another function, and another. Find one which works as you want. Put it in your file. Done.
Rather than saving intermediate data to file, you keep them in a julia session to mess around with until you’re satisfied with how things work. Incrementally reaching a result by interacting with the REPL. When you’re satisfied, you have a program which works. Quite unlike writing whole programs with a edit-compile-run cycle.
I see your point, but even in that case I would like to make sure that I know which function is executed by calling that function inside my code and not by including scripts that implement this function with the same definition. It takes seconds to rename a function.
Note that you can then use the following workflow to re-run the script after making modifications.
julia> write("HelloWorld.jl", """
module HelloWorld
function helloworld()
println("Hello World")
# Put "script" here
end
__init__() = helloworld()
end
""")
145
julia> push!(LOAD_PATH, pwd());
julia> using Revise, HelloWorld
[ Info: Precompiling HelloWorld [top-level]
Hello World
# Edit the file with your favorite editor
julia> write("HelloWorld.jl", """
module HelloWorld
function helloworld()
println("¡Hola mundo!")
# Put "script" here
end
__init__() = helloworld()
end
""")
147
julia> HelloWorld.__init__() # re-execute the "script" after making changes
¡Hola mundo!
Also, you can also run the “module” like a script.
Ambiguous self-deprecation is also discouraged here. I’m sure you are capable of expressing your opinions without any personal judgments. I am not offended personally, and in this particular instance I do not think what you said alone could cause the discussion to devolve. However, other people might escalate due to misunderstandings or bad moods (and I would like to commend the participants here for showing patience instead), so even slight strays from decorum can snowball into ugly spats that admins have to stop. Debating ideas instead of judging people, and flagging personal hostility instead of retaliating (click … icon under a comment, then click the flag icon that shows), are probably the best guidelines for curbing that. You contributed a good thread and I’d like that to repeat smoothly in the future.
@Benny, if someone reads carefully he will realize that I am referring to general practices and not individual people. In fact I am referring to my “stupidity” that I included 2 scripts with the same function definitions. I have never done this in the past in C++ or Fortran because the code does not compile there. But Julia did not prevent me from doing so. I have a high appreciation for Julia and its masterminds. There are things in that language that are adorable. But under no means one should satisfy safety.
As I see it, Julia is a new Language created by younger people who ought to not repeat the mistakes for their fathers. But produce something way better than anything in the past. But protecting people and promoting safe code should have the highest priority. If not, what would be the result? It will be people doing mistakes like mine until they learn what pitfalls the language allows one to fall into.