Autoreload in iPython works only one layer. Is there a way to autoreload recursively?
If module A imports module B, and my notebook imports module A. When I change module B, it doesn't autoreload. Is there a way to change this behaviour?
Related
My Folder Structure looks like the following
person-package
|- __init__.py
|- person.py
|- person_manager.py
main.py
person_manager.py imports person.py
import person as x
The main.py imports person_manager.py
import person_package.person_manager as x
When running main.py I get:
ModuleNotFoundError: No module named 'person'
I know, I could solve that by changing the import of person_manager.py to the following
from . import person as x
However, when running now person_manager.py directly, I get:
ImportError: attempted relative import with no known parent package
So I can't test person_manager.py on its own.
What is the most elegant way to solve that?
1. I recommend to always use absolute imports (unless strictly impossible).
2. person-package is not a valid Python name since it contains a dash -, if I were you I would rename to person_package with an underscore _.
3. Since person_manager.py is part of a Python importable package (i.e. it is in a directory containing a __init__.py file), then it should not be run as python person_package/person_manager.py, but as python -m person_package.person_manager.
In rebar3 erlang library I have two modules: t1 and t1 in src directory and t3 module in extras directory. Now in mylib.app.src I'm trying to make them available outside library by:
{modules, [t1, t2, t3]}
I pointed that extra directory in rebar3.config:
{extra_src_dirs, ["extras"]}.
But still, I cannot use t3 module in project, which uses this library. What else should I do to make this module available outside?
Use {src_dirs, ["extras"]}.. Please refer to rebar3 documentation for more information (Directories) section.
Also you do not need to include the modules in mylib.app.src manually. rebar3 automatically adds all the source modules to the mylib.app file during compilation. The .app would be in ebin directory (_build/default/lib/mylib/ebin/).
I've written a GUI in Java and use a lua-script to calculate some values for images with a neural network. Therefore the lua-script requires some modules from torch7.
I got so far that it finds the modules which have a init.lua file. However, it fails when a module only has a .so file. The module is required in one of the init.lua files.
Before I require the modules in the script i set the new package.path and the package.cpath to LUA_PATH and LUA_CPATH because luaj only used the default path which didn't work.
I think this a LuaJ problem because when I run the script in the terminal with lua script_name.lua it works fine.
package.path = package.path .. ';/home/user/.luarocks/share/lua/5.1
/?.lua;/home/user/.luarocks/share/lua/5.1/?/init.lua;/home/user/torch
/install/share/lua/5.1/?.lua;/home/user/torch/install/share/lua/5.1
/?/init.lua;./?.lua;/home/user/torch/install/share/luajit-2.1.0-
beta1/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1
/?/init.lua'
package.cpath = '/home/user/torch/install/lib/?.so;/home/user/.luarock
/lib/lua/5.1/?.so;/home/user/torch/install/lib/lua/5.1/?.so;./?.so;
/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so'
require 'torch'
require 'nn'
require 'image'
The error message is as follows:
exception in thread "main" org.luaj.vm2.LuaError: #/home/user/torch/install/share/lua/5.1/paths/init.lua:1 module 'libpaths' not found: libpaths
no field package.preload['libpaths']
libpaths.lua
/home/user/.luarocks/share/lua/5.1/libpaths.lua
/home/user/.luarocks/share/lua/5.1/libpaths/init.lua
/home/user/torch/install/share/lua/5.1/libpaths.lua
/home/user/torch/install/share/lua/5.1/libpaths/init.lua
./libpaths.lua
/home/user/torch/install/share/luajit-2.1.0-beta1/libpaths.lua
/usr/local/share/lua/5.1/libpaths.lua
/usr/local/share/lua/5.1/libpaths/init.lua
no class 'libpaths'
I call the script from my java program:
public ScoreImage(){
G_ = JsePlatform.standardGlobals();
//G_.get("dofile").call( LuaValue.valueOf(changePath_));
G_.get("dofile").call( LuaValue.valueOf(script_));
}
I use lua 5.1 because some of the problems where solved by changing from lua 5.2 to lua 5.1. I have Ubuntu 14.04 LTS and luaj 3.0.1.
I really appreciate any help!
It seems that LuaJ does not have the ability to load dll files and so files.
You may want to look into jnlua:
https://code.google.com/archive/p/jnlua/
I want to integrate the aerospike erlang client to the erlang environment as a global module in Fedora 21.
I achieve to make the client nif and module but I have to always copy the files in every project.
Now I want to use the aerospike module like the erlang or os modules.
How can I make this?
I had the same issue when experimenting with the Aerospike binding. The problem is that the .so file is assumed to be in the current working directory. I made a small change to aerospike.erl so it's located correctly independent of the path.
Replace
ok = erlang:load_nif("./aerospike_nif", 0).
in init()
with
EbinDir = filename:dirname(code:which(?MODULE)),
SoFile = filename:join(EbinDir,"aerospike_nif"),
erlang:load_nif(SoFile, 0).
When starting erl, add the path to the directory containing the Aerospike beam files and .so: erl -pa path_to_aerospike/erlang/
in Java/Groovy, afaik, a package has to be defined in the corresponding folder. This results in all class files which are stored in /a/b/c start with the line package a.b.c. Is this still necessary? With regards to convention over configuration, this isn't DRY...
What kind of problems would arise when this package definition would be optional`?
While it is conventional for the directory structure to match the package structure, and certain problems arise if they don't match, it is in fact not a requirement that they match. This is also true of Java (though a lot of folks don't realize that).
Below is an example which demonstrates this.
groovydemo $ mkdir classes
groovydemo $
groovydemo $ cat src/groovy/com/demo/SomeClass.groovy
package com.somethingotherthandemo
class SomeClass {}
groovydemo $
groovydemo $ groovyc -d classes/ src/groovy/com/demo/SomeClass.groovy
groovydemo $ find classes -type f
classes/com/somethingotherthandemo/SomeClass.class
The reasons for using packages in Groovy (and Grails) are some of the same reason why they are used in Java.
Packages serve to organize classes into logical namespaces, typically by grouping collaborating classes together.
It helps avoid naming conflicts with other classes (either Java or Groovy).
In any non-trival system where you have hundreds or thousands of classes, packages provide a very useful mechanism for organization and structure.
I think what you're saying is that the package name is implied by the directory the class is in, so why do you need to state it explicity? This is only true in some cases (like Grails) where there's a convention that establishes the root of the source files (e.g. src/groovy).
But imagine I'm writing a Groovy app and have a file at /a/b/c/D.groovy, how can we tell if the root of the source files is /a and thus the package name is b.c or the root of the source files is /a/b and therefore the package name is just c? As far as I can see, we can't, so the package name needs to be stated in the source file explicitly.