Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)


My email address is Spam me harder! *moan*

Journal of scrottie (4167)

Tuesday October 23, 2007
04:53 PM

ActiveState sucks (a brief survey of Perl compilers)

[ #34742 ]

Yes, I'm aware that writing a series of aricles titled in the format of "$x sucks" makes me a troll. Maybe I'll write later that "trolls suck" and lament that even when trying very hard to approach delicate topics delicately, some people, such as myself, generally fail miserably and are confronted with a choice of not approaching delicate topics at all (a popular choice) or living life as a troll. But that's neither here nor there. Perhaps a better title would be "any attempt to compile Perl results in suckage". Anyway...

So, I've got this project. It involves physical gaming machines installed at real casinos in Vegas -- pretty damn neat. In order to accomplish this, all systems including all code must be approved by the Navada Gaming Commission. Many, many, many things are required for that to happen, but one of them is that all code must be compiled.

"That's dumb!", a thousand voices cry in unison. It's security through obscurity. The effect it has on C code, that of badly mangling it, it doesn't have on Perl. With minimal effort, a good faximilie of the original can be reproduced. But regardless, we need this.

Perl's built-in B::Bytecode (perl -MO=Bytecode) unearthed a string of coredumps, some from the compiler, some from the compilee. Anyway, I've come around to needing to explore this more. Likewise, par and pp utterly fall down, but Bytecode filtering is marked as depricated, so I'm not filing any bug reports there.

People involved in the project before me settled on IndigoStar's compiler. It threatens to work pretty well, but then exhibits brain damage where least expected. Regexes inexplicably fail, and comparisons come out wrong. $^O, printed out, clearly says "linux", but $^O eq 'vms' on my Linux laptop comes back true, taking the VMS case on an if statement. But trying to use a module that uses another module utterly fails, no matter how many #perl2exe_include lines you put in. Argh!

That brings me to ActiveState Perl. There are a lot of fly by night sites that have good graphic design but were clearly done by complete kiddies. I know ActiveState employes well known and well respected Perl personalities, but they send off this vibe, big time. First stop, they make you make an account. Ghetto, lame, but whatever. Download the product. Next step, documentation. Hmm. None of the four or five nav bars say anything about documentation but there's a search bar. Search for documentation: exy&cof=FORID%3A11&q=%A0documentation&sa.x=0&sa.y=0

Zero results.

Okay, the documentation is probably in the tarball. In fact, there's a Welcome.txt, telling me exactly where to find the documentation:

    Please see the PDK User Guide at %%HTMLDIR%%/index.html

cd '%%HTMLDIR%%'. No such file or directory. Alright, probably just a string of glitches. Taking an educated guess and doing some find'ing, I cd into pdk/share/doc/HTML/en/pdk where there's an index.html. I fire up w3m on it. There is a blank page, save for two gif logos. My heart skips a beat. Then I realize that w3m doesn't do JavaScript or Flash, and it's probably an intro page. Firefox. Nope. index.html really is blank.

Version seven of this "perl development kit" thing. Maybe version eight will offer documentation. Originally I hadn't thought to air this bit of dirty laundry and go be a troll. I was going to tease them a bit for their profound bit of silliness and failed at that too. I clicked on contact, and even though I had made an account and "logged in" so I could download the thing, it informed me that I hadn't verified my account and offered to resend the verify email, which I did. Ten minutes later, still no email from them shows up. I bet they don't get a lot of feedback...

So, after this long, tedious, painful journey of Perl compilers not working right, do I really want to try one that has a whole site that doesn't work right and no documentation to be found?


Next question. It's almost impossible to write secure C, and it's very tedious to do anything in it. I hate Python but it compiles well. I don't know about compilation in Ruby. Java is extremely tedious but an option. Dear reader, if I have to rewrite this project just to make it compile, what language should I use?


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • "perl" is compiled...the "program" is really just an input file to the "perl" program. Just stop calling it a program and calling it data...yeah, I don't think that logic will get past the Nevada Gaming Commission either (nor I suppose would Acme::Bleach []) :-(
    • Semantics... I should have said, the program that's delivered must be pre-compiled, sort of like how snack food is pre-processed... I'm not sure where they'll draw the line, but there are source code filters that encrypt. Acme::Bleach or one of those might be the winner...

  • If "compiled" was a requirement I would't have started with Perl in the first place. I would have went for Tcl (starkits are awesome) or went the heavy route with Java.
    • Didn't know TCL did that. Interesting. If I started this project and knew it had to be compiled, I probably wouldn't have picked Perl either... or if I had, I'd have been awfully ashamed of myself at this point. Come to think of it, I'd probably pick Ocaml for the job, especially considering security is a concern.

  • One minor thing: your search was q=%A0documentation, so I'm not 100% surprised that it didn't match anything.

    As to which language, I'd probably say Java. It may be ugly as sin, but it does work, and it's designed to be compiled. And the tools [] are quite useful.

  • Any reason you couldn't use PAR's pp tool to generate an executable - presumably that would be acceptable?

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
  • "Likewise, par and pp utterly fall down"

    Care to elaborate? I have successfully packaged applications with over 150k SLOC. There is an active PAR mailing list which helps most requesters who have managed to at least skim the FAQ list. I don't think statements like the one I'm quoting above help much except vent off frustration.

    Also, the topic of your rant is quite inappropriate. ActiveState have done a lot to improve Perl-support on Win32. Their Perl Dev Kit, at least when I bought it, was a valuable resourc
    • par and pp utterly fall down *when* *using* -f Bytecode on this particular program. The man page for PAR::Filter::Bytecode says it's deprecated, as I already said. As I already said, I neglected to file a bug report with them because it's deprecated. This is not an attack on the Par people; it's merely a statement of fact that par isn't up to the task of bytecode compiling and packaging this particular application. And by calling it deprecated, it isn't even claiming to be up to the task. I might as we
  • I've used both PAR/pp and PerlApp for a long time. They both do the job very well. Sometimes they have problems with an app and I didn't bother to trouble shoot it but rather just switched to the other one and it worked. That's rare though.

    Using PAR + Inline::CPP has been a bit of trouble, but even that could be worked around.

    Both suffer from the dynamic problem that not all modules can be inferred from a static inspection of the code, but it's nothing hard to work through if you're aware of the situation.
    • If you figured out the issues with using Inline::CPP with PAR, would you be so kind as to write up a FAQ entry for the FAQ at I would think you might not be the last person to have trouble with that.

      As for adding "use Foo;" for every module so that the packagers can pick it up: That may be undesirable in several occasions. For example, you may have optionally loaded modules, environment/OS dependent modules, or just the case where you want a GUI app to show a loading-progress-bar as soon as po
      • Come to think of it, regarding making sure modules get picked up, there are command line options to add modules as well. I just thought it was easier to put them in the source.
  • I've also used PAR quite successfully in deploying a number of Perl apps across 100+ callcenter WinXP desktops. What problems did you run into? What kind of answers did you receive when you asked for help on the PAR mailing list?
    • As I said, the documentation for Par::Filter::Bytecode clearly labels it as deprecated. The fact that it doesn't work in a way that it advertises itself not to work is not a call for a bug report. If anything, I'd be stating the obvious by mailing them: "hey, this thing doesn't work just like it says it doesn't!".

      I should have been more clear about using pp with -f Bytecode as a lot of traffic was generated by concerned par users.

  • You're a direct beneficiary of core Perl contributions by ActiveState employees. Your abusive tone is totally uncalled for.
    • He never said they were kiddies. In fact he pointed out that they include many well-known people in the Perl world.

      He just said that their site looks like a fly by night site that was put together by kiddies. He's got a point. Although I must admit that I like the current design a more than the old one. That one looked like they ripped the artwork from some Soviet propaganda.

      Of course the people who are well-known at ActiveState are known for their programming abilities, and not their graphical prowess.
      • I believe he said the design was the only thing he thought was good.

        Incidentally, there is a documentation link right on the main PDK page ("resources" on the right side) and typing "documentation" into the search box on any page brought back hundreds of results.

        I don't know what local docs they bundle, but %%HTMLDIR%% looks like a Makefile target or similar, so maybe some kind of build/install procedure hadn't been run yet. But that's only a guess.

        In short, I think the rumors of ActiveStat
        • Let's see.

          You're right that documentation is on the right if you visit the right page. I don't know about you, but I tend to look for documentation on the top and left. Where normal sites put it. As he described, there is no link to documentation on the places where you expect the nav bar to be.

          Type documentation into the search bar, yup, lots of results. But if you look at his post he gives the link to the search result that he got []. Try that link, and no results. Why not? Well staring carefully at t
          • Note which high-bit character strayed into his URI: it says %A0, byte value 160, which, if interpreted as Latin-1, is U+00A0, otherwise known as NO-BREAK SPACE and declared in HTML as  . Ring a bell? If so, you can tell why he missed it…

        • Given an isolated example, you may choose to call it invalid because it doesn't fairly represent the norm. Or, if you're clever, you can call it a bad sample size, being a sample size of one =)

          I could have swore I tried the search twice, thinking something must have misfired, but maybe I was having a bad keyboard day.

          I'm not attacking ActiveState. Relax. I'm merely publicly bitching at them for frustrating *me* when *I* tried to find their documentation, with no pretense that my experience is normal. Bu
      • Hi btilly,

        Thanks for your comment. As usual, my high level of drama got a few feathers rilled.

        Anyway, I don't know graphic design and really can't comment on it, but I thought the site looked good. But that's part of what gives me the vibe -- sites that look really good but work very badly, especially with regards to user interface design. I can understand wanting to cut down on inappropriate email, but not letting people contact you until they've verified their account will keep you from ever hearing fr
  • Lots of comments! The articles that get discussion always surprise me. No one cared that I did my best to kick Solaris in the nuts over and over again, and no one has any thoughts on data homelessness, which I thought was an interesting topic. But that's okay.

    As usual, people veered into the minutia rather than running with the topic. Some people were concerned about me having problems with par (I should have been more clear that it was the deprecated Par::Filter::Bytecode module to blame). Others were
    • The articles that get discussion always surprise me. No one cared that I did my best to kick Solaris in the nuts over and over again, and no one has any thoughts on data homelessness

      It's use Perl;, after all. Or maybe you just timed your post right so that it appeared at the top of the list of recent blogs at the optimum time. Or maybe those who replied first happen to have lots of Friends, who then saw their comments. Or your words had a blogelectic-fit inducing pattern in them.

  • You said

    if I have to rewrite this project just to make it compile, what language should I use?

    Well, the first language I'm planning on looking into next, is D []. It's like an alternative to C++, but with plenty of features that are commonly only seen with scripting languages. At least, that's what I hope to find.

    Some links:

  • Clearly he should be writing it in OCaml.