-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
store the actual source code of a method #2625
Comments
If we stored the source (compressed) of each method definition when running interactively, this could be done rather easily and work correctly even when source files change and even when source line annotation isn't quite perfect. That would also help with the #265 (see also this discussion) since you could use the source to recompile things. We could also store the AST in compressed form instead – six vs. half a dozen. |
No, it won't help with #265. We already have all the information, it just doesn't look like source code anymore. If you want to look at the original code, the best way is to read it from the file. |
Agree with @JeffBezanson and this would be a departure from R where typing the function without parens barfs out the source code. If the source is more than a few lines long, it becomes unusable (there is no way to scroll through the output afaik). |
+1 with read from file. |
Just to understand, is the feeling here that there shouldn't be a function to echo the source code of methods, but rather to rely on 'edit' for that purpose? That might not play well with the IPython web notebook that's interacting with a remote Julia kernel, since I think the file will open on the kernel's machine instead of the client's. |
For what it's worth, in interactive modes, I'd like to keep source code around, rather than rely on what's in files. I want to be able to see the source code of things that were input via the repl too. See also #3988. |
pager support #6921 may negate some concerns on the usefulness of this. I find this very convenient in ipython (via |
Also, |
|
If the following two features were available
then it may be possible to do run time code listing/traversal/manipulation/generation.
in response to comment : JeffBezanson commented on Mar 20, 2013 So you think this is possible ? What happens where there are include/require statements and other things ?
|
@hgkamath I'm afraid I don't understand the question, but it seems better-suited for the users mailing list. Please do read the metaprogramming and reflection sections of the manual. |
Another use case would be |
Oh, did I solve this in #22007 ? |
Sort of – I still think that in REPL mode we should stash the original source for functions for display. |
There is also the question of displaying anonymous functions, where it would be nice to be able to display the original AST. julia> x -> x+1
(::#5) (generic function with 1 method) is not super useful. (See also discourse.) |
we already basically do, it's just annoying to access:
|
"annoying to access" == "not useful enough to be considered solved" |
I admit that it would be useful. I frequently debug by modifying a function in and running different variations in different REPLs to compare them. Sometimes I lose track of which REPL corresponds to which variation. Printing the function that is currently defined would then be nice to have. |
A use case in Yao provided by https://github.com/MasonProtter/LegibleLambdas.jl Every block has a argument of number of qubits, and we don't want to write it repeatedly, so it can be auto-curried when you don't feed this number, e.g julia> using Yao
julia> control(2, 1=>X)
(n -> control(n, 2, 1 => X gate)) So the user will be aware of this is not a block, it need this number of qubits for further evaluation. Before we have LegibleLambdas, it is quite confusing with just a number like But there are a lot corner cases that we can't support in LegibleLambdas, it would be nice, that we could directly get these information in REPL with the support from compiler instead extern package. |
It still seems perverse to me that we support this julia> @code_native 1 + 2
.section __TEXT,__text,regular,pure_instructions
; ┌ @ int.jl:53 within `+'
leaq (%rdi,%rsi), %rax
retq
; └
; ┌ @ int.jl:53 within `<invalid>'
nopw %cs:(%rax,%rax)
; └ and this julia> @code_llvm 1 + 2
; @ int.jl:53 within `+'
define i64 @"julia_+_13402"(i64, i64) {
top:
%2 = add i64 %1, %0
ret i64 %2
} and this julia> @code_typed 1 + 2
CodeInfo(
1 ─ %1 = Base.add_int(x, y)::Int64
└── return %1
) => Int64 and this julia> @code_lowered 1 + 2
CodeInfo(
1 ─ %1 = Base.add_int(x, y)
└── return %1
) but not this julia> @code_source 1 + 2
ERROR: LoadError: UndefVarError: @code_source not defined
in expression starting at REPL[23]:1 We can introspect all different possible versions of a method except for the one that everyone using Julia knows how to read and write. I'm gonna mark this as "help wanted" to indicate that it would be a welcomed addition to the language to have an optional mode where we remember the source representation of a function. It could be turned on by default in interactive mode but turned off by default in non-interactive mode. |
Similar functionality is now implemented by https://github.com/timholy/CodeTracking.jl, which is part of Revise.jl. I played with it a little, and while it is not perfect, it works more often than not. The documentation says it's much better when also using Revise. This was suggested in this discussion. |
This might be excellent in combination with automatic differentiation (like https://github.com/FluxML/Zygote.jl), since you can then show the derivative as julia code |
|
|
https://github.com/timholy/CodeTracking.jl has some tools for this. |
Julia has a lot of useful REPL things like
methods
andhelp
.However, I still end up needing to just look at the code to see what it's doing.
It would be cool to be able to do:
It's kind of like the jump-to code stuff in some IDEs, but in the REPL, and only showing the one function.
This obviously has limitations, since you can't just scroll up and see the implementation of
_base
or search for the definition ofdig_syms
in that file, but it does let you see what the default values are.You can already see the signature for
_base
, which makes the implementations ofbase
more meaningful. (without needing to switch from the REPL to a text editor)Considering that the line numbers/files are already included in the output of
methods
, it seems like it should be straightforward to grab the appropriate lines of code from the file.The text was updated successfully, but these errors were encountered: