[EMAIL PROTECTED] wrote:
> What are we doing with it?  We are killing perl2exe.

Not exactly.

> The niches of:
>
>     1. "I don't want to use modules because the end-user might not have
>         them installed"
>

Yes.

>     2. "My end-users might not have Perl installed"  Bundling a Perl
>        interpretor with your program (until perlcc is viable)
>

No. I don't expect Perl installation or any other otherwise executable or
installation program to be bundled inside of archives. Correct if I'm wrong,
but archives are meant for Perl scripts and Perl modules. (documentation,
resource files, binaries of compiled extensions, ext. language source code,
and even binaries that instantiate a perl interpreter are ok, but not perl
libs.)


>     3. "I want to hide my source code from Evil Vicious Users!"  A
>        consequence of #2, however we can make the "hiding" very, very
>        cheesy and pun can "decompile".  But that's good enough for most.
>

No. One objectives of `par' is ``g) The archive file should be stored in a
format that can be easily created and inspected with widely available
external tools.'' (from alpha PDD). That means every user can access the
code inside the archive without problems. And this will be documented, so
that developpers can mess with their archives themselves.


> Unfortunately, this might hurt IndigoSTAR (makers of perl2exe) and the
> last thing I want to do with par is damage a Perl-friendly business.
> I'm not entirely sure how to approach them on this.
>

As I said before, #2 and #3 will not be hurt by `par'. However, `perlcc' in
Perl 6 will probably make building static executables easy and compiling to
bytecode will hide the source code, so I think `perl2exe' will probably and
unfortunately loose its mean, in Perl 6.

I actually agree that this is undesired (as you said, IndogoSTAR is
perl-friendly). But maybe there will still be people that want `perl2exe',
because even with perl2cc, bytecode and par all together, you won't be able
to compile this all into an executable with scripts and all static libraries
directly... And probably there will be still some Perl 5 applications that
benefit from it too.


>
> > 2: Is this really still language? If not, where should we be discussing
it?
>
> [EMAIL PROTECTED] anyone?
>

If someone cares to create this list? It should probably be
[EMAIL PROTECTED], because I believe the main focus is on shipping it with
Perl 6, althought I think we'll probably have a preliminary version on Perl
5.

- Branden

Reply via email to