Is there a way to reload a module or all modules in PureScript's REPL? If I make a change to a module, I've got to :quit and then import all the modules I'm working with each time.
You can use :r or :reset, but you would still need to import modules again. We have plans to try to make that simpler, by allowing PSCi configuration files with a default set of imports to use on load.
Another option is to define your own module with the reexports that you need. Then you only need to do a reload followed by one import.
Related
I'm using Module::Load to load certain modules at runtime. However, I have to make do with an older version (2013) that does not import the autoload function.
Thus, I'm doing something like this:
use Module::Load;
if(some condition)
{
load "Cwd", qw(getcwd abs_path);
}
I can now use the getcwd() and abs_path() functions provided by the Cwd module.
This is clearly not practical when I need to load a module that imports a lot of functions. How can I use load and still manage to import all the default functions without having to quote them all?
It is usually a better idea to just import what you are actually using. That said, many modules can be asked for qw(:DEFAULT) to explicitly get all the default exports.
I'm using browserify to manage dependencies. require('rangy') seems to only import rangy-core, but not its sub-modules.
How can I import rangy-classapplier?
If I import the file (require('./node_modules/rangy/lib/rangy-classapplier.js')) it works, but I'd like to do it without having to include the file address.
I think
require('rangy/lib/rangy-classapplier.js');
is what you want, at least as things are now. I don't see a neat way for me to make the path any simpler; I don't want to clutter the root directory. Possibly the rangy- prefix is unhelpful and I should get rid of it but I'll have a think about that.
since I usually use ipython to play around with code under development, I come across the situation where I change the code of a class after I import it to ipython. I want to reload the new class definition without restarting ipython. The problem is that the reload function in ipython only works with modules.
I searched the solution to this problem and found a previous thread:
how to reload a Class in python shell?
However, I followed the approaches there but it didn't work. I think the reason why it works in that thread is that the class name happened to be the same with the module name, so it can be found in sys.modules and thus can be deleted. When the class name is different from the module name, that approach cannot work.
I am wondering if there is solution to this problem. Thanks!
Yes, there's an IPython extension called 'autoreload' for exactly this sort of thing. Here's the documentation on how to use it.
You can also reload individual module
For example:
#reload every time
import my_module
reload(my_module)
#reload a module recursively
import deep_reload_my_module
dreload(deep_reload_my_module)
My eclipse is configured so that when I save the java source file, it automatically inserts the missing import declarations. Except when the reference is ambiguous. Fpr instance, the most annoying ambiguity is with List<T> - both java.util and java.awt declare it. Here eclipse demands manual resolution.
I was wondering if it was possible to configure somewhere that whenever List<T> is used then java.util should be imported. Or alternatively, since I am not using java.awt, I could just remove it from the list of possible suggestions.
Any ideas?
Thanks.
This sounds like a possible duplicate of Exclude packages from Eclipse's organize imports.
Basically, you want to change your Type Filters preference to exclude java.awt.* packages. Keep in mind that doing so will make things harder/confusing if you ever try to write AWT/Swing code.
One thing that pops into my mind is altering the class template in the preferences to include the line:
import java.util.List
Unless you are going to use the AWT version of a List, or care about unused import statements, that should solve this annoying issue ..
Manually invoke Organize Imports and it will ask you when an ambiguity is found.
I have many standalone scripts. The only thing they share, is that they use() a large set of CPAN modules (that each export several functions). I would like to centralize this list of modules. I found several methods. Which one is the best?
I could create SharedModules.pm that imports everything and then manually exports everything to main:: using Exporter.
I could create SharedModules.pm that starts with "package main;" so it will import directly into main::. It seems to work. Is it bad practice and why?
I could require() a sharedmodules.pl that seems to import everything into main:: as well. I don't like this method as require() doesn't work that well under mod_perl.
Number two looks best to me, however I wonder why for example Modern::Perl doesn't work that way.
Edit: I figured this question has been asked before.
Maybe more flexible than putting everything into main namespace would be to import into caller's namespace. Something like this:
package SharedModules;
sub import {
my $pkg = (caller())[0];
eval <<"EOD";
package $pkg;
use List::Util;
use List::MoreUtils;
EOD
die $# if $#;
}
1;
The problem with all three of your proposed solutions is that the module may be used from another module, in which case the symbols should be exported into the useing module's package, not into main.
bvr's solution of using caller to import things directly into that package is a major step in the right direction, but prevents the 'real' package from using use ShareableModules qw( foo bar baz); to selectively import only what it actually needs.
Unfortunately, preserving the ability to import selectively will require you to import all relevant symbols from the underlying modules and then re-export them from ShareableModules. You can't just delegate the import to each underlying module's import method (as Modern::Perl does) because import dies if it's asked for a symbol that isn't exported by that module. If that's not an issue, though, then Modern::Perl's way of doing it is probably the cleanest and simplest option.
Using require is the most natural way to do this. Under mod_perl you may need to modify #INC during server startup.
Maybe you want Toolkit.
File import.pl:
require blah; blah->import;
require blubb; blubb->import;
Skripts:
#!/usr/bin/perl
do 'import.pl'
...
Patrick