FAQ
Hi,

i try to reactivate an old project, which relies heavily on Embperl. But
i run in to some problems.

- Which is the actual version?

CPAN: http://search.cpan.org/dist/Embperl/ -> gives 2.4.0
Homepage News: http://perl.apache.org/embperl/ -> gives 2.2.0 from 2006
Homepage Download: ftp://ftp.dev.ecos.de/pub/perl/embperl -> does not work
Mailinglist-archive: -> discusses 2.5.x, but i cant find it anywhere.

- Is Embperl stil compatible with actual perl versions? See
http://matrix.cpantesters.org/?dist=Embperl+2.4.0

- Embperl is deleted from Debian testing (Wheezy, 7.0) and Ubuntu 12.04.
Is there any hope that it will get back in Wheezy? I saw some discussion
here about this issue, but could not figure out, if there is any hope.

- In general: Is emperl still a living project or should i consider
porting my project to some alternative? I liked embperl very much, would
be sad to see it dying.

Thanks for any help.

Greatings, Benni
--
http://bennibaermann.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org

Search Discussions

  • Neil Gunton at Sep 2, 2012 at 8:02 am
    Hi Benni,

    I am still using Embperl in my ongoing project, which is a bicycle
    touring journals website with forums, classifieds etc. Actually I think
    it's the biggest bicycle touring website out there. I have over 7,000
    journals by people from all over the world, and we recently passed a
    million photos. I've been using Embperl since 2000, and it continues to
    work very well. I build from source, currently using Debian Wheezy on my
    dev workstation and Squeeze on the production server. There are some
    issues with Perl 5.14 on Wheezy, just related to error reporting
    (sometimes I don't get any line number, just 'compiler error'). I have
    raised this on the list here but it just petered out with no solution.

    I am not sure what Gerald sees for Embperl these days, the world at
    large appears to have largely moved on (from Perl/mod_perl, too) but I
    still really like it. It's weird seeing something that just works really
    well get kind of passed over, kind of sad really. If I "make it big"
    with my project then I intend to throw some financial support Gerald's
    way, but that is still in the future (just getting by myself at the moment).

    So this is just me saying that I'm still here! I hope Embperl carries on
    for the foreseeable future, I have a large amount of development time
    invested in it at this point (over 10 years worth) and it would be a
    huge hassle to switch to something else.

    Neil

    Benni Bärmann wrote:
    Hi,

    i try to reactivate an old project, which relies heavily on Embperl. But
    i run in to some problems.

    - Which is the actual version?

    CPAN: http://search.cpan.org/dist/Embperl/ -> gives 2.4.0
    Homepage News: http://perl.apache.org/embperl/ -> gives 2.2.0 from 2006
    Homepage Download: ftp://ftp.dev.ecos.de/pub/perl/embperl -> does not work
    Mailinglist-archive: -> discusses 2.5.x, but i cant find it anywhere.

    - Is Embperl stil compatible with actual perl versions? See
    http://matrix.cpantesters.org/?dist=Embperl+2.4.0

    - Embperl is deleted from Debian testing (Wheezy, 7.0) and Ubuntu 12.04.
    Is there any hope that it will get back in Wheezy? I saw some discussion
    here about this issue, but could not figure out, if there is any hope.

    - In general: Is emperl still a living project or should i consider
    porting my project to some alternative? I liked embperl very much, would
    be sad to see it dying.

    Thanks for any help.

    Greatings, Benni

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Dominic Hargreaves at Sep 2, 2012 at 10:22 am

    On Sun, Sep 02, 2012 at 08:44:05AM +0200, Benni Bärmann wrote:

    - Embperl is deleted from Debian testing (Wheezy, 7.0) and Ubuntu
    12.04. Is there any hope that it will get back in Wheezy? I saw some
    discussion here about this issue, but could not figure out, if there
    is any hope.
    The main reason for this is, as far as I can remember, that there is
    no released version which works with current mod_perl. I can't remember
    if there are also issues with perl 5.14 also.

    The Debian bug report is

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624578

    Note that this bug meant it was not possible to build the package against
    perl 5.14, which is why I worked on it (I was responsible for the perl
    5.12 and perl 5.14 migrations in Debian), but I don't use embperl myself.

    Unfortunately I think we're too late to get embperl back into wheezy
    even if there was someone around who had the time and expertise. If a
    release which works with current mod_perl and perl comes out, it can
    be subsequently added to unstable and then added to wheezy-backports
    after release, though.

    --
    Dominic Hargreaves | http://www.larted.org.uk/~dom/
    PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Gerald Richter at Sep 3, 2012 at 7:23 am
    Hi,

    Embperl is still alive :-), also it's moving slowly :-(

    The version in the svn and the dev snapshot 2.5.0_1 (which can be found at http://www.embperl.org/downloads/ ) solves the debian problem.

    There are some problems left with mod_perl and perl 5.14 and 5.16 .

    There is a solution for the "compile error" problem in the current svn version (but this causes some warnings when a page is changed and recompiled).

    Please use Version 2.5.0_1 or the source from the svn if you run Perl 5.14 or 5.16 .

    The good news is that I currently working on a payed project which includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be a new release in a few weeks, which solves all these problems.

    Gerald

    -----Original Message-----
    From: Dominic Hargreaves
    Sent: Sunday, September 02, 2012 12:22 PM
    To: Benni Bärmann
    Cc: embperl@perl.apache.org
    Subject: Re: Status of Embperl?
    On Sun, Sep 02, 2012 at 08:44:05AM +0200, Benni Bärmann wrote:

    - Embperl is deleted from Debian testing (Wheezy, 7.0) and Ubuntu
    12.04. Is there any hope that it will get back in Wheezy? I saw some
    discussion here about this issue, but could not figure out, if there
    is any hope.
    The main reason for this is, as far as I can remember, that there is no
    released version which works with current mod_perl. I can't remember if
    there are also issues with perl 5.14 also.

    The Debian bug report is

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624578

    Note that this bug meant it was not possible to build the package against perl
    5.14, which is why I worked on it (I was responsible for the perl
    5.12 and perl 5.14 migrations in Debian), but I don't use embperl myself.

    Unfortunately I think we're too late to get embperl back into wheezy even if
    there was someone around who had the time and expertise. If a release
    which works with current mod_perl and perl comes out, it can be
    subsequently added to unstable and then added to wheezy-backports after
    release, though.

    --
    Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5
    from the.earth.li (keyserver,web,email)

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jean-Christophe Boggio at Sep 3, 2012 at 7:40 am

    Le 03/09/2012 09:22, richter@ecos.de a écrit :
    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
    be a new release in a few weeks, which solves all these problems.
    Great news, be strong !

    --
    Jean-Christophe Boggio -o)
    embperl@thefreecat.org /\\
    Independant Consultant and Developer _\_V

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jose Fonseca at Sep 3, 2012 at 1:44 pm
    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be a
    new release in a few weeks, which solves all these problems.

    That is actually very exciting news. I'd like to thank Gerald Richter for
    his work and how available he is for all of us. I've never had a support
    email go unanswered, so Gerald and the community around Embperl are
    definitely at the heart of its success.

    About Embperl being alive or not: My job is to maintain a tourism-related
    system that is now about 15 years old.

    As most Perl apps, it all started with a simple CGI .pl script which grew
    and was divided into modules and became a whole app with time. In 2005 the
    front end of the system was migrated to Embperl and we're still using it to
    this day. In 2006 we migrated 90% of our PHP code into Embperl and Perl
    modules. We're still unable to get rid of the PHP module in Apache, because
    some of our users publish Wordpress blogs.

    We feel that there are pros and cons in our deployment.

    Pros: Embperl is extremely stable, well implemented and has been debugged
    for years. We simply deploy and forget about it. The Embperl templating
    system is well thought out, there is no strange crosstalk between tags,
    there are no unexpected behaviors and dependency conflicts in between
    Embperl sections even though some run at different times(no "magical" and
    difficult to debug collateral effects, etc). When I did parallel
    programming projects which used JSP or ASP, I immediately felt the
    diffculty introduced by the excessive complication and bloat in those
    technologies. Embperl is very Perl-ish, it makes easy things easy, hard
    things possible.

    When our app grew and a whole host of features were added such as a
    DBIx::Class ORM backend(which in turn pulls in hundreds of modules) we had
    absolutely zero problems with Embperl, it simply does not mess with the
    rest of Apache and does not introduce any module incompatibilities to the
    rest of our app. Apart from the infamous CGI.pm change in namespace which
    broke our upload forms, we've never had an issue with the thousands of
    modules running in the background at any given moment. This may seem
    "obvious" but it's not, it is in fact quite improbable that with so many
    dependencies to our app, that it actually runs so smoothly.

    Cons/Ideas:

    *Book*
    Embperl could really use a book. There should be a "Camel book" for Embperl
    IMHO, nowadays it could be an eBook, I'm sure the community would buy it.

    *Config*
    The configuration directives currently have two versions, the environment
    version and the Apache instruction, that was a source of confusion for our
    team at some point. I think these days that could be unified into one
    standard configuration system. One global config on a embperl.ini file and
    a per-application config in a specific location would solve it, getting rid
    of %ENV.

    *Perl JAR*
    Perl does not have a JAR-like packaging system, so deployments are always
    tough, we can't just deploy a package that is then automatically started as
    an application on the server. Right now we're using Amazon AMI's for this
    job, we basically package a whole server as the application, to avoid 2
    hours running CPAN compilations before a server can go up.

    This, of course, is a Perl issue not Embperl, but if you're considering
    Embperl for a project, you probably should consider this fact.

    Another Con is, Embperl is very low level in order to achieve speed. This
    couples it to the OS and to Perl very tightly, thus we get these issues
    mentioned on this thread now and then, compilation is straight down to
    platform-dependent binaries. A Embperl installation in our development
    servers does not run on our production servers.

    With the price of hardware being ridiculous these days, maybe it'd be a
    good idea to abstract more of Embperl into pure Perl instead of C, we may
    lose some efficiency but then again nowadays we're more concerned with
    parallelism and being able to scale sideways.

    Scaling horizontally is very difficult with Embperl. Unless you package a
    whole server as the application, every new machine added to a pool will
    have to run CPAN and update hundreds of modules, which may take hours.

    So the main con against Embperl is not actually an Embperl issue: Perl
    urgently needs an application packaging system like Java already has had
    for 17 years. Upload a binary and the app is deployed, that's how simple it
    should be in 2012. Nobody deserves to sit there and watch GCC compilation
    messages scroll by in this time and age, IMHO. You can afford it as a
    single developer, but when using Embperl for tens of deployments that is
    simply undoable.

    Aside from that, Embperl has survived this mess of "Web 2.0" booms and
    busts for us. Our REST web services are implemented in Embperl, with JSON
    in the back. The DBIx::Class ORM has held up to the test of time and our
    migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth sailing.

    So there's our story. Embperl continues to be alive and well for us and we
    depend on it on a daily basis with historically near zero downtime due to
    Embperl itself.

    Cheers!
    On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio wrote:

    Le 03/09/2012 09:22, richter@ecos.de a écrit :

    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
    be a new release in a few weeks, which solves all these problems.
    Great news, be strong !

    --
    Jean-Christophe Boggio -o)
    embperl@thefreecat.org /\\
    Independant Consultant and Developer _\_V


    ------------------------------**------------------------------**---------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.**apache.org<embperl-unsubscribe@perl.apache.org>
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Dominic Hargreaves at Sep 3, 2012 at 1:53 pm

    On Mon, Sep 03, 2012 at 10:44:27AM -0300, Jose Fonseca wrote:
    So the main con against Embperl is not actually an Embperl issue: Perl
    urgently needs an application packaging system like Java already has had
    for 17 years. Upload a binary and the app is deployed, that's how simple it
    should be in 2012. Nobody deserves to sit there and watch GCC compilation
    messages scroll by in this time and age, IMHO. You can afford it as a
    single developer, but when using Embperl for tens of deployments that is
    simply undoable.
    If you don't want to compile software, may I recommend that you use
    a binary distribution which contains the software you need? Even if
    Embperl itself isn't in great shape in Debian at the moment, everything
    else that Embperl needs is in there.

    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
    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, which is why I suggest that you
    look to something like Debian.

    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-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jose Fonseca at Sep 3, 2012 at 2:06 pm

    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.
    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.

    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.

    On Mon, Sep 3, 2012 at 10:52 AM, Dominic Hargreaves wrote:
    On Mon, Sep 03, 2012 at 10:44:27AM -0300, Jose Fonseca wrote:
    So the main con against Embperl is not actually an Embperl issue: Perl
    urgently needs an application packaging system like Java already has had
    for 17 years. Upload a binary and the app is deployed, that's how simple it
    should be in 2012. Nobody deserves to sit there and watch GCC compilation
    messages scroll by in this time and age, IMHO. You can afford it as a
    single developer, but when using Embperl for tens of deployments that is
    simply undoable.
    If you don't want to compile software, may I recommend that you use
    a binary distribution which contains the software you need? Even if
    Embperl itself isn't in great shape in Debian at the moment, everything
    else that Embperl needs is in there.

    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
    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, which is why I suggest that you
    look to something like Debian.

    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-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Dominic Hargreaves at Sep 3, 2012 at 6:45 pm

    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-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jose Fonseca at Sep 3, 2012 at 8:12 pm
    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 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-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Ragnar Hákonarson at Sep 4, 2012 at 12:37 am
    I just want to join Jose and air my gratitude to Gerald for his
    outstanding work and, not least, his availability which has been
    acknowledged by many over the years.



    I started using Embperl in 1999 and there are projects under my hat that
    are still at large today utilising Embperl. I, as many, do not question
    the robustness nor concept behind Embperl but have started to question
    whether Embperl is something to utilise in a new project. Embperl
    addresses current needs but the apparent lack of enthusiasts behind it
    today (apart from Gerald himself and a few die hard including myself) does
    beg the question whether it is as a wise choice for future needs.



    I for one would love to see the return of the vibrant community once
    associated with Embperl and, as far as I can see, the sudden influx in
    activity on this mailing list tells me there may very well still be life
    in this “animal”.



    Time to join forces behind Gerald and bring Embperl back to the forefront?



    From: Jose Fonseca
    Sent: 03 September 2012 16:08
    To: embperl@perl.apache.org
    Subject: Re: Status of Embperl?


    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be a
    new release in a few weeks, which solves all these problems.

    That is actually very exciting news. I'd like to thank Gerald Richter for
    his work and how available he is for all of us. I've never had a support
    email go unanswered, so Gerald and the community around Embperl are
    definitely at the heart of its success.

    About Embperl being alive or not: My job is to maintain a tourism-related
    system that is now about 15 years old.

    As most Perl apps, it all started with a simple CGI .pl script which grew
    and was divided into modules and became a whole app with time. In 2005 the
    front end of the system was migrated to Embperl and we're still using it
    to this day. In 2006 we migrated 90% of our PHP code into Embperl and Perl
    modules. We're still unable to get rid of the PHP module in Apache,
    because some of our users publish Wordpress blogs.

    We feel that there are pros and cons in our deployment.

    Pros: Embperl is extremely stable, well implemented and has been debugged
    for years. We simply deploy and forget about it. The Embperl templating
    system is well thought out, there is no strange crosstalk between tags,
    there are no unexpected behaviors and dependency conflicts in between
    Embperl sections even though some run at different times(no "magical" and
    difficult to debug collateral effects, etc). When I did parallel
    programming projects which used JSP or ASP, I immediately felt the
    diffculty introduced by the excessive complication and bloat in those
    technologies. Embperl is very Perl-ish, it makes easy things easy, hard
    things possible.

    When our app grew and a whole host of features were added such as a
    DBIx::Class ORM backend(which in turn pulls in hundreds of modules) we had
    absolutely zero problems with Embperl, it simply does not mess with the
    rest of Apache and does not introduce any module incompatibilities to the
    rest of our app. Apart from the infamous CGI.pm change in namespace which
    broke our upload forms, we've never had an issue with the thousands of
    modules running in the background at any given moment. This may seem
    "obvious" but it's not, it is in fact quite improbable that with so many
    dependencies to our app, that it actually runs so smoothly.

    Cons/Ideas:

    Book
    Embperl could really use a book. There should be a "Camel book" for
    Embperl IMHO, nowadays it could be an eBook, I'm sure the community would
    buy it.

    Config
    The configuration directives currently have two versions, the environment
    version and the Apache instruction, that was a source of confusion for our
    team at some point. I think these days that could be unified into one
    standard configuration system. One global config on a embperl.ini file and
    a per-application config in a specific location would solve it, getting
    rid of %ENV.

    Perl JAR
    Perl does not have a JAR-like packaging system, so deployments are always
    tough, we can't just deploy a package that is then automatically started
    as an application on the server. Right now we're using Amazon AMI's for
    this job, we basically package a whole server as the application, to avoid
    2 hours running CPAN compilations before a server can go up.

    This, of course, is a Perl issue not Embperl, but if you're considering
    Embperl for a project, you probably should consider this fact.

    Another Con is, Embperl is very low level in order to achieve speed. This
    couples it to the OS and to Perl very tightly, thus we get these issues
    mentioned on this thread now and then, compilation is straight down to
    platform-dependent binaries. A Embperl installation in our development
    servers does not run on our production servers.

    With the price of hardware being ridiculous these days, maybe it'd be a
    good idea to abstract more of Embperl into pure Perl instead of C, we may
    lose some efficiency but then again nowadays we're more concerned with
    parallelism and being able to scale sideways.

    Scaling horizontally is very difficult with Embperl. Unless you package a
    whole server as the application, every new machine added to a pool will
    have to run CPAN and update hundreds of modules, which may take hours.

    So the main con against Embperl is not actually an Embperl issue: Perl
    urgently needs an application packaging system like Java already has had
    for 17 years. Upload a binary and the app is deployed, that's how simple
    it should be in 2012. Nobody deserves to sit there and watch GCC
    compilation messages scroll by in this time and age, IMHO. You can afford
    it as a single developer, but when using Embperl for tens of deployments
    that is simply undoable.

    Aside from that, Embperl has survived this mess of "Web 2.0" booms and
    busts for us. Our REST web services are implemented in Embperl, with JSON
    in the back. The DBIx::Class ORM has held up to the test of time and our
    migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth sailing.

    So there's our story. Embperl continues to be alive and well for us and we
    depend on it on a daily basis with historically near zero downtime due to
    Embperl itself.

    Cheers!

    On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio
    wrote:

    Le 03/09/2012 09:22, richter@ecos.de a écrit :



    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
    be a new release in a few weeks, which solves all these problems.



    Great news, be strong !

    --
    Jean-Christophe Boggio -o)
    embperl@thefreecat.org /\\
    Independant Consultant and Developer _\_V



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Gerald Richter at Sep 7, 2012 at 11:28 am
    Hi,


    I think that's the point. Embperl is missing an active  community. Nearly all of the work is done by myself and (as for most of us) my time is limited. Also Embperl is still alive and I will keep to maintain it, there could be much more going on if the work would be shared by more people. To get it back into a living project it would necessary to


    -          Update the website

    -          Update the documentation (for example Embperl::Form is nearly undocumented and I guess unused, also it's very powerfull)

    -          Creating packages for the main linux distribution

    -          Writing articles (I don't think it's realistic to have a book, but having articles about it would help a lot)


    As already said I am about to create a new release for Perl 5.14&5.16 and I hope to get some time to do some (minimal) updates on the website (so the project doesn't look dead, as it seems from the website right now), but that's all I can do for now.


    It would be really great, if anybody has a chance to do some of the above work ( other ideas are always welcome)


    Gerald



    From: Ragnar Hákonarson
    Sent: Tuesday, September 04, 2012 3:00 AM
    To: 'Jose Fonseca'; embperl@perl.apache.org
    Subject: RE: Status of Embperl?


    I just want to join Jose and air my gratitude to Gerald for his outstanding work and, not least, his availability which has been acknowledged by many over the years.


    I started using Embperl in 1999 and there are projects under my hat that are still at large today utilising Embperl. I, as many, do not question the robustness nor concept behind Embperl but have started to question whether Embperl is something to utilise in a new project. Embperl addresses current needs but the apparent lack of enthusiasts behind it today (apart from Gerald himself and a few die hard including myself) does beg the question whether it is as a wise choice for future needs.


    I for one would love to see the return of the vibrant community once associated with Embperl and, as far as I can see, the sudden influx in activity on this mailing list tells me there may very well still be life in this "animal".


    Time to join forces behind Gerald and bring Embperl back to the forefront?


    From: Jose Fonseca
    Sent: 03 September 2012 16:08
    To: embperl@perl.apache.org
    Subject: Re: Status of Embperl?

    The good news is that I currently working on a payed project which includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be a new release in a few weeks, which solves all these problems.
    That is actually very exciting news. I'd like to thank Gerald Richter for his work and how available he is for all of us. I've never had a support email go unanswered, so Gerald and the community around Embperl are definitely at the heart of its success.

    About Embperl being alive or not: My job is to maintain a tourism-related system that is now about 15 years old.

    As most Perl apps, it all started with a simple CGI .pl script which grew and was divided into modules and became a whole app with time. In 2005 the front end of the system was migrated to Embperl and we're still using it to this day. In 2006 we migrated 90% of our PHP code into Embperl and Perl modules. We're still unable to get rid of the PHP module in Apache, because some of our users publish Wordpress blogs.

    We feel that there are pros and cons in our deployment.

    Pros: Embperl is extremely stable, well implemented and has been debugged for years. We simply deploy and forget about it. The Embperl templating system is well thought out, there is no strange crosstalk between tags, there are no unexpected behaviors and dependency conflicts in between Embperl sections even though some run at different times(no "magical" and difficult to debug collateral effects, etc). When I did parallel programming projects which used JSP or ASP, I immediately felt the diffculty introduced by the excessive complication and bloat in those technologies. Embperl is very Perl-ish, it makes easy things easy, hard things possible.

    When our app grew and a whole host of features were added such as a DBIx::Class ORM backend(which in turn pulls in hundreds of modules) we had absolutely zero problems with Embperl, it simply does not mess with the rest of Apache and does not introduce any module incompatibilities to the rest of our app. Apart from the infamous CGI.pm change in namespace which broke our upload forms, we've never had an issue with the thousands of modules running in the background at any given moment. This may seem "obvious" but it's not, it is in fact quite improbable that with so many dependencies to our app, that it actually runs so smoothly.

    Cons/Ideas:

    Book
    Embperl could really use a book. There should be a "Camel book" for Embperl IMHO, nowadays it could be an eBook, I'm sure the community would buy it.

    Config
    The configuration directives currently have two versions, the environment version and the Apache instruction, that was a source of confusion for our team at some point. I think these days that could be unified into one standard configuration system. One global config on a embperl.ini file and a per-application config in a specific location would solve it, getting rid of %ENV.

    Perl JAR
    Perl does not have a JAR-like packaging system, so deployments are always tough, we can't just deploy a package that is then automatically started as an application on the server. Right now we're using Amazon AMI's for this job, we basically package a whole server as the application, to avoid 2 hours running CPAN compilations before a server can go up.

    This, of course, is a Perl issue not Embperl, but if you're considering Embperl for a project, you probably should consider this fact.

    Another Con is, Embperl is very low level in order to achieve speed. This couples it to the OS and to Perl very tightly, thus we get these issues mentioned on this thread now and then, compilation is straight down to platform-dependent binaries. A Embperl installation in our development servers does not run on our production servers.

    With the price of hardware being ridiculous these days, maybe it'd be a good idea to abstract more of Embperl into pure Perl instead of C, we may lose some efficiency but then again nowadays we're more concerned with parallelism and being able to scale sideways.

    Scaling horizontally is very difficult with Embperl. Unless you package a whole server as the application, every new machine added to a pool will have to run CPAN and update hundreds of modules, which may take hours.

    So the main con against Embperl is not actually an Embperl issue: Perl urgently needs an application packaging system like Java already has had for 17 years. Upload a binary and the app is deployed, that's how simple it should be in 2012. Nobody deserves to sit there and watch GCC compilation messages scroll by in this time and age, IMHO. You can afford it as a single developer, but when using Embperl for tens of deployments that is simply undoable.

    Aside from that, Embperl has survived this mess of "Web 2.0" booms and busts for us. Our REST web services are implemented in Embperl, with JSON in the back. The DBIx::Class ORM has held up to the test of time and our migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth sailing.

    So there's our story. Embperl continues to be alive and well for us and we depend on it on a daily basis with historically near zero downtime due to Embperl itself.

    Cheers!

    On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio wrote:

    Le 03/09/2012 09:22, richter@ecos.de a écrit :


    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
    be a new release in a few weeks, which solves all these problems.


    Great news, be strong !

    --
    Jean-Christophe Boggio                       -o)
    embperl@thefreecat.org                       /\\
    Independant Consultant and Developer        _\_V



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Neil Gunton at Sep 7, 2012 at 5:27 pm

    richter@ecos.de wrote:
    I think that’s the point. Embperl is missing an active community.
    Nearly all of the work is done by myself and (as for most of us) my time
    is limited. Also Embperl is still alive and I will keep to maintain it,
    there could be much more going on if the work would be shared by more
    people. To get it back into a living project it would necessary to

    -Update the website
    I agree, the website looks really bad at the moment. When you go to this
    page:

    http://perl.apache.org/embperl/pod/doc/Embperl.-page-19-.htm

    and click on the link to download Embperl, it just sits there saying
    'connecting'. It makes it look like this is a dead project, to be
    honest, and who knows how many potential Embperl users the site has
    turned off. You would never hear from them, so we have no idea.
    -Update the documentation (for example Embperl::Form is nearly
    undocumented and I guess unused, also it’s very powerfull)
    This would be good too, I am sure you did lots of cool stuff in Embperl
    2.0 but it's no use if nobody knows about it.
    -Creating packages for the main linux distribution
    This would be nice, but I know I probably wouldn't use it, since I tend
    to build my own Apache (I do two versions, one front end caching reverse
    proxy and one back-end mod_perl), and so I don't want an Embperl which
    wants to also pull in and install the default Apache Debian packages.
    But it would definitely be nice if it was in Debian again, that is
    always a sign of the health and legitimacy of a project (for better or
    worse).
    -Writing articles (I don’t think it’s realistic to have a book, but
    having articles about it would help a lot)
    I wrote a 'howto' article early on for Embperl 1.3, but somewhere along
    the line it got dropped. I also offered to clean up spelling and grammar
    for the English version of the documentation, but that was years and
    years ago now. If you would like help with any new documentation, then
    just let me know and I would be glad to help.

    I could also write an article or two on my own website (probably
    neilgunton.com) about how I use Embperl. I am kind of weird, though,
    while I think I'm an ok programmer in some respects, in other respects I
    really don't know much at all. For example, whenever I start looking
    deeper into Perl itself, I realize that I pretty much skate
    superficially over some of the more powerful aspects of the language in
    my own use. I tend to write simple code, which is good, I guess, but
    because of that I'm probably not the best person to write about any
    gee-whiz super advanced stuff. That said, maybe I know more than I
    realize, I mean I've been developing with Embperl for over 10 years now,
    so I must know something. Maybe I've been doing some things wrong all
    this time, I don't know, but if you like I can try to write something.
    Just be prepared for some forehead slapping moments when you see how I
    use it! ;-)
    As already said I am about to create a new release for Perl 5.14&5.16
    and I hope to get some time to do some (minimal) updates on the website
    (so the project doesn’t look dead, as it seems from the website right
    now), but that’s all I can do for now.
    Thanks! Let me know if you need any help with anything. If I can help
    from my end, I'd be glad to.
    It would be really great, if anybody has a chance to do some of the
    above work ( other ideas are always welcome)
    I have been getting into Google Maps API v3 recently. I actually bought
    a book on the topic which I thought would be useful, but in practice I
    found that the code samples on Google's own site are most useful. For
    me, just seeing how the code is supposed to be used (or was intended to
    be used by the developer) is most useful. So perhaps some code samples
    of the things you think each feature could be used for? There are lots
    of things in Embperl that I don't use, but I'm sure you put them in
    there for a reason. If you like, I could help with doing this too, at
    least in English, if you can give me the outlines (we can do that
    offline if you're up for it) and I can understand what you're talking
    about, then I could do that as another article. It would really be most
    natural on your website, but since you're busy I can certainly just post
    it on my own site and have you link to it. Whatever works, I'm easy.

    Thanks again, Gerald, I'm very grateful for all the work you have put
    into Embperl over the years.

    Neil
    *From:*Ragnar Hákonarson
    *Sent:* Tuesday, September 04, 2012 3:00 AM
    *To:* 'Jose Fonseca'; embperl@perl.apache.org
    *Subject:* RE: Status of Embperl?

    I just want to join Jose and air my gratitude to Gerald for his
    outstanding work and, not least, his availability which has been
    acknowledged by many over the years.

    I started using Embperl in 1999 and there are projects under my hat that
    are still at large today utilising Embperl. I, as many, do not question
    the robustness nor concept behind Embperl but have started to question
    whether Embperl is something to utilise in a new project. Embperl
    addresses current needs but the apparent lack of enthusiasts behind it
    today (apart from Gerald himself and a few die hard including myself)
    does beg the question whether it is as a wise choice for future needs.

    I for one would love to see the return of the vibrant community once
    associated with Embperl and, as far as I can see, the sudden influx in
    activity on this mailing list tells me there may very well still be life
    in this “animal”.

    Time to join forces behind Gerald and bring Embperl back to the forefront?

    *From:*Jose Fonseca
    *Sent:* 03 September 2012 16:08
    *To:* embperl@perl.apache.org *Subject:* Re: Status of Embperl?
    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be
    a new release in a few weeks, which solves all these problems.

    That is actually very exciting news. I'd like to thank Gerald Richter
    for his work and how available he is for all of us. I've never had a
    support email go unanswered, so Gerald and the community around Embperl
    are definitely at the heart of its success.

    About Embperl being alive or not: My job is to maintain a
    tourism-related system that is now about 15 years old.

    As most Perl apps, it all started with a simple CGI .pl script which
    grew and was divided into modules and became a whole app with time. In
    2005 the front end of the system was migrated to Embperl and we're still
    using it to this day. In 2006 we migrated 90% of our PHP code into
    Embperl and Perl modules. We're still unable to get rid of the PHP
    module in Apache, because some of our users publish Wordpress blogs.

    We feel that there are pros and cons in our deployment.

    Pros: Embperl is extremely stable, well implemented and has been
    debugged for years. We simply deploy and forget about it. The Embperl
    templating system is well thought out, there is no strange crosstalk
    between tags, there are no unexpected behaviors and dependency conflicts
    in between Embperl sections even though some run at different times(no
    "magical" and difficult to debug collateral effects, etc). When I did
    parallel programming projects which used JSP or ASP, I immediately felt
    the diffculty introduced by the excessive complication and bloat in
    those technologies. Embperl is very Perl-ish, it makes easy things easy,
    hard things possible.

    When our app grew and a whole host of features were added such as a
    DBIx::Class ORM backend(which in turn pulls in hundreds of modules) we
    had absolutely zero problems with Embperl, it simply does not mess with
    the rest of Apache and does not introduce any module incompatibilities
    to the rest of our app. Apart from the infamous CGI.pm change in
    namespace which broke our upload forms, we've never had an issue with
    the thousands of modules running in the background at any given moment.
    This may seem "obvious" but it's not, it is in fact quite improbable
    that with so many dependencies to our app, that it actually runs so
    smoothly.

    Cons/Ideas:

    *Book*
    Embperl could really use a book. There should be a "Camel book" for
    Embperl IMHO, nowadays it could be an eBook, I'm sure the community
    would buy it.

    *Config*
    The configuration directives currently have two versions, the
    environment version and the Apache instruction, that was a source of
    confusion for our team at some point. I think these days that could be
    unified into one standard configuration system. One global config on a
    embperl.ini file and a per-application config in a specific location
    would solve it, getting rid of %ENV.

    *Perl JAR*
    Perl does not have a JAR-like packaging system, so deployments are
    always tough, we can't just deploy a package that is then automatically
    started as an application on the server. Right now we're using Amazon
    AMI's for this job, we basically package a whole server as the
    application, to avoid 2 hours running CPAN compilations before a server
    can go up.

    This, of course, is a Perl issue not Embperl, but if you're considering
    Embperl for a project, you probably should consider this fact.

    Another Con is, Embperl is very low level in order to achieve speed.
    This couples it to the OS and to Perl very tightly, thus we get these
    issues mentioned on this thread now and then, compilation is straight
    down to platform-dependent binaries. A Embperl installation in our
    development servers does not run on our production servers.

    With the price of hardware being ridiculous these days, maybe it'd be a
    good idea to abstract more of Embperl into pure Perl instead of C, we
    may lose some efficiency but then again nowadays we're more concerned
    with parallelism and being able to scale sideways.

    Scaling horizontally is very difficult with Embperl. Unless you package
    a whole server as the application, every new machine added to a pool
    will have to run CPAN and update hundreds of modules, which may take hours.

    So the main con against Embperl is not actually an Embperl issue: Perl
    urgently needs an application packaging system like Java already has had
    for 17 years. Upload a binary and the app is deployed, that's how simple
    it should be in 2012. Nobody deserves to sit there and watch GCC
    compilation messages scroll by in this time and age, IMHO. You can
    afford it as a single developer, but when using Embperl for tens of
    deployments that is simply undoable.

    Aside from that, Embperl has survived this mess of "Web 2.0" booms and
    busts for us. Our REST web services are implemented in Embperl, with
    JSON in the back. The DBIx::Class ORM has held up to the test of time
    and our migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth
    sailing.

    So there's our story. Embperl continues to be alive and well for us and
    we depend on it on a daily basis with historically near zero downtime
    due to Embperl itself.

    Cheers!

    On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio
    wrote:

    Le 03/09/2012 09:22, richter@ecos.de a écrit :

    The good news is that I currently working on a payed project which
    includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
    be a new release in a few weeks, which solves all these problems.

    Great news, be strong !

    --
    Jean-Christophe Boggio -o)
    embperl@thefreecat.org /\\
    Independant Consultant and Developer _\_V



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jean-Christophe Boggio at Sep 8, 2012 at 6:18 pm

    Le 07/09/2012 19:26, Neil Gunton a écrit :
    richter@ecos.de wrote:
    -Update the documentation (for example Embperl::Form is nearly
    undocumented and I guess unused, also it’s very powerfull)
    This would be good too, I am sure you did lots of cool stuff in Embperl
    2.0 but it's no use if nobody knows about it.
    Embperl 2 is quite enough documented. What's missing, in my PoV, is,
    here and there, what is specific to Embperl 1 and/or
    obsolete/recommended in Embperl 2.

    I'd also like a bigger faq/hints (wiki-based ?)
    -Creating packages for the main linux distribution
    But it would definitely be nice if it was in Debian again, that is
    always a sign of the health and legitimacy of a project (for better or
    worse).
    I'm always installing from Debian/Ubuntu. I'm not sure I could do the
    job alone but I could help packaging it (I would start by marking
    libembperl-perl as conflicting with apache2-mpm-worker ;-) )
    I am kind of weird, though,
    while I think I'm an ok programmer in some respects, in other respects I
    really don't know much at all. For example, whenever I start looking
    deeper into Perl itself, I realize that I pretty much skate
    superficially over some of the more powerful aspects of the language in
    my own use. I tend to write simple code, which is good, I guess, but
    because of that I'm probably not the best person to write about any
    gee-whiz super advanced stuff. That said, maybe I know more than I
    realize, I mean I've been developing with Embperl for over 10 years now,
    so I must know something. Maybe I've been doing some things wrong all
    this time, I don't know, but if you like I can try to write something.
    Just be prepared for some forehead slapping moments when you see how I
    use it! ;-)
    Word for word, the same for me :-)


    Thanks Gerald for your work and support.

    --
    Jean-Christophe Boggio -o)
    embperl@thefreecat.org /\\
    Independant Consultant and Developer _\_V

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Kee Hinckley at Sep 7, 2012 at 7:59 pm
    It's been a while since I've looked at existing frameworks in Perl (I'm stuck in a long-term Python project right now). When I last did, I used Catalyst and replaced TT with Embperl. I also augmented Embperl with a few features (a [] construct that does *no* escaping, and a dynamic include capability that works well with the object model for giving you what pieces you need in the right order only and only once—it's been a while, so I can't really describe it well).

    I'd be happy to contribute both of those, although neither are what I'd call polished.

    The key issue I have is Frameworks, Frameworks, Frameworks. People expect more out of their tools than Embperl provides. I think that Embperl would have a much better chance of survival if it could be embedded in an existing Framework. It's way faster than the pure-perl solutions, and it's much better at managing cross-site scripting areas and form filling than any other system out there.
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Gerald Richter at Sep 9, 2012 at 12:46 pm
    Hi,

    thanks for all the responses :-)

    I have 2.5.0_2 nearly ready. Hopefully I can release it during next week.

    After cleaning up the current web, I will setup a wiki on embperl.org, so everybody can easily contribute.

    I like the idea of creating a kind of Cookbook with code snippets and examples.

    Of course any other contribution, like spell checking etc. is very welcome.

    2.5.0_2 will contain patches from Debian and additionals one I just received from Florian, so I think it would be the best to base any further work on the upcoming 2.5.0_2 release

    Gerald






    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Jose Fonseca at Sep 10, 2012 at 12:44 am
    I think the wiki idea is a great one. I can help with translations to
    Portuguese if you guys think it'd be useful. (Assuming a multi-lingual
    Wiki?)
    I like the idea of creating a kind of Cookbook with code snippets and
    examples.

    This IMO would really drive users into it. Supported and, with whatever
    time allows me to do, I'd love to help.

    Jose
    On Sun, Sep 9, 2012 at 9:45 AM, wrote:

    Hi,

    thanks for all the responses :-)

    I have 2.5.0_2 nearly ready. Hopefully I can release it during next week.

    After cleaning up the current web, I will setup a wiki on embperl.org,
    so everybody can easily contribute.

    I like the idea of creating a kind of Cookbook with code snippets and
    examples.

    Of course any other contribution, like spell checking etc. is very welcome.

    2.5.0_2 will contain patches from Debian and additionals one I just
    received from Florian, so I think it would be the best to base any further
    work on the upcoming 2.5.0_2 release

    Gerald






    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • D K at Sep 10, 2012 at 3:26 pm
    I would second Kee's point.

    At $work, (a very large company which has been a heavy user of EmbPerl for years), they are considering switching away (from both Embperl and even Perl).

    One of the biggest things that was a problem was a lack of a good MVC framework - we had to roll our own, slow and clumsy ones.

    If I could show people how to plug our existing EP code as a view layer into Catalyst, it would go a long way to convince the $powers that Embperl is worth looking at.


    ________________________________
    From: Kee Hinckley <nazgul@somewhere.com>
    To: richter@ecos.de
    Cc: embperl@perl.apache.org
    Sent: Friday, September 7, 2012 3:59 PM
    Subject: Re: Status of Embperl?

    It's been a while since I've looked at existing frameworks in Perl (I'm stuck in a long-term Python project right now). When I last did, I used Catalyst and replaced TT with Embperl. I also augmented Embperl with a few features (a [] construct that does *no* escaping, and a dynamic include capability that works well with the object model for giving you what pieces you need in the right order only and only once—it's been a while, so I can't really describe it well).

    I'd be happy to contribute both of those, although neither are what I'd call polished.

    The key issue I have is Frameworks, Frameworks, Frameworks. People expect more out of their tools than Embperl provides. I think that Embperl would have a much better chance of survival if it could be embedded in an existing Framework. It's way faster than the pure-perl solutions, and it's much better at managing cross-site scripting areas and form filling than any other system out there.
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Gerald Richter at Sep 10, 2012 at 6:06 pm
    Hi,


    we have a project that uses Embperl inside of Catlyst. That’s no problem. I am not the who maintains it, but I will get the necessary modules and post it here. Just give me a few days.


    Gerald



    From: D K
    Sent: Monday, September 10, 2012 5:26 PM
    To: Kee Hinckley; Gerald Richter - ECOS
    Cc: embperl@perl.apache.org
    Subject: Re: Status of Embperl?


    I would second Kee's point.


    At $work, (a very large company which has been a heavy user of EmbPerl for years), they are considering switching away (from both Embperl and even Perl).


    One of the biggest things that was a problem was a lack of a good MVC framework - we had to roll our own, slow and clumsy ones.


    If I could show people how to plug our existing EP code as a view layer into Catalyst, it would go a long way to convince the $powers that Embperl is worth looking at.


    --------------------------------
    From: Kee Hinckley <nazgul@somewhere.com
    To: richter@ecos.de
    Cc: embperl@perl.apache.org
    Sent: Friday, September 7, 2012 3:59 PM
    Subject: Re: Status of Embperl?


    It's been a while since I've looked at existing frameworks in Perl (I'm stuck in a long-term Python project right now). When I last did, I used Catalyst and replaced TT with Embperl. I also augmented Embperl with a few features (a [] construct that does *no* escaping, and a dynamic include capability that works well with the object model for giving you what pieces you need in the right order only and only once—it's been a while, so I can't really describe it well).

    I'd be happy to contribute both of those, although neither are what I'd call polished.

    The key issue I have is Frameworks, Frameworks, Frameworks. People expect more out of their tools than Embperl provides. I think that Embperl would have a much better chance of survival if it could be embedded in an existing Framework. It's way faster than the pure-perl solutions, and it's much better at managing cross-site scripting areas and form filling than any other system out there.
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org
  • Andrew O'Brien at Sep 8, 2012 at 4:53 am
    Hi all,

    [apologies for the html format - I'm sending from a work webmail client]
    - Embperl is deleted from Debian testing (Wheezy, 7.0) and Ubuntu 12.04.
    Is there any hope that it will get back in Wheezy? I saw some discussion
    here about this issue, but could not figure out, if there is any hope.
    I've just taken 2.5.0_1 from the tar.gz Gerald has posted months back and after some blood sweat and tears I've got the debianisations (patches etc) from earlier distributions either deleted, modified or merged across and can successfully build a debian package under wheezy.

    Since this currently requires ignoring the (harmless) test failures its certainly not going to make it into debian as-is. However, when Gerald has had a chance to polish up the newer version of the codebase that he's working on I'll repeat the process and, if successful, pass it on to the debian perl team (I'm not a Debian packager myself). It won't make it into wheezy but I'll be happy to maintain unofficial packages in the meantime.

    Let me know if anyone wants to beat on it and I'll send it via email or post a link to the list. I haven't had a chance to do any more than confirm it doesn't make Apache segfault when its actively loaded at this point so the more testing the better ;-)
    - In general: Is emperl still a living project or should i consider
    porting my project to some alternative? I liked embperl very much, would
    be sad to see it dying.
    For my 2c we use it extensively here at work, currently all on slightly older Debian servers (we have a refresh project happening at the moment hence my work on getting a wheezy package up and running). It works out of the box for a reasonably large embperl::object website that forms the front end to our primary service offering so its certainly not going anywhere for us soon.

    Its fast, reliable and its been years since we've had any WTF? moment with it in dev or production.

    To be honest I don't know whether this is actually a biggish website or not any more but to give you an idea the web tree has just under 40k lines of embperl code - this count only includes non-comment embperl lines or blocks, not html JS CSS etc.

    I'll certainly be continuing to support Embperl in whatever way I can.

    Cheers,

    Andrew
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
    For additional commands, e-mail: embperl-help@perl.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupembperl @
categoriesmodperl, perl
postedSep 2, '12 at 6:44a
activeSep 10, '12 at 6:06p
posts20
users10
websiteperl.apache.org

People

Translate

site design / logo © 2018 Grokbase