Is there any library for the implementation of playfair cipher in dart? Just new flutter dev and have no idea about how the 2d matrix and other functionalities would be perform in dart.
Thanks
Here's an example for Java and by following the code, the only two libraries being used are:
import java.awt.Point;
import java.util.Scanner;
Point Class is available in Dart: https://api.dart.dev/stable/2.7.1/dart-math/Point-class.html
Also for Scanner:
https://api.flutter.dev/flutter/package-string_scanner_string_scanner/StringScanner-class.html
https://pub.dev/packages/string_scanner
For 2D Vector List you'd need to use something like:
List<List<String>> // or any other object
Other than that, I'm not seeing any limitations on Dart to make it happen.
If you're looking for already good implemented encryption libraries, you have:
PointyCastle
SQLCipher
Related
I'm looking at using NURBS surfaces with THREE.js,
and (what seems like older) documentation points
me to a THREE.NURBSurface class. Trouble is, I can't seem to find it in the official documentation, so I suspect it's been more recently changed.
So, my question is: under what name might I find such functionality, and where might I find a URL containing its documentation?
The class has still the name THREE.NURBSSurface. When using npm you can import it like so:
import { NURBSSurface } from 'three/examples/jsm/curves/NURBSSurface.js';
The class is undocumented so you don't find an entry in the official documentation. However, there is an official example that uses it: webgl_geometry_nurbs
I'm am trying to perform Instrumental Variable (IV) regression in Python. I saw online that the statsmodels.gmm package has the function I need (http://statsmodels.sourceforge.net/devel/gmm.html#), but when I ran import statsmodels.gmm as gmm in Python I get this error No module named gmm
. I'm using ipython with python 2.7.9. Any suggestions would be much appreciated.
GMM and related IV estimators are still in the sandbox and have not been included in the statsmodels API yet.
The import needs to be directly from the module
from statsmodels.sandbox.regression import gmm
Then, these classes can be accessed with, for example gmm.GMM
The main models that are currently available are:
GMM, IV2SLS, IVGMM, LinearIVGMM, NonlinearIVGMM
The mailing list has a recent discussion on the current status, and links to "secret" Gists
https://groups.google.com/d/msg/pystatsmodels/o6NY7qGrPw0/vzf897jy3vMJ
(I just found that the t_test doesn't work for a GMM model.)
I have a central package that provides several interfaces that other packages are dependent on (let us call one Client). Those other packages, provide several implementations of those first interfaces (UDPClient, TCPClient). I instantiate a Client by calling NewClient in the central package, and it selects and invokes the appropriate client implementation from one of the dependent packages.
This falls apart when I want to tell the central package about those other packages, so it knows what clients it can create. Those dependent client implementations also import the central package, creating a cyclic dependency which Go does not allow.
What's the best way forward? I'd prefer not to mash all those implementations in a single package, and creating a separate registry package seems overkill. Currently I have each implementation register itself with the central package, but this requires that the user knows to import every implementation in every separate binary that makes use of client.
import (
_ udpclient
_ tcpclient
client
)
The standard library solves this problem in multiple ways:
1) Without a "Central" Registry
Example of this is the different hash algorithms. The crypto package just defines the Hash interface (the type and its methods). Concrete implementations are in different packages (actually subfolders but doesn't need to be) for example crypto/md5 and crypto/sha256.
When you need a "hasher", you explicitly state which one you want and instantiate that one, e.g.
h1 := md5.New()
h2 := sha256.New()
This is the simplest solution and it also gives you good separation: the hash package does not have to know or worry about implementations.
This is the preferred solution if you know or you can decide which implementation you want prior.
2) With a "Central" Registry
This is basically your proposed solution. Implementations have to register themselves in some way (usually in a package init() function).
An example of this is the image package. The package defines the Image interface and several of its implementations. Different image formats are defined in different packages such as image/gif, image/jpeg and image/png.
The image package has a Decode() function which decodes and returns an Image from the specified io.Reader. Often it is unknown what type of image comes from the reader and so you can't use the decoder algorithm of a specific image format.
In this case if we want the image decoding mechanism to be extensible, a registration is unavoidable. The cleanest to do this is in package init() functions which is triggered by specifying the blank identifier for the package name when importing.
Note that this solution also gives you the possibility to use a specific implementation to decode an image, the concrete implementations also provide the Decode() function, for example png.Decode().
So the best way?
Depends on what your requirements are. If you know or you can decide which implementation you need, go with #1. If you can't decide or you don't know and you need extensibility, go with #2.
...Or go with #3 presented below.
3) Proposing a 3rd Solution: "Custom" Registry
You can still have the convenience of the "central" registry with interface and implementations separated with the expense of "auto-extensibility".
The idea is that you have the interface in package pi. You have implementations in package pa, pb etc.
And you create a package pf which will have the "factory" methods you want, e.g. pf.NewClient(). The pf package can refer to packages pa, pb, pi without creating a circular dependency.
Those dependent client implementations also import the central package
They should rely on another package defining interfaces that they need to rely on (and that are implemented by the first central package).
This is usually how an import cycle is broken (and/or using dependency inversion).
You have more options described in "Cyclic dependencies and interfaces in Golang".
go list -f can also help visualizing those import cycles.
I have no idea why people with me say this that don't use static import of Mockito methods while writing
unit test cases.
They say doing so may dramatically increase memory usage and caused build failures.
I want to know whether they are right or wrong. And please explain the reason behind it.
Please share links, thoughts or personal experiences.
Thanks.
I use the static import for a long time in my unit test. Static import from org.junit.Assert and org.mockito.Mockito. By doing this the syntax is more concise and my test is more readable.
There isn't any performance issue. This is just a syntactic sugar:
syntax within a programming language that is designed to make things easier to read or to express. (wikipedia)
You could have problem if you are importing two methods or constants with the same name.
Well in this case you will have to disambiguate.
But it is the same problem if you are using two different classes having the same name (You will have to use a qualified name).
import java.awt.List
...
java.util.List dataList = new ArrayList();
List viewList = new List();
I have a string with name of package (like "my/package/test") and I wanna import that and call some function from package.
Something like this:
func init() {
var pkg string = "test/my/pkg"
import pkg
pkg.Test()
}
PS. Thanks for help
The Go language does not allow what you mentioned in your example. This is a conscious choice. In my opinion, the reason behind this choice has to do with compiler performance and ease of code understanding by the machine. This for example enables tools such as gofix that can partially fix Go code without need for user intervention.
It also enables a programmer to clearly see all of the statically imported packages used by the program.
See also the grammar rules for source file organization in the Go language specification.
In relation to dynamically loading packages at run-time: Go has no support for loading packages at run-time. A future Go run-time might implement this feature (for example, it is occasionally being requested in messages in the golang-nuts mailing list), but the current state is that there is no support for this feature.
That's not possible in Go. The linker has to know the dependencies at compile-time, your string (and the init-function) are however evaluated at run-time. Also note, that parts of your programs which are not used, i.e. everything which isn't referred explicitly, wont even be part of the final binary - so reflection is not possible either.
If you need something like that, you have to manage the mapping on your own. You can for example use a global map in one package and use the init functions in the other packages to register the relevant functions, by adding them to the map. After that, you can use the map to do your look-ups dynamically.
Take a look at the http package for example. In a fictional blog package you might use the blog.init() function to register a couple of http handlers using the http.HandleFunc(pattern, handler) function. The main package then might call http.ListenAndServe() which looks up the right handlers at run-time.