On Mon, Oct 6, 2008 at 5:49 AM, Elyse M. Grasso
[EMAIL PROTECTED] wrote:
My company sells an application that links a bugtracking tool with an SCM tool
so that, for example, the files changed for each bug are recorded in the
bugtracking tool. It is currently written in (mostly) non-object-oriented
perl5.
We are re-architecting the application so that it can work with different
bugtracking tools and SCM tools, and do things like sync data from specific
fields between a help desk tool and the bugtracking tool. This would be a good
time for us to transition to perl6.
yes, it seems perfectly reasonable to consider language choices when
re-designing your product's architecture. certainly, the perl 6
specification makes it an attractive choice.
As far as I can tell from the various faqs and wikis, the existing
functionality in rakudo should support most of our needs for the initial
release. I may need to assist with the porting of some database access and
other modules from CPAN to C6PAN in the longer term.
the core functionality of rakudo may support what you need, but at
this point i have some concerns with chosing rakudo as the runtime for
a client-facing production product. mainly, there are un- and
under-tested portions of the language implementation, which to me
suggests that there are bugs lurking as it hasn't been proven
otherwise by passing tests. this isn't to suggest that rakudo is not
ready for use, but it is a risk--until we (rakudo project team) have
higher test coverage and more passing tests.
anybody can help, by adding tests which cover the official perl 6
specification (http://spec.pugscode.org/) to the pugs repository
(http://svn.pugscode.org/). anyone who is interested can get commit
priviliges to the repository; the procedure is simple, and approval is
always granted. feel free to contact this list with a commit bit
request. also, there are a number of us with experience writing tests
that cover the spec, and we're happy to share our knowledge on the
subject.
porting modules to perl 6 definitely needs some help. currently there
is no c6pan, there is only the pugs repository, where some previously
ported modules live. i haven't seen much visible work on c6pan lately,
and i'm sure there's no solution nearing production. this means it's
best to package any required modules with your product rather than
relying on an external resource to provide perl 6 modules at
build/configure/install-time.
However, I am concerned about deployment of a perl6 based product to
customers. Perl5 can be reasonably specified as a prerequisite for loading our
application, since it is generally available (and shipped with some of the
products we integrate). That is not the case with Perl6.
this is another case for concern, for sure. parrot's installation code
is not extremely robust, but is improving quickly. as of last month's
release (0.7.1), parrot is released as a source distribution from the
source repository (http://svn.perl.org/parrot/tags/RELEASE_0_7_1), a
CPAN module (http://search.cpan.org/~pmic/parrot-0.7.1/), a windows
installation package (http://parrotwin32.wiki.sourceforge.net/), a
cygwin package (libparrot0 and libparrot-devel), and a debian package
(http://packages.qa.debian.org/p/parrot.html). these installation
methods are in varying states of maturity, and all are being actively
improved. depending on your user system requirements, these methods
may work well for you. i suggest investigating further.
Is it practical now to deploy a Perl6/Parrot runtime with a (possibly
precompiled) version of our product? Will it be practical any time soon? I can
probably get away with occasionally requiring Linux and Solaris users to
rebuild Parrot to fit their local configuration, but Windows is another
matter.
(Shipping a known version of the runtime with our product will also allow us
to tune our application to a known set of available perl6 functions.)
possible? yes, definitely. practical? that's hard to say. if parrot
and rakudo meet your functionality needs, and the packages are
available, then yes. however, i can't call it practical until i've
tried it successfully at least three times in simulated user
environments.
The mechanism for generating the packages I ship to my customers does not need
to be pretty, it just needs to exist. If there are instructions already online
about how to generate such packages (now or in the near future), I would
appreciate a pointer to them.
parrot has a guide for creating the monthly release package, and there
is a guide for debian packaging as well, found at
http://svn.perl.org/parrot/trunk/docs/project/). questions here or on
other related mailing lists are most welcome.
if, during the course of your further examination of parrot and
rakudo, you develop concerns on stability, portability, packaging,
completeness or other topics, there are multiple ways to address those
concerns. firstly, the mailing lists are an excellent
