I am working on a Package,
this package using BinDeps to pull in some C source code, and compile some binaries.
My julia module then mostly just exposes ccalls to those functions.
Now there are about 5 different options for how the C source can be compiled, with various different optimisations turned on.
And to go with them various other changes that are triggered by by a constant that is written to the deps.jl that is output by BinDeps.
So I would like to import each of the different builds of my package as different modules, so I can benchmark them using BenchmarkTools.jl.
Currently, my plan is to make a script that generates 5 different versions of my module, by copying it, and changing it's name, and by using a different deps.jl files to link to different compiled shared libraries.
And then (assuming I renamed them numerically):
using BenchmarkTools
import MyMod_1
import MyMod_2
import MyMod_3
import MyMod_4
import MyMod_5
#show #benchmark MyMod_1.foo()
#show #benchmark MyMod_2.foo()
#show #benchmark MyMod_3.foo()
#show #benchmark MyMod_4.foo()
#show #benchmark MyMod_5.foo()
Currently I am scripting the copying and renaming of modules.
It is a little scary, and seems a bit brittle.
But is there a better way?
Related
I have to make some functions that will use different lanaguages (python, R, js).
I got stuck at the part of generating random numbers in Python to initialize a list with random elements. I looked up on ways of initializing random lists, and then I decided to use result = polyglot.eval("python", "[random.randint(0,10) for i in range(20)];").
The problem that I face now is that I need to import the "random" library from python, or whatever libraries will I need from different languages. I heard that it might be a problem with the dependencies, but I am not sure...
What am I supposed to do? Is it even possible to import libraries from more languages in a single project? What other alternatives do I have?
Note that solution for different dynamic languages may differ.
Also js component is stable, while python (as of 2021) is still experimental.
Here is example for Python with modules
https://github.com/paulvi/java-python-graalvm-template
And if you really do polyglot (using Python object in Java code),
see https://github.com/hpi-swa-lab/graalpython-java-example
There is still issue how to actually deploy this in production
https://github.com/hpi-swa-lab/graalpython-java-example/issues/6
as just bundling venv subfolder into jar, will just work.
One solution is in ttps://github.com/paulvi/java-python-graalvm-template
Also randon, i.e. any library with graalvm is still big issue, as different packages have different issues, see https://github.com/oracle/graalpython/issues/228
I suggest, that before really mixing a lot of languages, just try one, e.g. js that is more stable, make it work, and then try next.
BTW PyCharm does not yet support graalpython.
If you do any open source, or later find somethin new, please let me know via GitHub issue
I have thrift generated code in my project? How do I stop this from affecting my coverage stats? They're dismal.
This help message from go test seems to suggest you can filter the packages you're testing:
-coverpkg pkg1,pkg2,pkg3
Apply coverage analysis in each test to the given list of packages.
The default is for each test to analyze only the package being tested.
Packages are specified as import paths.
Sets -cover.
Another simpler option, and this is what I do, is to import the generated code as a library package that sits outside your code tree, and thus the cover tool ignores it in its stats.
e.g. if your app is github.com/Fuser97381/myproj, put the generated code in github.com/Fuser97381/protocols. Then your code looks like this:
package main
import (
"github.com/Fuser97381/protocols/myproto"
"git.apache.org/thrift.git/lib/go/thrift"
)
...
I am using pandas to do some data analysis. Others in my company are wanting to process data in a similar fashion, but won't want to use a programming language to do it. After significant googling, I found Orange, which has the perfect interface for what I'm wanting people to do. However, the widgets don't do the types of tasks we're looking at. So, I decided to see if I could write my own widgets for Orange to do the tasks.
I'm trying to use Orange3; this seems like the best bet when I'm using WinPython. I must say that going through the documentation for widget creation (for Orange2) and the code for the Orange3 widgets is rather impressive - very nicely written and easy to use to implement what I'm wanting to do.
After writing a couple of widgets, how do I get them into Orange3? the widget creation tutorial is for Orange2 (in Python 2.7), and I haven't got it to work for Orange3.
My project is at the moment rather small:
dir/
orangepandas/
__init__.py
owPandasFile.py
pandasQtTable.py
setup.py
setup.py currently contains the following:
from setuptools import setup
setup(name='orangepandas',
version='0.1',
packages=['orangepandas'],
entry_points={'Orange.widgets': 'orangepandas = orangepandas'}
)
When I run python setup.py install on this and then try opening Orange3 canvas, I don't see my shiny new widget in its new group.
After tracing through how Orange3 imports external libraries, it seems that Orange relies on the actual widget file existing, rather than being inside a egg (zipped) file. Adding
zip_safe=False
to the setup options allowed Orange3 to import the widgets correctly. Orange3 uses os.path.exists in cache_can_ignore in canvas/registry/discovery.py to detect if the path exists at all, and if it doesn't, it doesn't try to import it. Using zip_safe=False makes sure that the addon stays uncompressed so that the individual files are accessible.
(For the next person who tries to do what I was doing.)
I come from Java backgrounds and the problem of packaging is as follows then:
I can have many files under the same package, say com.parobay.io. I can then distribute this as a library, and the users will use it like this:
import com.parobay.io.Input;
import com.parobay.io.Output;
or
import com.parobay.io.*; // to import everything
So I can have a single "module (com.parobay.io) and classes defined in multiple files.
So how to I achieve the same in D? Do I have to create a directory com\parobay\io and there place two files called Input.d and Output.d or is there a smarter way?
In Java the rules are very strict, so it's hard to get it wrong. In D there are many possibilities. So are there any conventions, like one class per file, or file name equal to the name of class?
You can choose to do it basically the same as Java, though remember these items:
import foo.* doesn't work in D, but you CAN make a file called package.d in the directory which manually lists public import foo.Input; public import foo.Output; etc. which allows you to import the whole package.
ALWAYS put a module com.parobay.io.Input; or whatever line at the top of any file that is imported. Don't expect it to just work based on directory structure and filename. The directory structure actually isn't strictly necessary, it is just a convention to easily find the file. The module line at the top with the name is the authoritative thing the compiler checks.
D modules often have all lowercase names, but you can use uppercase ones if you like. I think it is nice to use a lowercase name like the class name, so you might call the module io.input and the class Input. The reason for this convention is sometimes filename case gets lost when transferring from system to system. But developers are pretty aware of case so in practice either way should work.
One class per file will work fine or you can put two tightly coupled classes together in the same file (they'll have access to each other's private members if they are in the same file).
See this page for more info: http://dlang.org/module especially search for the heading "Package Module"
Don't use two separate files for your Input and Output classes. Instead, put both classes in a single file, parobay/io.d (corresponding to the module parobay.io).
It's definitely not the convention to limit yourself to just one class per file. D modules are for grouping together code of related functionality. When someone does import parobay.io;, they expect to get all of parobay.io - classes, utility functions and whatever else is relevant. It's similar to Java's import com.parobay.io.*;.
If someone really wants to import specific parts of your module, they can use selective imports:
import parobay.io: Input; // Just the Input class of the parobay.io module.
import parobay.io: Output; // Just the Output class.
import parobay.io: Input, Output; // Just the Input and Output classes.
There are a few additional things to note about this.
Package and module names are conventionally all-lowercase.
It makes everyone's lives easier if the path to the file matches up exactly with its full module name. For example, module foo.bar.baz should be in the file foo/bar/baz.d.
In my experience, it's rare for a D module to be named after a domain name. You can prefix your module names with com or org or net if you really want to, but it's not expected like it is in Java.
Adam D. Ruppe's answer has some great points about explicit module declarations and class member visibility. It's also well worth reading the module and style pages on the official D website.
D community has three widely accepted alternatives.
Write a module named all.d which includes all modules from your package. (Literally '*' --> 'all'). After that you simply do import com.paroboy.io.all;
I see more and more that D developers use _ for this. So they write a module called _.d for this purpose. Similarly to #1, you do import com.paroboy.io._;
Relatively new addition to the D programming language is the package.d module, which can be used to import the package. More about this at the following DIP: http://wiki.dlang.org/DIP37 . If I remember well, DMD supports it since v2.064 . (Documentation: http://dlang.org/module#PackageModule)
I myself use the #1 approach because it is obvious what is going on. While #2 and #3 may be confusing to people reading D source file, especially the third one. A valid question someone may ask: "What the heck am I importing, package?? But import is only for modules!??"
Allthough nothing stops you from having separate module per-class, I would not recommend it. D is truly modular language, so take advantage of that. Group all your types in a single D module. That is my advice, and that is the "D way".
NOTE:
There is a (big) semantic difference between Java "module" and a D module, as you have probably already noticed. I am primarily a Java programmer, so I know how confusing this may be to Java programmers who are playing with D. Java classes in the same package quite often take advantage of the package-level access. However, classes within the same module behave like "friends" in C++.
Speaking about Java modules, they were supposed to come with Java 8 (true modules!), but were posponed and will hopefully be included in Java 9.
UPDATE: We reached conclusion, after a chat on FreeNode (IRC) with some members of the D-Programming-Language, that it is indeed safe now to use the package attribute. It behaves as the specification says.
I wonder if there is a way to use namespaces in the Go language in a similar way as Python does.
In Python if I have the following files containing functions:
/a.py
def foo():
/b.py
def bar():
I can access foo and bar in a third Python file as following:
import a
a1 = a.foo()
import b
b1 = b.bar()
I had some difficulties finding some documentation on namespaces with the Go language.
How are namespaces implemented in go? With package and import? Or is import dedicated to external libraries?
I think I understood that for each package there should be a dedicated directory. I wonder if this is absolutely mandatory, because it can become impractical whenever a high granularity of modules is the best way to engineer a certain idea. In other words, I would like to avoid using one directory per package (for internal use).
Go's equivalent to Python modules are packages. Unlike Python modules that exist as a single file, a Go package is represented by a directory. While a simple package might only include a single source file in the directory, larger packages can be split over multiple files.
So to take your Python example, you could create a file $GOPATH/src/a/a.go with the following contents:
package a
import "fmt"
func Foo() {
fmt.Println("a.Foo")
}
In your main program, you can call the function like so:
package main
import "a"
func main() {
a.Foo()
}
One thing to note is that only exported types and functions in a will be available externally. That is, types and functions whose names begin with a capital letter (which is why I renamed foo to Foo).
If you don't want to set up a Go workspace, you can also use relative paths for your imports. For instance, if you change the import in the main program to import "./a", then the source code for the a package can be located at a/a.go relative to the main program.