Just wanted to everyone's attention to this section of the official Perl 6 wiki:
http://www.perlfoundation.org/perl6/index.cgi?perl_6_marketplace
Hopefully Jerry will want to add an entry now.
Hopefully Elyse will want to add one soon.
Best regards,
Conrad Schneiker
www.AthenaLab.com
Official Perl 6 Wiki — http://www.perlfoundation.org/perl6
> -----Original Message-----
> From: jerry gay [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 06, 2008 7:30 AM
> To: Elyse M. Grasso
> Cc: perl6-users; [EMAIL PROTECTED]
> Subject: Re: Practical Considerations
>
> 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 resource, as
> well as parrot's and rakudo's bug tracking systems
> (http://rt.perl.org/rt3/).
>
> however, if you want targeted development/design/training to address
> your company's needs, donations to the perl foundation
> (http://www.perlfoundation.org/) and parrot foundation
> (http://www.parrot.org) can produce wonderful results. for an example,
> see patrick michaud's perl 6 development grant final report
> (http://www.pmichaud.com/perl6/mfp6grant.pdf). as president of parrot
> foundation, i'd be happy to discuss this topic more.
>
> additionally, there are for-profit companies (like mine,
> http://www.rakudoconsulting.com) that offer services including
> targeted development on rakudo/parrot features and maintenance plans
> that give you the confidence you need to adopt a new technology and
> succeed, without the constraints under which a non-profit foundation
> operates. i'd be happy to discuss the specifics of what rakudo
> consulting group has to offer your business in an off-list discussion.
>
> ~jerry
