Testing an FTP module
I just uploaded to CPAN some FTP-related modules (Net::FTP::AutoReconnect and Net::FTP::RetrHandle). In one of the unit tests, I connect to ftp.cpan.org and retreive MIRRORED.BY to make sure everything works OK. Just in the last little bit, though, I've noticed that a connection to ftp.cpan.org is timing out. So my questions are: * Is ftp.cpan.org a reliable way to access CPAN? Is there a more reliable way, besides looking and MIRRORED.BY? * Is testing by connecting to CPAN an appropriate thing to do? * If not, what's a better way to do unit tests for a network protocol? Thanks for any thoughts! ---ScottG.
Releasing slower pure-perl module and faster Inline::C version
Hello,
Some quick background: I've got some code I use that does a lot of
distance calculations. I found that a limiting factor for me was the
time it took to do a great circle calculation, a trigonometric
calculation of the distance along the surface of a sphere (see
Math::Trig::great_circle_distance). I rewrote that function in C
using Inline::C, and achieved a substantial speedup (a 300% speedup
for the great circle calculation, resulting in about 30% overall
speedup). So I actually do have an application that cares about the
speed of this function, and I have benchmarked and the Inline::C
version is substantially faster.
I'm interested in releasing the Inline::C version of this code.
Because it's often called from within modules, I'd like to make it
easy for module authors to use the accelerated version if it's
available, but without limiting their support to platforms that have a
compiler and Inline::C.
I think the easiest way to do this would be to release the Inline::C
version as Math::GreatCircle::Fast and a pure-perl version as
Math::GreatCircle. Math::GreatCircle would check for an installation
of Math::GreatCircle::Fast, and if it found it would override all of
its own functions with the C equivalents from the accelerated module.
That would allow module authors to simply say use Math::GreatCircle
in their module and PREREQ_PM = {Math::GreatCircle=0} in their
Makefile.PL, and they'd get the fast version if it was available,
without having any dependencies on Inline::C or a compiler. If a user
needed the faster distance calculations, they could install
Math::GreatCircle::Fast; otherwise things would still work OK, but a
little slower.
The functionality of Math::GreatCircle would be pretty much the same
as Math::Trig's great circle functions; primarily it's a wrapper for
Math::GreatCircle::Fast.
Does anybody see any problems with, or have any objections to, this
approach?
Thanks for any thoughts,
---ScottG.
Re: RFC - Test::Stupid module
David Baird [EMAIL PROTECTED] writes: On 8/19/05, Andy Lester [EMAIL PROTECTED] wrote: On Fri, Aug 19, 2005 at 03:21:00AM -0700, David Baird ([EMAIL PROTECTED]) wrote: Maybe you could combine these techniques to keep it really simple for the really stupid. How about if we get off our thrones and stop referring to people who take the time to put out their code on CPAN as really stupid? Sure, but the point remains, perhaps better stated as make it really easy for the really lazy, including me. I'm all in favour of modules that help *me* not make an ass of myself. We're all potential victims of our own stupidity. Maybe Test::BrownPaperBag would be a good name, since the goal is really to help module authors avoid making embarrassing mistakes. From the Jargon File: brown-paper-bag bug: n. A bug in a public software release that is so embarrassing that the author notionally wears a brown paper bag over his head for a while so he won't be recognized on the net. Entered popular usage after the early-1999 release of the first Linux 2.2, which had one. The phrase was used in Linus Torvalds's apology posting. Scott.
Namespace question: Ekahau location sensing system
Hello, I'm finishing up a module to interface with the Ekahau location sensing system, and I'm trying to figure out a good top-level namespace to put it in. I felt confident people here would have opinions. :) Ekahau is a system that provides location estimates based on a vector of wireless signal strengths, a large set of training data, and a proprietary Bayesian-like statistical model. My module interfaces with it using their own protocol, which runs on TCP and smells a little like XML. I'm tempted to release it as simply Ekahau::*, since a new toplevel namespace seems to be the preferred place to put interfaces to proprietary systems. I considered Net::Ekahau, but it seems plausible to me that Ekahau could release a version of their software that communicated over IPC or a serial port, so I think that's not a great idea. I considered creating a new topleve namespace LocSys for location-sensing systems, but that seems premature, since I don't see any other modules for interfacing with these sorts of systems, and I don't plan on writing any more myself in the immediate future. So: Does anybody have any objections to a new top-level Ekahau namespace, for interfacing with proprietary equipment from Ekahau? ScottG.
Re: Including a 480K data file with a module
Hugh S. Myers [EMAIL PROTECTED] writes: I've a similar although smaller situation with one of my modules and I finally decided that the only platform non-dependant solution was to keep the DB in question in the install tree of the module. That way it is the same regardless of OS. That's what I did, too. I couldn't find another straightforward way to figure out a good place to put it, and where I could find it later. ScottG.
Re: Including a 480K data file with a module
_brian_d_foy [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], Scott W Gifford [EMAIL PROTECTED] wrote: Why not just leave it uncompressed, and let the compression of the whole package into Geo-PostalCode-US-0.1.tar.gz take care of compressing it? I recommend not doing that. I had a lot of problems distributing the data for Business::ISBN with the code. Most notably, installing the module overwrote any updated data the user had added. If the user has custom data, they would just install Geo::PostalCode and build their own database (it includes a short script to do this, and the process takes about 2 minutes). Geo::PostalCode::US doesn't replace Geo::PostalCode, but just adds a second module with the data. -ScottG.
Re: Including a 480K data file with a module
Chris Josephes [EMAIL PROTECTED] writes: [...] 2. Include a make install-data target that will unzip the data, and then install it in a standard location your module will search by default. Would /usr/share/postal/us be a bad place? Is anyone else doing this? The problem is that you can't easily do this from perl -MCPAN -e shell. None of the objections I've seen so far have related to the size of the data. There have been many concerns about the freshness, but because of how rarely it's updated (every 10 years) and the lack of a standard way to get and process the data, I think that there isn't really a better alternative. There have been many concerns about having to re-distribute the data when the code changes, or the code when the data changes, but the data is in a seperate module with very little code (26 lines), so I don't really think that's a problem, either. If you have any objections about the size of the file, or any other objections that haven't been brough up already, let me know; otherwise I'll recommend to TJ that he upload the Geo::PostalCode::US module with the data. Thanks for all the feedback! -ScottG.
Re: Module naming advice
Ovid [EMAIL PROTECTED] writes: [...] That fails because it makes the common case more difficult: use aliasing Really::Long::Class:Name; # or use aliasing Really::Long::Class:Name, as = CName; However, I do like the name aliasing.pm Anyone else? It's not perfect, but the one that reads the most naturally class, seems to not be favored by people. What about something like 'shortname': use shortname Really::Long::Class::Name; use shortname CName = Really::Long::Class::Name; or use shortname CName for Really::Long::Class::Name; It's confusing to have unrelated modules called Alias and aliasing. ScottG.
Re: Including a 480K data file with a module
A private emailer wrote: [...] Even better isn't all this on a USPS server? Whatever tool you use to grab their server database, include it and do that as part of the build process or perhaps offer it as an option , the alternative being to go to the USPS server every time. Three things I don't like about that. First, it gives a single point of failure for the system, as compared to relying on CPAN's large network of mirrors; worse, it would break if USPS's server ever changed the file location or format. Second, if you want to use something like CPAN on CD to install onto a non-Internet connected machine, downloading from an external server will break; you'll have to arrange for that one file to be copied over and installed by hand. Third, if you cache CPAN modules for installation to many machines, this will bypass the cache. Andy Lester [EMAIL PROTECTED] writes: [...] I'd be more concerned about the updates. Make ::Data subdistro of it, like brian d foy has done with Business::ISBN and Business::ISBN::Data. Right, the data is in a new module called Geo::PostalCode::US; Geo::PostalCode is the main module. The code for Geo::PostalCode::US is 26 lines plus some cleverness in Makefile.PL, so I'm not too concerned about seperating code and data for this module. When the code updates, you don't have to push out half a gig again. Just to be clear, it's half a meg; I wouldn't put half a gig onto CPAN. Chris Josephes [EMAIL PROTECTED] writes: [...] Is the data currently encoded in a standard format? How difficult is it for end users and developers to get updated copies of the data. [...] One concern I would have is how dependent would your users be on you to be the primary provider of the data updates? The main Geo::PostalCode module provides easy instructions for generating your own location database from a simple tab-seperated value file. Geo::PostalCode::US is just for easier download and installation. Would updates always be in the form of a re-versioned perl module? Yes. They'd be very infrequent. The data we're using now is from 1999. I'm working on this in response to a user on PerlMonks who had a very difficult time getting Geo::PostalCode installed and set up right on a hosting provider. It's much nicer to be able to install it with the standard perl Makefile.PL; make; make test; make install. ScottG.
Re: Namespace for Z-machine parse/translate module
Randy W. Sims [EMAIL PROTECTED] writes: Amir Karger wrote: [...] * Games::Zmachine - well, Z-machine isn't technically just for games. [...] This is the namespace I'd expect to find it in This is also where I would expect to find it. ScottG.
Re: META.yml keywords (was: Re: Finding prior art Perl modules)
Mark Stosberg [EMAIL PROTECTED] writes: [...] The search algorithm could pay attention to the first X keywords and ignore the rest. Or at least, it could heavily weight the first few. I think this is part of how search engines prevent the same kind of above of the meta-tag keyword system. You can put as many keywords as you want into the list, but I think the search engines only really care about the first few. My understanding is that nowadays, most search engines ignore keywords altogether, because they were so badly abused they became worthless. ScottG.
Re: New module: Regexp::Trie
Sounds like cool stuff!
David Landgren [EMAIL PROTECTED] writes:
[...]
2. Is Regexp::Trie a good name? (I fall into the regexp is spelt with
a p camp, but if Regex is preferred that's fine by me. I can never
remember which, if either, is deprecated).
There are 688 modules with Regex in their name, and 582 with Regexp,
so I don't think a clear consensus has emerged. :)
I personally think ::Trie is a bit technical; a user who needs this
module isn't likely to search for 'Trie', or find this by browsing
among the other 582 modules with Regexp in their name. I would think
Regexp::Optimize{,r,d} would be better names, but that's just MHO.
3. Is the lexer namespace a good idea? Or is there a better way do to
this? I'm open to any design suggestions on this issue since nothing
is written yet.
shrug It depends on whether you foresee a large number of Lex
modules being required, or updating the Lex portions of your module
independently of the Regexp::Trie portions. If either of these seem
likely, it's a good idea; otherwise it's just an implementation
decision.
-ScottG.
Re: ANNOUNCE: WWW::Map 0.01
Dave Rolsky [EMAIL PROTECTED] writes: [...] Right now I'm leaning towards either keeping WWW::Map or going with WWW::MapService. I think the former is actually reasonably clear given the WWW namespace, which is all about interacting with web stuff, not generating HTML or anything like that. I like WWW::StreetMap, since that's exactly what they are, and is short and unambiguous. I don't think WWW::MapService is much better than WWW:Map, but then again I don't think WWW::Map is that bad. :) ScottG.
Re: ANNOUNCE: WWW::Map 0.01
Dave Rolsky [EMAIL PROTECTED] writes: On Fri, 10 Jul 2004, Scott W Gifford wrote: Right now I'm leaning towards either keeping WWW::Map or going with WWW::MapService. I think the former is actually reasonably clear given the WWW namespace, which is all about interacting with web stuff, not generating HTML or anything like that. I like WWW::StreetMap, since that's exactly what they are, and is short and unambiguous. I don't think WWW::MapService is much better than WWW:Map, but then again I don't think WWW::Map is that bad. :) Calling it StreetMap would definitively remove the possibility of making links that aren't to actual addresses, which as someone pointed out, is possible with at least MapQuest. I disagree. I can go to a local gas station and buy a street map of Flint without knowing a particular address. You can plug in Minneapolis, MN and it'll give you a map of the area. Right, but it will give you a street map of the area, as compared to a topological map, a population map, or some other kind of map. I guess if you were to type in an area with no streets (Lake Michigan, MI; Mojave Desert, CA; The Moon) it wouldn't be much of a street map, but I can't find a way to type that into MapQuest anyways. :) ScottG.
ANN: rfid-perl 0.002
I've written some Perl modules for interfacing with RFID readers, and I thought I'd post here to see if anybody has any thoughts or feedback. They're on CPAN as RFID::*, and we have a Web page at: http://www.eecs.umich.edu/~wherefid/code/rfid-perl/ Thanks for any comments, criticism, ideas, etc. If you're interested in these modules in particular, please consider joining the rfid-perl mailing list; information is on the above Web page. Here's a summary of the modules: The rfid-perl modules aim to provide a consistent interface to RFID readers, so that code can be written that will work with many types and brands of readers. Part of that goal is making it straightforward to write new drivers. Currently, we support two readers (Matrics and Alien), and much of the code to support both the readers is factored out into base classes. Each of the driver classes took about a week and 1,000-2,000 lines of code to write and test. We suspect that adding other drivers will take similar amounts of code and time. We also support creating and parsing EPC tags, according to the specifications from EPCGlobal. This is currently beta-quality software, but we're using it on a day-to-day basis without problems. It is tested on Linux and Windows, and is written in pure Perl, so it should run anywhere Perl does. ScottG.
