Api can used to translate text using Yandex, It can translate 94 languages. Yandex.Translate (previously Yandex.Translation) is a web service provided by Yandex intended for the translation of text or web pagesinto another language. The service uses a self-learning statistical machine translation, developed by Yandex. The system constructs the dictionary of correspondences based on the analysis of millions of translated texts.

This is yet another email address validation module. The main goal is support RFC 6531 (UTF-8 email addresses). And this is default mode of the module.

The major part of the code written in C and there is the separate library called libeav which may be embedded in any application, not just Perl.

Actually, the libeav supports all email address specifications as described in RFC 822, RFC 5321, RFC 5322 and RFC 6531. Also it can be easily modified for your tastes.

This module checks "addr-spec" and does not the "address" specification as many modules does already. See details below:

address = mailbox / group
mailbox = name-addr / addr-spec
addr-spec = local-part "@" domain

So far the only languages to interface with Zhinst devices were Matlab, Python, LabVIEW, .NET and C.

This module adds the desperately needed Perl interface and will allow us to write high-level Lab::Measurement drivers.

My first XS code...

Any feedback appreciated!

Update: Now uploaded to CPAN:

MetaCPAN

search.cpan.org

Perl gives access to the user's shadow password itself via getpw*, but the rest of the shadow entry is not available (expire is theoretically available if compiled that way, but it isn't universal). This module provides a Perl interface to the shadow routines getspnam, getspent, setspent and endspent, allowing the full shadow password structure to be returned. Like all access to the shadow files, root privileges are required to return anything - non-root users get nothing.

Hi,

binary.com needs full-powered FIX 4.4. protocol. There are a few exising FIX implementations in CPA:

1) https://metacpan.org/pod/FIX::Lite

2) https://metacpan.org/pod/Finance::FIX

3) https://metacpan.org/pod/FIX::Parser

1) is not transport-layer neytral. I.e. it opens underlying socket connections etc. So, it is not suitable for server-side usage, e.g. in conjunction with Mojolicious.

2) Seems just and intention for implementation. It does nothing, as I can see.

3) Is another binary.com module, but it provides only encoding, i.e. without any knowledge about Fields, Groups etc.

The new module Protocol::FIX will be constructed on fly from xml description of the protocol ( taken at http://www.quickfixengine.org/ , targeted at 4.4 version for nwo).

Something like WWW::Mechanize::GZip.

Differences:

(1) Subclass LWP::UserAgent, not WWW::Mechanize.

(2) Use Gzip::Faster for compression tests

(3) Offer functions which can easily be added as "ok ($obj->is_compressed ())", etc. for Test::More compatilbility.

I would be interested to hear about

• Any other modules which do the same thing.
• Proposed added tests;
• Websites offering this service would be useful.
• Better naming or naming more consistent with Perl conventions.

This library provides access to the BigWig and BigBed file formats designed by UCSC. However rather than use kent libraries this uses libBigWig from https://github.com/dpryan79/libBigWig as it provides an implementation that avoids exiting when errors happen. libBigWig provides access to BigWig summaries, values and intervals alongside providing access to BigBed entries.

1) Sometimes I feel like applying a series Test::More-like checks to user input, dynamically loaded plugin, object instance being passed etc. Unfortunately, Test::Builder makes it impossible without turning the whole application into a test script. Hence this OO interface.

2) Instead of using ok($condition, $message) as a foundation, this module uses a refute statement which is an inverted assertion. I.e. if everything is OK, we only need 1 bit of information; if something went wrong, we need more details. Think of Unix programs returning 0 on success and different error codes otherwise.

This way, extending the test arsenal becomes much simpler: a test function may know nothing about the test framework, it ONLY needs to try hard to find a discrepancy in its own arguments (aka pure function). A builder module is available that imports user's test subroutines into the main module.

3) Also supported: subcontracts to group complex checks, functional interface (Test::More compatible), checking that contract is fulfilled to exactly the given extent (useful for testing the test routines themselves).

C compilers typically don't warn about daft mistakes like putting function arguments in the wrong order, or using the wrong size of a variable, or things like not checking the return value of malloc, etc. This module would check for typical errors in C programs like switch fallthroughs, use of equals instead of == in an if statement, insist on using braces with if statements, bad if statement indentation, like

if (x) 
      printf ("reached");
      printf ("reached even if x is not true, despite this indentation");

etc.

At the moment I have a script which does something like the above, wondering whether it would be worth working up into a module.

I've been developing a C program which indexes files by making trigrams of the contents of files. It's working reasonably well now and I'm thinking of extending it to a Perl version which could be used to index files, database entries and other things.