Re: renaming or adding some operators

[Carl Mäsak]

Darren (>):
> Firstly, regarding the string replication ops as documented in Synopsis 3,
> 'x' and 'xx', I'm wondering whether it might be better to have something
> that incorporates a '~', since that operation is about catenation.
>
> Would perhaps '~*' work better than 'x' to signify better what the operation
> is doing; the '~' in this case means catenation and the '*' is meant to
> invoke 'multiply', not 'whatever'.  So '~*' means "catenate a multiple of
> times".
>
> This would then free up 'x' to be used for something else, if anything.
>
> As for a substitution for 'xx', I'm less sure about that.
>
> Thoughts?

I like 'x' for string replication and 'xx' for list replication. To
me, they share a sort of symmetry with '*' and '**' that at least help
as a mnemonic to their use.

There's a bit of symbolism in using 'x' for strings repetition too.
You may want an asterisk in your version of the operator because the
asterisk symbolizes multiplication/repetition to you, but the 'x'
looks like a cross operator, and indicates to me that some kind of
multiplication is going on here, but not the regular one. I can read
'$text x 5' as 'dollar text times five' in a way that feels very
natural.

// Carl

Re: renaming or adding some operators

[Darren Duncan]

Buddha Buck wrote:

Secondly, regarding the Bool type, I think it would be useful for Perl 6 to
define the full complement of dyadic logical operators, of which I count a
few that you don't appear to already have.  Probably the best place is in
Synopsis 32.


There are 16 dyadic logical operators, not all of which make sense to
have.You name 10.


I think you answered your own criticism right there.  The ones I didn't mention 
are ones that don't make sense to have.


2 of the 16 dyadic operators always result in false or true respectively, 
regardless of the arguments, same as 2 of the 4 monadic operators, and same as 
the only 2 niladic operators, contradiction/⊥ and tautology/⊤; only the last 
make sense to have.  Another 2 of the 16 always result in a certain one or other 
of the arguments, respectively, regardless of the value of the second argument; 
they are like 1 of the 4 monadic operators that always results in its argument, 
and so isn't useful.  Another 2 of the 16 always result in the opposite of the 
previous 2 I mentioned, and these are like the only 1 useful monadic operator, 
not/¬, that returns the opposite of its argument.


This then leaves 10 dyadic operators that are actually useful, of which Perl 
(and most languages) clearly includes 3 as standard infix operators: and, or, 
xor/!===, === (xnor), which leaves 6 others of which AFAIK implies/→ is the most 
commonly used of those.


Now, clearly ←,↚ are redundant with →,↛ if you just switch the operands around, 
but then by the same token <,≤/<= are also redundant with >,≥/>= if you just 
switch the operands, but it is useful to have both versions regardless.



I'm certain I know the semantics of these (and chooses the minimum of
the two, or the maximum, xor checks for difference, xnor checks for
sameness), but I'm uncertain of some of the rest...


But here are a few more dyadic:
* nand aka ⊼ aka ↑

true unless both operands are true


* nor aka ⊽ aka ↓

true if both operands are false


* implies aka imp aka →

true unless left operand true and right operand false.


* nimp aka ↛

true if left operand true and right operand false?


* if aka ←

true unless left operand false and right operand true


* nif aka ↚

true if left operand false and right operand true?


See these urls which were 2 of my primary references when building my lists:

  http://en.wikipedia.org/wiki/Logical_connective

  http://www.rbjones.com/rbjpub/logic/log048.htm

They should give you all the details.


The other six, which don't depend on the value of both operands, would
(if they existed) have the names false, left, right, nright, nleft,
and true.


I believe traditionally they are called: contradition, p, q, ¬q, ¬p, tautology 
(where p and q are the names of the arguments).



Thirdly, there are I'm sure a number of other aliases that could be added to
other ops, such as ≤ and ≥ for <= and >=, and ≠ for one of the inequality
operators, although that last one would probably make more sense if = was
the equality test operator, so maybe best to avoid ≠ then.


Perhaps ≡ and ≢ as aliases?


Well that's a thought, since those actually talk about 'identical' rather than 
'equal', though I believe for purposes of logic (ignoring geometry say) they 
mean exactly the same thing, and I prefer the = and ≠ symbols.


For all of that matter, I think that Perl 6 would look a lot prettier if it used 
= as the generic equality test op (what === is used for now) and used the likes 
of := for assignment/binding/etc.


I don't know if using = for assignment is actually liked by people because they 
think it looks better or just because it has momentum say from Perl 5 and C et 
al.  Probably the single main advantage I can see for needing a single character 
there is it combines easily with infix ops to make =foo ops, not that this still 
can't be done another way.


Larry, did you choose = for assignment and == etc for comparison because you 
thought that looked prettier, or because that was the C/etc convention that you 
decided to copy?


-- Darren Duncan

Re: Amazing Perl 6

[Geoffrey Broadwell]

Tim Nelson:
> There's some standard that says this is how to generate unicode:
>
> 1.Hold down Ctrl+Shift
> 2.Press U
> 3.Type the hexadecimal for the unicode character
> 4.Release Ctrl+Shift

This works under GNOME, which also has a variant that is a little
friendlier to the fingers (and probably also works better with various
accessibility changes to the shift keys):

1. Press Ctrl+Shift+U
2. Release; see 'underlined u' feedback
3. Type the hex for the Unicode character (leading 0's optional);
   hex digits continue showing underline feedback
4. Press Enter; underlined u and digits are replaced with final glyph


-'f

Re: renaming or adding some operators

[Timothy S. Nelson]

On Fri, 29 May 2009, Darren Duncan wrote:


Timothy S. Nelson wrote:

How about if xx became x, and then we did things like:

[~] @list x $count

...to get the string replciation?


Maybe you meant this?

 [~] $item x $count


	No, I'm pretty sure I meant what I wrote.  But if x coerced $item into 
a list (treated it as a list of one item), then that would work too.




I like that a lot.

And we could still have ~x as a shorthand for that specific case since it 
would likely be used often enough.


	Well, if we think it warrants it.  About the only P5 operator I use 
less than x are the bitwise ones, and the '...' operator.  And maybe modulus.


	If I only had the one replication operator to remember, I think I'd 
prefer it.  But I'm happy with whatever Larry decides.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: renaming or adding some operators

[Jon Lang]

Darren Duncan wrote:
>> Side note: one thing that I recently learned concerning implication
>> operators is that the direction of the implication doesn't necessarily
>> follow the direction of the arrow.  In particular, "A if B" is "A←B",
>> and "A only if B" is "A→B": in both of the original statements, the
>> implication flows right to left.
>
> I thought that the direction did matter, and that's why there are distinct
> versions in each direction.  It's like how < and > are the same thing but
> with the direction reversed, or subset/superset or contains/contained-by.
>
> If you read "A → B" as "A implies B" then that's the same as "if A then B",
> then the cause-effect reads left to right, which does follow the direction
> of the arrow, like Perl's "if cond() then action()".

The point is that it's equally valid to read "A → B" as "A only if B",
with the cause-effect going from B to A.  You have the same truth
table for both "A only if B" and "if A then B", so they use the same
logical operator; but the cause/effect flow is reversed between them.

-- 
Jonathan "Dataweaver" Lang

renaming or adding some operators

[Buddha Buck]

Resending to list

On Fri, May 29, 2009 at 9:53 PM, Darren Duncan  wrote:
> I had some thoughts lately about the Perl 6 operators, and wanted to bounce
> some ideas.
>
> 
>
> Secondly, regarding the Bool type, I think it would be useful for Perl 6 to
> define the full complement of dyadic logical operators, of which I count a
> few that you don't appear to already have.  Probably the best place is in
> Synopsis 32.

There are 16 dyadic logical operators, not all of which make sense to
have.    You name 10.

>
> Note that all the dyadic ops I am discussing are meant to be read as infix
> ops only.
>
> These are the boolean/logical ops you already have:
>
> Niladic ops aka value literals / constants:
> * Bool::False
> * Bool::True
>
> Monadic:
> * not aka !, but ¬ alias could be added
>
> Dyadic:
> * and aka &&, but ∧ alias could be added
> * or aka ||, but ∨ alias could be added
> * xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
> * ===, but xnor, ↔ aliases could be added

I'm certain I know the semantics of these (and chooses the minimum of
the two, or the maximum, xor checks for difference, xnor checks for
sameness), but I'm uncertain of some of the rest...

>
> But here are a few more dyadic:
> * nand aka ⊼ aka ↑
true unless both operands are true

> * nor aka ⊽ aka ↓
true if both operands are false

> * implies aka imp aka →
true unless left operand true and right operand false.

> * nimp aka ↛
true if left operand true and right operand false?

> * if aka ←
true unless left operand false and right operand true

> * nif aka ↚
true if left operand false and right operand true?

The other six, which don't depend on the value of both operands, would
(if they existed) have the names false, left, right, nright, nleft,
and true.

>
> For that matter, as you know, every single boolean/logical operator could
> also have a bitwise analogue, if people were so inclined.
>
> 
>
> Thirdly, there are I'm sure a number of other aliases that could be added to
> other ops, such as ≤ and ≥ for <= and >=, and ≠ for one of the inequality
> operators, although that last one would probably make more sense if = was
> the equality test operator, so maybe best to avoid ≠ then.

Perhaps ≡ and ≢ as aliases?

Re: renaming or adding some operators

[Darren Duncan]

Timothy S. Nelson wrote:

How about if xx became x, and then we did things like:

[~] @list x $count

...to get the string replciation?


Maybe you meant this?

  [~] $item x $count

I like that a lot.

And we could still have ~x as a shorthand for that specific case since it would 
likely be used often enough.


-- Darren Duncan

Re: renaming or adding some operators

[Darren Duncan]

Jon Lang wrote:

I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now.  I suppose that you might also introduce a '?x' and/or a '+x' to
complete the set, though for the life of me I can't think of how
they'd work or what they'd be good for.


I don't think that every ~foo needs a corresponding +foo or ?foo.  Sometimes 
doing that makes sense, and other times not.  So your idea may work on its own. 
 And actually if 'x' became '~x' and 'xx' became 'x', I think that would 
increase the amount of symmetry with other sets of Perl 6 operators, where plain 
'foo' is  the most generic version and adding ~ or + or ? etc is making 
specialized versions or post processing.  So then, 'x' simply means make a list 
of repeated items, and the ~ prefix means post-process with catenation.


So does anyone else have thoughts on that?


* ===, but xnor, ↔ aliases could be added


By the way, another alias for the above is 'iff' (if and only if)


 carry subtly varied semantics involving
short-circuiting behavior: andthen and orelse are like && and ||
except that they work off of success/failure instead of true/false;
"also" is an ordered, short-circuiting version of "&" (and thus
"all").  For some time now, I've wanted an analog for '|' and 'any' -
but the only name I can think of for it would be 'else', which has
some obvious clarity issues.


Thanks for the reminder.  So then, none of those are analogous to distinct 
boolean operators.



But here are a few more dyadic:
* nand aka ⊼ aka ↑
* nor aka ⊽ aka ↓
* implies aka imp aka →
* nimp aka ↛
* if aka ←
* nif aka ↚


Side note: one thing that I recently learned concerning implication
operators is that the direction of the implication doesn't necessarily
follow the direction of the arrow.  In particular, "A if B" is "A←B",
and "A only if B" is "A→B": in both of the original statements, the
implication flows right to left.


I thought that the direction did matter, and that's why there are distinct 
versions in each direction.  It's like how < and > are the same thing but with 
the direction reversed, or subset/superset or contains/contained-by.


If you read "A → B" as "A implies B" then that's the same as "if A then B", then 
the cause-effect reads left to right, which does follow the direction of the 
arrow, like Perl's "if cond() then action()".


If you read "A ← B" as "A if B", that the cause-effect reads right to left, like 
Perl's "action() if cond()".


So practically speaking then, these operators would be served by Perl's basic 
conditionals if each conditional block resulted in the thing specified when the 
condition is true, and some appropriate other value otherwise, so they can be 
used in an expression.  But since its probably saner to keep the existing 'if' 
etc as statements, then just make new ones as expressions; while using the same 
keyword, they wouldn't conflict due to different usage syntax.



Most of these suggestions could be implemented in a "Unicode
Operators" module; I see little need to put them into the default
setting.  I'm leery of introducing new unicade operators that don't
have ASCII aliases, as you might be inclined to do with set operators.


All of the logic operators I proposed *do* have ASCII aliases, which is the 
alphanumeric terms: same as we have [not, and, or, xor], we have [iff/xnor, 
nand, nor, implies/imp, nimp, if, nif], so I don't see a problem here.


Separately, while I support that one should be able to use all the Perl 6 
features without touching trans-ASCII characters if they don't want to, we 
shouldn't be afraid to exploit them in the default setting; any exploitations 
would just be aliases for the operator names.  See ext/Set.pm again for an 
example of how this could work.


Besides-which, on modern computers, you usually can read all the Unicode 
characters, whose use would probably make code more readable (and prettier), and 
if you have a decent toolset, it is easy to type those characters too.  I mean, 
what modern system doesn't support "input methods" by default?  People in most 
parts of the world must be able to write their non-Latin characters efficiently 
on Latin keyboards somehow right?  So just use the same method to write your 
math/etc symbols.  I'm doing so right now and its hardly any slower than typing 
ASCII characters.  (Note, unlike say Chinese where there could be tens or 
hundreds of thousands of characters, I would anticipate that a Perl 6 standard 
setting that exploits Unicode would only involve a few dozen math/etc symbols, 
not too many to deal with I think.)


-- Darren Duncan

Re: New CPAN

[Timothy S. Nelson]

On Fri, 29 May 2009, Mark Overmeer wrote:


* Timothy S. Nelson (wayl...@wayland.id.au) [090529 11:26]:

I'd like to suggest to Mark and Daniel that, seeing as I won't be
making it to any Perl event outside Australia, and maybe not even some
inside, and Mark can't keep up with IRC (my sympathies there), that the
best place for such a discussion might be a mailing list such as p6l!
(No sarcasm intended -- I'm saying you're doing the right thing, keep it
up :) ).


Once some people want to spend time on details of the subject, I suggest
to revive a separate mailinglist for it.  The list which we started two
years back was never used.  Installation/distribution is a complex matter
with many aspects to be discussed, so deserves its own list simply not
to bother the (quite independent subject of) Perl6.


What's the mailing list called?  And is it gone, or active-unused?


Who (besides Perl people) expect 5.10 after 5.8?

Err, lots of people?
kernel-2.6.27.5-117.local.fc10.i686


Eh, yes of course.  That problem is only inside perl programs, where version
numbers are considered floating point numbers.  Where 5.8.8 == 5.008008 ==
5.008_008.  And then you have test versions like 68.17_02, which are broken
floats and therefore flagged as development versions.


	I believe Perl 6 explicitly supports a "version" type that handles 
some of this (I know that's not a general solution, but still...).



 Allow me to point out that all the package managers out there have
solved this problem, so it must be solveable.


Yes... but that also means that for some packaged products, versions need
to get translated into a different versioning scheme.


	That may be the case, but it's probably the worry of 
Software::Packager.  Hopefully we can make it cope.



One of the main problems with the current set-up is the very limited
pre-information about the installation available to CPAN.pm.  It
downloads a 02packages.details file which does not contain info about
dependencies and such.  One of the much heart complaints from normal


Fixing this++


My internet connection is very fast.  Yours probably as well.  We don't
care about this, do we?


I do!  :)


IMO, fragmentation is crucial: you can not stack the load on a small
group of dedicated people because they burn-up that way.  People must
be able to fork their own pet project, like search.cpan.org.  And yes,
that enlarges the chance that such a project dies.  But that's normal
evolution.  At least, you have dedicated people with a work-load of their
own choice.


	The thing is, CPAN is mirrored everywhere.  If fragmentation occurs, 
some parts that are not mirrored may not be completely lost.  I guess that's 
my fear.


Anyway, I hope some of this helps.

:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: renaming or adding some operators

[Timothy S. Nelson]

On Fri, 29 May 2009, Jon Lang wrote:


On Fri, May 29, 2009 at 6:53 PM, Darren Duncan  wrote:

I had some thoughts lately about the Perl 6 operators, and wanted to bounce
some ideas.



Firstly, regarding the string replication ops as documented in Synopsis 3,
'x' and 'xx', I'm wondering whether it might be better to have something
that incorporates a '~', since that operation is about catenation.

Would perhaps '~*' work better than 'x' to signify better what the operation
is doing; the '~' in this case means catenation and the '*' is meant to
invoke 'multiply', not 'whatever'.  So '~*' means "catenate a multiple of
times".

This would then free up 'x' to be used for something else, if anything.

As for a substitution for 'xx', I'm less sure about that.

Thoughts?


I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now.  I suppose that you might also introduce a '?x' and/or a '+x' to
complete the set, though for the life of me I can't think of how
they'd work or what they'd be good for.


How about if xx became x, and then we did things like:

[~] @list x $count

...to get the string replciation?

HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Alex Elsayed wrote:


IMO, that discussion should go in the direction of additional services:
the CPAN archive distributes what authors publish.  The install tools
(CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
systems. As a service, other people can publish the results of their
specific module installation via package-managers to the world, such
that those people can use they platform native software management
tools.  Just like search.cpan.org is an independent additional service
on the CPAN archive.

And once again we run into an issue: This workflow would require that each end
user, rather than using /only/ CPAN(PLUS)? or /only/ their package manager to
install, they are forced to use one to generate packages, and then the other
to install them! By providing a very open metadata  spec, we can make it so
that neither the Perl community nor the end-users need to take on that burden.
Instead, it would go to the distributions, who are already well-prepared to
handle packaging. We'd just be providing the tools and material they need to
do so.


	Let me reiterate that, while I'd love to have the complete CPAN 
available pre-packaged for my distro, it doesn't seem like that's necessarily 
going to happen.  Thus, what I want is a tool that will allow me to download 
the source, turn it into a package for my distro, and install it.  This is why 
I want the Software::Packager solution.  Empower the user :).


Also. TMTOWTDI.  I'd like it so that the solution allows for:
-   People who want to install distro-packages from repos (this would
require nothing on the client side except yum/apt repo config)
-   People who want to build their distro-packages locally and install
them
-   People who want to build their distro-packages locally and not install
them
-   People who want to install the software directly into the Perl
directories without packaging them for their distro at all

Metadata++, though.


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: New CPAN

[Daniel Carrera]

Wayland wrote:
Allow me to point something out.  He wants to write a freely 
available software package that can share data, and is useful for the 
Perl6 environment. He's not suggesting that we have holiday photos on 
CPAN-the-network,


I'm not sure about that. We were talking about what things to include in 
CPAN-the-network (the new hypothetical p2p one where mirrors can choose 
what they want to mirror). I say that we could possibly permit compiled 
Perl module binaries or Ruby modules that run on Parrot. Mark says "why 
stop there? why not share holiday pictures?".



simply that the software not care whether the data 
inside it is a package or not, just whether it has metadata.  If you 
don't like the "holiday photos" examples, just skim over them :).  It's 
only 5 or so words to skip :).


It is not just 5 words to skip if those 5 words are the main point of 
his email (words are not created equal :) ).



Daniel.

Re: Amazing Perl 6

[Timothy S. Nelson]

On Fri, 29 May 2009, John M. Dlugosz wrote:

Ah yes, on the PC historically you hold down the ALT key and type the code 
with the numpad keys.


	At least when I used it, this was a decimal, rather than hex number, 
and had to be preceded by a 0 (zero).


So if anyone is still on eg. Windows 98, this may be the way to go :).


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Alex Elsayed wrote:


This problem strikes me as intractable - I think the only thing we can do is
provide a dependency specifier, clearly tagged as being external to the CPAN 6
archive, with a sensible name that allows a human to intervene and find the
correct package for their distro.


...and a store of "common mappings" for various distros :).

-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

renaming or adding some operators

[Jon Lang]

On Fri, May 29, 2009 at 6:53 PM, Darren Duncan  wrote:
> I had some thoughts lately about the Perl 6 operators, and wanted to bounce
> some ideas.
>
> 
>
> Firstly, regarding the string replication ops as documented in Synopsis 3,
> 'x' and 'xx', I'm wondering whether it might be better to have something
> that incorporates a '~', since that operation is about catenation.
>
> Would perhaps '~*' work better than 'x' to signify better what the operation
> is doing; the '~' in this case means catenation and the '*' is meant to
> invoke 'multiply', not 'whatever'.  So '~*' means "catenate a multiple of
> times".
>
> This would then free up 'x' to be used for something else, if anything.
>
> As for a substitution for 'xx', I'm less sure about that.
>
> Thoughts?

I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now.  I suppose that you might also introduce a '?x' and/or a '+x' to
complete the set, though for the life of me I can't think of how
they'd work or what they'd be good for.

> Secondly, regarding the Bool type, I think it would be useful for Perl 6 to
> define the full complement of dyadic logical operators, of which I count a
> few that you don't appear to already have.  Probably the best place is in
> Synopsis 32.
>
> Note that all the dyadic ops I am discussing are meant to be read as infix
> ops only.
>
> These are the boolean/logical ops you already have:
>
> Niladic ops aka value literals / constants:
> * Bool::False
> * Bool::True
>
> Monadic:
> * not aka !, but ¬ alias could be added
>
> Dyadic:
> * and aka &&, but ∧ alias could be added
> * or aka ||, but ∨ alias could be added
> * xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
> * ===, but xnor, ↔ aliases could be added
>
> Now I'm not sure whether or not [also, andthen, orelse] have the desired
> semantics of any others or not, or whether [if, unless] could be used as a
> value-resulting infix operator or not.

 carry subtly varied semantics involving
short-circuiting behavior: andthen and orelse are like && and ||
except that they work off of success/failure instead of true/false;
"also" is an ordered, short-circuiting version of "&" (and thus
"all").  For some time now, I've wanted an analog for '|' and 'any' -
but the only name I can think of for it would be 'else', which has
some obvious clarity issues.

> But here are a few more dyadic:
> * nand aka ⊼ aka ↑
> * nor aka ⊽ aka ↓
> * implies aka imp aka →
> * nimp aka ↛
> * if aka ←
> * nif aka ↚
>
> For that matter, as you know, every single boolean/logical operator could
> also have a bitwise analogue, if people were so inclined.

Side note: one thing that I recently learned concerning implication
operators is that the direction of the implication doesn't necessarily
follow the direction of the arrow.  In particular, "A if B" is "A←B",
and "A only if B" is "A→B": in both of the original statements, the
implication flows right to left.

Most of these suggestions could be implemented in a "Unicode
Operators" module; I see little need to put them into the default
setting.  I'm leery of introducing new unicade operators that don't
have ASCII aliases, as you might be inclined to do with set operators.

--
Jonathan "Dataweaver" Lang

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Daniel Ruoso wrote:


So, I'd expect to have a Debian archive, in the Debian case, hosted by
the Debian Perl group (which packages about ~ 500 CPAN modules to Debian
today) with the binary packages targetting each of the Debian
versions...

The same would go for RedHat and other linux distros, while for the
Win32 world, we would have something in the lines of what ActiveState
already does...

But, I insist, CPAN should only store the source packages and the source
metadata should only describe what are the sources, and not how to
compile and install them...


	Nononono.  Some of this is what I'm trying to get away from.  I 
semi-regularly want to use packages that have never been RPM-ed by anyone, or 
at least not a recent version.  I want an auto-building tool.  I could live 
without CPAN-or-whatever having the binaries stored in a public place, but I 
want to be able to auto-generate an RPM from and CPAN package.


	I hope we can work out a sensible solution that keeps us all happy. 
I'm following the discussions of DanielC and MarkOv with interest.



-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: Amazing Perl 6

[John M. Dlugosz]

Ah yes, on the PC historically you hold down the ALT key and type the 
code with the numpad keys.





There's some standard that says this is how to generate unicode:

1.Hold down Ctrl+Shift
2.Press U
3.Type the hexadecimal for the unicode character
4.Release Ctrl+Shift

I'm under the impression that Windows supports this in some 
circumstances, and I know some Linux programs support it too.  
Unfortunately my e-mail program (Pine) seems to have some trouble with 
unicode -- I may have to look at alternatives after 14 years of use :(.


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ 
PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Alex Elsayed]

> I know that Rakudo is not the official implementation. The problem is
> that you misunderstood my post. I did not say to distribute PIR to the
> exclusion of Perl source. You know that I was replying to Larry's
> comment that he supported the notion of distributing binaries. Surely
> you didn't think that Larry meant "distribute binaries to the exclusion
> of Perl source", did you? Therefore, my comment is a reply to the binary
> aspect and the central part of my comment is the problem with modules
> that require a C compiler.
Sorry about that then.

> > * Collision detection - It becomes impossible to prevent another package
> > from overwriting a file installed this way
>
> Nothing is impossible. The first method that crossed your mind may not
> do it, but that doesn't mean that it can't be done. In any case, the
> drawbacks are no worse than what the current CPAN shell does today. And
> the current CPAN shell obviously work fairly well. The current system
> has room for improvement, but any argument that says "it can't work" is
> flawed because it is working right this minute and it has been working
> for years.

It may not be impossible, but the only way to achieve that without making 
ebuilds and letting the package manager handle the package directly (on Gentoo 
at least) seem to be limited to "Support the (non-standardized) VDB database 
for installed packages internally". Which is a pretty shitty road to go down. 
Also, the Gentoo developers have flat-out declared that they will not 
officially support modules installed with the CPAN shell because of these 
issues, so the CPAN shell actually _doesn't_ work "fairly well" on Gentoo. It 
gives you an environment where your install is considered to be out of the 
control of the package manager and, therefore, a spaghetti mess where you have 
multiple package managers which overlap and interfere with each other, yet 
don't have any mechanism for cooperation, synchronization, or communication.

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Mark Overmeer wrote:


* PAUSE6; this is an actual network based on the CPAN6 software (see
  above).  It also is not documented here.


Pause6 is one implementation of archive maintenance software.  In the
first version written in Perl5, it implements things like


I'm still not sure we're on the same page.  Let me give an example:

-   HTTP is a specification
-   Apache is an implementation of a server for that specification
-   www.example.com runs a copy of Apache

Or another example:
-   Perl6 is a specification
-   Rakudo is an implementation of that specification
-   www.example.com runs a copy of Rakudo (to serve their site)

So we have:
-   Specification
-   Implementation
-   Installation

	Which of those is CPAN6?  Which is Pause6?  Your use of the word 
"implementation" is confusing me; I'm saying Pause6 is the installation 
(accessible to the world).  Is that what you're saying?


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Alex Elsayed]

> I believe he is arguing that whatever we end up doing needs to make it
> easy for an external package-manager to find out what files CPAN6.pm
> is going to install, and where, and what the dependencies were (both
> Perl and system libraries).  So that the various distributions can
> make native packages from perl packages automatically (or at least as
> close to automatically as possible, it gets a little uglier when
> external libraries are involved).
I am completely in agreement here.

> So if there is program "foo" that is written in Perl that Fedora wants to
> distribute, they want to be able to list the dependencies when they
> make the package for "foo".  If foo requires a few packages, then they
> just want to say that and then when foo is installed, pull in those
> packages and any that those depend on,
Agreed.

> including any non-perl ones
> that are needed by the perl packages.
Here is where it gets sticky. Let's take a perl module which requires the 
Berkely DB - in fact, requires a specific API version. In Gentoo, you'd 
specify that with a slot dependency, while on Fedora you'd specify the 
release. The two distros may well use different names for the package and/or 
the slot/release specifier.

This problem strikes me as intractable - I think the only thing we can do is 
provide a dependency specifier, clearly tagged as being external to the CPAN 6 
archive, with a sensible name that allows a human to intervene and find the 
correct package for their distro.

Re: [Fwd: Re: New CPAN]

[Timothy S. Nelson]

On Fri, 29 May 2009, Austin Hastings wrote:


How about "Parrot"?


	Because the SMOP Perl 6 implementation doesn't target Parrot, and 
won't, and we want to include them too.  Likewise other P6 implementations.


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

renaming or adding some operators

[Darren Duncan]

I had some thoughts lately about the Perl 6 operators, and wanted to bounce some 
ideas.




Firstly, regarding the string replication ops as documented in Synopsis 3, 'x' 
and 'xx', I'm wondering whether it might be better to have something that 
incorporates a '~', since that operation is about catenation.


Would perhaps '~*' work better than 'x' to signify better what the operation is 
doing; the '~' in this case means catenation and the '*' is meant to invoke 
'multiply', not 'whatever'.  So '~*' means "catenate a multiple of times".


This would then free up 'x' to be used for something else, if anything.

As for a substitution for 'xx', I'm less sure about that.

Thoughts?

Was that operator called 'x' because it was the best or because that was how 
Perl 5 did it, and Perl 6 wanted to not change things if it didn't need to?




Secondly, regarding the Bool type, I think it would be useful for Perl 6 to 
define the full complement of dyadic logical operators, of which I count a few 
that you don't appear to already have.  Probably the best place is in Synopsis 32.


Note that all the dyadic ops I am discussing are meant to be read as infix ops 
only.

These are the boolean/logical ops you already have:

Niladic ops aka value literals / constants:
* Bool::False
* Bool::True

Monadic:
* not aka !, but ¬ alias could be added

Dyadic:
* and aka &&, but ∧ alias could be added
* or aka ||, but ∨ alias could be added
* xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
* ===, but xnor, ↔ aliases could be added

Now I'm not sure whether or not [also, andthen, orelse] have the desired 
semantics of any others or not, or whether [if, unless] could be used as a 
value-resulting infix operator or not.


But here are a few more dyadic:
* nand aka ⊼ aka ↑
* nor aka ⊽ aka ↓
* implies aka imp aka →
* nimp aka ↛
* if aka ←
* nif aka ↚

For that matter, as you know, every single boolean/logical operator could also 
have a bitwise analogue, if people were so inclined.




Thirdly, there are I'm sure a number of other aliases that could be added to 
other ops, such as ≤ and ≥ for <= and >=, and ≠ for one of the inequality 
operators, although that last one would probably make more sense if = was the 
equality test operator, so maybe best to avoid ≠ then.


Lots of the other ones I can think of apply to sets, and the ext/Set.pm bundled 
with Pugs already documents them quite well.


However, I think some set ops could also be used with hashes.  For example, an 
alternate way of spelling "exists %foo{$bar}" is "$bar ∈ %foo" or "%foo ∋ $bar".


So, any thoughts?

-- Darren Duncan

Information Model manuscript, pt.2

[John M. Dlugosz]

Please see part 2 of my comprehensive explaination of the Perl 6 
Information Model, at .


This isn't linked up to my main page yet.  I'm taking comments and 
further discussion here before I make it public.


--John

Re: Amazing Perl 6

[Timothy S. Nelson]

On Fri, 29 May 2009, Jon Lang wrote:


On Fri, May 29, 2009 at 6:52 AM, John Macdonald  wrote:

Yep, I've done that.

But comparing the difference in effort between:

- press a key
- Google for a web page that has the right character set, cut, refocus, paste

means that I don't bother for the one or two "weird" characters
every few months that is my current Unicode usage.  If I were
working with Unicode frequently, it would be worth setting up
links and mechanisms, or learning the keyboard compose sequences
for frequently used characters.  I'm sure that there are many
people in a similar situation.


Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
love to be able to have a simple keyboard shortcut that produces these
two characters.  Unfortunately, I am often stuck using a Windows
system when coding; and the easiest method that I have available to me
there (that I know of) is to pull up Character Map.


There's some standard that says this is how to generate unicode:

1.  Hold down Ctrl+Shift
2.  Press U
3.  Type the hexadecimal for the unicode character
4.  Release Ctrl+Shift

	I'm under the impression that Windows supports this in some 
circumstances, and I know some Linux programs support it too.  Unfortunately 
my e-mail program (Pine) seems to have some trouble with unicode -- I may have 
to look at alternatives after 14 years of use :(.


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Alex Elsayed]

On Friday 29 May 2009 1:51:40 am Mark Overmeer wrote:
> I would really like to see a split in terminology being used for the
> various seperate problems.  The traditional confusion about what CPAN is:
> an archive or an install tool.  Package manager discussions are in the
> process AFTER the install tool: to distribute OS changes to be made.
> In the messages on the list, I see people merge requirements of these
> very independent tasks.
Okay, I will readily admit that there is a real need to have there be a more 
clear separation between these two separate things which are both called CPAN. 

> I think that package managers are not a "CPAN" related problem at all.
> The Perl install tool decides which files it wants to have within some
> file-system tree and versioned environment, and then package managers
> distribute those files and meta-data.
Here I'll have to disagree, for several reasons.
* The structure of the archival system will heavily impact the structure of 
the install tool
* If the archive does not provide sufficient information in a useful format, 
then it may be difficult or impossible to delegate installation to the local 
package manager. With the current CPAN architecture for Perl 5, it is 
impossible for an external package manager to calculate dependencies without 
first downloading the entire /source/ of all modules in the dependency list 
*due to a limitation of the archive architecture*

> Also, there are various different package managers around for Linux
> distributions, and they tend to be replaced every few years.  If you
> want people to use Perl modules on their Linux systems in a convenient
> way, you have to distribute each perl module in all of the existing
> formats. Of course, a tool like "alien" can be used to simplify the
> task of creating all these flavors.
This feels like a straw man to me.
* Package managers are actually relatively stable. The .deb, .rpm, and .ebuild 
formats (just to name three _big_ ones) have been around for at least 10 years 
each.
* We don't need to provide everything in all formats - If the archive 
structure makes automated conversion easy, then _each_ _distro_ can just run a 
cron job to
* Sync with the CPAN archive
* Automagically build packages for their own distro
* Publish those packages (PPA for Debian and Ubuntu, overlay for Gentoo)
* Alien is really not a very good solution, as it only works for binary 
distros, not source or hybrid ones (Gentoo, Exherbo, Arch) and even then only 
a few binary distros are supported

> IMO, that discussion should go in the direction of additional services:
> the CPAN archive distributes what authors publish.  The install tools
> (CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
> systems. As a service, other people can publish the results of their
> specific module installation via package-managers to the world, such
> that those people can use they platform native software management
> tools.  Just like search.cpan.org is an independent additional service
> on the CPAN archive.
And once again we run into an issue: This workflow would require that each end 
user, rather than using /only/ CPAN(PLUS)? or /only/ their package manager to 
install, they are forced to use one to generate packages, and then the other 
to install them! By providing a very open metadata  spec, we can make it so 
that neither the Perl community nor the end-users need to take on that burden. 
Instead, it would go to the distributions, who are already well-prepared to 
handle packaging. We'd just be providing the tools and material they need to 
do so.

> > I personally believe that there are a few requirements for a package
> > format that is sufficient for Perl 6:
> > * It must enable packaging for both binary- and source-based distros
> > * It must enable automatic generation of packages for supported systems
> > (although it may well not be capable of it out of the box)
> > * It must permit (or preferably help with) attempts to support new
> > systems * It must be simple to submit packages in the correct format
> > * It must enable the design and building of an automatic testing system
>
> The worst flaws in software design are based on the idea that you can
> organize the outside world.  The Perl community will never be able to
> push its packaging mechanism into Linux distributions.  We may be able
> to select the ideal packaging mechanism, and then they will wrap that
> in their own packaging mechanism.
As I said above, it doesn't need to. What my mail was suggesting was mainly a 
very information-rich metadata spec, which would contain enough information 
that the distros could package the modules without needing much more than 
that.
* For my first point, it merely says that the metadata must contain enough 
information to run an installation process, which is usually the information 
needed to build a distro package
* The second bulled adds the constraint that this should be doable in an

Re: New CPAN

[Andrew Whitworth]

On Fri, May 29, 2009 at 5:37 PM, Daniel Carrera
 wrote:
> Mark Overmeer wrote:
>>
>> And the next consideration: when we have a piece of software which
>> administers Perl5 or Perl6 or Nokia.bin or Elf.  Why stop there?
>> What is the overlap?  It is basically all just some blob of data with
>> some associated meta-data to search and retreive the blobs.  It is only
>> the client side install tool which looks into the content of the package.
>> Why not allow pure pod releases?  A small step to documents in any other
>> format.  Why not share holiday pictures?  Also just a blob of data with
>> some meta-data.
>
> Your idea of using CPAN to share holiday pictures is one of the things that
> really turned me off from your CPAN6 proposal. I do want this to be about
> Perl, you don't, and that's a point where we differ. In my examples,
> Nokia.bin is so that mobile users don't have to compile software on their
> tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot
> world, there is real opportunity  for Perl and Ruby to share libraries with
> each other (e.g. Perl on Rails). But when you start talking about sharing
> holiday pictures, you have completely left the Perl realm and I am
> completely turned off.

I agree. Doing one thing well is so much better for everybody then
doing a million things poorly. An assorted "blob of data" repository
is far less valuable to the Perl5, Perl6, and Parrot communities then
a dedicated library repository is. Adding metadata to something like
the existing CPAN that describes language and implementation is a step
that allows Perl6 libraries and maybe even POD-only releases
(language="pod", platform="pod") to be supported in the short term and
opens the possibility of multiple languages being supported in the
future. However, adding these two bits of metadata cannot be used
meaningfully to allow all sorts of random media, which is a Good
Thing.

We want a future CPAN to be "the place to go for supported and tested
library packages for Perl and maybe other languages", not "the place
where people dump assorted unrelated shit".

--Andrew Whitworth

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 05:50:57PM -0500, John M. Dlugosz wrote:
> Copy and paste it from the message into a word processor or other  
> program that lets you choose a font where it is not missing and make it  
> very large so you can see the details.
>
> Or see  for a large graphic in several fonts.

Or feed it as an argument to this program, whereupon it will tell you
directly which character it is.

Larry

#!/usr/bin/perl -C

binmode STDOUT, ":utf8";
$pat = "@ARGV";
if (ord $pat > 256) {
$pat = sprintf("%04x", ord $pat);
print "That's $pat...\n";
$pat = '\b' . $pat . '\b';
}
elsif (ord $pat > 128) {# arg in sneaky UTF-8
$pat = sprintf("%04x", unpack("U0U",$pat));
print "That's $pat...\n";
$pat = '\b' . $pat . '\b';
}

@names = split /^/, do 'unicore/Name.pl';
for my $line (@names) {
$hex = hex($line);
$_ = chr($hex)."\t".$line;
if (/$pat/io) {
print ' ' if /COMBINING/;
print;
}
}

Re: Amazing Perl 6

[John M. Dlugosz]

Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote:

On Fri, May 29, 2009 at 3:43 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
  

Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote:


In response to this thread, I activated the "US International"
keyboard layout, and once that's done theoretically one can get
"Spanish style quote mark" with RightAlt+[ and RightAlt+] like so: «
and ».

The questions which remain (for me, at least) is if (a) the symbols
survive in email, and (b) if they really are the proper marks for
Perl6.


  

Yes to both.  I see them fine, and they are the U+00AB and U+00BB
characters.

Care to try ☃ ?  That's alt-meta-hyper-doublebucky-cokebottle.



That's an eth, ð, right?  Hmm, doesn't look the same.  What is that?
  

--John


Copy and paste it from the message into a word processor or other 
program that lets you choose a font where it is not missing and make it 
very large so you can see the details.


Or see  for a large graphic in several fonts.

--John

r26969 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-05-30 00:57:54 +0200 (Sat, 30 May 2009)
New Revision: 26969

Modified:
   docs/Perl6/Spec/S04-control.pod
Log:
[S04] typos


Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-05-29 22:50:49 UTC (rev 26968)
+++ docs/Perl6/Spec/S04-control.pod 2009-05-29 22:57:54 UTC (rev 26969)
@@ -1021,7 +1021,7 @@
 object in C<$!> and knows whether it has been handled or not.  C<$!>
 contains one main exception, the most recent, plus an internal list
 of unhandled exceptions that may be accessed via the C<.pending> method.
-Whenever a new exceptions is stored in C<$!>, it becomes the new main
+Whenever a new exception is stored in C<$!>, it becomes the new main
 exception, and if the old main exception is not marked as handled,
 it is pushed onto the internal list of unhandled exceptions.
 
@@ -1053,7 +1053,7 @@
 exceptions as the new thrown exception, keeping the same structure of
 main exception and list of unhandled exceptions.  (The C<$!> seen in a
 C block is specially bound to this in-flight exception as the
-blocks initial value for C<$!>, but it may be modified by additional
+block's initial value for C<$!>, but it may be modified by additional
 failures as can any other block's C<$!> value.)  A C likewise
 moves all C<$!> exceptions up into C<< CALLER::<$!> >> before
 returning the current exception as normal return of a C.
@@ -1064,7 +1064,7 @@
 to throw those exceptions as a single new exception, which may then
 be caught with a C block in the current (or caller's) scope.
 The new main exception is the most recent one, with any older unhandled
-exceptions attached as additional.
+exceptions attached as pending.
 
 You can cause built-ins to automatically throw exceptions on failure using
 
@@ -1076,14 +1076,14 @@
 various parallel processing primitives that will tend to get blown
 up prematurely by thrown exceptions.  Unthrown exceptions are meant
 to provide a failsoft mechanism in which failures can be treated
-as data and dealt with one by one, without aborting executation
+as data and dealt with one by one, without aborting execution
 of what may be perfectly valid parallel computations.  If you
 I deal with the failures as data, then the block exit
 semantics will eventually trigger a thrown exception.
 
 In any case, the overriding design principle here is that no
 unhandled exception is ever dropped on the floor, but propagated
-onward through subsequent C<$!> variables until it is handled.  If
+outward through subsequent C<$!> variables until it is handled.  If
 that never happens, the implicit outermost exception handler will
 eventually decide to abort and print all unhandled exceptions found
 in the C<$!> that it is responsible for.

r26968 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-05-30 00:50:49 +0200 (Sat, 30 May 2009)
New Revision: 26968

Modified:
   docs/Perl6/Spec/S04-control.pod
Log:
[S04] expand on C<$!> semantics, remove requirement for GC on block exit


Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-05-29 14:29:27 UTC (rev 26967)
+++ docs/Perl6/Spec/S04-control.pod 2009-05-29 22:50:49 UTC (rev 26968)
@@ -12,8 +12,8 @@
 
   Maintainer: Larry Wall 
   Date: 19 Aug 2004
-  Last Modified: 25 May 2009
-  Version: 78
+  Last Modified: 29 May 2009
+  Version: 79
 
 This document summarizes Apocalypse 4, which covers the block and
 statement syntax of Perl.
@@ -1015,41 +1015,79 @@
 
 =head1 Exceptions
 
-As in Perl 5, many built-in functions simply return C when you ask
-for a value out of range, or the function fails somehow.  Perl 6 has
-C objects, any of which refers to an unthrown C object in
-C<$!> and knows whether it has been handled or not.
+As in Perl 5, many built-in functions simply return C when you
+ask for a value out of range, or the function fails somehow.  Perl 6
+has C objects, any of which refers to an unthrown C
+object in C<$!> and knows whether it has been handled or not.  C<$!>
+contains one main exception, the most recent, plus an internal list
+of unhandled exceptions that may be accessed via the C<.pending> method.
+Whenever a new exceptions is stored in C<$!>, it becomes the new main
+exception, and if the old main exception is not marked as handled,
+it is pushed onto the internal list of unhandled exceptions.
 
 If you test a C for C<.defined> or C<.true>, it causes C<$!>
-to mark the exception as I; the exception acts as a relatively 
harmless
-undefined value thereafter.  Any other use of the C object to
-extract a normal value will throw its associated exception immediately.
-(The C may, however, be stored in any container whose type
-allows the C role to be mixed in.)  The C<.handled> method
-returns C on failures that have not been handled.  It returns C 
for
-handled exceptions and for all non-C objects. (That is,
-it is an C method, not a C method.  Only C objects
-need to store the actual status however; other types just return C.)
+to mark the main exception as I; the exception acts as a
+relatively harmless undefined value thereafter.  Any other use of the
+C object to extract a normal value will throw its associated
+exception immediately.  (The C may, however, be stored in
+any container whose type allows the C role to be mixed in.)
+The C<.handled> method returns C on failures that have not
+been handled.  It returns C for handled exceptions and for
+all non-C objects. (That is, it is an C method,
+not a C method.  Only C objects need to store the
+actual status however; other types just return C.)
 
-Because the contextual variable C<$!> contains all exceptions collected in the
-current lexical scope, saying C will throw all exceptions,
-whether they were handled or not.  A bare C/C takes C<$!> as the
-default argument.
+The C<.handled> method is C, so you may mark an exception as handled
+by assigning C to it.  Note however that
 
-At scope exit, C<$!> discards all handled exceptions from itself, then performs
-a garbage-collection check for all remaining (unhandled) exceptions.  If all of
-them are still alive (e.g. by becoming part of the return value), then they are
-appended to C<< CALLER::<$!> >>.  Otherwise, it calls C to throw those
-exceptions as a single new exception, which may then be caught with a C
-block in the current (or caller's) scope.
+$!.handled = 1;
 
+marks only the main exception as handled.  To mark them all as handled
+you must access them individually via the C<.pending> method.
+
+A bare C/C takes C<$!> as the default argument specifying
+the exception to be thrown or propagated outward to the caller's C<$!>.
+
+Because the contextual variable C<$!> contains all exceptions collected
+in the current lexical scope, saying C will rethrow all those
+exceptions as the new thrown exception, keeping the same structure of
+main exception and list of unhandled exceptions.  (The C<$!> seen in a
+C block is specially bound to this in-flight exception as the
+blocks initial value for C<$!>, but it may be modified by additional
+failures as can any other block's C<$!> value.)  A C likewise
+moves all C<$!> exceptions up into C<< CALLER::<$!> >> before
+returning the current exception as normal return of a C.
+
+At scope exit, C<$!> discards all handled exceptions from itself,
+then if there are any remaining unhandled exceptions, either as the
+main exception or as any listed unhandled exception, it calls C
+to throw those exceptions as a single new exception, which may then
+be caught with a C block in the current (or caller's) scope.
+The new main exception is the most recent one, with any older unhandled
+exceptions attached as additional.
+
 You can cause built-ins to automatically

Re: New CPAN

[Daniel Carrera]

Mark Overmeer wrote:

And the next consideration: when we have a piece of software which
administers Perl5 or Perl6 or Nokia.bin or Elf.  Why stop there?
What is the overlap?  It is basically all just some blob of data with
some associated meta-data to search and retreive the blobs.  It is only
the client side install tool which looks into the content of the package.
Why not allow pure pod releases?  A small step to documents in any other
format.  Why not share holiday pictures?  Also just a blob of data with
some meta-data.


Your idea of using CPAN to share holiday pictures is one of the things 
that really turned me off from your CPAN6 proposal. I do want this to be 
about Perl, you don't, and that's a point where we differ. In my 
examples, Nokia.bin is so that mobile users don't have to compile 
software on their tiny CPUs. I can see merit in adding Ruby modules 
because in a new Parrot world, there is real opportunity  for Perl and 
Ruby to share libraries with each other (e.g. Perl on Rails). But when 
you start talking about sharing holiday pictures, you have completely 
left the Perl realm and I am completely turned off.


Daniel.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 19:55]:
> Btw, if we do go ahead with this "meta CPAN" idea, it'll be important to  
> divide the network into self-contained groups. Earlier I used the word  
> "target". Alternatively we could say "platform". Example platforms could  
> include:
>
> Perl 5 <-- Perl 5 source code.
> Perl 6 <-- Perl 6 source code.
> Parrot <-- Parrot assembly.
> Lua<-- Lua source code.
> Nokia.bin <-- Compiled binary for the Nokia handheld.
> Elf-ia64  <-- Compiled binary in ELF format for the IA64 architecture.
>
> You get the idea...  Mirrors pick which platforms they'll hold.

Now we are getting somewhere.  A "mirror" doing only a part is a bit
strange.  A mirror doing half-work is more a filter.

So, if we replace your term "platform" into my term "archive", and your
"meta CPAN archive" into my "CPAN6", then we are on the same track...
I call it "CPAN6 servers invite selected archives on their system",
where you like to say "CPAN mirrors copy selected platforms/targets of
the main archive"

And the next consideration: when we have a piece of software which
administers Perl5 or Perl6 or Nokia.bin or Elf.  Why stop there?
What is the overlap?  It is basically all just some blob of data with
some associated meta-data to search and retreive the blobs.  It is only
the client side install tool which looks into the content of the package.
Why not allow pure pod releases?  A small step to documents in any other
format.  Why not share holiday pictures?  Also just a blob of data with
some meta-data.

Those final steps changed my world.  Where Windows has a "My Pictures"
directory, how do we organize "Our Pictures"?  Just a hack: Flickr or
a shared NFS disk.  And "Our Software?": CPAN.  And there are document
management systems, ftp-servers, linux distributions, ... etc etc...
And all facilitate creating collections of a certain type.

People are collectors by evolution, for their own or for a group.  It is
simple to organize a private collection on computers, but for all group
collections on computers, we only have hacks.  Studying different kinds
of collections have led me to a relatively small set of features we need.
What will we share, with whom, how do we distribute, where do we store
it what does it need additionally.  Add some modern needs as security,
fail-over and license tracking and see my meta-data design.

The surprise is that I have not been able to find any software where you
can start collections as general basic infrastructure.  On the level of
network file-system.  A totally new application of Internet.  The beauty
of our community collection in CPAN can be extended to benefit all
computer users.  That is where my CPAN6 is about.  CPAN to the power 6.
Oh, maybe it will also be used for the Perl6 module collection.  That's
to the Perl people to decide.
-- 
Regards,
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: Commentary on S22 (CPAN [DRAFT])

[Daniel Carrera]

Daniel Carrera wrote:
4) Lastly, while we are at it, why don't we add a signature file to the 
_par directory?


_par/
META.info
CHECKSUMS.asc

The CHECKSUMS.asc file would contain the SHA1 sums of every file in the 
archive except for itself. The file could be GPG-signed with --armor 
(.asc extension).


To expand on this idea: The current JIB spec includes an Author field in 
META.info. The spec says:


- Author CPAN author id


This is perfect. We can offer that people create a CPAN id before 
distributing apps in PAR format, and upload their GPG public key. Then, 
when the user installs the app, the installer downloads the public key 
from CPAN and checks the signature.


Of course, we can't mandate that people register with CPAN. This is just 
a service. So there should be an option to check a signature using a 
public key you got from elsewhere, or to disable the signature check 
entirely.


Daniel.

Commentary on S22 (CPAN [DRAFT])

[Daniel Carrera]

Hello,

I finished reading S22 (CPAN [DRAFT]). This synopsis is about the 
package format, not about the network. I have some comments:


1) Instead of calling the format "JIB", how about "PAR"? It can stand 
for Perl ARchive or the recursive PAR ARchive. This is more memorable.


2) S22 proposes the following structure:

p5-Foo-Bar/
lib/
Foo/
Bar.pm
t/
00_load.t
_jib/
META.info


In the rest of this email I will replace "_jib" by "_par".

Now, the first thing I notice is that a single package could hold many 
modules. I'm sure this is intentional:


lib/
Canine/
Dog.pm
Feline/
Cat.pm


This gave me another idea: This same format could be used to distribute 
*applications*. All we need to do is add an "bin" directory:


p6-Pets-App/
lib/
Canine/
Dog.pm
Feline/
Cat.pm
bin/
Pets.pl
t/
00_load.t
_par/
META.info


So the same package can carry an app, as well as all the modules it 
depends on. Even better, the app package can say what Perl modules it 
depends on. If my application uses the DBI module, I don't have to 
bundle the DBI module with my app. I can simply say that my app depends 
on that module and let the package manager take care of it.



This change would make it much easier to distribute Perl apps.

What do you think?

3) Then again, if we are going to allow that, then maybe we also want to 
allow a "share" directory:


p6-Pets-App/
lib/
Canine/
Dog.pm
Feline/
Cat.pm
bin/
Pets.pl
share/
pets-icon.png
t/
00_load.t
_par/
META.info



4) Lastly, while we are at it, why don't we add a signature file to the 
_par directory?


_par/
META.info
CHECKSUMS.asc


The CHECKSUMS.asc file would contain the SHA1 sums of every file in the 
archive except for itself. The file could be GPG-signed with --armor 
(.asc extension).


What do you think?

Daniel.

Re: Amazing Perl 6

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

On Fri, May 29, 2009 at 6:52 AM, John Macdonald  wrote:
  

Yep, I've done that.

But comparing the difference in effort between:

- press a key
- Google for a web page that has the right character set, cut, refocus, paste

means that I don't bother for the one or two "weird" characters
every few months that is my current Unicode usage.  If I were
working with Unicode frequently, it would be worth setting up
links and mechanisms, or learning the keyboard compose sequences
for frequently used characters.  I'm sure that there are many
people in a similar situation.



Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
love to be able to have a simple keyboard shortcut that produces these
two characters.  Unfortunately, I am often stuck using a Windows
system when coding; and the easiest method that I have available to me
there (that I know of) is to pull up Character Map.

  
Windows:  see Tavultasoft's key mapper.  Free to use existing keyboard 
layouts, pro version needed to make your own.  It was awesome when 
writing stuff heavily-leaden with IPA characters.

Re: Amazing Perl 6

[John M. Dlugosz]

Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote:

In response to this thread, I activated the "US International"
keyboard layout, and once that's done theoretically one can get
"Spanish style quote mark" with RightAlt+[ and RightAlt+] like so: «
and ».

The questions which remain (for me, at least) is if (a) the symbols
survive in email, and (b) if they really are the proper marks for
Perl6.

  



Yes to both.  I see them fine, and they are the U+00AB and U+00BB 
characters.


Care to try ☃ ?  That's alt-meta-hyper-doublebucky-cokebottle.

--John

Re: Amazing Perl 6

[Patrick R. Michaud]

On Fri, May 29, 2009 at 10:04:39AM -0700, Larry Wall wrote:
> On Fri, May 29, 2009 at 09:50:36AM -0700, yary wrote:
> : Show that much of the basics still work:
> : > my @x=('a' .. 'z'); @x[3,4]=qw(DeeDee Ramone);
> :   say @x.splice(2,4).join(',')
> : c,DeeDee,Ramone,f
> 
> That qw is not a good example of what still works, since it is supposed
> to be interpreted as a qw subroutine (rakudo bug).  I recommend square
> brackets instead.

And Rakudo now correctly treats qw() like a function instead of
a quote:

  $ ./perl6
  > say qw(DeeDee Ramone);
  Could not find non-existent sub Ramone
  > say qw (DeeDee Ramone);
  DeeDeeRamone
  > say qw[DeeDee Ramone];
  DeeDeeRamone
  > 

Thanks Larry!

Pm

Re: New CPAN

[Daniel Carrera]

John Macdonald wrote:

Comprehensive Programming Archive Network.


Another problem with "Programming" is that it assumes that other 
languages will actually use the system. We don't know that currently
and it is a bit presumptions to assume that they will. It would look 
awkward if only Perl used the Comprehensive Programming Archive Network.


I think it's better to pick a name that doesn't assume very much in 
either direction and just see what happens.



Btw, if we do go ahead with this "meta CPAN" idea, it'll be important to 
divide the network into self-contained groups. Earlier I used the word 
"target". Alternatively we could say "platform". Example platforms could 
include:


Perl 5 <-- Perl 5 source code.
Perl 6 <-- Perl 6 source code.
Parrot <-- Parrot assembly.
Lua<-- Lua source code.
Nokia.bin <-- Compiled binary for the Nokia handheld.
Elf-ia64  <-- Compiled binary in ELF format for the IA64 architecture.


You get the idea...  Mirrors pick which platforms they'll hold.

Then we can say that if anyone wants to add a platform to CPAN, they 
have to find people willing to maintain it. In other words, the Perl 
guys will only maintain the Perl platforms. But the Lua guys are welcome 
to get people together and administer a Lua platform on CPAN.


Just some ideas...

Daniel.

Re: Amazing Perl 6

[John M. Dlugosz]

John Macdonald john-at-perlwolf.com |Perl 6| wrote:

On Thu, May 28, 2009 at 08:10:41PM -0500, John M. Dlugosz wrote:
  

John Macdonald john-at-perlwolf.com |Perl 6| wrote:


However, the assumption fails if "process" is supposed to mean that
everyone is capable of generating Unicode in the messages that they
are writing.  I don't create non-English text often enough to have
it yet be useful to learn how.  (I'd just forget faster than I'd use
it and have to learn it again each time - but Perl 6 might just be
the tipping point to make learning Unicode composition worthwhile.)
  
  
Just copy/paste from another message or a web page.  Perhaps a web page  
designed for that purpose...



Yep, I've done that.

But comparing the difference in effort between:

- press a key
- Google for a web page that has the right character set, cut, refocus, paste

means that I don't bother for the one or two "weird" characters
every few months that is my current Unicode usage.  If I were
working with Unicode frequently, it would be worth setting up
links and mechanisms, or learning the keyboard compose sequences
for frequently used characters.  I'm sure that there are many
people in a similar situation.
  
I noticed I Wikipedia that the edit page now has a selection at the 
bottom.  Very handy.  I usually use BabelMap to explore characters and 
also copy them to the clipboard.


But a while back I started writing a book on basic science for kids and 
curious adults, and started off with scientific notation.  The crosses, 
dots, and math-minus was driving my nuts, in such quantity as to prevent 
the flow of thought.  So I bought a 16-button "X-keys" strip.  Turns out 
the software stinks to high heaven and was essentially useless (hmm, 
what's the point, then?) so I had to write my own driver for it.  
Minimal, but gets the job done. 


--John

Re: Feature request: Grammar debugging support

[Patrick R. Michaud]

On Fri, May 29, 2009 at 11:20:20AM -0700, Larry Wall wrote:
> Can't help you with PGE, but STD supports a trace facility by
> setting the STD5DEBUG environent variable to -1, or a set of bits
> defined in src/perl6/Cursor.pmc in the pugs repo.

I'll look at what STD is using for its traces and see if I can
come up with something similar for PGE.

Pm

Re: New CPAN

[Daniel Carrera]

John Macdonald wrote:

On Fri, May 29, 2009 at 07:26:11PM +0200, Daniel Carrera wrote:
Btw, if the majority wants to start uploading Ruby, Python and Lua  
modules to CPAN, we can rename CPAN so that the P stands for something  
else that doesn't mean anything. "Comprehensive Peacock Archive  
Network"? "Comprehensive Platypus Archive Network"?


Comprehensive Programming Archive Network.


I thought of that, but it sounded very broad to me (e.g. assembly 
language, compiled binaries that can't be used b Perl, etc).


In any case, if most people agree with the general principle of renaming 
CPAN, we can have a Condorcet vote. Condorcet is a method whereby you 
rank all the options in order of preference and Condorcet selects the 
compromise candidate. Unlike the antiquated voting system that most 
countries use, Condorcet does not suffer from split votes.


Daniel.

[Fwd: Re: New CPAN]

[Austin Hastings]

Sorry, didn't do a reply-all on this.
--- Begin Message ---

How about "Parrot"?

I think the original point, along with one of the original claims for 
Parrot, was that Parrot would not just be the "Perl internals engine" 
but would be general enough to run other languages. (Specifically, there 
are Tcl, Python, Pascal, and Lua implementations in various stages of 
dress.)


So if someone wrote the next killer thing (Rails, anyone?) in some 
language that compiles to Parrot, it should be possible to install the 
parrot binary and have it work if you're a Perl6/Parrot user instead of 
a Ruby/Parrot or C#/Parrot or Pascal/Parrot user.


The risk is that there are now more Perl6es than just Rakudo. This tends 
to force "language level" instead of "binary level" distribution. It's 
sort of like the difference between CPAN and Maven.


Maybe they're two different things. There's a use-case question there, 
which should probably be addressed by someone who has read the CPAN6 
requirements doc (I have not).


=Austin


Daniel Carrera wrote:

Daniel Carrera wrote:
Btw, if the majority wants to start uploading Ruby, Python and Lua 
modules to CPAN, we can rename CPAN so that the P stands for 
something else that doesn't mean anything. "Comprehensive Peacock 
Archive Network"? "Comprehensive Platypus Archive Network"?



my (@C,@P,@A,@N);
@C = ;
@P = ;
@A = ;
@N = ;

say (@C.pick,@P.pick,@A.pick,@N.pick).join(" ");


Cheers,
Daniel.




--- End Message ---

Re: New CPAN

[John Macdonald]

On Fri, May 29, 2009 at 07:26:11PM +0200, Daniel Carrera wrote:
> Btw, if the majority wants to start uploading Ruby, Python and Lua  
> modules to CPAN, we can rename CPAN so that the P stands for something  
> else that doesn't mean anything. "Comprehensive Peacock Archive  
> Network"? "Comprehensive Platypus Archive Network"?

Comprehensive Programming Archive Network.

(I started with Pscripting, but decided that was too restrictive.)

Re: Feature request: Grammar debugging support

[Larry Wall]

Can't help you with PGE, but STD supports a trace facility by
setting the STD5DEBUG environent variable to -1, or a set of bits
defined in src/perl6/Cursor.pmc in the pugs repo.

Note the log uses ANSI color, so you might want to use less -R
or some such.

Larry

Re: New CPAN

[Daniel Carrera]

Daniel Carrera wrote:
Btw, if the majority wants to start uploading Ruby, Python and Lua 
modules to CPAN, we can rename CPAN so that the P stands for something 
else that doesn't mean anything. "Comprehensive Peacock Archive 
Network"? "Comprehensive Platypus Archive Network"?



my (@C,@P,@A,@N);
@C = ;
@P = ;
@A = ;
@N = ;

say (@C.pick,@P.pick,@A.pick,@N.pick).join(" ");


Cheers,
Daniel.

Feature request: Grammar debugging support

[Austin Hastings]

I'm using the PGE/PCT tools for working with grammars on Parrot, and I 
have to say that while there's a lot of power, there's very little 
debugging support. What's more, the debugging that is possible seems to 
be "parrot debugging" --i.e., single-stepping through routines, etc. -- 
instead of "grammar debugging."


Given that P6 grammars are at least partially supported in P5, it seems 
like it would pay dividends to insert some sort of debugging mechanism 
at the grammar spec level.


Right now, I'm talking about things like understanding the paths and 
alternations considered by the parser. "Why is that rule being executed 
twice? Shouldn't this be a short-name instead of an identifier?" Maybe 
this is purely output-oriented, at least for early days, but the ability 
to set some kind of $grammar.trace(1) flag would be a real win.


It may be that there are other useful things to get from the engine than 
rule sequencing. But that's the level I'm operating at right now, and I 
can't think of the other stuff (possibly because all these trees are in 
the way...).


=Austin

Re: New CPAN

[Daniel Carrera]

Larry Wall wrote:

I think this is an important point, philosophically.  The internet,
and later the web, both succeeded primarily because they unified
identity *without* resorting to centralization (except to bootstrap
the top-level nameservers, of course).  But identity must not be
confused with location.  It's perfectly fine for various repos to
store only a subset of an archive, just as it's perfectly fine for
a node on the internet to only handle a portion of the traffic.
But they get away with this only because of uniform addressing.


Indeed, there is no reason why every CPAN mirror has to hold *all* of 
CPAN. As long as the actual module-mirror resolution happens 
transparently, what does it matter?


Following up on the points raised by Mark and Larry, a more distributed 
CPAN (where each mirror can choose *what* to mirror) could point the way 
to resolving both of the issues I've mentioned:


1) Mirrors who want to hold Perl but not (say) Ruby.
2) Mirrors who don't want to hold (say) binaries for the Nokia handheld.


If mirrors can choose what parts of the CPAN repository they want to 
mirror, the above issues go away. If you don't want to mirror binaries 
in your server, you don't have to. As long as we use some URI/DNS type 
system, we can locate *some* mirror that has the module we are looking 
for, and just grab it from there.


Taking the distributed idea further, mirrors could use some kind of P2P 
system in the style of Bittorrent in order to distribute new modules and 
updates throughout the CPAN network.


What do you think?

With these changes (letting mirrors choose what they want to mirror) I 
would guess that the only issues left with CPAN holding Ruby modules is 
philosophical. Personally I don't feel strongly about the philosophy. I 
would be quite happy to install a module I can use from Perl 6 even if 
it was written in Ruby ("Perl on Rails" anybody?).



Btw, if the majority wants to start uploading Ruby, Python and Lua 
modules to CPAN, we can rename CPAN so that the P stands for something 
else that doesn't mean anything. "Comprehensive Peacock Archive 
Network"? "Comprehensive Platypus Archive Network"?


Daniel.

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 09:50:36AM -0700, yary wrote:
: Back to the question of "cool things about perl6"- after showing some
: of the extended syntax and its expressiveness, put up a slide saying
: "it's still Perl".
: 
: Show that much of the basics still work:
: > my @x=('a' .. 'z'); @x[3,4]=qw(DeeDee Ramone);
:   say @x.splice(2,4).join(',')
: c,DeeDee,Ramone,f

That qw is not a good example of what still works, since it is supposed
to be interpreted as a qw subroutine (rakudo bug).  I recommend square
brackets instead.

Larry

Re: New CPAN

[Larry Wall]

On Fri, May 29, 2009 at 04:32:00PM +0200, Mark Overmeer wrote:
: * Daniel Carrera (daniel.carr...@theingots.org) [090529 14:24]:
: > I think that it would be a good idea to put Perl 5 and Perl 6 modules in  
: > the same CPAN.
: 
: I have a very cowardous reply on this.  My CPAN6 design supports both
: sub-setting and super-setting archives.  So, it can produce three
: access-points: pure-perl6, pure-perl5 and combined.  If they physically
: share a disk "store", you even do not even need copies of the releases.
: 
: And... I do not really care what kind of information people keep inside
: the archive.  That is for the founding "board" of the archive to decide.
: As long as it has meta-data, it is ok to my scope.

I think this is an important point, philosophically.  The internet,
and later the web, both succeeded primarily because they unified
identity *without* resorting to centralization (except to bootstrap
the top-level nameservers, of course).  But identity must not be
confused with location.  It's perfectly fine for various repos to
store only a subset of an archive, just as it's perfectly fine for
a node on the internet to only handle a portion of the traffic.
But they get away with this only because of uniform addressing.

So think of this as more a problem of identity.  The data can flow
wherever it likes, as in a p2p network; as long as you can actually
*name* what you want to acquire, the network can figure out how to give
it to you eventually.  This is why S11 specs that module versions are
immutable once made official, and names include versions and naming
authorities (and presumably some checksumming), so that it doesn't
matter where you get the module from, it will always be the same thing.

Nothing else is likely to scale.  Let's all remember the old joke:

Biologist: What could possibly be worse than a velociraptor?
Physicist: Obviously, an acceloraptor.

Long term, acceloraptors tend to beat out velociraptors.  Perl 6 is
all about being an acceloraptor.  :)

Larry

Re: New CPAN

[Larry Wall]

On Fri, May 29, 2009 at 05:32:16PM +0200, Mark Overmeer wrote:
: >> Perl6 and Perl5 have some things in common, just like PHP and Perl5.
: >
: > Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5  
: > compatibility mode and Perl 6 is intended to be able to use Perl 5  
: > modules. That makes Perl 5 different from PHP.
: 
: The parrot-based PHP implementation will be able to link Perl6 and
: PHP code, if I understand correctly.  And the same for Python.  And
: Lua. and so on.  I don't know.  I am less convinced about a strong
: bond than you.

And indeed, Perl 6 considers all other languages to be dialects of
itself.  Even if you say "Perl only", any Perl 6 program can say:

use Befunge;

and then continue in the Befunge dialect of Perl 6, assuming the
Befunge Perl 6 module is available.  :)

I realize this is not the current attitude of (much of) the Perl 5
community, but originally Perl succeeded because it *connected* with
everything else it could, not because it was trying to be an island
to itself.  Perl was never supposed to be about drawing boundaries.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 10:47:44AM -0400, Buddha Buck wrote:
: The questions which remain (for me, at least) is if (a) the symbols
: survive in email, and (b) if they really are the proper marks for
: Perl6.

Yes, and yes.

Me, I just defined a compose key, and compose << does the right thing.
(though I often use ^K<< in vim).

Larry

Re: Amazing Perl 6

[yary]

Back to the question of "cool things about perl6"- after showing some
of the extended syntax and its expressiveness, put up a slide saying
"it's still Perl".

Show that much of the basics still work:
> my @x=('a' .. 'z'); @x[3,4]=qw(DeeDee Ramone);
  say @x.splice(2,4).join(',')
c,DeeDee,Ramone,f

the splice and join as methods instead of subs is different in p6 then
p5 but should still look familiar. And if that is too harsh there's

"use v5"

so one can use the old syntax, if there's a want or need to.

The real benefit/amazing thing about perl6's back-compatibility is the
ability to still use the substantial mass of code libraries in cpan-

use Catalyst;

Huge plus there!

It's good to show/remind people that their investment in perl is still
valid when they pick up perl v6. That's one of the amazing things.
IMHO, it is really cool that the perl6 specs mandate that older perl
modules will work... just as I was happy that perl 5.0 let me use my
old perl 4 packages, with single quotes instead of "::" and all...

I'd also like to help "nip in the bud" a tendency to view perl v6 as a
different language from perl v5. Along those lines, might be worth
mentioning how perl 6 is already leaking into perl 5.10+, things such
as "say", the smart-match operator "~~", and various cpan modules that
implement perl v6 features like gather/take in perl v5.

Re: [RFC] CPAN6 requirements analysis

[Ben Bennett]

On Fri, May 29, 2009 at 10:02:20PM +1000, Timothy S. Nelson wrote:
> On Fri, 29 May 2009, Mark Overmeer wrote:
>> IMO, that discussion should go in the direction of additional services:
>> the CPAN archive distributes what authors publish.  The install tools
>> (CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
>> systems. As a service, other people can publish the results of their
>> specific module installation via package-managers to the world, such
>> that those people can use they platform native software management
>> tools.  Just like search.cpan.org is an independent additional service
>> on the CPAN archive.
>
>   Are you arguing here for eg. a yum/apt/whatever repository on Pause6?

I believe he is arguing that whatever we end up doing needs to make it
easy for an external package-manager to find out what files CPAN6.pm
is going to install, and where, and what the dependencies were (both
Perl and system libraries).  So that the various distributions can
make native packages from perl packages automatically (or at least as
close to automatically as possible, it gets a little uglier when
external libraries are involved).

So if there is program "foo" that is written in Perl that Fedora wants to
distribute, they want to be able to list the dependencies when they
make the package for "foo".  If foo requires a few packages, then they
just want to say that and then when foo is installed, pull in those
packages and any that those depend on, including any non-perl ones
that are needed by the perl packages.


-ben

[RFC] CPAN6 requirements analysis

[Alex Elsayed]

While lurking in IRC, I've seen several discussions of what CPAN 6 should 
look like. Honestly, wayland76++'s idea for packaging seems the best to me. 
Most of the suggestions so far, especially those based on alien, apt, yum, 
or other existing package managers have a few major problems:

* Alien only converts between a few package formats
* All of these suggestions are _heavily_ biased towards binary distributions
* These suggestions make automatic packaging for new distros extremely 
difficult, because they require major changes to multiple projects

For example, let's take Gentoo or Exherbo. Gentoo has two package managers, 
one which is used by most Gentoo users (Portage) and one which is more 
featureful and advances faster (for various reasons, including more 
developers) (Paludis). Portage supports binary packages through .tbz2 files 
with trailing metadata. Paludis does not support these, as they have been 
deemed ill-conceived and poorly implemented by the lead developer, and is 
working on its own binary package system. Exherbo uses Paludis exclusively. 
Both distros are source-based.

Paludis has a tool which can import arbitrary trees to merge into the 
filesystem, but it's generally preferred that it be used only by users, not 
system packagers.

Portage has no such tool.

One existing problem for Gentoo is supporting installation of Perl 5 
modules. Because all metadata is spread out (and more importantly, /inside/ 
the tarballs), it is impossible to, say, add a new kind of repository for 
Perl modules - you'd have to have the full source for every module on your 
machine. Similarly, the automatic ebuild creator for P5 modules, g-cpan, is 
forced to recursively download packages, unpack them, and read their 
metadata before fetching their dependencies. This poses a significant 
problem for distros which mandate up-front configuration without an 
interactivity requirement (i.e., Exherbo and to a lesser degree Gentoo).

I think that wayland76++'s idea of having a common metadata system with 
filters to convert that metadata into a distribution package is the best 
currently-proposed solution, but I also feel that it needs some additional 
extension.

I personally believe that there are a few requirements for a package format 
that is sufficient for Perl 6:

* It must enable packaging for both binary- and source-based distros
* It must enable automatic generation of packages for supported systems 
(although it may well not be capable of it out of the box)
* It must permit (or preferably help with) attempts to support new systems
* It must be simple to submit packages in the correct format
* It must enable the design and building of an automatic testing system

My extensions to wayland76++'s proposal are as follows:

* Include in the metadata enough information to:
* Build a binary package ( deb, rpm, etc)
* Create a source build script ( ebuild, exheres, PKGBUILD, etc)
* Fetch the source package
* Contact maintainer/author/etc with issues
* Query stability information
* Prod the testing framework (not the actual tests, though)
* Separate the metadata from the package
* If the metadata is in the source distribution, have CPAN 6 extract it, 
and put it in a separate tree of just metadata
* This enables simple fetching of the entire /metadata/ tree without the 
entire /source/ tree
* Also opens the door to package managers natively supporting this 
format (Paludis has done this with CRAN and is working on Ruby Gems support)
* Have well-documented example filters, and a skeleton-filter-builder script
* Enables packaging developers to rapidly roll out support for new 
systems
* Encourage use of pure-P6 filters, so as to enable cross-distro 
mantainership
* Like building Fedora packages on the developer's Debian workstation
* Multiple submission avenues
* Simple login-controlled FTP
* Web submission
* PAUSE-like client
* Hosted SCM source w/tagging


Comments?

Re: [RFC] CPAN6 requirements analysis

[Daniel Ruoso]

Em Sex, 2009-05-29 às 01:54 +0200, Daniel Carrera escreveu:
> Larry Wall wrote:
> > I support the notion of distributing binaries because nobody's gonna
> > want to chew up their phone's battery doing unnecessary compiles.  The
> > ecology of computing devices is different from ten years ago.
> By binaries, I assume you mean native binaries, as opposed to Parrot 
> bytecode. The only problem I see is that it may be impractical to ask 
> CPAN mirrors to hold multiple binaries of each module for every OS and 
> every CPU.

I really don't think it will be CPAN's job to distribute the binary
packages, CPAN should only distribute the source package, as it does
today. Binary dependency is something that needs to be handled too
closely to the underlying operating system to be made generic.

So, I'd expect to have a Debian archive, in the Debian case, hosted by
the Debian Perl group (which packages about ~ 500 CPAN modules to Debian
today) with the binary packages targetting each of the Debian
versions...

The same would go for RedHat and other linux distros, while for the
Win32 world, we would have something in the lines of what ActiveState
already does...

But, I insist, CPAN should only store the source packages and the source
metadata should only describe what are the sources, and not how to
compile and install them...

daniel

Re: New CPAN

[Jonathan Scott Duff]

On Thu, May 28, 2009 at 11:07 AM, Daniel Carrera <
daniel.carr...@theingots.org> wrote:

> Mark Overmeer wrote:
>
>> The problem is more serious.  Perl6 installation needs to have multiple
>> versions of the same module installed in parallel (and even run within
>> the same program!).
>>
>
> Why?
>

See   http://perlcabal.org/syn/S11.html#Versioning

-Scott

-- 
Jonathan Scott Duff
perlpi...@gmail.com

Re: Amazing Perl 6

[Mark J. Reed]

On Fri, May 29, 2009 at 10:56 AM, Austin Hastings
 wrote:
>> Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
>> love to be able to have a simple keyboard shortcut that produces these
>> two characters.

Windows; set keyboard to US-International.  Right-alt + [ and ].

Mac (standard US keyboard): option + \ for «, same key shifted for »

Linux: Lots of variables: X input manager, modifier keymap, etc.  But
digraphs work in vim: control-K < < and control-K > >

-- 
Mark J. Reed 

Re: New CPAN

[John Macdonald]

On Fri, May 29, 2009 at 04:23:56PM +0200, Mark Overmeer wrote:
> What's in a name.
> Is it also
>   CPAN is the Comprehensive Parrot Archive Network
>   CPAN is the Comprehensive Pieton Archive Network
>   CPAN is the Comprehensive Pony   Archive Network
>   CPAN is the Comprehensive PHPArchive Network
>   CPAN is the Comprehensive PRuby  Archive Network
> 
> So, where do you stop?
> Perl6 and Perl5 have some things in common, just like PHP and Perl5.
> Some people say that Perl6 is a different language, not a next
> generation of Perl5.

With parrot supporting many scripting languages and making them
accessible from perl, there is a huge value in having cpan.pm
(whatever it ends up being called) providing transparent access
to all of those and more - regardless of whether they are all in
a single archive or (more likely) a network of archives, each
providing some sub-set of the possibilities.

Taking a valuable module written in another language and rewriting
it in perl has been done many times in the past, but will be less
necessary in the future.  A perl6 sub-class of the original module
will be a much easier task and often provide the specific addition
that is required.

> Do we need to install Perl5 on our system to get access to the
> install tools to install Perl6 modules?

Certainly we need to install Perl5 *modules* until they are *all*
superceeded by Perl6 (or Ruby or Python) replacements.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 14:39]:
> Much, actually. As the ZCAN document explains, the set of mirrors are  
> donated to Perl by various donors who agreed to hold *Perl* modules.  
> These computers do not belong to us. If the donors agreed to hold Perl  
> modules, it would be an abuse to use it to upload Ruby and Python  
> modules as well.

Actually, there are various kinds of ftp-servers.  Some are huge: they
really don't care.  Other are small: companies who use Perl and have
made some diskspace available.  They like to have a copy, and use it
also for there own local installations.

With Perl6 and other derivates, with the new version needs, the size of
the archive will grow with factors.  The current CPAN is tiny (fits on
your photo-camera)  "The big guys" really don't care about diskspace.
The smaller may say: I am not using Perl6, so I don't want this 50GB on
my ftp server.  I would like to host Perl5, not Perl6/Parrot.

Should we care to lose some ftp-mirrors?  Ah, no, not really. Technology
improvements made this a non-issue.  One nicely connected ftp-server
per continent may very well be sufficient now-adays.

>> So, where do you stop?
>
> You stop at the point where you start breaching your verbal agreement  
> with the owners of the computers you are using.

I don't know: did they agree on Perl or Perl5?  That's unclear. And
will resolve itself some way or the other when either solution gets
implemented.

>> Perl6 and Perl5 have some things in common, just like PHP and Perl5.
>
> Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5  
> compatibility mode and Perl 6 is intended to be able to use Perl 5  
> modules. That makes Perl 5 different from PHP.

The parrot-based PHP implementation will be able to link Perl6 and
PHP code, if I understand correctly.  And the same for Python.  And
Lua. and so on.  I don't know.  I am less convinced about a strong
bond than you.

Ok, enough stirring-up for today.  Let's eat diner.
-- 
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: Amazing Perl 6

[Austin Hastings]

Jon Lang wrote:

Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
love to be able to have a simple keyboard shortcut that produces these
two characters.  Unfortunately, I am often stuck using a Windows
system when coding; and the easiest method that I have available to me
there (that I know of) is to pull up Character Map


Set your keyboard to us-international. There's a bunch of goodies in 
there. The problem is the delayed keystrokes on composed accented 
characters, formed by quote+letter. (like 'a)


So write your own keyboard module. I did one for P6 several years ago.

In the mean time, it's alt+shift, altgr+[

=Austin

Re: Amazing Perl 6

[Buddha Buck]

On Fri, May 29, 2009 at 10:23 AM, Jon Lang  wrote:
> On Fri, May 29, 2009 at 6:52 AM, John Macdonald  wrote:
>> Yep, I've done that.
>>
>> But comparing the difference in effort between:
>>
>> - press a key
>> - Google for a web page that has the right character set, cut, refocus, paste
>>
>> means that I don't bother for the one or two "weird" characters
>> every few months that is my current Unicode usage.  If I were
>> working with Unicode frequently, it would be worth setting up
>> links and mechanisms, or learning the keyboard compose sequences
>> for frequently used characters.  I'm sure that there are many
>> people in a similar situation.
>
> Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
> love to be able to have a simple keyboard shortcut that produces these
> two characters.  Unfortunately, I am often stuck using a Windows
> system when coding; and the easiest method that I have available to me
> there (that I know of) is to pull up Character Map.

In response to this thread, I activated the "US International"
keyboard layout, and once that's done theoretically one can get
"Spanish style quote mark" with RightAlt+[ and RightAlt+] like so: «
and ».

The questions which remain (for me, at least) is if (a) the symbols
survive in email, and (b) if they really are the proper marks for
Perl6.

>
> --
> Jonathan "Dataweaver" Lang
>

Re: New CPAN

[Daniel Carrera]

Mark Overmeer wrote:

CPAN is the Comprehensive Perl Archive Network.
Not the Comprehensive Perl 5 Archive Network.


What's in a name.


Much, actually. As the ZCAN document explains, the set of mirrors are 
donated to Perl by various donors who agreed to hold *Perl* modules. 
These computers do not belong to us. If the donors agreed to hold Perl 
modules, it would be an abuse to use it to upload Ruby and Python 
modules as well.


It is perfectly reasonable to put Perl 6 in CPAN. Perl 6 is Perl. It is 
defensible to put Parrot assembly in CPAN. But it is not ok to use a 
computer that was donated for Perl to also distribute Java, Ruby, PHP, 
Lua and Smalltalk modules.




So, where do you stop?


You stop at the point where you start breaching your verbal agreement 
with the owners of the computers you are using.




Perl6 and Perl5 have some things in common, just like PHP and Perl5.


Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5 
compatibility mode and Perl 6 is intended to be able to use Perl 5 
modules. That makes Perl 5 different from PHP.


Daniel.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 14:24]:
> I think that it would be a good idea to put Perl 5 and Perl 6 modules in  
> the same CPAN.

I have a very cowardous reply on this.  My CPAN6 design supports both
sub-setting and super-setting archives.  So, it can produce three
access-points: pure-perl6, pure-perl5 and combined.  If they physically
share a disk "store", you even do not even need copies of the releases.

And... I do not really care what kind of information people keep inside
the archive.  That is for the founding "board" of the archive to decide.
As long as it has meta-data, it is ok to my scope.
-- 
Regards,
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: New CPAN

[Daniel Carrera]

Nicholas Clark wrote:

On Fri, May 29, 2009 at 02:43:13PM +0200, Mark Overmeer wrote:

* Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]:



"CPAN shall not piggyback another language" -- from ZCAN.
Judging from the ZCAN page, I don't expect that uploading Ruby modules  
to CPAN will go well, even if that module can be compiled to Parrot. The  
ZCAN page gave good reasons for this.

Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
unrelated sets of data.  The only relation is the people who use it.


I disagree.

Strongly.

CPAN is the Comprehensive Perl Archive Network.

Not the Comprehensive Perl 5 Archive Network.


I agree with Nicholas. I disagree with Mark. Though Mark may have 
replied to my comment with the word "Agreed", I never said that we 
should separate Perl 5 and Perl 6!!!  That is Mark's idea, not mine.


As Nicholas says, CPAN is the Comprehensive *Perl* (not "Perl 5") 
Archive Network. The example in my email was *Ruby*. Ruby is not Perl. 
But Perl 6 is Perl.


I think that it would be a good idea to put Perl 5 and Perl 6 modules in 
the same CPAN. Not only do I not want to fragment CPAN, but for at least 
several years Perl 6 programs will depend heavily on Perl 5 modules. So 
all those Perl 5 modules up there in CPAN right now are going to be the 
first "Perl 6" modules (via "use v5").


Daniel.

Re: New CPAN

[Mark Overmeer]

* Nicholas Clark (n...@ccl4.org) [090529 14:07]:
> On Fri, May 29, 2009 at 02:43:13PM +0200, Mark Overmeer wrote:
> > > "CPAN shall not piggyback another language" -- from ZCAN.
> > > Judging from the ZCAN page, I don't expect that uploading Ruby modules  
> > > to CPAN will go well, even if that module can be compiled to Parrot. The  
> > > ZCAN page gave good reasons for this.
> > 
> > Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
> > unrelated sets of data.  The only relation is the people who use it.
> 
> I disagree.
> Strongly.

;-)

> CPAN is the Comprehensive Perl Archive Network.
> Not the Comprehensive Perl 5 Archive Network.

What's in a name.
Is it also
  CPAN is the Comprehensive Parrot Archive Network
  CPAN is the Comprehensive Pieton Archive Network
  CPAN is the Comprehensive Pony   Archive Network
  CPAN is the Comprehensive PHPArchive Network
  CPAN is the Comprehensive PRuby  Archive Network

So, where do you stop?
Perl6 and Perl5 have some things in common, just like PHP and Perl5.
Some people say that Perl6 is a different language, not a next
generation of Perl5.

Do we need to install Perl5 on our system to get access to the
install tools to install Perl6 modules?
-- 
Regards,
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: Amazing Perl 6

[Jon Lang]

On Fri, May 29, 2009 at 6:52 AM, John Macdonald  wrote:
> Yep, I've done that.
>
> But comparing the difference in effort between:
>
> - press a key
> - Google for a web page that has the right character set, cut, refocus, paste
>
> means that I don't bother for the one or two "weird" characters
> every few months that is my current Unicode usage.  If I were
> working with Unicode frequently, it would be worth setting up
> links and mechanisms, or learning the keyboard compose sequences
> for frequently used characters.  I'm sure that there are many
> people in a similar situation.

Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
love to be able to have a simple keyboard shortcut that produces these
two characters.  Unfortunately, I am often stuck using a Windows
system when coding; and the easiest method that I have available to me
there (that I know of) is to pull up Character Map.

-- 
Jonathan "Dataweaver" Lang

Re: [RFC] CPAN6 requirements analysis

[Mark Overmeer]

* Timothy S. Nelson (wayl...@wayland.id.au) [090529 12:02]:
> On Fri, 29 May 2009, Mark Overmeer wrote:
> * CPAN6; this is a piece of software for managing an archive network (such as
>   Pause6, below).  This is not specified in this document; see
>   http://cpan6.org/

Yes.  It facilitates organization of archives: exchanging releases
(f.i. software distributions), without the knowledge about the internal
organization of the archive.  This layer ensures that various servers do
not need to run the same version of the archiving software: alternative
implementations can exist as long as they have a minimal subset of
features.

It contains things like
  . protocol negotiation
 . XML, YAML, Data::Dumper syntax?
 . packaged with tar, cpio, zip, none?
 . compressed with gzip, bzip2, none?
 . transport protocol http, ftp, rsync, ..
  . release addresses: archive name (URI), product name, version name

Quite simple.

> * PAUSE6; this is an actual network based on the CPAN6 software (see
>   above).  It also is not documented here.

Pause6 is one implementation of archive maintenance software.  In the
first version written in Perl5, it implements things like
  . archive maintenance rules
  . uploaded release inspection
  . actual storage on disk
  . trust, licenses, authors
  . sub-setting and merging archives
  . mirror synchronization
  . simple meta-data searches
  . end-user downloads
These are all server-side things: the client code is very small!  Client-
side, it is more like ftp (downloads are done via ftp, http, etc.

The simplest CPAN6 client is this:
  wget http://cpan6.org/perl5/get?product=XML-LibXML
which gives you a copy of the seperate files in the last version
of XML-LibXML without packaging or compression via http from a mirror
nearby you.  Then
  cd XML-LibXML-0.69/payload/; make install
Something like that.

So: Pause6 is the logic behind our current Pause upload interface plus
all the maintenance tasks from CPAN maintainers.

> * CPAN6.pm; this is a piece of software that starts with what it can get
>   on PAUSE6, and attempts to give you an installed perl module (this is a
>   replacement for CPANPLUS/cpan2dist)

Well, in my current implementation, CPAN6.pm is a faint layer on top
of CPAN.pm.  It will search a little differently (search on the web or
local disk when using a CD, no 02packages.details), but downloads are
still managed by LWP.

>> I think that package managers are not a "CPAN" related problem at all.
>> The Perl install tool decides which files it wants to have within some
>> file-system tree and versioned environment, and then package managers
>> distribute those files and meta-data.
>
> The terms you've used here are so general that they could describe any  
> one of a number of things.  I'd like some concretification or something.  
> Example?

CPAN archive and Perl install tools are fields of the software author:
his/her attempt to get software from the own disk usable on someone else's
system. Package managers are used by the end-user to have control over
their system.  This is a different problem, each OS(-version) has other
solutions.

> Have you seen Software::Packager?  It's a Perl5 module that's designed  
> to create a "source package"* for any supported package manager.  

What I see in the module is two-fold:
  . some meta-data
  . some wrapping (tar)

On the meta-data side, it is much too UNIX oriented and far too little.
It totally lacks any support for platform dependent problems like
  . which charsets are supported by filesystems
  . which characters have a special meaning on various OSes, and
how do install tools work around encountered problems.
(for instance a ':' in a name, unicode package names, ...)
  . all kinds of important additional meta-data are missing, like
license.  The Meta.YML is much more complete.
  . the implementation is very UNIX centric

As indicated before, I think the transport wrapper, like tar, is totally
unimportant: it should be abstracted as a transport layer, hidden on
the application level of installation tools.

> Just for the record, I'm interested in having a Software::Packager  
> port/rewrite be part of the installation tool; overlapping what you're 
> calling CPAN6.pm.

My CPAN6.pm implementation transports a directory of files from the
source (author) to the end-user, without knowledge about the content
of that directory: whether it is one perl5.tar.gz or a dozen pictures.
In parallel, it uses a meta-data file for such release, which contains
cpan6, pause6, and release specific meta-data. For Perl5, it will capture
all of the Meta.YML info and more.  For instance, it will add checksums
for all files, and crypto-signatures.

>   I'd like to suggest a further terminology split:
> - 6PAN: command-line install tool
The term 6pan has also been claimed before.
I would say "pause6" or "cpan6" (no capitals)

> - CPAN6.pm: Module relied upon by 6PAN for interactions with Pause6
As my idea of C

Re: New CPAN

[Nicholas Clark]

On Fri, May 29, 2009 at 02:43:13PM +0200, Mark Overmeer wrote:
> * Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]:

> > "CPAN shall not piggyback another language" -- from ZCAN.
> > Judging from the ZCAN page, I don't expect that uploading Ruby modules  
> > to CPAN will go well, even if that module can be compiled to Parrot. The  
> > ZCAN page gave good reasons for this.
> 
> Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
> unrelated sets of data.  The only relation is the people who use it.

I disagree.

Strongly.

CPAN is the Comprehensive Perl Archive Network.

Not the Comprehensive Perl 5 Archive Network.

ftp://ftp.cpan.org/pub/CPAN/src/unsupported/4.036/

Nicholas Clark

Re: Amazing Perl 6

[John Macdonald]

On Thu, May 28, 2009 at 08:10:41PM -0500, John M. Dlugosz wrote:
> John Macdonald john-at-perlwolf.com |Perl 6| wrote:
>> However, the assumption fails if "process" is supposed to mean that
>> everyone is capable of generating Unicode in the messages that they
>> are writing.  I don't create non-English text often enough to have
>> it yet be useful to learn how.  (I'd just forget faster than I'd use
>> it and have to learn it again each time - but Perl 6 might just be
>> the tipping point to make learning Unicode composition worthwhile.)
>>   
>
>
> Just copy/paste from another message or a web page.  Perhaps a web page  
> designed for that purpose...

Yep, I've done that.

But comparing the difference in effort between:

- press a key
- Google for a web page that has the right character set, cut, refocus, paste

means that I don't bother for the one or two "weird" characters
every few months that is my current Unicode usage.  If I were
working with Unicode frequently, it would be worth setting up
links and mechanisms, or learning the keyboard compose sequences
for frequently used characters.  I'm sure that there are many
people in a similar situation.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]:
> Timothy S. Nelson wrote:
>> While I've no objection to building the end-user software to 
>> support multiple repositories, I know that there are certain segments 
>> of the community who are very very keen to keep everything in the one  
>> repository.
>
> After reading the Zen of Comprehensive Archive Networks (ZCAN), I think  
> there is very good reason for retaining the current infrastructure with  
> the current, large, set of mirrors. That is not to say that we can't  
> upgrade the packages and metadata.

It also says:
  "Another important credo is: Avoid bottlenecks and interdependencies.
  Decentralize. Create and encourage alternatives."

When reading the ZCAN, be very aware that it discusses CPAN. As users of
CPAN, we all know that it works (for the moment).  But that should never
be a reason the think outside that box of daily practice!  When making a
step in development, first figure out which components of CPAN are really
valuable, which are outdated, and which are missing.  Then keep the good,
salvage the outdated and fill-in the missing.

Just to give you something to think of: with the current speed of
networks and price of hardware, you do not need a huge network of
daily synchronizing mirrors but a sufficiently large network of very
up-to-date mirrors.  Preferrably smart mirrors, which can answer
(Ajax-like) some simple questions about distributions, such that you
do not have to download the immensely growing 02packages.details files
anymore.

Ftp-mirror sync trees.  If you add subtrees on your disk which contain
different archives or targets, then these will get mirrored as well.

> "CPAN shall not piggyback another language" -- from ZCAN.
> Judging from the ZCAN page, I don't expect that uploading Ruby modules  
> to CPAN will go well, even if that module can be compiled to Parrot. The  
> ZCAN page gave good reasons for this.

Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
unrelated sets of data.  The only relation is the people who use it.
-- 
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: New CPAN

[Mark Overmeer]

* Timothy S. Nelson (wayl...@wayland.id.au) [090529 11:26]:
>   I'd like to suggest to Mark and Daniel that, seeing as I won't be  
> making it to any Perl event outside Australia, and maybe not even some 
> inside, and Mark can't keep up with IRC (my sympathies there), that the 
> best place for such a discussion might be a mailing list such as p6l!  
> (No sarcasm intended -- I'm saying you're doing the right thing, keep it 
> up :) ).

Once some people want to spend time on details of the subject, I suggest
to revive a separate mailinglist for it.  The list which we started two
years back was never used.  Installation/distribution is a complex matter
with many aspects to be discussed, so deserves its own list simply not
to bother the (quite independent subject of) Perl6.

>> Who (besides Perl people) expect 5.10 after 5.8?
> Err, lots of people?
> kernel-2.6.27.5-117.local.fc10.i686

Eh, yes of course.  That problem is only inside perl programs, where version
numbers are considered floating point numbers.  Where 5.8.8 == 5.008008 ==
5.008_008.  And then you have test versions like 68.17_02, which are broken
floats and therefore flagged as development versions.

In general, there are many versioning schemes which do often look alike,
but do have subtile differences.

>  Allow me to point out that all the package managers out there have  
> solved this problem, so it must be solveable.

Yes... but that also means that for some packaged products, versions need
to get translated into a different versioning scheme.

> While I've no objection to building the end-user software to support  
> multiple repositories, I know that there are certain segments of the 
> community who are very very keen to keep everything in the one 
> repository.

I would like to add
  . cpants information
  . cpan-tester reports
  . code-only extracts# for small systems to install Perl
  . pod-only extracts # to add to code-only systems on demand
  . tests-only extracts
  . deb packages
  . rpm packages
  . pieton distributions
  . etc

Oh, and then without name-space conflicts.  And maintained by a small
set of people.

One of the main problems with the current set-up is the very limited
pre-information about the installation available to CPAN.pm.  It
downloads a 02packages.details file which does not contain info about
dependencies and such.  One of the much heart complaints from normal
Perl users is about the flood of unpredictable changes in the system
once you install one module.  Linux Distributions do also install many
packages with one change, but are able to present that far more cleanly.
Simply because they have more information at the start.
What you probably need: dependencies, package size, licenses used,
supported platforms, short description.

An other consideration is the size of the 02packages file.  This is now
750kB.  It now lists only the last versions of each of the packages (not
distribution!) in CPAN.  But, when Perl6 introduces parallel versions,
you may have people who actually want to use that feature.  Business
people other want an explicit module version, not the newest one.  This
means that the size of the 02packages files explodes with

   N times avg.nr.versions
 times number.of.targets
 times useful.additional.metadata

My internet connection is very fast.  Yours probably as well.  We don't
care about this, do we?

> The big problem with the multiple repos idea is that, unless each has a 
> large organisation behind it, they die (witness the DAG RPM repo, which  
> seemed deadish last time I looked; the packages are still there, but no  
> updates seemed to be being made).

Most projects die.  The only reason why CPAN hasn't died is because of
enormous effort by Andreas and a small group of other people.  When
Andreas is overrun by a Berlin bike, we have a serious problem.  It is
hard to find dedicated maintainers, as many Open Source projects have
found out.

IMO, fragmentation is crucial: you can not stack the load on a small
group of dedicated people because they burn-up that way.  People must
be able to fork their own pet project, like search.cpan.org.  And yes,
that enlarges the chance that such a project dies.  But that's normal
evolution.  At least, you have dedicated people with a work-load of their
own choice.

Considering above, I changed the concept of "CPAN" from a special
thing for Perl5 only, into: "collecting information is a basic need
for groups of people".  People start together an "archive" (collection)
with a certain purpose.  They lay-down the rules of that archive (who
has super-user rights, permitted licenses, etc).  And then, they have
a standard implementation for collection needs: mirroring, versioning,
various up- and download protocols, release under embargo, ..etc.

A lot of maintenance effort by the current CPAN maintainers will not be
needed anymore.  Maintainers can focus on the quality of the content.
Perl6, Perl5, parrot, pieton, python, PHP, family

Re: New CPAN

[Timothy S. Nelson]

On Fri, 29 May 2009, Daniel Carrera wrote:


Timothy S. Nelson wrote:
While I've no objection to building the end-user software to support 
multiple repositories, I know that there are certain segments of the 
community who are very very keen to keep everything in the one repository.


After reading the Zen of Comprehensive Archive Networks (ZCAN), I think there 
is very good reason for retaining the current infrastructure with the 
current, large, set of mirrors. That is not to say that we can't upgrade the 
packages and metadata.


Agreed.


 I'd agree with them, on the following conditions:

-CPAN accepts packages in Perl5, Perl6, and anything else that runs on
Parrot


"CPAN shall not piggyback another language" -- from ZCAN.

Judging from the ZCAN page, I don't expect that uploading Ruby modules to 
CPAN will go well, even if that module can be compiled to Parrot. The ZCAN 
page gave good reasons for this.


	I didn't find them compelling, myself.  Because it's possible to call 
the Ruby modules from Perl6 now, if they're compiled on Parrot, it may be 
worth thinking about.



-Some of the other changes mentioned here get implemented (ie. Larry's
idea of putting binary packages on CPAN as well)


I personally don't care. But some mirrors might object to having their disk 
usage go up 5-fold because we decided to include binaries for many operating 
systems and CPUs.


	I agree that's a problem.  However, the recent suggestion of multiple 
repos on CPAN for the different OSs has given me an idea; make it possible to 
mirror CPAN for a certain set of architectures, ie. "Source only" (this is the 
default), "Fedora", "Debian", "Nokia", etc.


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Mark Overmeer wrote:


* Alex Elsayed (eternal...@gmail.com) [090528 22:17]:

While lurking in IRC, I've seen several discussions of what CPAN 6 should
look like.


I would really like to see a split in terminology being used for the
various seperate problems.  The traditional confusion about what CPAN is:
an archive or an install tool.  Package manager discussions are in the
process AFTER the install tool: to distribute OS changes to be made.
In the messages on the list, I see people merge requirements of these
very independent tasks.


Ok, here's some terms I've picked up:

These are from Mark's Paper:

-   CPAN6: a general infrastructure to create and distribute archives
-   Pause6: one implementation of archive management
-   CPAN6.pm one transport mechanism to install Perl modules from Pause6
archives (or presumably any CPAN6 server)

I've rephrased them in S22 as:

* CPAN6; this is a piece of software for managing an archive network (such as
  Pause6, below).  This is not specified in this document; see
  http://cpan6.org/

* PAUSE6; this is an actual network based on the CPAN6 software (see
  above).  It also is not documented here.

* CPAN6.pm; this is a piece of software that starts with what it can get
  on PAUSE6, and attempts to give you an installed perl module (this is a
  replacement for CPANPLUS/cpan2dist)

	I've replicated that here so that Mark et. al. can verify or deny that 
we're thinking the same thing.  Please keep in mind that if I got them wrong, 
I'll be using the S22 definitions in the rest of this e-mail.


The area I'm interested in overlaps mainly with CPAN6.pm.


I think that package managers are not a "CPAN" related problem at all.
The Perl install tool decides which files it wants to have within some
file-system tree and versioned environment, and then package managers
distribute those files and meta-data.


	The terms you've used here are so general that they could describe any 
one of a number of things.  I'd like some concretification or something. 
Example?



Also, there are various different package managers around for Linux
distributions, and they tend to be replaced every few years.  If you
want people to use Perl modules on their Linux systems in a convenient
way, you have to distribute each perl module in all of the existing
formats. Of course, a tool like "alien" can be used to simplify the
task of creating all these flavors.


	Have you seen Software::Packager?  It's a Perl5 module that's designed 
to create a "source package"* for any supported package manager. 
Unfortunately, CPANPLUS has never used it.  This is the part of the whole 
discussion that interests me the most, because it's where my problems have 
lain.


	Just for the record, I'm interested in having a Software::Packager 
port/rewrite be part of the installation tool; overlapping what you're calling 
CPAN6.pm.


I'd like to suggest a further terminology split:
-   6PAN: command-line install tool
-   CPAN6.pm: Module relied upon by 6PAN for interactions with Pause6
-   Software::Packager: Module relied upon by 6PAN for interactions with
the local packaging system, and for installing files.

If there are no objections, I'll pop these in S22 as well.

	Having clarified the terms, I'd urge people not to use the term "CPAN" 
without qualifiers in the discussion any more, as it conflates things.



IMO, that discussion should go in the direction of additional services:
the CPAN archive distributes what authors publish.  The install tools
(CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
systems. As a service, other people can publish the results of their
specific module installation via package-managers to the world, such
that those people can use they platform native software management
tools.  Just like search.cpan.org is an independent additional service
on the CPAN archive.


Are you arguing here for eg. a yum/apt/whatever repository on Pause6?


I personally believe that there are a few requirements for a package format
that is sufficient for Perl 6:
* It must enable packaging for both binary- and source-based distros
* It must enable automatic generation of packages for supported systems
(although it may well not be capable of it out of the box)


Just to clarify, this is what I want :).


* It must permit (or preferably help with) attempts to support new systems
* It must be simple to submit packages in the correct format
* It must enable the design and building of an automatic testing system


The worst flaws in software design are based on the idea that you can
organize the outside world.  The Perl community will never be able to
push its packaging mechanism into Linux distributions.  We may be able
to select the ideal packaging mechanism, and then they will wrap that
in their own packaging mechanism.


	Agreed.  I've chosen my package manager, and I

Re: New CPAN

[Daniel Carrera]

Timothy S. Nelson wrote:
While I've no objection to building the end-user software to support 
multiple repositories, I know that there are certain segments of the 
community who are very very keen to keep everything in the one 
repository.


After reading the Zen of Comprehensive Archive Networks (ZCAN), I think 
there is very good reason for retaining the current infrastructure with 
the current, large, set of mirrors. That is not to say that we can't 
upgrade the packages and metadata.



 I'd agree with them, on the following conditions:

-CPAN accepts packages in Perl5, Perl6, and anything else that runs on
Parrot


"CPAN shall not piggyback another language" -- from ZCAN.

Judging from the ZCAN page, I don't expect that uploading Ruby modules 
to CPAN will go well, even if that module can be compiled to Parrot. The 
ZCAN page gave good reasons for this.




-Some of the other changes mentioned here get implemented (ie. Larry's
idea of putting binary packages on CPAN as well)


I personally don't care. But some mirrors might object to having their 
disk usage go up 5-fold because we decided to include binaries for many 
operating systems and CPUs.


The big problem with the multiple repos idea is that, unless each 
has a large organisation behind it, they die (witness the DAG RPM repo, 
which seemed deadish last time I looked; the packages are still there, 
but no updates seemed to be being made).  CPAN, because it has a large 
enough organisation behind it, has a number of people behind it 
empowered with keeping it going.  People don't want to have to keep up 
with the fashionable repos.


+1

Daniel.

r26959 - docs/Perl6/Spec

[pugs-commits]

Author: wayland
Date: 2009-05-29 13:33:54 +0200 (Fri, 29 May 2009)
New Revision: 26959

Modified:
   docs/Perl6/Spec/S22-package-format.pod
Log:
[S22] Updated bad terminology that I created yesterday to the better 
terminology that Mark Overmeer created ages ago.  


Modified: docs/Perl6/Spec/S22-package-format.pod
===
--- docs/Perl6/Spec/S22-package-format.pod  2009-05-29 06:00:52 UTC (rev 
26958)
+++ docs/Perl6/Spec/S22-package-format.pod  2009-05-29 11:33:54 UTC (rev 
26959)
@@ -32,10 +32,10 @@
 =item * CPAN6; this is a piece of software for managing an archive network 
(such as CPAN).  
 This is not specified in this document; see http://cpan6.org/
 
-=item * 6PAN-network; this is an actual network based on the cpan6 software 
(see above).  It also 
+=item * PAUSE6; this is an actual network based on the cpan6 software (see 
above).  It also 
 is not documented here.  
 
-=item * 6PAN-packager; this is a piece of software that starts with what it 
can get on 6PAN-network, and 
+=item * CPAN6.pm; this is a piece of software that starts with what it can get 
on PAUSE6, and 
 attempts to give you an installed perl module (this is a replacement for 
 CPANPLUS/cpan2dist)
 

Re: New CPAN

[Timothy S. Nelson]

On Fri, 29 May 2009, Mark Overmeer wrote:


* Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]:

Mark Overmeer wrote:

In March 2006, Sam Vilain and I started to think about a new CPAN
what we named CPAN6.  There is a lot of information about the project on
http://cpan6.org


I know about CPAN6, thanks. It's come up a couple of times on IRC.
Perhaps you could hang out on the IRC channel so we don't have different
people going off in different directions with CPAN.


It's not a discussion like "let's make a change to the current set-up",
so IRC doesn't seem to me a good spot to discuss it. I gave various
talks on YAPC's and interviewd a few of the CPAN maintainers.  Workshops,
Hackathons and YAPCs are more suitable.


	I support Daniel in that you should expect to miss things if you don't 
hang out on IRC.  But I support Mark in the idea of longer formats, although I 
think 30 pages is a bit long.  I've skimmed the document, though, enough to 
know what I need to know at the moment, I think (please correct me if I'm 
wrong).


	I'd like to suggest to Mark and Daniel that, seeing as I won't be 
making it to any Perl event outside Australia, and maybe not even some inside, 
and Mark can't keep up with IRC (my sympathies there), that the best place for 
such a discussion might be a mailing list such as p6l!  (No sarcasm intended 
-- I'm saying you're doing the right thing, keep it up :) ).



Trying to keep-up with normal email is already a daily struggle.  Besides,
having 9 hours time-difference with the West Coast doesn't help: when they
wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home.
And when he finally sleeps, I am tired ;-)


	Mark: There's usually someone awake somewhere, even if it's only me 
here in Australia.


	DanielC: Don't argue with his time management until you have children. 
I don't, either, but I can see what a time-sink a family would be (even good 
things have their downsides).



A) Can we add "version", "target" flags to CPAN metadata? I was
thinking  that current modules would all be version=1 and
target=perl5.


CPAN does not have an official concept of version numbers on distributions,
but only on the pm files which are inside the distribution.


I know, thanks. I was suggesting a change.


I had a discussion of two days about "versions" with Sam Vilain.  What
we came up with, is that there is only one solution: versions need to
be strings without meaning.  Of course, you can help yourself using some
kind of logic sequencing these strings, but everyone has different ideas
about how to do that. Who (besides Perl people) expect 5.10 after 5.8?


	Err, lots of people?  The Linux kernel does its versions this way, so 
most people in the Open Source world are familiar with it.


RPM seems to be able to handle things just fine, too.  Example:

kernel-2.6.27.5-117.local.fc10.i686

Version = 2.6.27.5
Release = 117.local

	The Version can be split up on the dots, and each compared numerically 
if available, and as strings if there are non-numerics.


	Allow me to point out that all the package managers out there have 
solved this problem, so it must be solveable.



The solution is simple: each release has a unique version string. The
release also lists as meta-data what kind of follow-up it is to which
existing release.  For instance:
  5.10.0   diverts from 5.8.8  (upgrade)
  5.8.9replaces 5.8.8  (update)
  5.10.1-blead diverts from 5.10.0 (devel)
  5.10.1   replaces 5.10.0 and 5.10.1-blead (merge)


	It may be useful to have these as recommendations, but I would hope 
that user policies and choices would be able to override them.



D) In addition to target=perl5 and target=perl6 we could have target=parrot.


IMO, we need many more.  What you call "target" is actually a namespace.
The current CPAN archive has only one target.


Target, namespace, same difference. It's an identifier to divide modules
into categories.


Well... do you need all archives to share one infrastructure?  I think it
is nicer to have people being able to open-up CPAN-like archives with
additional features.  For instance, if someone wants to publish pre-compiled
PIR versions of modules, then s/he should not need the assistence of the
core CPAN.  With an URI namespace, you address an archive where you can
find the data.  A part of that namespace (URI fragment) could be a target
within the archive.


	While I've no objection to building the end-user software to support 
multiple repositories, I know that there are certain segments of the community 
who are very very keen to keep everything in the one repository.  I'd agree 
with them, on the following conditions:


-   CPAN accepts packages in Perl5, Perl6, and anything else that runs on
Parrot
-   Some of the other changes mentioned here get implemented (ie. Larry's
idea of putting binary packages on CPAN as well)

	I have also been wondering about the idea of making CPAN a cl

Re: [RFC] CPAN6 requirements analysis

[Timothy S. Nelson]

On Fri, 29 May 2009, Daniel Carrera wrote:


Timothy S. Nelson wrote:

I can confirm that Redhat supports multiple versions:

$ rpm -q kernel
kernel-2.6.27.5-117.fc10.i686
kernel-2.6.27.12-170.2.5.fc10.i686
kernel-2.6.27.5-117.local.fc10.i686


AFAIK the way RPM implements "multiple versions" is by making an entirely 
different package. Like, for example, if you have Gimp 1.x installed, the 
package might be called "gimp". When Gimp 2.0 comes out, if you don't want to 
remove the old Gimp, you make an entirely separate package called "gimp2" 
with its own set of versions.


	No, this is not necessary.  Let me paste what I said on IRC to Daniel 
after he sent the mail to which I am replying.


[20:00]  Let me give the kernel example
[20:01]  kernel-2.6.27.5-117.local.fc10.i686
[20:01]  package = kernel
[20:01]  version = 2.6.27.5
[20:01]  release = 117-local
[20:01]  distro = fc10
[20:02]  arch = i686
[20:02]  (I'm not 100% sure about "distro" there)

The point is that we may have trouble scaling that to cover all the stuff 
that S11 says. I'm not saying it can't be done. I'm saying it might be 
difficult, as we'd be using RPM and DEB in a way that they were not intended.


	Well, I suggest that we do our best within their frameworks, and if 
necessary, allow people the option of installing outside their package manager 
if it can't support the features we're offering.  Empower the user!  Easy 
things easy, hard things possible.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 09:38]:
>> He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU
>> 2007 (UK) where we gave a presentation about the subject.  The results
>> are in the initial paper page 22-24
>
> The discussion did not happen on this mailing list? Was it just you and  
> Sam? I was hoping to see the discussion thread (rather than just "this  
> is what we decided").

Two days of personal discussion is more than just an email thread. And
"decided" is too strong: for well-thought reasons it went into the design
this way.  Until someone has a better idea with good arguments.

>> Reading a paper is much less work than following IRC.  When the brain-
>> storm on IRC is over, someone will have to structurize the ideas into
>> pages with comparible size and complexity.
>
> I'm sorry, but I am not going to read your 30-page paper. Even the  
> Synopses are not that long, and I can be fairly confident that the  
> Synopses are the product of community consensus, so at least I have a  
> good reason to read those.

Do not be blind folded by the formatting.  A PDF of 30 pages with a few
images easily looks larger than a plain text POD file.  For instance,
S02-bits.pod (the first real Synopsis) has 24078 words on 3790 lines.
My plain-text TeX files have 11229 words on 1764... so the whole CPAN6
project is described in less than half the size of one Synopsis chapter.

Synopses where written by Larry, of course after discussions but mainly
based on his great personal design capabilities. And then polished
further and further by the community. I do not see a difference with my
approach... other than that there is not yet a community.

Congratulated in advance with your marriage, next month. Of course, we
can meet at some other moment because you live close-by.  Or you can
join the long list of people who guess that they understand what the
CPAN6 project proposes and comment on that weak assumption.

Anyone interested in a CPAN6 hackathon?
-- 
Regards,
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: New CPAN

[Daniel Carrera]

Mark Overmeer wrote:

* Daniel Carrera (daniel.carr...@theingots.org) [090529 08:17]:

Workshops, Hackathons and YAPCs are more suitable.

But those venues are not available on a day-to-day basis.


At least, you get the time to discuss it in depth. Some even basic meta-
data issues are just too complex for the short size of email, let alone
IRC.


It'll have to be, because that's what we have. Hackathons and YAPCs 
don't happen that regularly. Hackathons and YAPCs are immensely valuable 
venues and they are far more efficient than email and IRC. But most of 
the time, email and IRC is all you have.




 Will you be at YAPC::EU in Lisbon?  Let's BoF.


No. I will be in my honey-moon. I'm getting married in July. My wife 
would kill me if I took her to YAPC for our honey moon :-)




I had a discussion of two days about "versions" with Sam Vilain.  What
we came up with, is that there is only one solution:
Where did that discussion happen? Here? Could you send me the link to  
the right page on the list archives?


He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU
2007 (UK) where we gave a presentation about the subject.  The results
are in the initial paper page 22-24


The discussion did not happen on this mailing list? Was it just you and 
Sam? I was hoping to see the discussion thread (rather than just "this 
is what we decided").




Reading a paper is much less work than following IRC.  When the brain-
storm on IRC is over, someone will have to structurize the ideas into
pages with comparible size and complexity.


I'm sorry, but I am not going to read your 30-page paper. Even the 
Synopses are not that long, and I can be fairly confident that the 
Synopses are the product of community consensus, so at least I have a 
good reason to read those.


Daniel.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090529 08:17]:
>> Workshops, Hackathons and YAPCs are more suitable.
> But those venues are not available on a day-to-day basis.

At least, you get the time to discuss it in depth. Some even basic meta-
data issues are just too complex for the short size of email, let alone
IRC.  Will you be at YAPC::EU in Lisbon?  Let's BoF.

>> I had a discussion of two days about "versions" with Sam Vilain.  What
>> we came up with, is that there is only one solution:
> Where did that discussion happen? Here? Could you send me the link to  
> the right page on the list archives?

He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU
2007 (UK) where we gave a presentation about the subject.  The results
are in the initial paper page 22-24
   http://www.cpan6.org/papers/cpan6-design.pdf
A lot of the content of that design paper comes from discussions with
many, many people.

>> Oh, that's the small one.
> In that case, I don't think I have time to read your papers. I'm sorry.  
> I have other work to do.

Reading a paper is much less work than following IRC.  When the brain-
storm on IRC is over, someone will have to structurize the ideas into
pages with comparible size and complexity.

> One other problem with a long paper is that it is not a conversation.  
> It is a one-way communication medium, so it is less likely to build  
> consensus (unless the paper itself was written through a consensus 
> process).

The paper describes many small components which need to be addressed,
with limited detail. Of course, most is open for discussion.  Most did
have a lot of discussion already before it was written down.

IMO, it never happens that things get implemented as described in the
initial design.  So, there is so much what can be changed when people
come up with better plans.

But nothing in there is about Perl6 installation tools or Linux
Distribution packaging, where most of the discussion seems to be about.
The overlap is meta-data definition and data transport.
-- 
Regards,
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: [RFC] CPAN6 requirements analysis

[Mark Overmeer]

* Alex Elsayed (eternal...@gmail.com) [090528 22:17]:
> While lurking in IRC, I've seen several discussions of what CPAN 6 should 
> look like.

I would really like to see a split in terminology being used for the
various seperate problems.  The traditional confusion about what CPAN is:
an archive or an install tool.  Package manager discussions are in the
process AFTER the install tool: to distribute OS changes to be made.
In the messages on the list, I see people merge requirements of these
very independent tasks.

I think that package managers are not a "CPAN" related problem at all.
The Perl install tool decides which files it wants to have within some
file-system tree and versioned environment, and then package managers
distribute those files and meta-data.

Also, there are various different package managers around for Linux
distributions, and they tend to be replaced every few years.  If you
want people to use Perl modules on their Linux systems in a convenient
way, you have to distribute each perl module in all of the existing
formats. Of course, a tool like "alien" can be used to simplify the
task of creating all these flavors.

IMO, that discussion should go in the direction of additional services:
the CPAN archive distributes what authors publish.  The install tools
(CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
systems. As a service, other people can publish the results of their
specific module installation via package-managers to the world, such
that those people can use they platform native software management
tools.  Just like search.cpan.org is an independent additional service
on the CPAN archive.

> I personally believe that there are a few requirements for a package format 
> that is sufficient for Perl 6:
> * It must enable packaging for both binary- and source-based distros
> * It must enable automatic generation of packages for supported systems 
> (although it may well not be capable of it out of the box)
> * It must permit (or preferably help with) attempts to support new systems
> * It must be simple to submit packages in the correct format
> * It must enable the design and building of an automatic testing system

The worst flaws in software design are based on the idea that you can
organize the outside world.  The Perl community will never be able to
push its packaging mechanism into Linux distributions.  We may be able
to select the ideal packaging mechanism, and then they will wrap that
in their own packaging mechanism.

IMO, as Perl community, we should focus on the things we are good in:
have people contribute free Perl code in a simple and platform independent
way.  Let package manager specialists do their job!  They will NEVER be
satisfied by the choices we make for them.

To help package builders do their job simple and correctly, we have to
supply them with as good metadata as we can.  Which means:
  . as much as possible (sufficient kwantity)
  . very explicitly defined structure and content (predictable quality)
  . added with minimal hassle for the (often lazy) authors of
the code (usability)
  . extensible meta-data structure (future grow path by design)

To get these things right is already an increadible amount of work... and
no-one else does that for us.  There are so many improvements in this
area to be made in our current set-up already, which no-one picks up.
Does anyone like to see my wishlist?

See http://cpan6.org/papers/2008yapceu/   In the last example
  http://cpan6.org/papers/2008yapceu/cache-release.xml
I show much more additional meta-data information than currently
provided my Meta.YML, but all very usefull for packaging tools and other
services.  (I have used XML as syntax, because with XML-schemas I can
precisely describe the structure and content: quality!, but you can also
transmit the data in YAML, JSON, Data::Dumper,... that is just unimportant
syntax!!!)

One thing to mention: I have separated some meta-data into own
releases as well.  For instance, in stead of including all kinds of
personal information (like email address) inside the distribution,
I let people make a release which contains that information just like
a software release.  The released software only contains a reference
to the personal information.  That means that people can upgrade their
personal information (make a new release of themselves) when the email
address changes.  Of course, that exact content of "personal information"
is not an Perl6 issue, but it is solved in my CPAN6.

PACKAGING IS NOT OUR BALLGAME!!!
-- 
Regards,

   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: New CPAN

[Daniel Carrera]

Mark Overmeer wrote:
I know about CPAN6, thanks. It's come up a couple of times on IRC.  
Perhaps you could hang out on the IRC channel so we don't have different  
people going off in different directions with CPAN.


It's not a discussion like "let's make a change to the current set-up",
so IRC doesn't seem to me a good spot to discuss it.


Nonetheless, IRC seems to be the place where discussion does happen. IRC 
has pros and cons over email. If you want to convince people to make the 
new CPAN the way you want, you have to join the conversation wherever it 
takes place.




Workshops, Hackathons and YAPCs are more suitable.


But those venues are not available on a day-to-day basis.


Trying to keep-up with normal email is already a daily struggle.  Besides,
having 9 hours time-difference with the West Coast doesn't help:


I have a 9-hour difference with the US West Coast. I suspect that I am 
in the same timezone as you. In addition, wayland76 is in Australia, and 
that's a 7h time difference between him and me. But somehow it works.





I had a discussion of two days about "versions" with Sam Vilain.  What
we came up with, is that there is only one solution:


Where did that discussion happen? Here? Could you send me the link to 
the right page on the list archives?




F) In summary, we have a possible course of action:

There is a lot more structurally problematic.  Please read one of my
papers on the cpan6.org website.

I have scanned through the first one. It's 30 pages...


Oh, that's the small one.


In that case, I don't think I have time to read your papers. I'm sorry. 
I have other work to do.


One other problem with a long paper is that it is not  a conversation. 
It is a one-way communication medium, so it is less likely to build 
consensus (unless the paper itself was written through a consensus process).


Daniel.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]:
> Mark Overmeer wrote:
>> In March 2006, Sam Vilain and I started to think about a new CPAN
>> what we named CPAN6.  There is a lot of information about the project on
>> http://cpan6.org
>
> I know about CPAN6, thanks. It's come up a couple of times on IRC.  
> Perhaps you could hang out on the IRC channel so we don't have different  
> people going off in different directions with CPAN.

It's not a discussion like "let's make a change to the current set-up",
so IRC doesn't seem to me a good spot to discuss it. I gave various
talks on YAPC's and interviewd a few of the CPAN maintainers.  Workshops,
Hackathons and YAPCs are more suitable.

Trying to keep-up with normal email is already a daily struggle.  Besides,
having 9 hours time-difference with the West Coast doesn't help: when they
wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home.
And when he finally sleeps, I am tired ;-)

>>> A) Can we add "version", "target" flags to CPAN metadata? I was 
>>> thinking  that current modules would all be version=1 and 
>>> target=perl5.
>>
>> CPAN does not have an official concept of version numbers on distributions,
>> but only on the pm files which are inside the distribution.
>
> I know, thanks. I was suggesting a change.

I had a discussion of two days about "versions" with Sam Vilain.  What
we came up with, is that there is only one solution: versions need to
be strings without meaning.  Of course, you can help yourself using some
kind of logic sequencing these strings, but everyone has different ideas
about how to do that. Who (besides Perl people) expect 5.10 after 5.8?

The solution is simple: each release has a unique version string. The
release also lists as meta-data what kind of follow-up it is to which
existing release.  For instance:
   5.10.0   diverts from 5.8.8  (upgrade)
   5.8.9replaces 5.8.8  (update)
   5.10.1-blead diverts from 5.10.0 (devel)
   5.10.1   replaces 5.10.0 and 5.10.1-blead (merge)

In upgrade paths, replacements are safe upgrades and diversion may break
code interfaces, where upgrades need more care (and probably explicit
user approval)

Which this approach, you can safely create all the weird versioning needs
that Perl6 has designed.

A picture could be presented to the users, to help making choices:

 |
   5.8.8
 |  \
 |   \
   5.8.9  5.10.0
 |  \
 |   \
 |5.10.1-blead
 |   /
  5.10.1

>>> D) In addition to target=perl5 and target=perl6 we could have target=parrot.
>>
>> IMO, we need many more.  What you call "target" is actually a namespace.
>> The current CPAN archive has only one target.
>
> Target, namespace, same difference. It's an identifier to divide modules  
> into categories.

Well... do you need all archives to share one infrastructure?  I think it
is nicer to have people being able to open-up CPAN-like archives with
additional features.  For instance, if someone wants to publish pre-compiled
PIR versions of modules, then s/he should not need the assistence of the
core CPAN.  With an URI namespace, you address an archive where you can
find the data.  A part of that namespace (URI fragment) could be a target
within the archive.

>>> F) In summary, we have a possible course of action:
>> There is a lot more structurally problematic.  Please read one of my
>> papers on the cpan6.org website.
> I have scanned through the first one. It's 30 pages...

Oh, that's the small one.
-- 
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: [RFC] CPAN6 requirements analysis

[Daniel Carrera]

Timothy S. Nelson wrote:

I can confirm that Redhat supports multiple versions:

$ rpm -q kernel
kernel-2.6.27.5-117.fc10.i686
kernel-2.6.27.12-170.2.5.fc10.i686
kernel-2.6.27.5-117.local.fc10.i686


AFAIK the way RPM implements "multiple versions" is by making an 
entirely different package. Like, for example, if you have Gimp 1.x 
installed, the package might be called "gimp". When Gimp 2.0 comes out, 
if you don't want to remove the old Gimp, you make an entirely separate 
package called "gimp2" with its own set of versions.


The point is that we may have trouble scaling that to cover all the 
stuff that S11 says. I'm not saying it can't be done. I'm saying it 
might be difficult, as we'd be using RPM and DEB in a way that they were 
not intended.


Daniel.

Re: [RFC] CPAN6 requirements analysis

[Daniel Carrera]

Alex Elsayed wrote:

On Thursday 28 May 2009 4:54:50 pm Daniel Carrera wrote:

On the other hand, distributing Parrot bytecode (or PIR, or PASM) seems
fine. But I don't know what to suggest for modules that require a C
compiler.
The problem with that is that Rakudo isn't the "Official" impelentation, and 
never will be. Distributing modules as Parrot bytecode would lock out other 
implementations, something that is very strongly discouraged.


I know that Rakudo is not the official implementation. The problem is 
that you misunderstood my post. I did not say to distribute PIR to the 
exclusion of Perl source. You know that I was replying to Larry's 
comment that he supported the notion of distributing binaries. Surely 
you didn't think that Larry meant "distribute binaries to the exclusion 
of Perl source", did you? Therefore, my comment is a reply to the binary 
aspect and the central part of my comment is the problem with modules 
that require a C compiler.



* Collision detection - It becomes impossible to prevent another package from 
overwriting a file installed this way


Nothing is impossible. The first method that crossed your mind may not 
do it, but that doesn't mean that it can't be done. In any case, the 
drawbacks are no worse than what the current CPAN shell does today. And 
the current CPAN shell obviously work fairly well. The current system 
has room for improvement, but any argument that says "it can't work" is 
flawed because it is working right this minute and it has been working 
for years.


Daniel.

Re: New CPAN

[Mark Overmeer]

* Daniel Carrera (daniel.carr...@theingots.org) [090528 21:46]:
> use Whiteness:from;
> So we have to give some thought to how the modules are going to be  
> stored in the system.

Actually, I have made some progress to implement this for Perl5. The
problem is that you need parallel trees of the same version. So naturally
you get something like:
  /usr/lib/perl5.10.1/File-Slurp-0.98/File/Slurp.pm
  /usr/lib/perl5.10.1/File-Slurp-0.99/File/Slurp.pm
And put the right File-Slurp-0.9[89] in your INC path.  Even: we can just
untar the distribution on that spot, run make, and then use the blib tree
in the INC path.

But what is the right version?  One of the problems companies often have,
is that they have a stable system with perl applications. Then, they
add a new application which requires newer versions of modules which
are already in use. By upgrading, they may break their stable code.

So, I came up with the idea to have a index file of used module versions
per script.  It defines which distributions are used for that script. The
first time you run the script, it collects all the newest distribution
versions and "freezes" that list for all next runs. The list of newest
modules, as is used in the initial run of a script, only accepts a new
version if the tests succeed and also all the tests from modules which
depend on that have been re-run successfully.
The index file also solves the performance hazard of scanning huge INC
paths, which makes runtime look-up for module locations slow.

I have started to implement above as part of CPAN::Site for Perl5, more
as feasability study. Not releasable yet. Quite straight forward with
an INC code-hook.
-- 
   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net