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:
http://www.activestate.com/search/index.plex?cx=005567415255730122040%3Aiof7ftsiexy&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?
Bleah.
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?
-scott
Re:perl is compiled!
scrottie on 2007-10-25T08:49:39
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...
-scott
Re:Heh
scrottie on 2007-10-25T08:51:28
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.
-scott
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.
Re:Not helpful
scrottie on 2007-10-25T09:30:47
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 well have said that Pop Rocks are bad at fixing flats, and your rush to the defense of par would be about as appropriate as a Pop Rocks fan rushing to the defense of its application for fixing flats. It seems that you missed my point.
Another reader pointed out that simply pp'ing it without a filter should be adequate, and he's probably right. I'll have to try that angle -- which will involve endless hanging with a government organization, explaining to them in great detail exactly what it is. Being able to say "compiled, just like Java!" to explain Bytecode is a lot easier to sell.
ActiveState sucks in so much as their documentation is unfindable and they can't be contacted to report the various problems. It's comical to think that if an organization does a lot of work for a segment of the Perl community (while profiting), it's reprehensible to criticize their lack of documentation. Or did you miss my point on that one?
"I don't think statements like the one I'm quoting above help much except vent off frustration." Yes, that was exactly the point of that post. I'm sorry you missed that point.
As far as talking to "someone who might clear up confusion", I thought I explained exactly what steps I took to contact ActiveState and failed. I'm sorry I didn't make that point more clear so that you wouldn't miss it.
I understand that ActiveState and IndigoSTAR started with Malcolm's work originally. This bit of trivia should not be used to construe an attack on him, nor to introduce forgiveness to people who would resell his work.
Look, here's the short version, hopefully in a form you can understand:
Compiling Perl is hard. No one of any authority has said otherwise. Because it's hard, and no one has been able to (for lack of resources) make it work well, it's being deprecated in various places. Third party vendors are still trying just because of commercial demand (mostly from people with far less of an excuse than I have), but that doesn't change the fact that's a dubious proposition. The PAR mailing list can't change that. ActiveState can't. IndigoSTAR can't.
As far as asking the right people to help, one of the core dumpers in 5.8.8 was reported to the Perl 5 Porters, who helpfully pointed me at a patch in the 5.8 branch. B::Generate is still triggering a few others, but I need to investigate more before filing reports.
You could read my post as a horror story of pain and tribulations of trying to bytecode compile Perl, or you might even find it humorous. Or you could rush to defend every name mentioned in it. You apparently missed every point I made in the original article, so I have no idea what I hope to accomplish by feeding you more prose for you to misunderstand. I guess I just don't want to let the record left to appear as though you had any point. Towards that effort, please don't post in my blog anymore.
-scott
Re:Packaging, not compiling
tsee on 2007-10-24T14:02:01
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 par.perl.org? 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 possible. In those cases, you can just add a sub that is never called to some package which will be scanned. In that subroutine, you would then put "require Foo;" for every module the packager doesn't find by itself. The require will never be executed, but it will be recognized as a dependency by the packager.
By the way: I entirely agree with you that it's questionably whether Perl is a legitimate choice in this case. There is Steve Hay's Filter::Crypto (and PAR::Filter::Crypto) which is intended to make it harder to get at the code. It goes as far as possible with perl. Make sure you read the CAVEATS section thoroughly before use, though.Re:Packaging, not compiling
jplindstrom on 2007-10-25T12:33:32
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.
Re:+1 For PAR
scrottie on 2007-10-25T09:34:10
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.
-scott
Re:not kiddies
btilly on 2007-10-24T23:46:49
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'm sure I'd do no better, and would probably do worse in their position. But that is why every company who has hired me has had the sense to hire a graphic artist who does have the design sense to come up with a nice design.
And as much as we'd both like for it not to matter, in the real world it does. (Which is a good thing for those graphics people, else they wouldn't have jobs.) Sure, not for dealing with technical people who know what they are doing. But to show non-technical managers?Re:not kiddies
perrin on 2007-10-25T00:26:23
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 activestate.com 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 ActiveState's suckage are a bit exaggerated.Re:not kiddies
btilly on 2007-10-25T03:18:41
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 the URL, it looks like he had a typo. He has a high-bit character in there. How or why I don't know, but I've experienced tunnel vision enough to understand how he could miss that fact. Particularly if he was already frustrated with the site.
So then he downloads the file and starts looking through it. I agree that if he ran the appropriate Makefile he'd have had a much better time of things. But I'm quite sure that he had exactly the experience that he described.
And after an experience like that, I can understand why he blogged about it.
Now I agree that there were some user errors here, and he had pretty much a worst case experience. However I know that I have found their website rather unfriendly the last couple of times that I've tried it. Intellectually I understand why they would bury the free download as far as they can, but as a user I didn't appreciate it. With my past experiences, I also have sympathy for someone who didn't find the correct way through the maze.Re:not kiddies
Aristotle on 2007-10-25T20:19:06
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…Re:not kiddies
scrottie on 2007-10-25T09:55:46
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. But that's an aside. Mostly I'm giving -- or trying to give -- a colorful account of the misery in store for anyone who would try to bytecode compile Perl. ActiveState just happened to become part of that story.
-scott
Re:not kiddies
scrottie on 2007-10-25T09:48:22
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 from people who are having trouble verifying your account, and that could, in theory, translate to people who want to give you money being unable to do so.
Between that snafu and finding my efforts at finding documentation to be futile, the vibe is bad.
I'm not going to be pretentious and scream about "all the money they're losing!" or anything like that, but I also don't agree with the people who think no one should say anything about the problem;)
Regards,
-scott
Re:"ActiveState sucks" roundup
slanning on 2007-10-25T17:16:00
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 homelessnessIt'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.
Some links:
