> Adding an intermediate bytecode to perl5 is unrealistic, yes. IIRC it's already there ;)
http://search.cpan.org/~rjbs/perl-5.16.1/ext/B/B.pm > Okay, that's one way of looking at things. I prefer to look at the > distribution as being a core part of the way software is managed (I work > in an environment where no software gets installed on a server unless > it comes from a Debian package of some sort). YMMV, clearly :) That doesn't seem to fix the core issue of Perl app mobility. Whether you're installing from a Debian repository or from a Red Hat Enterprise license, you still have to install - that is my problem. The example I brought up is that other languages make it very easy to pack all dependencies into one tarball and it works almost anywhere. > I think the two approaches are so radically opposed I'm going to be hard > pushed to recommend something you'd want. There are tools available; one > I know of is <http://par.wikia.com/wiki/Main_Page> but I don't know how > they handle compiled extensions. Thanks for the tip. I recall PAR, I am almost sure we tried it at some point. Also chromatic's hacks book has a hack to create self-contained distributions. We tried several such ideas and problems arose because there is lots of orthogonality between system paths, libraries, conflicts. They're so many variables, our staging systems deployed that way were unstable, we had random crashes and finally went back to just installing everything from CPAN then creating a virtual machine snapshot. So instead of deploying a JAR-like package, we are deploying a computer...one whole virtual machine image that contains a computer in it...several GB's in size just to accommodate an application. It's like driving a bus all by yourself to work every day. Best wishes. Jose Fonseca On Mon, Sep 3, 2012 at 3:45 PM, Dominic Hargreaves <d...@earth.li> wrote: > On Mon, Sep 03, 2012 at 11:06:05AM -0300, Jose Fonseca wrote: > > > The fact that java has it doesn't mean that it makes sense for perl, > > > on technical grounds. The vast majority of perl is pure-perl, not > > > > It does relate to Perl IMO. We're in an age where scaling up is no longer > > the only way forward. > > > > I can add 100 Cassandra database machines in Amazon AWS in one click but > I > > can't deploy more Perl-based servers. That tells us Perl needs a > Java-like > > deployment system with easier packaging IMO. > > > > > compiled, but the bits that do get compiled get compiled to native > code. > > > not an intermediate byte-code. A universal binary distribution format > > > is not, therefore, particularly realistic, > > > > There exist several bytecode binary systems that work - and they work on > > major websites, I don't know what you mean by "A universal binary > > distribution format is not, therefore, particularly realistic, " - I > guess > > systems similar to .NET, Java, Scala, Jython and Parrot are unrealistic? > > Again this is unrelated to Embperl, but it's a consequence of choosing > Perl > > for an app, which is why I mentioned it. > > Adding an intermediate bytecode to perl5 is unrealistic, yes. > > > > which is why I suggest that you > > > look to something like Debian. > > > > The Linux distro, with all due respect, is absolutely unrelated to > anything > > I said. We completely ignore what is underneath our Perl app. At this > > moment it's Fedora Core or RedHat I believe, but we pay zero attention to > > it, it could be FreeBSD or a Mac for what it's worth. In fact my personal > > mobile development and testing machine is on MacOS. And at this moment I > > write you from Fedora Core in which the app runs fine. > > Okay, that's one way of looking at things. I prefer to look at the > distribution as being a core part of the way software is managed (I work > in an environment where no software gets installed on a server unless > it comes from a Debian package of some sort). YMMV, clearly :) > > > The distro is irrelevant and to answer your suggestion, no there is not a > > single distro out there with all the modules required by our app. > > Deployment has been an issue for us for ages, our only solution has been > to > > use Amazon AMI's. If you have suggestions or ideas for easy packaging of > > Embperl apps with thousands of dependencies, we'd really appreciate it. > > I think the two approaches are so radically opposed I'm going to be hard > pushed to recommend something you'd want. There are tools available; one > I know of is <http://par.wikia.com/wiki/Main_Page> but I don't know how > they handle compiled extensions. > > Cheers, > Dominic. > > -- > Dominic Hargreaves | http://www.larted.org.uk/~dom/ > PGP key 5178E2A5 from the.earth.li (keyserver,web,email) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: embperl-unsubscr...@perl.apache.org > For additional commands, e-mail: embperl-h...@perl.apache.org > >
