>
> Currently PyJulia does not support \`KeyboardInterrupt\`. That is to say, in long…-running Python and Julia computation, there is no way to terminate a sub-computation by catching \`KeyboardInterrupt\` as done in normal Python programming.
>
> Aside: Recommended way to cancel current input in REPL is to use IPython 7.0 or above. Ctrl-C would cancel the input without causing SIGINT.
>
> This problem is previously mentioned in: https://github.com/JuliaPy/pyjulia/issues/189, https://github.com/JuliaPy/pyjulia/issues/185#issuecomment-418614274
>
> What follows is a summary of my understanding:
>
> When PyJulia is initialized, libjulia takes over all signal handling. \[I couldn't find a way to disable this behavior\](https://discourse.julialang.org/t/how-can-i-handle-sigint-when-using-libjulia-c-api-in-python-ctypes/14794). Julia documentation mentions that \["Julia requires a few signal to function property."\](https://docs.julialang.org/en/latest/devdocs/debuggingtips/#Dealing-with-signals-1) so it probably would not have something like \[\`Py\_InitializeEx\`\](https://docs.python.org/3/c-api/init.html#c.Py\_InitializeEx) to initialize libjulia without installing signal handlers anytime soon.
>
> What would be more easily achievable is to let Julia translate SIGINT to \`InterruptException\` and then let PyCall to translate it to Python's \`KeyboardInterrupt\`. I have implemented it in https://github.com/JuliaPy/PyCall.jl/pull/574 but it introduced \[a bug\](https://github.com/JuliaPy/PyCall.jl/pull/574#issuecomment-425322221) which is hard to track. I reported it in Julia: https://github.com/JuliaLang/julia/issues/29498. Note that this strategy is not perfect because long-running pure-Python computation or I/O cannot respond to SIGINT. If Julia implements some kind of signal handling https://github.com/JuliaLang/julia/issues/14675 then maybe we can call \[\`PyErr\_SetInterrupt\`\](https://docs.python.org/3/c-api/exceptions.html#c.PyErr\_SetInterrupt) (which does not need GIL) from it.
---
### Author:  [@Roger-luo](https://discourse.julialang.org/u/Roger-luo)
#### Post date: [March 23, 2019, 8:58am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/5 "2019-03-23T08:58:09Z")
Thanks for your suggestions, this is very helpful.
I mean directly map part of the torch function to Julia via pyjulia. There won’t be a torch script anymore. Like what diffeqpy do, amd yes, torch user could still use their old code, but the backend is changed (backend I mean ATen and Autograd in C++)
---
### Author:  [@Balinus](https://discourse.julialang.org/u/Balinus)
#### Post date: [March 23, 2019, 8:42pm UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/6 "2019-03-23T20:42:06Z")
I think that `pyjulia` is a really strategic package and core Julia should ease the pain of using it. I know some projects that consider the use of Julia for hot-loops and right now, the set-up of `pyjulia` is far from plug and play and some people is reluctant to chose this approach. Hopefully, this will be easier as development goes by! Anyway, right now it’s usable and proof-of-concepts can be done to highlights the possibilities.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [March 23, 2019, 9:05pm UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/7 "2019-03-23T21:05:28Z")
Personally I’d be very interested to see some development of the named tensor concept. I think the current approach to this is AxisArrays. But as I I’ve looked over the most recent work in the package it seems there’s a bit of collective discontent with bits of the current API it has (maybe I’m just projecting a little 😉).
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [March 24, 2019, 3:01am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/8 "2019-03-24T03:01:20Z")
I see. Now I realized that’s what you said in your first post. My bad. Transpiling was the topic in the original thread so I misread your post.
I don’t use TorchScript so I don’t have the full picture. But is TorchScript only used by PyTorch experts? If TorchScript is something used also by ML researchers, and if your plan is to use Julia language instead of TorchScript, my concern is that they may not use this backend if they feel they don’t have time to learn a new programming language.
But I think using PyCall/PyJulia only for high-level Julia-Python interaction is a good approach in general. I just don’t know PyTorch enough to see how appealing it would be for PyTorch users.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [March 24, 2019, 3:39am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/9 "2019-03-24T03:39:08Z")
I think the shortest path for making PyJulia easier to use is [RFC: a "workaround" for the multi-project precompilation cache problem without long-term code debt](https://discourse.julialang.org/t/rfc-a-workaround-for-the-multi-project-precompilation-cache-problem-without-long-term-code-debt/22233) with [Make PyCall.jl AOT-compilable by tkf · Pull Request #651 · JuliaPy/PyCall.jl · GitHub](https://github.com/JuliaPy/PyCall.jl/pull/651). (The idea is to create a system image for PyJulia and let Julia automatically use precompilation cache dedicated to PyJulia.) Maybe you can help me in [that thread](https://discourse.julialang.org/t/22233) 🙂
I also added Julia option support recently (available only in master). You can use `Julia(compiled_modules=False)` to workaround the compilation cache problem: [Troubleshooting — PyJulia 0.5.8.dev documentation](https://pyjulia.readthedocs.io/en/latest/troubleshooting.html#turn-off-compilation-cache) It would make PyJulia setup plug-and-play _if_ you are OK with waiting for precompilation for each Python process (yeah, I know this is not super practical for all purposes).
---
### Author:  [@Roger-luo](https://discourse.julialang.org/u/Roger-luo)
#### Post date: [March 24, 2019, 6:09am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/10 "2019-03-24T06:09:38Z")
Well, TorchScript is kinda a python like new language as well, and it is not as mature as Julia yet (not every command you write intuitively is working), which is because again it’s hard to accelerate something like Python. I think it’s used for people writing fast custom operations while not writing c++. So it depends on what you need, currently I don’t see much people using torch script, because people don’t want to learn another new language… (at least among my collaborators, they’d rather writing c++, but some of these people know Julia already)
But Julia comes in as a nice option when someone really need to extend the functionality, define a lot customized tensor, data type (e.g complex number tensor, dual number tensor etc.) I don’t think this is doable in torchscript yet, and not straight forward in C++ (pytorch has data type hooks now, but yet not mature enough). I think this will be the best option and make this kind of user willing to learn a new language :-).
Well it’s hard to make someone who is OK with Python to learn another language, but it’s always easy to persuade a multilingual guy to learn another language who knows Python.
So I guess it will depends how fast and how mature we could make it.
And I notice that diffeqpy can use numba with Julia, is this something still working today?
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [March 24, 2019, 7:03am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/11 "2019-03-24T07:03:07Z")
> [@Roger-luo](#):
>
> Well, TorchScript is kinda a python like new language as well, and it is not as mature as Julia yet
As TorchScript is a subset of Python, I thought you can use it also in good old define-by-run mode? If that’s the case, I suppose you can use all the mature Python tools like a variety of debuggers? (Even though the TorchScript compiler may not be matured yet.)
> [@Roger-luo](#):
>
> currently I don’t see much people using torch script, because people don’t want to learn another new language… (at least among my collaborators, they’d rather writing c++, but some of these people know Julia already)
>
> But Julia comes in as a nice option when someone really need to extend the functionality, define a lot customized tensor, data type (e.g complex number tensor, dual number tensor etc.) I don’t think this is doable in torchscript yet, and not straight forward in C++
I see. It makes sense now. Thanks a lot for explaining this.
My another concern is the overhead of calling Julia function from Python. I thought PyTorch devs wanted to develop JIT because even calling C extension from Python had some overhead (but I’m not sure if this info is fresh and correct). But this probably can be improved once enough people are interested in this. There is already optimization you can do like `pyfunction`.
> [@Roger-luo](#):
>
> And I notice that diffeqpy can use numba with Julia, is this something still working today?
I don’t think there is much benefit in using numba with diffeqpy _unless_ the computing the derivatives is so computation-intensive such that overhead of calling Python function from Julia is neglegible _and_ such computation-intensive code can benefit from using numba (i.e., way faster than composing numpy functions). But @ChrisRackauckas may know other use-cases.
I think a better approach would be to expose a Pythonic API for [ModelingToolkit.jl](https://github.com/JuliaDiffEq/ModelingToolkit.jl) or create [SymPy-to-Julia transpiler specialized for diffeq](https://github.com/JuliaDiffEq/diffeqpy/issues/32). Having said that, it would be very interesting (at least in purely curiosity-based sense) if you can inline LLVM IR generated by Numba into Julia function.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [March 26, 2019, 5:03am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/12 "2019-03-26T05:03:47Z")
> [@tkf](#):
>
> I don’t think there is much benefit in using numba with diffeqpy _unless_ the computing the derivatives is so computation-intensive such that overhead of calling Python function from Julia is neglegible _and_ such computation-intensive code can benefit from using numba (i.e., way faster than composing numpy functions). But @ChrisRackauckas may know other use-cases.
Yeah, that is the use case, and it should still work. If it’s a PDE or stochastic PDE discretization then this makes a lot of sense. If it’s a 3 ODE system then this overhead matters a lot. So it’s just a use case kind of thing. The asymtopically large problems are more algorithm driven (since implementation-wise everything is dominated by the sparse linear solver cost) and so diffeqr and diffeqpy are very effective interfaces to share our algorithms (since in this case, being algorithmically efficient matters a lot more than low level efficiency). This makes the performance of the bridge use-case dependent, similar to NumPy though.
> [@tkf](#):
>
> I think a better approach would be to expose a Pythonic API for [ModelingToolkit.jl](https://github.com/JuliaDiffEq/ModelingToolkit.jl) or create [SymPy-to-Julia transpiler specialized for diffeq](https://github.com/JuliaDiffEq/diffeqpy/issues/32). Having said that, it would be very interesting (at least in purely curiosity-based sense) if you can inline LLVM IR generated by Numba into Julia function.
Yup, I think this is the direction to go. And once we are sufficiently advanced here, we could just have some kind of DSL file format where the differential equation can be written in a way that can be used from any of the bridges we make to other languages. The core of DiffEq will always be Julia, but this would then be a nice way to make all of the advances useful everywhere else.
I think this is a good place to clarify my stance on the “language wars”. DifferentialEquations.jl and its components are built in Julia because of the competitive advantage we get for being able to make full use of the compilation structures of the language. Not just speed but also a lot of features, like easily writing compilers like ModelingToolkit, full language AD systems like Zygote, tooling built with Cassette, etc. that just aren’t available elsewhere. However, our dedication is to the science and not necessarily the language. I plan to continue to make bridges to allow DiffEq to be used from other languages. Tooling like the ability to compile OrdinaryDiffEq.jl on Float64s to a binary for use from Python/R will go a long way to making this nicer. Julia’s development advantages also make it a great language for building libraries, and we should share that as much as possible. Power users will still come to Julia since there will always be more you can do when using it from Julia of course (some of the ML integration is an example, in cases not using adjoint sensitivity analysis). And honestly, these tools have been great Julia recruitment tools not just for power users.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [March 27, 2019, 2:46am UTC](https://discourse.julialang.org/t/pytorch-and-julia/22211/13 "2019-03-27T02:46:04Z")
> [@ChrisRackauckas](#):
>
> we could just have some kind of DSL file format where the differential equation can be written in a way that can be used from any of the bridges we make to other languages
This sounds like a great approach. But one thing I’ve been wondering is that in DSL you tend to lose benefits in the host language like debugger and how to deal with that. This mirrors different debuggability in define-by-run and static graph approach of NN frameworks. DSL is an obvious way forward for readability and writability for complex mathematical models. It would be great if debuggability (and other benefits in Julia like `@code_*`) can be recovered. Maybe that’s as easy as recording and attaching `LineNumberNode` when generating function. I think this would benefit Python/R/… users, too. I don’t think it’s too crazy to launch Julia debugger from Python debugger.
> [@ChrisRackauckas](#):
>
> However, our dedication is to the science and not necessarily the language.
👏 👏 👏