When I get libraries with the using keyword I get warnings in the console on startup. How can I mitigate the problem of name clashes? I don't see library alias keyword as which is available in other programming languages.
You can use import instead. You can always alias it yourself since modules are just variables:
import DifferentialEquations
DiffEq = DifferentialEquations
const DE = DifferentialEquations # Don't know if const matters here
There's an open issue for providing import as syntactic sugar for this. https://github.com/JuliaLang/julia/issues/1255
Related
I'm trying to pickle functions with dill. I want to include the whole function and not just a reference to it. Here are my two files:
fun.py:
import dill
from foo import ppp
def qqq(me):
return me + 1
print(dill.dumps(ppp, protocol=4, recurse=True, byref=True))
print(dill.dumps(qqq, protocol=4, recurse=True, byref=True))
And foo.py
def qqq(me):
return me + 1
When I run fun.py I get the following output:
b'\x80\x04\x95\x0f\x00\x00\x00\x00\x00\x00\x00\x8c\x03foo\x94\x8c\x03ppp\x94\x93\x94.'
b'\x80\x04\x95\x90\x00\x00\x00\x00\x00\x00\x00\x8c\ndill._dill\x94\x8c\x10_create_function\x94\x93\x94(h\x00\x8c\n_load_type\x94\x93\x94\x8c\x08CodeType\x94\x85\x94R\x94(K\x01K\x00K\x01K\x02KCC\x08|\x00d\x01\x17\x00S\x00\x94NK\x01\x86\x94)\x8c\x02me\x94\x85\x94\x8c\x06fun.py\x94\x8c\x03qqq\x94K\x04C\x02\x00\x01\x94))t\x94R\x94}\x94h\rNN}\x94Nt\x94R\x94.'
I want to be able to make the first line of output be more similar to the second line, and actually encapsulate the function without the need for a context when reloaded later. Is there a way to do this?
Thanks so much!
James
If the module (foo) is installed on both computers, then there should be no need to do anything but import the function. So, I'll assume the question is in regard to a module that is only installed on the first machine.
It also depends on whether the module foo is "installed" on sys.path or is just available in the current directory. See:
https://github.com/uqfoundation/dill/issues/123
If it's only available in the current directory, either use dill to pickle the file itself or use something like dill.source.getsource to extract the source of the module as a string, and then transfer the string as a "pickle" (this is what ppft does).
Generally, however, dill pickles imported functions by reference, and thus assumes they are available on both sides of the load/dump.
In the "official" scala REPL I can do
scala> import util.Random
scala> util.Random.nextInt
res0: Int => -306696783
but in Ammonite-REPL I get
# import util.Random
cmd3.sc:1: object Random is not a member of pack ammonite.util
import util.Random
^
Compilation Failed
So right now I have to use the scala. prefix to make it work in Ammonite:
# import scala.util.Random
# scala.util.Random.nextInt
res1: Int = 503117434
I'm kind of new to Scala so I don't get why would ammonite use a different util than the (for me) "official" util, so I would appreciate if anyone can provide a rationale for this.
And more specifically, Is there any way to make util to be scala.util instead of ammonite.util?
It's not that Ammonite is replacing a different util library for the normal Scala one, it's that the Ammonite namespace has it's own util package which has a whole bunch of methods specific to Ammonite. Perhaps it would be nicer if the developer had chosen a different name for his package, but this is not an issue specific to Ammonite. It is something you will run into all the time. When there is a clash of namespaces, your only option is to fully qualify the package name for the one you want. So what you actually did is a fine solution. You can find more about this here.
And btw, since there is no util.Random in the Ammonite package you can do this after your import--I tested and this is a cut and paste from my terminal:
# Random.nextInt
res1: Int = 1045964363
When you do actually have a collision of method names, you can find a solution here
In perl, sometimes it is necessary to specify the function name in the use statement.
For example:
use Data::DPath ('dpath');
will work but
use Data::DPath;
won't.
Other modules don't need the function names specified, for example:
use WWW::Mechanize;
Why?
Each module chooses what functions it exports by default. Some choose to export no functions by default at all, you have to ask for them. There's a few good reasons to do this, and one bad one.
If you're a class like WWW::Mechanize, then you don't need to export any functions. Everything is a class or object method. my $mech = WWW::Mechanize->new.
If you're a pragma like strict then there are no functions nor methods, it does its work simply by being loaded.
Some modules export waaay too many functions by default. An example is Test::Deep which exports...
all any array array_each arrayelementsonly arraylength arraylengthonly bag blessed bool cmp_bag cmp_deeply cmp_methods cmp_set code eq_deeply hash
hash_each hashkeys hashkeysonly ignore Isa isa listmethods methods noclass
none noneof num obj_isa re reftype regexpmatches regexponly regexpref
regexprefonly scalarrefonly scalref set shallow str subbagof subhashof
subsetof superbagof superhashof supersetof useclass
The problem comes when another module tries to export the same functions, or if you write a function with the same name. Then they clash and you get mysterious warnings.
$ cat ~/tmp/test.plx
use Test::Deep;
use List::Util qw(all);
$ perl -w ~/tmp/test.plx
Subroutine main::all redefined at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
Prototype mismatch: sub main::all: none vs (&#) at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
For this reason, exporting lots of functions is discouraged. For example, the Exporter documentation advises...
Do not export method names!
Do not export anything else by default without a good reason!
Exports pollute the namespace of the module user. If you must export try to use #EXPORT_OK in preference to #EXPORT and avoid short or common symbol names to reduce the risk of name clashes.
Unfortunately, some modules take this too far. Data::DPath is a good example. It has a really clear main function, dpath(), which it should export by default. Otherwise it's basically useless.
You can always turn off exporting with use Some::Module ();.
The reason is that some modules simply contain functions in them and they may or may not have chosen to export them by default, and that means they may need to be explicitly imported by the script to access directly or use a fully qualified name to access them. For example:
# in some script
use SomeModule;
# ...
SomeModule::some_function(...);
or
use SomeModule ('some_function');
# ...
some_function(...);
This can be the case if the module was not intended to be used in an object-oriented way, i.e. where no classes have been defined and lines such as my $obj = SomeModule->new() wouldn't work.
If the module has defined content in the EXPORT_OK array, it means that the client code will only get access to it if it "asks for it", rather than "automatically" when it's actually present in the EXPORT array.
Some modules automatically export their content by means of the #EXPORT array. This question and the Exporter docs have more detail on this.
Without you actually posting an MCVE, it's difficult to know what you've done in your Funcs.pm module that may be allowing you to import everything without using EXPORT and EXPORT_OK arrays. Perhaps you did not include the package Funcs; line in your module, as #JonathanLeffler suggested in the comments. Perhaps you did something else. Perl is one of those languages where people pride themselves in the TMTOWTDI mantra, often to a detrimental/counter-productive level, IMHO.
The 2nd example you presented is very different and fairly straightforward. When you have something like:
use WWW::Mechanize;
my $mech = new WWW::Mechanize;
$mech->get("http://www.google.com");
you're simply instantiating an object of type WWW::Mechanize and calling an instance method, called get, on it. There's no need to import an object's methods because the methods are part of the object itself. Modules looking to have an OOP approach are not meant to export anything. They're different situations.
I'm trying to compile some D. The code that I've written uses the std.string library as well as std.algorithm. One of my functions calls indexOf on a string: unfortunately, apparently there's also a indexOf function in std.algorithm, and the compiler doesn't like it:
assembler.d(81): Error: std.algorithm.indexOf!("a == b", string, immutable(char)).indexOf at /usr/share/dmd/src/phobos/std/algorithm.d(4431) conflicts with std.string.indexOf!(char).indexOf at /usr/share/dmd/src/phobos/std/string.d(334)
assembler.d(81): Deprecation: function std.algorithm.indexOf!("a == b", string, immutable(char)).indexOf is deprecated
How do I get around this? In C++ I could use the :: to explicitly say what namespace I'm in... what about D?
If you want to call std.string.indexOf explicitly, then do std.string.indexOf(str, c) instead of indexOf(str, c) or str.indexOf(c).
Or you can use an alias:
alias std.string.indexOf indexOf;
If you put that inside the function where you're calling indexOf, then it should then consider indexOf to be std.string.indexOf for the rest of the function. Or if you put it at the module level, then it'll affect the whole module.
However, due to a bug, UFCS (Universal Function Call Syntax) doesn't currently work with local aliases, so if you put the alias within the function, you'll have to do indexOf(str, c) instead of str.indexOf(c).
A third option is to use a selective import:
import std.string : indexOf;
With that import, only indexOf is imported from std.string, and when you use indexOf, it'll use the string version (even if you've also import std.algorithm). And you can even import std.string regularly in addition to the selective import to get the rest of std.string, and the selective import will still fix the conflict (in which case, it's really not that different from importing std.string and then aliases indexOf). However, due to a bug, selective imports are always treated as public, so doing a selective import of indexOf in a module will affect every module that imports it (potentially causing new conflicts), so you may want to avoid it at this point.
EDIT
I want to group together related functions to show that they are related.
If I have local:f1() and local:f2() then I could just change their names to local:menu-f1() and local:menu-f2() but is there a mechanism in the XQuery language to group related functions?
OP
I am very excited to discover that XQuery functions can be declared in a namespace other than local:. Where can I find info about how this works?
Having always declared functions in this way;
declare function local:foo() {
3+4
};
.. and used them in this way;
local:foo()
.. I discover that they can be declared like this;
declare namespace baz = "fred:bloggs";
declare function baz:foo() {
3+4
};
.. and used like this;
baz:foo()
But I can only find reference-like information about declare namespace and declare function separately, not tutorial-like information about how XQuery function namespaces work in general.
Is there a newbie guide to XQuery function namespaces?
I'm using a Saxon processor - XQuery 1.0.
What you are probably using are normal XQuery namespaces - what you probably are looking for are modules. You can put a bunch of functions in its own module namespace like this:
module namespace foo = "http://www.myurl.com/foo";
declare function foo:bar($args as item()*) as item()* {
() (: do something cool :)
};
Afterwards you can import the module in you main query and call the function:
import module namespace foo = "http://www.myurl.com/foo";
foo:bar(<my-element/>)
The problem is, that it is not standardized, how the processor has to find the query. And I don't know how Saxon implements the module resolving mechanism (you should look into the documentation and/or write to the Saxon mailing list).
But most XQuery processors look at the path given by an "at" clause relative from the location of the query. So to have something that should work on most implementations: For example you could store the module in a file named foo.xq and place it into the same directory than your main query and then for the module import you would write:
import module namespace foo = "http://www.myurl.com/foo" at "foo.xq";
which gives a hint to the XQuery engine where it should look for the module.
You can find some (not a lot at the moment) documentation about this stuff at http://www.xquery.me/ - hope this helps.
EDIT
Ok I see, you only want to group your functions. To do that you already figured out everything you need to know. But I still want to emphasize that splitting your query up into modules would probably be the better solution for your use-case (it's just somehow nicer, since your have more modularity and in the upcoming XQuery 3.0 recommendation you will even have the possibility to put stuff like private functions and variables in there). But if your query does not get big, your solution is of course also ok.
You can think about XML namespaces the same way you would think about namespaces in C++. In XQuery, functions, elements, collections, variables, attributes etc can be in an own namespace (again - like in C++). There are some implicitely defined namespaces like xs (the XML Schema namespace where you can find the data types like boolean, integer etc), local (a namespace where you can put in functions so that you are not forced to define your own namespace in a main query), fn (where all functions from the "XQuery 1.0 and XPath 2.0 functions and operators" recommendation are defined). But the prefix of this function is only an alias - you can use whatever you want.
So let's say you have the following code in the prolog of your query:
declare namespace blubb = "http://www.w3.org/2001/XMLSchema";
blubb:integer would be exactly the same type than xs:integer - the same holds for functions:
declare namespace l = "http://www.w3.org/2005/xquery-local-functions";
With declaring that you can access every function in the local namespace with the "l" prefix (so l:bar() if local:bar() exists).
If you do not type a prefix, XQuery assumes that this function is in the "fn" namespace. This is why bot
fn:concat("Hello ", "World!")
and
concat("Hello ", "World!")
are equivalent. You can change this behavior. You could include this line into the prolog:
declare default function namespace "http://www.w3.org/2005/xquery-local-functions";
which would tell the XQuery processor that you do not want to prefix local functions (so bar() would be equivalent to local:bar()).
I am not sure if I answered your questions or at least was able to bring in some clarity. I do not know about a tutorial for that (since in the beginning it is somehow confusing but in the end you realize that there is not a lot to say about since the mechanisms are much simpler than they look in the first place). The document where I always look up stuff is the recommendation at http://www.w3.org/TR/xquery/
If this does not help you please try to qualify and I can try again with an explanation..