Not Quite Perl
Hello, I've been reading a little about NQP (Not Quite Perl). I was wondering if NQP is part of the Parrot project, or if it is an independent spec. I'm wondering if a program written in NQP will be faster in general, or faster under Rakudo/Parrot, or not fast at all. Cheers, Daniel. -- I'm not overweight, I'm undertall.
The = operator and context
Hello. We are all familiar with this: (1..10).WHAT # = Range() @foo = 1..10; @foo.WHAT # = Array() When you assign a range to @foo, the result is an array. Something similar happens, for example, if you assign a scalar to @foo... The context of the assignment causes Perl 6 to convert the value into an array. I was wondering if this sort of magic is limited to pre-defined types (arrays, hashes, etc) or if it can be extended to any class that I might create. For example, imagine hat I create a 'Vector' class to do basic linear algebra. Imagine that it works this way: my @vec = Vector.new( 1,2,3,4 ) @vec * 3 # = ( 3,6,9,12 ) In other words, the '*' operator is overloaded to behave like scalar x vector multiplication in linear algebra. I was thinking that it would be neat if instead you could do this: my Vector @vec; @vec = 1,2,3,4; @vec.WHAT # = Vector() In other words, the context of the = sign tells Perl 6 to convert the array (1,2,3,4) into a Vector() object (presumably using the .new() method). As an additional example, you could imagine a matrix class like this: my Matrix @mat; @mat = [ \[ 1,2,3], \[3,4,5], \[5,6,7] ]; In my mind, what would happen here is that the array on the right-hand side (an array of arrays) would be converted into a matrix, which is a 2D object, and you could do regular matrix operations. Is this sort of thing possible in Perl 6? Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: The = operator and context
On 3 April 2012 17:24, Moritz Lenz mor...@faui2k3.org wrote:
You can, very nearly. You just need to write
my @vec is Vector;
because you really want to change the type of the container, not just of the
contents (my Vector @vec would be an array containing Vector objects).
Another option might be to just use scalar variables to hold vectors:
my Vector $vector;
my Vector @array_of_vectors;
$vector = 1,2,3,4,5;
class Vector is Array {}
multi sub infix:*(Vector $a, Real $b) {
Vector.new( $a.list X* $b );
}
my @vec := Vector.new(1, 2, 3, 4);
say @vec.WHAT;
say @vec * 3;
Output:
Vector()
3 6 9 12
Using binding := instead of assignment replaces the array container with a
Vector object.
Doesn't work for me :-( For me the last statement gives 12.
(you can also override the .STORE method of a scalar, but that's a bit
creepy if you ask me).
Hmm... So you'd have to mess with the STORE method of *all* scalars
(i.e. not just the Vector() class) ?
Daniel.
--
I'm not overweight, I'm undertall.
Re: The = operator and context
On 3 April 2012 20:38, Moritz Lenz mor...@faui2k3.org wrote: which version of Rakudo are you using? (I've tried on the last development version from git) Rakudo Star 2012.02 % perl6 --version This is perl6 version 2012.02 built on parrot 4.1.0 revision 0 Hmm... So you'd have to mess with the STORE method of *all* scalars (i.e. not just the Vector() class) ? No. Just those that you want to behave specially. And I never recommended it. Ok. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: N-dimensional arrays and compiler support
On 23 March 2012 12:55, Carl Mäsak cma...@gmail.com wrote: The shaped arrays/hashes parts of S09 have been in the planning stages a long time in Rakudo. They've had to wait for better MOP and better native-types handling (which is another part of S09), but now the time for shaped arrays/hashes is surely here. If jnthn or pmichaud hasn't started digging into them by the time I finish the macro grant, I likely will. Cool. Part of me wants to volunteer to help, but I know that I just don't have time... Still, I look forward to those parts being implemented. In some vague sense, shaped arrays/hashes are just sugar, but I believe they'll form an integral part in idiomatic Perl 6, and provide a real edge over corresponding unsugared Perl 5 code, even in fairly simple scripts. My work is probably not typical, but I would really like to see this feature. Most of my work is numerical computation. My workhorse language is Fortran 2008, but I always have either Octave or Python running on a shell for quick calculations and some times to experiment with algorithms. Thing is, I don't like Octave and I don't like Python (and I don't like PDL). Now that I've discovered the Rakudo shell, Perl 6 has basically replaced Python for me. I have considered writing a minimalist numerical array class for Perl 6 so I could replace Octave. I gave it a go a few days ago, but I quickly got stuck on how to deal with multi-dimensional arrays. I might come back to this in the summer if I have more time then. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 22 March 2012 04:59, Jonathan Lang datawea...@gmail.com wrote: My understanding is if you want to count by threes, starting at 2 and ending at 14, you should be able to write: 2, 5 ... 14 That certainly looks very intuitive, and it is similar to what I would write in an email. The only annoyance is that I have to do a bit of mental arithmetic. But I guess that's ok. Especially since most of the time you'd probably want to write 2,5...* anyway. So: 1, 3 ... 13 # same as 1,3,5,7,9,11,13 1 ... 10 # same as 1,2,3,4,5,6,7,8,9,10 1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64 That last one doesn't work on Rakudo :-( Meanwhile, using Whatever for the test condition means keep the series going indefinitely: 1, 3 ... * # every positive odd number. 1 ... * # all counting numbers. 1, 2, 4 ... * # all powers of 2. Yeah, and those are very convenient. And using '...^' instead of '...' changes the default final test condition from ' $n' to '= $n': 1, 3 ...^ 13 # same as 1,3,5,7,9,11 1 ...^ 10 # same as 1,2,3,4,5,6,7,8,9 1, 2, 4 ...^ 100 # same as 1,2,4,8,16,32,64 Ok. I hadn't thought of doing that. In short, what Damian is talking about is the more powerful and reliable use of the syntax; but the above approach (assuming it has been properly implemented) is a more intuitive use that covers the most common cases. Make common things easy, and make uncommon things possible. Yeah. Likewise, using Whatever in conjunction with operators is there to provide an intuitive way to calculate the next term from the previous one(s): 1, *+2 ... 13 # start at 1, step by 2s, stop at 13. 1, 1, *+* ... * # each new term is the sum of the previous two. Oh! That second one is cool. a one line implementation of the Fibonacci sequence. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 22 March 2012 11:02, Carl Mäsak cma...@gmail.com wrote: 1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64 That last one doesn't work on Rakudo :-( And it never will. Note that 100 is not a power of 2, and that the goal needs to match exactly. This is because smartmatching is used, ... If you're wondering why things are factored in this way, it's because previous versions of the spec that tried to special-case 100 to work in cases like the above, ended up not working out. It turned out that the unification of infix:... and smartmatching was what did work. It has the slight drawback that we have to educate users to write * = 100 instead of 100 in the case of not-exactly-matching goal states. But it's still a net win, because this unified semantics works better than anything we had before. But that's a bit of a problem if I *don't* want a value higher than 100. 2,4,8... * = 100 2 4 8 16 32 64 128 There is no simple formula I can use at the end to get the sequence to stop where I want. So I have to do something like: my @a = 2,4,8... * = 100; @a.pop # Use @a Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 22 March 2012 12:06, Moritz Lenz mor...@faui2k3.org wrote: But that's a bit of a problem if I *don't* want a value higher than 100. Then exclude it: 2, 4, 8 ...^ * 100 Ok... I looked up what you did. I see how it works. Thanks. Related questions: What types of sequences can Perl 6 recognize? -- I'm not overweight, I'm undertall.
N-dimensional arrays and compiler support
Hey, I have a few slightly related questions: 1. The semicolon operator would allow Perl 6 to support N-dimensional arrays... How would one iterate over that type of array? my num @matrix[ 10 ; 10 ; 10 ]; I ask because a natural extension is to add arithmetic operators and you have the beginnings of a Matlab-like array language. 2. Do you think Rakudo is likely to get support for N-dimensional arrays in... say... the next year or so? 3. Does anyone here know much about Niecza? Can you compare it with Rakudo? I am already familiar with the feature support page (http://perl6.org/compilers/features) so I am leaving the question intentionally vague. I'd be interested in anything that you think is interesting (e.g. speed, development style, progress, whatever). Cheers, Daniel. -- I'm not overweight, I'm undertall.
How to make a new operator.
Hello, Is it possible to create a new range operator ':' such that: a:b is the same as a..b (this is the easy part) a:b:c is a range from 'a' to 'b' by steps of 'c'. For example, 2:15:3 == 2,5,8,11,14 :b is the same as 0..b a: is the same as a..Inf ::c is the same as 0:Inf:c : is the same as 0..Inf I think you get the idea. This is inspired by NumPy. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: How to make a new operator.
Hi Moritz
a:b is the same as a..b (this is the easy part)
a:b:c is a range from 'a' to 'b' by steps of 'c'. For example, 2:15:3
== 2,5,8,11,14
That can be done by giving the new infix:: operator list associativity
(niecza already supports this)
Can you explain or give me a link that explains how to do that? I can
figure out a little bit on my own:
multi sub infix::( Int $a, Int $b ) {
# This is the case 'a:b'
}
multi sub infix::( Range $a, Int $b ) {
# Is this correct?
# I'm thinking that a:b:c could be interpreted as (a:b):c so it
is Range : Int.
# Am I on the right track?
}
:b is the same as 0..b
create a new prefix operator... except that that prefix : is already
taken for constructing pairs
Ok. I hadn't realized that you could define the same symbol as prefix,
infix and postfix... So.. ignoring the fact that : conflicts with
existing syntax, I could do this:
multi sub infix::( Int $a, Int $b ) { ... }
multi sub infix::( Range $a, Int $b ) { ... }
multi sub prefix::( Int $a ) { ... }
multi sub postfix::( Int $b ) { ... }
Right?
: is the same as 0..Inf
create a term::.
Ok.
There are hooks for all of that, but it requires you to come up with a
new syntax that doesn't collide heads-on with lots of existing grammar
rules.
Thanks. I'll see if I think of something that feels natural but
doesn't collide with anything. One option is to just use the existing
.. operator:
multi sub prefix:..( Int $b ) { 0..$b }
multi sub postfix:..( Int $a ) { $a..Inf }
Only problem is that something like 2..10..3 might be confusing.
Hmm... I must have made a mistake here somewhere... After defining
these functions, the traditional range '2..10' doesn't work anymore. I
suppose that my new functions have a higher precedence than the
traditional .. operator. I tried to fix this, but I failed:
multi sub prefix:..( Int $b ) is looser(infix:cmp) { 0..$b }
So, I'm not doing this right.
Cheers.
Daniel.
--
I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 21 March 2012 22:50, Carl Mäsak cma...@gmail.com wrote: It would also produce an infinite list, because by the rules you need the RHS of infix:... to match exactly, and 10 is not in the infinite list 2, 5, 8, 11, 14... Which is why you'd need to write something like * = 10. Ok, so infix:... isn't what I wish for either... Can you help me understand Damian's example? $a,*+$c...* =$b I see a lot of Perl magic here and I have no idea what any of it does. What does the first star do? And the plus sign? I tried to guess what the = does by experimentation, but I can't make heads or tails of it: 2..100 = 5 True 2...100 = 5 2 Also, I'm only now learning what ... does. I thought it was just the yada yada yada operator, but now I see that it makes an object called List(), which clearly is different from both Range() and Array()... Btw, I just found the section in S09 covering multi-dimensional arrays and the semicolon operator. I'll go read it now... One unrelated question: Is there a way to ask an object what methods it supports? That would make it easier for me to experiment. For example, just now I have been looking for the methods supported by the Range object (to see how I'd obtain the beginning and end points of a range) and haven't found anything. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 22 March 2012 00:08, Brandon Allbery allber...@gmail.com wrote:
* + $c --- the next value is the current value plus $c. (* means
Whatever, and generally refers to the current value of something. In this
case, we're specifying how to make a new value given a current value. You
can think of it as a way to make an anonymous function. In Haskell this
would be (+ c) or \x - x + c; in Python, lambda x: x + c; in Perl 5,
sub {$_[0] + $c}. The meaning of * is context dependent, though; when
accessing array elements, for example, * refers to the end of the array, so
@arr[* - 1] means the second last element of @arr.)
Interesting... a lambda expression...
my add3 = * + 3
WhateverCode.new()
add3(2)
5
Cool... this actually works... But I notice that to use 'add3' in the
list construction I need to put an ampersand:
2, add3 ... 14
2 5 8 11 14
Still... the fact that this works is neat.
* = $b --- this determines where the sequence ends: when the current value
is greater or equal to $b.
So... after the ... you have an anonymous function that has to
return 'True' for the sequence to end? Seems strange, but it works:
# A function that always returns True = List of one item.
2,5...True
2
So if I want to go from $a to $b by steps of $c, the correct recipe would be:
$a, *+$c ... * = $b - $c
With this information, I can write something like this:
sub infix:|( Range $r, Int $c ) {
my ($a, $b) = $r.bounds;
return $a, *+$c ... * = $b - $c
}
(2..10)|3 == 2, 5, 8
This would look better if I removed the parenthesis, but I'm having
trouble telling Rakudo that this infix operator is looser than the ..
operator:
sub infix:|( Range $r, Int $c ) is looser( infix:.. ) {
...
}
No applicable candidates found to dispatch to for 'trait_mod:is'.
haral:6704 Z$ ./perl6 -e 'say (2, 4 ... 10).^methods'
Thanks. That's very useful.
The .^ operator runs a method on the object's metaobject, which determines
how it associates with its class and roles. The metaobject is available via
the HOW method, but is not something you can print or etc.; working with it
directly is somewhat painful, which is why .^ exists.
Ok.
--
I'm not overweight, I'm undertall.
Re: How to make a new operator.
On 22 March 2012 01:13, Solomon Foster colo...@gmail.com wrote: It actually smartmatches whatever is on the right hand side against the sequence, and stops when the smartmatch returns True. It just happens that you smartmatch an anonymous function, it executes the function and returns its result. I see... I still find this a little confusing. The idea of smart-matching a function just doesn't quite fit with my brain. I can memorize the fact that smart-matching 7 and foo means evaluating foo(7) and seeing if the value is true, but I can't say I understand it. Examples: 2, 5 ... 11 # smartmatch is true when you hit 11 2, 5 ... True # stop right away 2, 5 ... False # never stop 2, 5 ... * # shorter way of saying never stop 2, 1, 1/2 ... Num # stop when the number switches from a Rat to a Num 'a' ... /f/ # stop when the regular expression matches Interesting. Cheer, Daniel. -- I'm not overweight, I'm undertall.
Re: Announce: Rakudo Star 2010.12 released
Out of curiosity, is it possible to get Rakukdo to talk to C, C++ or Fortran? On Thu, Dec 30, 2010 at 8:04 PM, Patrick R. Michaud pmich...@pobox.com wrote: On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the December 2010 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the December 2010 release is available from http://github.com/rakudo/star/downloads. Rakudo Star is aimed at early adopters of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These Star releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it. In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. The December 2010 Star release includes release #36 of the Rakudo Perl 6 compiler [1], version 2.11.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community. This release of Rakudo Star adds the following features over the previous Star release: * New .trans algorithm * Configuration improvements * More bug fixes There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Thus, we do not consider Rakudo Star to be a Perl 6.0.0 or 1.0 release. Some of the not-quite-there features include: * nested package definitions * binary objects, native types, pack and unpack * typed arrays * macros * state variables * threads and concurrency * Unicode strings at levels other than codepoints * pre and post constraints, and some other phasers * interactive readline that understands Unicode * backslash escapes in regex [...] character classes * non-blocking I/O * most of Synopsis 9 * perl6doc or pod manipulation tools In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed at rakudo...@perl.org. See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. An updated draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in the release tarball. The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or join us on IRC #perl6 on freenode. Starting with the January 2011 release, Rakudo Star releases will be created on a three-month cycle, or as needed in response to important bug fixes or improvements. The next planned release of Rakudo Star will be on January 25, 2011. [1] http://github.com/rakudo/rakudo [2] http://parrot.org/ -- No trees were destroyed in the generation of this email, but a large number of electrons were severely inconvenienced.
Re: Filename literals
+1 Carl Mäsak wrote: Very nicely put. We can't predict the future, but in creating something that'll at least persist through the next decade, let's not do elaborate things with lots of moving parts. Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality. moritz_ I agree. Matt-W magic can always be added with module goodness
Re: Multi-d array transforms (was Re: Array rotate)
Larry Wall wrote: Nevertheless, for any major methods borrowed from Perl 6, I'm not inclined to change them that drastically. Much more likely to define them as sugar for the more general list operators: .push means .=append .unshiftmeans .=prepend .splice means .=impend:-) or some such. I like those. I feel similar to Matt W. I kind of like .push and .unshift the way they are (probably just habit) But I can appreciate that non-mutating alternatives might open a new class of algorithms from the functional world. Daniel.
Re: Multi-d array transforms (was Re: Array rotate)
Damian Conway wrote:
In fact, I would even be happy with requiring @a.=push and @a.=shift, if
it meant that there were *no* special cases. One extra character is a
small price to pay for perfect SWIM (and not just Say What I Mean,
the real benefit is the other SWIM: See What I Meant).
I don't like @a.=shift. It looks like @a = @a.shift, which is of course
not what you mean.
In addition, the current @a.shift is useful because it returns the
element that was removed from the array, so you can do something with it:
loop {
@customers.push @c if (@c = new_customers());
serve_customer(@customers.shift);
}
I'm sure the more experienced people can suggest a better example.
Daniel.
Re: Module naming conventions
John M. Dlugosz wrote: Yes. did you read mine? Yes, I read your email. Sounds like you are thinking of Parrot vs pure perl, and missed my point about being utterly different implementations, not choices within one. Chances are, the most popular implementations of Perl 6 will allow C bindings, just like Perl 5. Some, like Rakudo, will have both C and Parrot bindings. In this day, users do have a choice. A Rakudo user could install a module that uses C bindings, or he could install a module that is all Perl, or he could install a module that uses Parrot. There are perfectly valid reasons why he might choose one option or another. A SMOP user might install a module that uses C bindings, or one that is all Perl. There are valid reasons why he might want one or the other. Daniel.
Re: Module naming conventions
Hi Patrick, To reduce list traffic, I'm replying to both of your emails together. Just because these are the only adverbs mentioned doesn't necessarily mean they're the only ones that will be allowed. Ok. My interpretation was that adding adverbs would require updating the spec. More importantly, I thought that it would be more difficult to get agreement on a new adverb. I figure that at this late stage in the process, you probably don't want to make a lot of language changes. In your other email, you say: For the Parrot case at least, I suspect one would/could do: use SHA:fromParrot; (See the :from adverb in S11.) That looks great. I didn't think of that. Perhaps it can be used for C as well. We might have to abuse the :from a little to include the name of the C bindings (if there is more than one option). Daniel.
Re: Module naming conventions
Mark Overmeer wrote: Currently in CPAN you have modules like: Digest::MD5 Digest::SHA Digest::MD5::Perl Digest::SHA::PurePerl The difference is that the first two are implemented in C and the later two in Perl. This is comparible to adding a target to each of the modules, a suggestion when you started this long thread. I'm thinking of a different problem. Regardless of how CPAN works, once stuff is installed in my system, I need a way to tell Perl which of the three different (installed) SHA modules I want to use. If there is no good solution, people will just use the module names in ad-hoc ways as exemplified above. Do we really want each person adding their own thing to the module name (::Perl vs ::PurePerl)? I figure that the ways to avoid that is to change the language semantics or add a naming convention. I assumed that changing the language semantics was a non-starter. Daniel.
Re: Module naming conventions
John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel.
Re: Module naming conventions
Chris Fields wrote: Speaking as an almost complete outsider (I'm a bioperl core dev writing up a perl6 port), I find the tone of several of these more recent posts (re: CPAN6 and module conventions) counterproductive. TimToady recently posted about snippiness and 'tensegrity', so I'm not the only one sensing it. Ok, I'll watch my tone. Sorry. I did try to temper my response. I admit I was a bit frustrated when I wrote, but not very. I did not think I was being too aggressive in my response. But clearly you disagree, so I will try to change. I don't seem to run into tenserity problems on IRC, and I seem to be much more productive there. I don't know why there is a difference (different people? different topics? different medium?). But whatever the reason, I think that I'll stay mostly on IRC, at least for now. Daniel.
Re: CPAN -- moving forward
Parrot Raiser wrote: One of the common factors that has contributed to the longevity of Unix (in the generic sense), and the Internet, is their layered architectures. +1 for layered architectures. If this discussion can be split into clear layers, (what gets stored, where, how, c.) it might be easier to produce results. I feel similar. I attempted to do something like that with my wiki page, but that didn't work so well. Now I'm trying a new approach: I am in IRC working with Rakudo folk on how Rakudo is going to store modules on the disk. Once that is done, one can begin talking about a package format and an installer, and then go from there. So far the discussion has been productive and we have some code written that we can experiment with. So I feel encouraged. Daniel.
Module naming conventions
Hi all, Currently in CPAN you have modules like: Digest::MD5 Digest::SHA Digest::MD5::Perl Digest::SHA::PurePerl The difference is that the first two are implemented in C and the later two in Perl. Naming issues are likely to become worse in Perl 6 when we also have modules that use Parrot. You might have three implementations of Digest::SHA, one in Perl 6, one that uses Parrot, and one that uses C. Worse, you might even find a module that depends on both Parrot *and* C. I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. My first thought was: P6::Digest::SHA C::Digest::SHA Parrot::Digest::SHA But that does nothing for modules that require both C and Parrot (it sounds horrendous, but I bet *someone* will do it). And btw, this isn't just to help users pick the right module. The modules do need different names to avoid naming conflicts. One idea is to introduce a non-alphanumeric character to separate dependencies. For example: Digest::SHA-- No dependencies. Just Perl. Digest::SHA/C -- Requires C. Digest::SHA/Parrot -- Requires Parrot. Digest::SHA/C/Parrot -- Requires C and Parrot. Remember that in Perl 6 modules can be named with any Unicode character, so / is fair game. I am not proposing a change to the language. Just a naming convention using characters that the language already allows. There are other possible symbols besides '/'. All in all, I think my favourite options are (in no particular order): Digest::SHA/C Digest::SHA/Parrot Digest::SHA!C Digest::SHA!Parrot Digest::SHA+C Digest::SHA+Parrot Digest::SHA.C Digest::SHA.Parrot Digest::SHA~C Digest::SHA~Parrot What do you think? If anyone can think of a symbol that is already used in Perl with a similar meaning, please let me know. Daniel.
Re: Module naming conventions
Jon Lang wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I read S11 and AFAICT Perl 6 only includes metadata for *versions* and *authority*: class Dog:ver1.2.1:authcpan:JRANDOM; class Dog:ver1.2.1:authhttp://www.some.com/~jrandom; class Dog:ver1.2.1:authmailto:jran...@some.com; This has nothing to do with dependencies. There is no reason why the same author cannot write two variations of the same module, with different dependencies. In fact, I suspect that will happen often. Digest::SHA and Digest::SHA::PurePerl are written by the same author. He recommends the C version to most people, but he also wrote a Perl only version for people who don't have access to a C compiler. module Using the version or authority fields to denote dependencies is a much greater abuse than using the base name. Daniel.
Re: Commentary on S22 (CPAN [DRAFT])
jesse wrote: 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. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called META-INF. There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. Sounds reasonable. Like you said, there is no strong reason to pick one name or another, so why not pick the name everyone else already uses? Daniel.
CPAN -- moving forward
Hello, In the hopes of helping the CPAN discussion move forward, in the direction of tangible work, I have made a wiki page with a proposal: http://wiki.github.com/perl6/misc/cpan-and-package-format Please read the Basics section, which is quite short. The main point of this section is to divide the issue into three parts: 1) A package format. 2) A low-level install tool, analogous to rpm or dpkg, that converts the package (2) into a local package format (rpm, deb, ebuild). 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. I have used the same numeric labels on the wiki. Tim N. is most interested in (2) and Mark O. is most interested in (3). I propose that we work on (1) and (2) first and do (3) later. (3) is quite independent of (1) and (2). Mark might want to check that the package format includes enough meta-data to not conflict with is ideas. If we can mostly agree on the package (1), we can move to (2). I think we can make quick progress with (2): 2.1 Start with a easyugly script using the alien and zip commands. Get the basic functionality down. 2.2 Gradually port Perl 5 modules (e.g. Software::Packager) and rewrite the script to remove dependency on shell commands. Think of it as a boot-strapping method. What do you think? Daniel.
Re: CPAN -- moving forward
Mark Overmeer wrote: A pity you didn't want to read the paper. I have better things to do with my life than read your 30-page paper. I'd rather participate in a consensus process where I feel I can make a difference. Please clarify ... how would you specify that? And how would you denote ranges of conflicting packages? Well, maybe start with putting that in your wishlist. And conflicting/dependencies in licenses? How would you resolve dependency conflicts? Design human intervention in this process of dependency processing. [big snip] My wiki page was purposely only an initial step. I don't believe in working in isolation for days or weeks and then handing down a massive ready-made solution to the masses. I offer a small, incremental step on top of Synopsis 22 and hope that it is useful. Daniel.
Re: CPAN -- moving forward
Daniel Ruoso wrote: The leap you make from the source package to the different binary formats is overlooking a lot of details. It would be interesting if you could take a look in the previous discussions on the matter. I'll be happy to. I was just trying to make a small iterative step on Synopsis 22. I know that there is a wide gap between that and binary formats. But I wouldn't do anyone any favours if I spend a lot of time on my own trying to make a complete solution. At least now you can point me to the relevant discussion and I'll be happy to read it. I just need a URL link. 1) A package format. This is supposed to be a source format, but different from current model used in CPAN, it's pretty clear already that it can't include a build system, like ExtUtils::MakeMaker or Module::Install. There's already some consensus that this source package format should describe what it contains, not how it should be built or installed. For instance, it should only say something like in the lib directory there's a set of STD Perl 6 modules that don't require any low-level integration. Ok. Thanks for the info. Notice that I didn't assume anything one way or the other on the page I wrote. Just some additions to S22 (mainly the manifest file). I tried not to make many assumptions precisely because I don't know the previous discussion. 2.0) Build tool Before installing it, you need to create a installable package, or binary package (that's what CPAN plus does today). The thing here is that the process of transforming the source package into an installable package will be specific to the Perl implementation, to the Operating System and to the vendor of the Operating system. That basically means it's implementation specific, and each implementation should do its best to provide that support. For instance, rakudo might want to compile the modules to Parrot Bytecode, while mildew might want to compile down some things to C. Seems logical. If you're in an OS that provides a rich package management system, it means you can generate native packages, otherwise you need to implement the next step as well, which is: 2.5) Install tool In systems where we don't generate native packages, we need a package manager on our own. It should be capable of taking any installable package and making it available in the system, checking all dependencies and other requirements.. Yes, certainly. 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. I do think this is very much implementation-specific, for instance, in Debian, with little work you could simply use apt-build to get your packages built and available for installation with apt-get. In Debian there is both apt-get and aptitude. Two different implementations of a high-level package manager wrapped around dpkg. In the RPM world there is yum and urpmi as well. In summary, The part 1 is really the critical issue, 2.0, 2.5 and 3 are mostly implementation specific and are considerably easier to adapt than the things in the part 1. We do need to find a very solid way of describing what the package contains in order that implementation-specific build tools can make them work. Yes, indeed. Most of what I put in the wiki page is an iterative step on the package format described in Synopsis 22. Should we start talking about the package format then? Daniel.
Re: [RFC] CPAN6 requirements analysis
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: [RFC] CPAN6 requirements analysis
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: New CPAN
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 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
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.
Re: New CPAN
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 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
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: New CPAN
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 = Comprehensively Conspicuously Continuously Completely Certainly; @P = Pathological Perplexing Powerful Pervasive Pedestrian Pure Posh; @A = Archive Array Anthology; @N = Network Nest; say (@C.pick,@P.pick,@A.pick,@N.pick).join( ); Cheers, Daniel.
Re: New CPAN
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.
Re: New CPAN
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.
Commentary on S22 (CPAN [DRAFT])
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: Commentary on S22 (CPAN [DRAFT])
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.
Re: New CPAN
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
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
Hi Damian, This is a really good list. Mind if I copy it / modify it and post it somewhere like my blog? One question: * Compactness of expression + semi-infinite data structures: @fib = 1,1...[+]# The entire Fibonacci sequence Very impressive. That's even shorter than Haskell. What's [+] ? How does this work? In Haskell: fibs = 1 : 1 : zipWith (+) fibs (tail fibs) PS: A really mean, but very effective, way of emphasizing the ease, expressiveness, compactness, and readability of Perl 6 code is to take each of the examples and show the same thing written in Java. ;-) It might be appropriate to compare some examples with Ruby or Python. Daniel.
New CPAN
Hello all,
There was some talk on IRC about a new version of CPAN to match the new
version of Perl.
Recap: wayland76 wants to integrate CPAN with the local package manager
(RPM, DEB). He proposed using Software::Package for that (which is
incomplete).
Now some ideas of my own:
A) Can we add version, target flags to CPAN metadata? I was thinking
that current modules would all be version=1 and target=perl5.
B) If we can, we can modify the cpan utility to run a different
program depending on the module version:
if (!$version or $version == 1) { system(cpan1 $module); }
else { system(cpan2 $module); }
So initially all modules go to the cpan1 program.
C) With this we are free to make a new CPAN format and a cpan2 install
script. We can upload the new modules to CPAN and the cpan script will
handle them correctly.
In other words: We don't need a new CPAN site. We can have two formats
in the same site. We just need a rule that a module can only depend on
modules with the same format.
Notice that Perl 5 authors can then also start using the new CPAN
format. They'd just set target=perl5.
All in all, I hope this would ease the migration to the new CPAN format.
D) In addition to target=perl5 and target=perl6 we could have target=parrot.
The CPAN user interface would have to be updated to allow two modules
with the same name but different targets.
E) With all this done, we can talk about the new CPAN package format. We
can use the alien utility (written in Perl) to finish the
Software::Package distribution (which currently only supports RPM).
F) In summary, we have a possible course of action:
1. Add version and target metadata to CPAN.
2. Write to the author of alien to see if he'll let us copy his code
under the Perl license.
3. Use alien to finish the Software::Package distribution, adding
support for at least DEB.
4. Use these to make a new CPAN format.
5. We can port Software::Package to Perl 6 and package them as a way to
test the new CPAN format with Perl 6.
...
What do you think?
Daniel.
Re: New CPAN
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. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. I can see how this could be a point of contention. If I made a website called gimp3.org I'd expect some flack from the Gimp people. 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. 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? 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. 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... Daniel.
Re: New CPAN
Jonathan Scott Duff wrote: See http://perlcabal.org/syn/S11.html#Versioning Yeah, I reached that part earlier today (but after I sent my email). Thanks. Daniel.
Re: New CPAN
Darren Duncan wrote: Because we need things to work effectively in the general case where what was originally a single module Foo with one name becomes forked with each creator (authority) going off in their own direction, or alternately the creator makes incompatible changes, and then later someone's project Bar may have a bunch of dependencies A and B where A depends on one version of Foo and B depends on an incompatible version of Foo; then both versions of Foo need to work together. And that's just one reason to have this support. -- Darren Duncan Yeah. At the time I wrote that I hadn't yet read S11. The new CPAN needs to handle all the metadata in S11. use Whiteness:fromperl5 Acme::Bleach 1.12 cpan:DCONWAY; So we have to give some thought to how the modules are going to be stored in the system. Daniel. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [RFC] CPAN6 requirements analysis
Hi Alex, I hve comments. Alex Elsayed wrote: 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 * We were mainly looking at Alien as a source of Perl code we could borrow. * The point of wayland76's proposal was to use the local package manager. Whether the local package manager is geared toward binary distributions is a separate issue. At first I liked wayland76's proposal, but now I have a new concern: Most package managers are not designed to hold multiple versions of the same package. As indicated in S11, it is important that a computer can hold multiple versions of the same package. I fear that using the native package manager will make this difficult. * 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 This is something I agree with. It seems smart to be able to download the metadata before downloading the source tree. This allows dependency resolution, searches, etc. Daniel.
Re: [RFC] CPAN6 requirements analysis
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. 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. Most of these package managers have ways of running an installation script at the end, so we could perhaps think of this as downloading an installer rather than the actual software, and the new version of the installer contains or has access to all the versions it knows should be installed, and interacts with the official Perl library installer to install them. I suggested something similar to wayland76 a couple of days ago, to solve a different problem. If I remember correctly, he was concerned about the local package manager not knowing which files were installed. Perhaps we should revisit this idea. This is what I proposed: We have our own package manager (e.g. /usr/bin/cpan6 ) that takes a .tgz file with an appropriate format: /usr/bin/cpan6 install Foo-Bar.tgz The RPM Foo-Bar.rpm would contain Foo-Bar.tgz and the rpm install script would simply run cpan6 install Foo-Bar.tgz. When the Fedora user uninstall the module, rpm runs a script which just calls cpan6 uninstall Foo::Bar. By the same token, it's smart to keep the metadata close to the thing it's describing, so if it's easy to extract up front reliably, that's probably sufficient. Yes. Daniel.
Re: Unexpected behaviour with @foo.elems
yary wrote:
I'm a relative beginner at perl6, but pretty good with perl5 (and C
and a few others), so I read
for 0...@foo.elems
as saying Give me a list with one item longer then @foo, not give
me the indexes of @foo.
But a Perl non-beginner did make that mistake. The problem is that it
looks a lot like the Perl 5 for my $k (0..$#foo).
Anyways, I am not suggesting a change. I am pointing out a possible
confusion and letting the experts decide what to do.
for @foo.values - $k { do_something($k,@foo[$k]) }
try @foo.keys instead!
Yeah... I noticed after I hit send.
Changing the meaning of elems to mean anything other then the number
of elements seems likely to cause even more confusion!
I did not say let's change the meaning of 'elems'. I was very careful
to suggest nothing. I simply raised a point of confusion and I can prove
that it is a point of confusion because someone who does know about Perl
6 got confused. But what to do about it is something I leave to the experts.
Daniel.
Re: Unexpected behaviour with @foo.elems
Patrick R. Michaud wrote:
An even cleaner shortcut might be to use ^...@foo instead of ^...@foo.elems:
for ^...@foo - $k { do_something($k, @foo[$k]) }
Somewhat clearer could be:
for @foo.keys - $k { do_something($k, @foo[$k]) }
And some may prefer:
for @foo.kv - $k, $v { do_something($k, $v) }
I think the anti-pattern of 0...@foo.elems (or its incorrect
form 0...@foo.elems) should probably disappear in favor of
the above forms instead.
Even if there is no language change, at least it'd be good to ensure
that 0...@foo.elems doesn't appear in the documentation. Instead,
whoever writes the docs should use @foo.keys and @foo.kv. Those are
*very* clear, and they do the right thing.
Daniel.
Re: Amazing Perl 6
Hi Daniel,
Sounds very interesting. Can you post slides? It'd be cool if the talk
was taped, like the Google tech talks. Will it be in English? I don't
speak Portuguese (I do speak Spanish and some German).
I'm planning to do a presentation to highlight the most impressive
aspects to Perl 6, in some way explaining why we are working on it for 9
years while still being excited about it.
Note: By trying to get things that are impressive, you don't want to do
things that are so complicated that the audience gets the feeling that
Perl 6 is too hard.
That said, lazy lists like 0..Inf is something that is both impressive
and easy to understand.
You could try to think of things that are made easier or simpler by the
new Perl 6. The only examples I can think of right now are:
sub foo($x,$y) { ... }
if $a $b $c { .. }
for @people - $dude { do something }
for %people.kv - $key, $value { do something }
Back on the subject of impressive, I really like lambdas:
$code = - $x { say $x }
$code(hello world);
I know this is not the approach you had in mind, but what do you think?
Daniel.
Re: Amazing Perl 6
Daniel Ruoso wrote:
I know this is not the approach you had in mind, but what do you think?
Well, you really made me realize that I'm looking for things that make
me impressed, and probably I don't get impressed that easy nowadays ;)
I understand. Your experience with Perl 6 makes you harder to impress.
So you are probably not impressed by the fact that you can do this:
if $a $b $c { ... }
But what if I told you that my university professor (while I was in
university) chose to teach in Python because he saw that in Python you
could do if a b c: and he thought oh! that's so cool!.
You know what you might want to do? Start with simple but neat examples
that everyone can understand (such as the if statement) and work upward
to more complex examples, so that your last example is something really
impressive. I figure that if you work up to it gradually, the audience
will not be intimidated when they see a large powerful example.
Daniel.
Re: Amazing Perl 6
Mark J. Reed wrote:
I really like the factorial example on the wiki page. That really
gets across the expressiveness of P6, without being too hard to
understand despite its brevity.
sub postfix:! { [*] 1..$^n }
say 5!;
WOW!! That *IS* cool. Can you explain to me how it works? I figured out
postfix: myself, but the rest is obscure to me.
I do think captures are inherently impressive, but not easy to explain...
Got a link?
Daniel.
Re: Amazing Perl 6
Daniel Carrera wrote:
sub postfix:! { [*] 1..$^n }
say 5!;
WOW!! That *IS* cool. Can you explain to me how it works? I figured out
postfix: myself, but the rest is obscure to me.
Here is another idea: Is it possible to declare a circumfix function
that calculates the magnitude of a vector?
$magnitude = |@vector|;
You know how in math, two vertical bars are a standard notation for
magnitude. Oh oh oh... is it possible to define a circumfix function for
the dot product? Something like:
$dot_product = @vector1,@vector2;
Is that possible? That would be uber-cool.
Daniel.
Re: Amazing Perl 6
Mark J. Reed wrote: 3. the reduction meta-operator [...] : [OP](@list) collects the result of applying OP to the elements of the list in order. That is, assuming foo() is a binary sub, [foo](1,2,3,4) = foo(foo(foo(1,2),3),4). So [+](@list) generates a sum of the listed values, [*] generates their product, etc. Wow... That's a foldl! In a functional language, that would be called a fold. It's very popular in Haskell. I like that Perl 6 seems to be taking steps in the direction of functional languages. First lazy lists (0..Inf) and now a fold. :-D Daniel.
Re: Amazing Perl 6
Mark J. Reed wrote: In Haskell it may be called fold (well, foldl and foldr), but the concept has has a variety of names. Two of the more common ones are reduce and inject; The terms I've seen are fold and reduce. The fold term is not just from Haskell. I've seen it elsewhere. If you had said inject I wouldn't have known what you meant. Daniel.
Re: Amazing Perl 6
Mark J. Reed wrote: Note that of the examples given, only Perl 6 and Common Lisp do two things that help immensely simplify the result: 1. reference the built-in * operator directly, without having to wrap it in a lambda expression; 2. actually name the function ! Yes, very neat. Haskell does that too, but I don't know if you can make the function a postfix in Haskell. Daniel.
Re: Amazing Perl 6
Larry Wall wrote:
$dot_product = @vector1,@vector2;
Is that possible? That would be uber-cool.
More likely just use
sub infix:· (@a,@b) { ... }
$dot_product = @vector1 · @vector2;
Thanks.
And for Daniel R. and other observers, how about this:
# Courtesy of Larry
sub infix:· (@a,@b) { [+] @a »*« @b }
my @vector1 = (1,2,3);
my @vector2 = (2,3,4);
say @vector1 · @vector2;
I think that's really nifty. So you can talk about Hyper operators and
then show the dot product. What do you think?
Daniel.
Unexpected behaviour with @foo.elems
Hello,
The following construction doesn't do what a user might expect:
for 0...@foo.elems - $k { do_something($k,@foo[$k]) }
Obviously, the intention is to step through every key/value in @foo. Buf
@f...@foo.elems] does not exist. If @foo = (1,2,3); then @foo.elems is
3, and @foo[3] is undefined.
Yes, I know that you could also have written:
for @foo.values - $k { do_something($k,@foo[$k]) }
But I point out that the earlier code sample was given to me on IRC at
#perl6. If one of the current developers can make that mistake, other
users will too. I cannot say whether it makes sense to alter the
language because of this. You are the language experts. I just wanted to
raise a likely point of confusion among users.
Cheers,
Daniel.
Idea: Literate programing
Hello,
I really like POD and I like the changes in the upcoming Perl 6 Pod.
Have you ever heard of literate programing? (see Wikipedia). I think it
would be neat if Pod could do literate programing. It is already very
close. For reference, please see this article:
For reference, please see this page:
http://www.perl.com/pub/a/tchrist/litprog.html
In brief, the only thing that Pod is missing is allowing you to write
code sections in whatever order is best for people to understand, and
have them be re-ordered when we run the program.
I would like to suggest a =ref block type (for reference) as well as
the :ref() configuration option for =head* and =code, such that:
start myshell.pl -
=begin pod
=head1 Intro
This program is an infinite loop. On each iteration we
read user input and do something with it.
=begin code
while 1 {
=ref handle_input
}
=end code
=head1 Handling user input :ref(handle_input)
To handle user input we simply give the input to
Perl's built-in eval() function.
=begin code :ref(handle_input)
print Prompt ;
eval(STDIN);
=end code
=end pod
end myshell.pl -
1) When you run perl myshell.pl, Perl would grab the second code
block, move to where =ref is, and run the program normally.
2) When you run (say) pod2html myshell.pl, the code block would remain
where it is, but the =ref would be replaced by a hyperlink to the
second =head1.
In this way, a relatively simple change makes Perl 6 Pod able to do
literate programing for anyone who is interested.
What do you think?
Re: Idea: Literate programing
Carl Mäsak wrote: In this way, a relatively simple change makes Perl 6 Pod able to do literate programing for anyone who is interested. What do you think? That it sounds like a good idea for a sublanguage-extending module. I'm not familiar with those. Are they hard to make? I guess that it is perfectly reasonable to make this a separate module. How would it work? Daniel.
