Getting a long list of warnings when "using" a package a second time

New to Julia
,
1

I get a long list of warnings when I load a package a second time. Is this normal? Or should I change my workflow? (I think I am doing something wrong, but I am not sure). A minimal working example is

julia> using DualNumbers
julia> workspace()
julia> using DualNumbers
WARNING: Method definition ntuple(F, Main.Base.Val{N}) in module Compat at /Users/UCIben/.julia/v0.6/Compat/src/Compat.jl:463 overwritten in module Compat at /Users/UCIben/.julia/v0.6/Compat/src/Compat.jl:463.
WARNING: Method definition spdiagm(Main.Base.Pair{A, B} where B where A...) in module Compat at /Users/UCIben/.julia/v0.6/Compat/src/Compat.jl:960 overwritten in module Compat at /Users/UCIben/.julia/v0.6/Compat/src/Compat.jl:960.
WARNING: Method definition #squeeze(Array{Any, 1}, typeof(Main.Base.squeeze), Any) in module Compat overwritten in module Compat.
WARNING: Method definition #replace(Array{Any, 1}, typeof(Main.Base.replace), AbstractString, Main.Base.Pair{A, B} where B where A) in module Compat overwritten in module Compat.
(And many more warnings...)

Below is my current workflow, which causes all the warnings:

  1. I wrote a bunch of functions in a module (let’s call it MyModule) and MyModule happens to need dual numbers, so that it contains a line that says
using DualNumbers

Is that the correct way to go? I.e., should one write modules that call another module inside of them?

  1. I then usually edit some functions in MyModule, say the function f(x), and want to run some tests on it (e.g., what is the value of f(1)), so I type something like this in the command-line julia:
julia> using MyModule
julia> f(1)
  1. Then, I edit f(x) a bit more in MyModule, and test it again, by typing:
julia> workspace()
julia> using MyModule
julia> f(1)

which results in the long list of warnings…

2

In 0.7 workspace is removed. The warnings are also removed…

3

I’ve found workspace() to be very unreliable for this and other reasons. I much prefer using Revise.jl: https://github.com/timholy/Revise.jl for live-editing modules.

4 Likes
4

This bring next questions:

  1. How long do you plan to support 0.6.x?

  2. Do you have some serious support plan for Julia after 1.0?

  3. What will be solution for briochemc’s problem? revise.jl will be part of std lib in 0.7?

5

Im not sure about 1 and don’t know what questions 2 means.

Revise is not an stdlib but is the solution to hotloading new code.

6

Sometimes, I think it’s best to not use a package a second time.

It gives you the opportunity to try other packages.

- Ken M

1 Like
7

:slight_smile: Well! It is simple - if language wants to be used seriously in industry it needs to do something like python do:

3.7 Lifespan

3.7 will receive bugfix updates approximately every 3-6 months for approximately 18 months. After the release of 3.8.0 final, a final 3.7 bugfix update will be released. After that, it is expected that security updates (source only) will be released until 5 years after the release of 3.7 final, so until approximately 2023-06.

I think that something similar could help to adopt Julia in wider audience. :slight_smile:

2 Likes
8

A release policy like that is a good idea and seems like something we indeed should strive to have.

4 Likes
9

Yes, we should certainly have a policy along those lines for 1.x releases and beyond. We will not continue to support 0.6.x, however, since we want to encourage everyone to upgrade to 1.0 as strongly as possible. We will also likely switch to a timed release model since that makes sense as soon as you are no longer making breaking changes: whatever changes are made in time for a release get included in the release; whatever isn’t ready goes into a later release.

3 Likes
10

While a support policy for earlier versions is a good thing to have for software at a certain level of maturity, it is important to be mindful of the trade-offs involved. Specifically, supporting earlier versions uses work hours from skilled contributors that could be used elsewhere, possibly to improve the language.

Regarding “serious” use: I am not sure that a support policy for earlier versions was a key factor for all languages which became popular. I am under the impression that some languages became popular first, then built up a large community which had the resources for backporting and security fixes.

3 Likes
11

Thank you for all your answers! However, I am still a bit confused about the recommended way to go regarding workflow, i.e., for (i) editing functions (using gvim in case it is relevant) while (ii) testing code in the command-line Julia. Some things that I am still uncertain about:

  • Should I be using a module at all?
  • Should I use Revise.jl?

[EDIT]: I should not have used reload with the .jl, so my rant was all my fault… Thanks Elrod! :slight_smile:
I.e., use

julia> reload("MyModule")

instead of what is below [/EDIT]

Also, what about the reload command? It is suggested in the “workflow tips” of the v0.6 documentation here, which I find very unclear. I don’t want to offend anyone, but it is frustrating that the recommended workflow gives an error (I am using Julia version 0.6.2 in case that’s relevant):

julia> reload("MyModule.jl")
ERROR: use `include` instead of `reload` to load source files

In case this is useful, I will describe how I have been working (mostly with MATLAB until now) and how, ideally, I would like to keep working. Please let me know if this is not the correct way:

  1. Start the editor on the file that defines my functions, e.g.,
$ gvim MyModule.jl
  1. Start the command line julia, e.g., typing
$ julia

  1. Edit some function, e.g., f(x) in the editor

  2. Run f (or something that uses f) in the command line julia, e.g.,

julia> f(x)
  1. If output is not as expected, go back to 3., otherwise the output is what I want and I’m done for this task.

This workflow allowed me to quickly reach the (efficient) [3. Edit → 4. Run → 3. Edit → 4. Run → …] short loop to test and improve code… Is this workflow doable in Julia?

12

Drop the “.jl”

julia> reload("Revise")

Yes, I would recommend using Revise. It automates the process, and only reloads the changes you make when you save files.
I’ve always used PkgDev.generate(.... to create modules, but I’m sure there’s a much smarter way to get them to properly appear in your path and get tracked.

13

Not sure if this is helpful, but I’m also a recent convert from Matlab. I suggest the following:

  1. Use jupyter-notebook to keep track of your work
  2. Write first version of function, e.g. myfunc(), in a cell in the notebook
  3. Test function & edit its cell until it works as expected for some inputs
  4. Copy-paste working function to a text file “myfunc.jl” with any required include, import, or using statements needed by that function prepended at the top (i.e. before the function definition)
  5. include("myfunc.jl") in the notebook
  6. Run test cases
  7. Edit your function further and then rerun the include cell to update the notebook
  8. If the state of the notebook gets wonky, for whatever reason:
    • Cell → AllOutput → Clear
    • Save
    • Log out and close notebook window
  9. Copy output-cleared saved notebooks to newly-named files before relaunching

The only issue I’ve found with rerunning include("myfunc.jl") is that if you change the function arguments or return tuple, you might end up with old methods that don’t reflect the latest edited version. Relaunching the notebook solves this problem.

Good luck!

14

Oh thanks I completely missed this! My bad!

15

So I have been using Revise and I really like it! If I may ask: How come Revise is not in the recommended workflow?

1 Like
16

On 0.7 there is

julia> workspace()
ERROR: `workspace()` is discontinued, consider Revise.jl for an alternative workflow.
Stacktrace:
 [1] error at ./error.jl:33 [inlined]
 [2] workspace() at ./deprecated.jl:1127
 [3] top-level scope
3 Likes