Re: Amazing Perl 6
· Quoth Larry: ˸ So let’s not make the mistake of thinking something ˸ longer is always less confusing or more official. ⋮ I already have too much problem with people thinking the ⋮ efficiency of a perl construct is related to its length. So you’re saying the Law of Parsimony has its uses… a̲n̲d̲ abuses? ☻ --tom -- ENTIA NON · SVNT M V L T I P L I C A N D A PRÆTER N̳E̳C̳E̳S̳S̳I̳T̳A̳T̳E̳M̳
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
* 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: 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: [RFC] CPAN6 requirements analysis
* 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 (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: 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
* 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: [RFC] CPAN6 requirements analysis
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] wayland76 Let me give the kernel example [20:01] wayland76 kernel-2.6.27.5-117.local.fc10.i686 [20:01] wayland76 package = kernel [20:01] wayland76 version = 2.6.27.5 [20:01] wayland76 release = 117-local [20:01] wayland76 distro = fc10 [20:02] wayland76 arch = i686 [20:02] wayland76 (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
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 clearing
r26959 - docs/Perl6/Spec
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 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: [RFC] CPAN6 requirements analysis
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'm
Re: New CPAN
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: New CPAN
* 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 pictures, business
Re: New CPAN
* 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: Amazing Perl 6
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: [RFC] CPAN6 requirements analysis
* 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 CPAN6.pm is just a layer on top of
Re: Amazing Perl 6
On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com 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: New CPAN
* 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: 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
* 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
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: Amazing Perl 6
On Fri, May 29, 2009 at 10:23 AM, Jon Lang datawea...@gmail.com wrote: On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com 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: Amazing Perl 6
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: New CPAN
* 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: New CPAN
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: Amazing Perl 6
On Fri, May 29, 2009 at 10:56 AM, Austin Hastings austin_hasti...@yahoo.com 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 markjr...@gmail.com
Re: New CPAN
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: [RFC] CPAN6 requirements analysis
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
[RFC] CPAN6 requirements analysis
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
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
Re: Amazing Perl 6
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: Amazing Perl 6
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: New CPAN
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: New CPAN
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: Amazing Perl 6
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 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.
Feature request: Grammar debugging support
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 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: Feature request: Grammar debugging support
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
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.)
[Fwd: Re: New CPAN]
Sorry, didn't do a reply-all on this. ---BeginMessage--- 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 = 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. ---End Message---
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: Feature request: Grammar debugging support
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: Amazing Perl 6
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: 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.
Re: Amazing Perl 6
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: Amazing Perl 6
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
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com 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.
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
* 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: 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.
r26968 - docs/Perl6/Spec
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 la...@wall.org 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 Cundef when you ask -for a value out of range, or the function fails somehow. Perl 6 has -CFailure objects, any of which refers to an unthrown CException object in -C$! and knows whether it has been handled or not. +As in Perl 5, many built-in functions simply return Cundef when you +ask for a value out of range, or the function fails somehow. Perl 6 +has CFailure objects, any of which refers to an unthrown CException +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 CFailure for C.defined or C.true, it causes C$! -to mark the exception as Ihandled; the exception acts as a relatively harmless -undefined value thereafter. Any other use of the CFailure object to -extract a normal value will throw its associated exception immediately. -(The CFailure may, however, be stored in any container whose type -allows the CFailure role to be mixed in.) The C.handled method -returns CFalse on failures that have not been handled. It returns CTrue for -handled exceptions and for all non-CFailure objects. (That is, -it is an CObject method, not a CFailure method. Only CFailure objects -need to store the actual status however; other types just return CTrue.) +to mark the main exception as Ihandled; the exception acts as a +relatively harmless undefined value thereafter. Any other use of the +CFailure object to extract a normal value will throw its associated +exception immediately. (The CFailure may, however, be stored in +any container whose type allows the CFailure role to be mixed in.) +The C.handled method returns CFalse on failures that have not +been handled. It returns CTrue for handled exceptions and for +all non-CFailure objects. (That is, it is an CObject method, +not a CFailure method. Only CFailure objects need to store the +actual status however; other types just return CTrue.) -Because the contextual variable C$! contains all exceptions collected in the -current lexical scope, saying Cdie $! will throw all exceptions, -whether they were handled or not. A bare Cdie/Cfail takes C$! as the -default argument. +The C.handled method is Crw, so you may mark an exception as handled +by assigning CTrue 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 Cdie to throw those -exceptions as a single new exception, which may then be caught with a CCATCH -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 Cdie/Cfail 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 Cdie $! 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 +CCATCH 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 Cfail likewise +moves all C$! exceptions up into C CALLER::$! before +returning the current exception as normal return of a CFailure. + +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 Cdie +to throw those exceptions as a single new exception, which may then +be caught with
r26969 - docs/Perl6/Spec
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 CCATCH 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 Cfail likewise moves all C$! exceptions up into C CALLER::$! before returning the current exception as normal return of a CFailure. @@ -1064,7 +1064,7 @@ to throw those exceptions as a single new exception, which may then be caught with a CCATCH 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 Idon't 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.
Re: Amazing Perl 6
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 http://www.marco.org/83873337 for a large graphic in several fonts. --John
Re: Amazing Perl 6
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 http://www.marco.org/83873337 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: New CPAN
On Fri, May 29, 2009 at 5:37 PM, Daniel Carrera daniel.carr...@theingots.org 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: [RFC] CPAN6 requirements analysis
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 automated fashion * The third bullet adds the
Re: Amazing Perl 6
On Fri, 29 May 2009, Jon Lang wrote: On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com 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-
Information Model manuscript, pt.2
Please see part 2 of my comprehensive explaination of the Perl 6 Information Model, at http://www.dlugosz.com/Perl6/web/lvalues.html. This isn't linked up to my main page yet. I'm taking comments and further discussion here before I make it public. --John
renaming or adding some operators
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
Re: [Fwd: Re: New CPAN]
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-
Re: [RFC] CPAN6 requirements analysis
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: [RFC] CPAN6 requirements analysis
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
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: Amazing Perl 6
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
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-
renaming or adding some operators
On Fri, May 29, 2009 at 6:53 PM, Darren Duncan dar...@darrenduncan.net 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. also andthen orelse 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
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-
Re: Amazing Perl 6
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: 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: [RFC] CPAN6 requirements analysis
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: renaming or adding some operators
On Fri, 29 May 2009, Jon Lang wrote: On Fri, May 29, 2009 at 6:53 PM, Darren Duncan dar...@darrenduncan.net 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: New CPAN
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
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) also andthen orelse 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: renaming or adding some operators
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
renaming or adding some operators
Resending to list On Fri, May 29, 2009 at 9:53 PM, Darren Duncan dar...@darrenduncan.net 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 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
Re: renaming or adding some operators
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: Amazing Perl 6
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
