Re: Disputation of g0n on the power and efficacy of XS

Replies are listed 'Best First'.
Re^2: Disputation of g0n on the power and efficacy of XS by Tanktalus (Canon) on Apr 20, 2005 at 23:03 UTC
I think part of g0n's point is just the pain of getting the external libraries. For example, I'm attempting to get XML::Parser compiled on an AIX box to get XML::Twig to work. Now I have to track down Expat for AIX because, of course, Expat isn't included with XML::Parser. I may be misinterpreting the original post, but that's one point I read from it.	[reply]
Re^3: Disputation of g0n on the power and efficacy of XS by brian_d_foy (Abbot) on Apr 21, 2005 at 03:23 UTC
Those things have never seemed especially hard for me. Just how easy do you want things to be? I'm not sure why you have to track down expat: it's not tough to find. There are even binaries for AIX (which I found by Googling "expat AIX" and following the top link). I'd rather not have expat as part of XML::Parser. I'll download the latest version and compile it myself. The current version of expat doesn't have to get out of step with the one that would get locked in with a version of XML::Parser. I can even update them separately. Installing libraries isn't that hard, and installing a C compiler isn't that hard (although it can be lengthy). Distributing them with the modules isn't going to make that any simpler. The original post complains that we even deign to use something written in C, and correctly says that if you don't like it, you can upload the pure Perl version to CPAN. I'd rather just use what other people have already than reinvent the wheel. :) -- brian d foy <brian@stonehenge.com>	[reply]
Re^4: Disputation of g0n on the power and efficacy of XS by Tanktalus (Canon) on Apr 21, 2005 at 04:15 UTC
I think you're missing the point. The point is, when I have two dozen XS-based modules to install on multiple machines, especially of different architecture (Windows, Unix, Linux, Mac, mainframe) where each architecture comes with different levels of different supporting code (if it comes with it at all, e.g., Linux comes with expat, but AIX doesn't), that's a lot to pull together. Yes, it can be done. It's just a reasonable amount of effort to do. And then you get situations where you have to fight a beaurocracy to get it done on hundreds of machines that you don't otherwise even have access to, but they need something to use the perl software you wrote depending on it (directly or indirectly). Not that this is incredibly different if we were to be writing in C - depending on expat is depending on expat. However, there are way more people who understand C/C++ limitations and are willing to work with them than there are for perl - so it's just a struggle. And, of course, in C/C++, I find people are often less willing to reuse existing code, preferring to reinvent wheels. So then the issue doesn't come up as often.	[reply]
Re^5: Disputation of g0n on the power and efficacy of XS by brian_d_foy (Abbot) on Apr 21, 2005 at 05:42 UTC
Re^6: Disputation of g0n on the power and efficacy of XS by Tanktalus (Canon) on Apr 21, 2005 at 14:04 UTC
Re^4: Disputation of g0n on the power and efficacy of XS by jhourcle (Prior) on Apr 21, 2005 at 12:35 UTC
expat isn't a hard find, but it'd be possible that other modules may use more obscure programs, which may not be available as source, or may be outdated and not compile under the compiler suite that you have available. I wouldn't mind seeing better use of the DSLIP codes when searching CPAN, or for there to be a more consistent way for there to be checking in Makefile.PL to verify non-perl dependancies. Of course, it would be difficult to determine the versions of any non-perl requirements. (which I got stung on just last week -- Astro::FITS::CFITSIO requires cfitsio. I didn't think it a problem to install cfitsio through darwin ports. One of the tests failed for Astro::FITS::CFITSIO. After much frustration, I did a little searching, and stumbled across the main site for Astro::FITS::CFITSIO, which mentions: NOTE: version 2.500 of the cfitsio library is required. No where is this mentioned in the POD for Astro::FITS::CFITSIO. (and of course, darwin ports had an earlier version) expat is just the tip of the iceburg. Other modules may contain dependancies on Fortan, like cfitsio, or other languages, that might make it otherwise more complicated to install. It'd be nice for those modules that are just perl wrapped around another program, for there to be a way to find something that is a pure perl implementation, especially when you're trying to debug interaction issues. (eg, Mozilla::LDAP vs. Net::LDAP)	[reply]
Re^2: Disputation of g0n on the power and efficacy of XS by g0n (Priest) on Apr 21, 2005 at 08:33 UTC
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	[reply]
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.	[reply] [d/l]
Re^4: Disputation of g0n on the power and efficacy of XS by dragonchild (Archbishop) on Apr 21, 2005 at 13:34 UTC
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. My wife's blog	[reply]
Re^5: Disputation of g0n on the power and efficacy of XS by Anonymous Monk on Apr 21, 2005 at 14:31 UTC
Re^6: Disputation of g0n on the power and efficacy of XS by dragonchild (Archbishop) on Apr 21, 2005 at 14:35 UTC
Some notes below your chosen depth have not been shown here