I have written a one-time pad encryption module that can also generate pads. I have read that Haskell comes with some kind of cryptographically secure random number generator, whose module name contains "Crypto". So I use my GHCi and type "import " and tab to bring up all of the possible imports. There is no Crypto module, only the plain old Random. I explicitly try to import "System.Crypto" and then, just "Crypto"; no luck. I perform a text search with Power Shell on the results of the autocomplete, but it finds no applicable entry. Where is the cryptographic random number generator? If I don't have it, where can I get it? Am I imagining things?
Details:
GHCi
version 7.6.3
Windows 7
Haskell does not "come with" a cryptographically secure random number generator, if by that you mean it should be included in the Haskell Platform.
Searching for "crypto" on Hackage throws up a number of packages you can install with Cabal, though. I'm not well versed in those but the top crypto-random one looks promising. This doesn't necessarily mean much, though. Although Hackage is the place to find most things Haskell, unfortunately it doesn't yet have good features to find out which of its packages are actually high quality. (This is expected to improve as the new Hackage 2 implementation is much more flexible than the old one.)
If you installed Haskell platform, you can find all libraries out of box here.
I find there is a System.Random package which has a global random number generator. The global random number generator is initialized automatically in some system-dependent fashion, for example, by using the time of day, or Linux's kernel random number generator.
Or you can use other packages by cabal install such as crypto-api.
Related
Now I have a decent knowledge of math, and I know it's possible to create pseudo-random sequences using a specific mathematics algorithm. I also know that in Python, there is a secrets module that apparently can produce random numbers. I tried tweaking around with it a little, but I still don't understand how it's supposed to work. Lets say this piece of code:
import secrets
secret_num = secrets.choice([1, 2, 3])
print(secret_num)
It's supposed to output a perfectly random number. But how is that possible using computers?
The documentation for the secrets module says it produces "cryptographically strong random numbers suitable for managing data such as passwords, account authentication, security tokens, and related secrets". The documentation doesn't specify how it does so exactly.
However, a usual requirement for "cryptographically strong random numbers" is that they should be hard to guess by outside attackers. To this end, the secrets module may rely on the random number generator provided by the operating system (as secrets.SystemRandom does, for example), and how that generator works depends in turn on the operating system. But in general, a random number generator designed for information security ultimately relies on gathering hard-to-guess bits from nondeterministic sources, as further explained in the following question:
How to get truly random data, not random data fed into a PRNG seed like CSRNG's do?
New to Python and come from a statically typed language background. I want type hints for https://lxml.de just for ease of development (mypy flagging issues and suggesting methods would be nice!)
To my knowledge, this is a python 2.0 module and doesn’t have types. Currently I’ve used https://mypy.readthedocs.io/en/stable/stubgen.html to create stub type definitions and filling in “any”-types I’m using with more information, but it’s really hacky. Are there any safer ways to get type hints?
There is an official stubs package for lxml now called lxml-stubs:
$ pip install lxml-stubs
Note, however, that the stubs are still in development and are not 100% complete yet (although very much usable from my experience). These stubs were once part of typeshed, then curated by Jelle Zijlstra after removal and now are developed as part of the lxml project.
If you want the development version of the stubs, install via
$ pip install git+https://github.com/lxml/lxml-stubs.git
(the project's readme installation command is missing the git+ prefix in URL's scheme and won't work).
Recently I have done much more gap filling based on lxml-stubs with some good progress.
Welcome to check out types-lxml if any late comer are still interested. For most people I think lxml.objectify is the only missing piece lacking from the stubs, which is planned immediately after current release.
I’ve used stubgen to create stub type definitions and filling in “any”-types
This is actually the correct approach if it's not lxml; creating template from mypy stubgen is the starting point for many stub files. But lxml is mostly written in Cython, for which stubgen do not have perfect support yet. Besides as OP noted, this is a python 2.0 era module, and author uses function arguments in a quite polymorphous way. There are lots of unique challenges annotating lxml, as lxml is essentially a python interface for libxml and libxslt in its core.
As an example, the support of both unicode and bytes input complicates matter too; this is the same difficulty found when annotating xml.etree bundled with python, but in a much greater magnitude.
I would not call this "hacky", rather it is gradual typing.
You can take a closer look at lxml-stubs repository. From about:
This repository contains external type annotations (see PEP 484) for the lxml package. Such type annotations are normally included in typeshed, but lxml's annotations were frequently problematic and have therefore been deleted from typeshed. In particular, the stubs are incomplete and it has been difficult to provide complete stubs.
Perhaps it will be useful to you
I don't know the best way to solve a simple (probably) problems (hackage related).
I asked for help about it (http://stackoverflow.com/questions/12841599/haskell-hackage-ghc-and-productivity-what-to-do) but I knew not explain well.
Today, I'm with a this kin problem.
The concrete problem isn't relevant, but is it:
`Write a function that, given a string, remove diacritics.`
Example:
`simpleWord "Cigüeñal" <-> "Ciguenal"
The correct way (I think) is to use the standard Unicode normalization. In some languages/frameworks (.Net, PHP, Python, ...) exist some related function.
In Haskell, thanks to hackage community exist too:
`Text.Unicode.Normalization.normalize`
But, I couldn't install with (eg) ghc-7.4 but compact-string (that depends of) fail.
A fix for compact-string exists (compact-string-fix) then: can't I use cabal to install (directly)?, should I download and patch it?, should I look for another alternative to function about?
I explained a concrete real case (simple or complex, don't care), the question (that I ask help for) is how can, a novice haskeller, know the best way to select correct libraries, ghc correct (balanced) version, without hit a wall.
I'm really lost about it.
Really, thank you very much for any suggestion.
Best regards.
The documentation for compact-string says, "This package is obsolete. Use text instead.".
The documentation for text says, "To use an extended and very rich family of functions for working with Unicode text (including normalization, regular expressions, non-standard encodings, text breaking, and locales), see the text-icu package.".
The documentation for text-icu shows that it successfully builds on GHC 7.4 and has support for Unicode normalization.
Here's the general process I follow when deciding which packages to use. First, I try to identify multiple packages that meet my needs. Then I look more closely at each package to try to determine which ones are the best for me, according to the criteria listed below.
It's usually better to use packages that are currently maintained. To determine if a package is currently maintained, I check the "Upload date" link on the package description page. (Of course, there are some old tried-and-true packages that haven't been modified in ages because they don't need modification.)
It's usually better to use packages that are mature, so I check the version number on the package description page. A package with a version number of 7.3.5 is probably more mature than a version 0.1 package.
It's usually better to use packages that are well documented. Sometimes there's a nice example of how to use the package in the Haddock documentation (yay!). I'll also check the "Home page" link on the package description page, because often there will be more documentation there.
It's usually better to use packages that are popular, because any problems will probably be addressed quickly, and other users can answer questions. I'll usually do a Google search and see whch packages are mentioned most often on Haskell mailing lists and StackOverflow.
It's usually better to use packages that don't require a lot of packages I don't already have, so I check the "Dependencies" section on the package description page.
I tend to follow this procedure when choosing a package for any programming language, not just Haskell.
I'm in the process of generating a Haskell documentation set for Dash (http://kapeli.com/dash).
I'm trying to index the documentation found at http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/index.html, and there seems to be a complete index at http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/doc-index-All.html.
However, there seem to be a lot of libraries (base, ghc and haskell2010 are some I found), libraries which duplicate the same functions (as far as I can tell).
Which libraries should I index? What would you expect to find in a Haskell documentation browser?
Thanks!
You should cross-reference against base. The other libraries such as haskell2010 only exist to provide stable standards against older versions of the language. ghc is a developer library only, that I wouldn't expect you to be targetting.
I think there are two different issues here.
Which modules to index?
Well, if you manage to index the whole hackage, and keep your system convenient to use with so many functions, that'd be cool and very useful.
Otherwise, you can restrict yourself to the packages in Haskell Platform.
Function duplication
In Haskell modules can re-export entities (functions, types) defined in other modules. This is not specific to base vs haskell2012.
I don't know what interface you provide in your docs browser, but you could display all modules in which the entity is found. This is what Hoogle does: http://www.haskell.org/hoogle/?hoogle=Int (see the first entry there).
In lots of Haddock-generated module documentation (e.g. Prelude), a small box in the top-right can be seen, containing portability, stability and maintainer information:
From looking at the source code to such modules and experimentation, I confirmed that this information is generated from lines like the following in the module description:
-- Maintainer : libraries#haskell.org
-- Stability : stable
-- Portability : portable
There are several strange things about this:
The fields only seem to work in this order — any fields put out of order are simply treat as part of the module description itself. This is despite the fact that the order in the source file is the opposite of the order in the generated documentation!
I have been unable to find any official documentation of these fields. There is a Cabal package property named stability, the example values of which match the values I've seen in the equivalent Haddock fields, but beyond that, I've found nothing.
So: How are these fields intended to be used, and are they documented anywhere?
In particular, I'd like to know:
The full list of commonly-used values for Portability and Stability. This HaskellWiki page has a list, but I'd like to know where this list originated from.
The criteria for deciding whether a module is portable or non-portable. In particular, the package I would like the answers to these questions for, acme-strfry, is an FFI binding to strfry, a function only available in glibc. Is the package non-portable, because it only works on glibc systems, or portable, because it does not use any Haskell language extensions? The common usage seems to imply the latter.
Why a specific order of fields is required in the source file, and why it's the opposite of the ordering in the generated documentation.
Oh, I thought those fields were from the cabal package description. They don't seem to be documented at all on Haddock's docs. I've found this, which doesn't really answer your question but:
http://trac.haskell.org/haddock/ticket/71
So if it's freeform anyway, why not just write "non-portable (depends on glibc)"? I've seen even "portable (depends on ghc)", which is odd. I also wonder what happens with modules that were non-portable due to non-Haskell98 extension Foo, after Foo was added to Haskell 2010.
Note that the Cabal documenation you link to also says stability is freeform. Of course, even if haddock or cabal were to define what are the acceptable values, it'd still be up to the maintainer to subjectively select one.
About the specific order, you should probably just ask at the haddock mailing list, or check the source and file a bug.
PS: strfry is an invaluable contribution to the Haskell community, but it should be pure and portable, don't you think?
Ah yes, one of the more obscure and crufty features of Haddock.
As best as I can tell, it's just an undocumented hack. There's no sane reason why the order of the fields should matter, but it does. The specific choice of formatting (i.e., as a special form inside the module comment rather than as a separate block of some kind) isn't the best either. My guess is that somebody wanted to quickly add this feature one day, so they hacked up something minimal but functioning, and left it at that. (Without bothering to document it.)
Personally, I just don't bother with these fields at all. The information is available from Cabal, so I don't bother duplicating it in Haddock as well. Perhaps some day Cabal will pass this information to Haddock automatically...