in reply to Re: Disputation of g0n on the power and efficacy of XS
in thread Disputation of g0n on the power and efficacy of XS

It sounds like your problem is access to a C compiler, not authors using XS. That problem isn't the availability of a C compiler for your platform, however. It's a social problem outside of technology.

Yes, that's exactly my problem. However, there are occasions when companies are not prepared to pay for a license for a c compiler, and not willing for whatever reason (anti open-source, excessive rootkit paranoia etc) to have gcc installed on their machines. Saying that's soooo stupid may be true, but it doesn't get us very far.

Moreover, in a company the size of the one I'm currently contracted to (>100k employees) policies do not change easily, and certainly not at the instigation of contract developers (who in the company hierarchy rate somewhere below the office cat).

Perl is an open source community and code re-use is rampant and appropriate. I'd rather see a module use a widely used and well maintained C library than reimplement it and fall into disrepair. You mention openssl: when the C library that most people use has a new version, I don't have to wait for a Perl version to catch up. I don't have to watch parallel evolution in code that does (or should do) the same thing.

OK, maybe openssl was a bad example, and I quite agree that its better to use a 'widely used and well maintained C module'. I'm suggesting that a) it would be useful for those occasions where compiled C is difficult or impossible to implement to have a pure perl alternative, where possible; but mainly b) that it would make life a lot easier to know when a module has a C/XS dependency. I know that's tricky, for the reasons I set out in my OP - that's why I raised the point for discussion.

Although it would be nice to have a way to select different implementations of things at a low level, and the programmer level I just want to use the same module name everywhere and know I'll get some implementation of it. If the local machine has the C implementation, I get the speedy C implementation. If it has the pure Perl implementation, I end up using that without changing my script.

Again, I agree, and I'm trying to do something of the sort in one of my modules, but at the moment I'm engrossed in improving functionality in the pure perl implementation.

g0n, backpropagated monk
  • Comment on Re^2: Disputation of g0n on the power and efficacy of XS

Replies are listed 'Best First'.
Re^3: Disputation of g0n on the power and efficacy of XS
by Anonymous Monk on Apr 21, 2005 at 09:13 UTC
    it would make life a lot easier to know when a module has a C/XS dependency.
    That's pretty trivial, isn't? Configure CPAN.pm to automatically follow dependencies. Do a perl -MCPAN -e'test Module'. If it has a C/XS dependency, it fails. If it doesn't, it either success, or some other error pops up.

    Yeah, it takes a few minutes more than looking it up a table. But it's hardly more work, and you're certain the answer will be accurate.

      This assumes, of course, that you don't mind potentially having a bazillion new modules installed somewhere on your machine. It also requires that the machine you're working on has a direct connection to the Net. The machines I work on (I'm also a contractor) are firewalled. My PC has a direct connection and I download CPAN modules to it and then FTP them to the dev servers. So, it'll be just a wee bit more work than you imply.
        This assumes, of course, that you don't mind potentially having a bazillion new modules installed somewhere on your machine.
        I fail to see what the problem is. Note that I wrote "test Module". Not "install Module". It means that dependencies get installed in your CPAN build area. If you're done, it's just a matter of removing the build area. Of course, if you decide to install the module, and said module has a bazillion dependencies, you'll have to install them. If you don't want to, it doesn't really matter whether there's an XS dependency.
        It also requires that the machine you're working on has a direct connection to the Net.
        No it doesn't. There are many scripts floating around on the net that will create you a "lite-CPAN" - which contain all the modules of CPAN, but the most recent version only, and doesn't include full perl distros. The result is small enough to fit on a CD. Of course, you can figure out the XS dependency from you net connected PC as well. Note also that getting the modules from CPAN is a problem unrelated to any XS depencies. If there wasn't an XS dependency, you still need to get them.