Re: feather.perl6.nl decommissioned
Oh, how sad. I recall fondly when it was first announced during the heyday of Pugs. I even had an account on there. Thank you for the resource ... And the stroll down memory lane. Brett Sent from my iPhone On Feb 28, 2015, at 9:22 AM, Juerd Waalboer ju...@tnx.nl wrote: Hi all, Just a short message to let you know that the server(s) known as feather will be shut down, permanently, 2015-03-31. All data will be deleted, so if there's anything in your home dir that you still want to have, get it now. If you have any DNS records pointing to any of these addresses, please remove them, because the IP addresses may be repurposed: - 193.200.132.135 - 193.200.132.142 - 193.200.132.146 - 2a02:2308:10::f:1 - 2a02:2308:10::f:2 - 2a02:2308:10::f:3 - 2a02:2308:10::f:* - 2a02:2308:10::f:*:* Feather has been online since 2005. There's a new server, run by Moritz Lenz. If you want access to the new server, read about signing up at http://perlgeek.de/blog-en/perl-6/2014-community-server-live.html I'm sending this to perl6-language, because that's where the original feather announcement was posted. -- Met vriendelijke groet, // Kind regards, // Korajn salutojn, Juerd Waalboer ju...@tnx.nl TNX
Re: The trouble with awesome
On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote: On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark n...@ccl4.org wrote: On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: Realistically, that's not going to happen. The internals of the Perl 5 interpreter are not flexible enough to implement a lot of the features that Perl 6 has that Perl 5 does not. Nicholas Clark * Or Python 2 to Python 3, as far as I can tell as an outsider. why can't we write a brand new perl5 interpreter or a better one based on parrot VM if perl6's strength more than perl5 is just internals of the interpreter? That's what Ponie is/was, right? I think there is a major disconnect with providing a standard interpreter versus providing implementations of language versions. It's less about making /usr/bin/perl (Perl 5) work on Parrot and more about providing a /usr/bin/perl6 on every machine and a chicken in every pot. In otherwords, people are more tied to the actual binary program called 'perl' than anything else. It's not about Perl 5 vs Perl 6, it's about either getting 'perl' as Perl 6ish as possible or introducing a new utility in /usr/bin (hence my earlier suggestion of a name change or reference imlementation/one_true_implementation^tm). How man awks or greps come on a standard system these days? More than one. I would not be against seeing various perls - eperl, zperl, 6perl, qperl, rperl, c++perl, jerl, etc. The way out is to quantify how well /usr/bin/perl implements the Perl 6 formalization - the level to which this is true would define how far Perl 5 is from being Perl 6 compliant. Of course, this would be a non-Parrot implementation. There is nothing saying Perl 6 compliant interpreters have to be written in Parrot; Parrot just provides an abstraction layer that allows there to be a cleaner separation between the compiler/interpreter and some of the complex things that need to be done to enable the features of Perl 6. Just throwing more out there as an outsider, but someone who really wants very badly to have a reason and simple way to start using it for stuff. cheers, Brett it seems Gcc community had a similar discussion about mess of internal. http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
Re: The trouble with awesome
First, yes, Perl 6 is awesome. Everything that's come out as a result
of this effort is awesome. The rest is inline below.
On Fri, May 25, 2012 at 10:32:35AM +0200, Moritz Lenz wrote:
Hallo Parrot,
we are well aware that the documentation for Perl 6 is quite lacking.
Any contributions in that area are greatly appreciated.
Am 23.05.2012 01:35, schrieb Parrot Raiser:
The problem we have is to provide a path for learning 6, that presents a
comprehensible but useful subset of the language to the average user
as soon as possible, while leading the programmer with more complex needs,
(and greater abilities), to the features they need or will appreciate.
The Synopses are comprehensive. They define the language in great depth,
feature by feature, (some features bordering on the pathological, do not
try this at home). Since they specify what the language is to become, not
what is implemented at present, they can be frustrating to follow. Maybe
it's just an effect of advancing age, but it's easy to forget the contents
of a previous synopsis by the time one has read the next. The Perl 6
Tablets have a similar organisation, and hence the same problem.
The synospis were not originally meant as learning material, and they
still are not. It's easy to forget, because they are the most
comprehensive documents out there. But you don't learn Java by reading
the specification either.
Some people do - the kind of folks interested in standards and the
like; just sayin' :)
I haven't recently revisited the book in Rakudo*, but it struck me, last
time I looked, as a powerful deterrent to learning the language. It starts
with the tricky stuff.
It's by design that it starts with tricky stuff, because it's not
directed at somebody who is new to programming. There are a lot of
programmers who know several programming languages already, and who
don't want to read a whole page on how to print 'Hello World', 5 pages
on if-statements and while-loops and another 10 pages explaining lists
and iteration.
At this point, Rakudo mostly appeals to language enthusiasts and early
adopters, so that's quite a good fit.
I have been following Parrot and Perl 6 from the start and in the shadows.
As an extreme Perl 5 enthusiast and general language geek, I can say
that for me (and I might be the only one), from the start calling it
Perl 6 has caused a stumbling block for me. I know, it's
a bikeshed - but a name speaks volumes to me. For one, you have to
automatically explain to someone familiar with Perl 5 (your most
obvious target user base) how it is different. What I suggest below is
superficial, but I believe semantically significant the the branding
of what the project is attempting to accomplish. If anything, my
suggestions below would make it easier for me (as a beginner to Perl
6, but not to Perl 5 or a host of other interesting languages) to join
in the fun.
A lot of cool new languages have surged in popularity since Perl 6 was
started (e.g., Go, Chapel, D, Qore, etc), and so has one particular
old one - Perl 5 (for a lot of good reasons, including the benefits
trickling down from Perl 6).
As an outside observer and long time fan, Perl 6 for me is more of a
formalization of the Perl language as it evolved (greatly influenced
by non-languages, such as Unix itself and natural language goals).
But, the truth is that it's not Perl 5 and it's not meant to replace
it (right?). It's an evolutionary step as the language itself moves
towards a more formalized specification. My point is that while it
started out as a way to improve/formalize Perl 5, it's developed
sufficiently to the point where it is its own language and not the
next version of 'perl'.
In the long run, we need a book for beginners too.
An attempt to write materials for beginners is at.
https://github.com/perlpilot/perl6-docs/
But much more is needed. Please help us with it.
Rebranding this as a new language is one step in the right direction.
Having the language called the same thing as whatever the defacto
reference implementation is would be a nice way to go. But it's more
than just a name to me, it's a signal saying that it's okay to stop
thinking of Perl 6 in terms of Perl 5 - and therefore it won't be
necessary to unlearn what I already know and love; rather, it'll allow
me to tap into the part of my brain that is willing and ready to learn
new languages.
Perhaps simply renaming the specification (OpenPerl?) and allowing the
reference implementation (Rakudo) to take center stage.
The Rakudo site has yet another caveat to the Perl 6 is not Perl 5
baggage:
In the Perl 6 world, we make a distinction between the language
('Perl 6') and specific implementations of the language such as
'Rakudo Perl'.
Seriously, this is a ridiculous and unnecessary qualification (IMO).
The most it should say is something like, Rakudo is the reference
implementation of the OpenPerl (formerly known as Perl 6).
For that
Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 09:57:26AM -0400, Mark J. Reed wrote: On Fri, Oct 15, 2010 at 7:42 AM, Leon Timmermans faw...@gmail.com wrote: Continuations and fibers are incredibly useful and should be easy to implement on parrot/rakudo but they aren't really concurrency. They're a solution to a different problem. I would argue that concurrency isn't a problem to solve; it's one form of solution to the problem of maximizing efficiency. Continuations/fibers and asynchronous event loops are different solutions to the same problem. Pardon my ignorance, but are continuations the same thing as co-routines, or is it more primitive than that? Also, doesn't this really just allow context switching outside of the knowledge of a kernel thread, thus allowing one to implement tasks at the user level? Concurrency can apply to a lot of different things, but the problem is now not only implementing an algorithm concurrently but also using the concurrency available in the hardware efficiently. Brett -- Mark J. Reed markjr...@gmail.com -- B. Estrade estr...@gmail.com
Re: threads?
On Tue, Oct 12, 2010 at 10:43:44PM +0200, Leon Timmermans wrote: On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway dam...@conway.org wrote: The problem is: while most people can agree on what have proved to be unsatisfactory threading models, not many people can seem to agree on what would constititute a satisfactory threading model (or, possibly, models). What we really need is some anecdotal evidence from folks who are actually using threading in real-world situations (in *any* languages). What has worked in practice? What has worked well? What was painful? What was error-prone? And for which kinds of tasks? Most languages either implement concurrency in a way that's not very useful (CPython, CRuby) or implement it in a way that's slightly (Java/C/C++) to totally (perl 5) insane. Erlang is the only language I've worked with whose threads I really like, but sadly it's rather weak at a lot of other things. In general, I don't feel that a shared memory model is a good fit for a high level language. I'm very much a proponent of message passing. Unlike shared memory, it's actually easier to do the right thing than not. Implementing it correctly and efficiently is not easier than doing a shared memory system though in my experience (I'm busy implementing it on top of ithreads; yeah I'm masochist like that). And we also need to stand back a little further and ask: is threading the right approach at all? Do threads work in *any* language? Are there better metaphors? Perhaps we need to think more Perlishly and reframe the entire question. Not: What threading model do we need?, but: What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks? I agree. I would prefer implicit over explicit concurrency wherever possible. I know you're speaking about the Perl interface to concurrency, but you seem to contradict yourself because message passing is explicit whereas shared memory is implicit - two different models, both of which could be used together to implement a pretty flexible system. It'd be a shame to not provide a way to both use threads directly or to fallback to some implicitly concurrent constructs. Brett -- B. Estrade estr...@gmail.com
Re: threads?
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote: Leon Timmermans wrote: For the love of $DEITY, let's please not repeat ithreads! $AMEN! Backwards compatibility is not the major design criterion for Perl 6, so there's no need to recapitulate our own phylogeny here. The problem is: while most people can agree on what have proved to be unsatisfactory threading models, not many people can seem to agree on what would constititute a satisfactory threading model (or, possibly, models). What we really need is some anecdotal evidence from folks who are actually using threading in real-world situations (in *any* languages). What has worked in practice? What has worked well? What was painful? What was error-prone? And for which kinds of tasks? And we also need to stand back a little further and ask: is threading the right approach at all? Do threads work in *any* language? Are there better metaphors? A more general metaphore would be asynchronous tasking, a thread being a long running implicit task. Other issues include memory consistency models, tasking granularity, scheduling, and flexible synchronization options. I am coming from the OpenMP world, so a lot of this falls on the shoulders of the runtime - a clear strength of Perl IMHO. It may be worth someone taking the time to read what the OpenMP spec has to say about tasking as well as exploring tasking support on Chapel, Fortress, X10, and Cilk. PGAS based languages may also offer some inspirations as a potential alternative to threads or tasks. The only scriping language that I know that supports threading natively is Qore. I've mentioned this before. Perl's functional aspects also make it fairly easy to create concurrency without the worry of side effects, but not everyone is lucky enough to have a loosely coupled problem or not need i/o. Now how to distill what's been learned in practice into a Perlish approach? Perhaps we need to think more Perlishly and reframe the entire question. Not: What threading model do we need?, but: What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks? There are something like 12 HPC domains that have been identified, all needing something a little different from the compiler, runtime, and platform - these do not include things for which Perl is often (ab)used. As someone who doesn't (need to) use threading to solve the kinds of problems I work on, I'm well aware that I'm not the right person to help in this design work. We need those poor souls who already suffer under threads to share their tales of constant misery (and their occasional moments of triumph) so we can identify successful patterns of use and steal^Wborg^Wborrow the very best available solutions. Are you sure you couldn't use threading over shared memory? :) Cheers, Brett Damian -- B. Estrade estr...@gmail.com
Re: threads?
On Tue, Oct 12, 2010 at 02:31:26PM +0200, Carl M?sak wrote: Ben (): If perl6 can statically (at compile time) analyse subroutines and methods and determine if they're reentrant, then it could automatically use the lightest weight threads when it knows that the entry sub won't have side effects or alter global data. I'm often at the receiving end of this kind of reply, but... ...to a first approximation, I don't believe such analysis to be possible in Perl 6. Finding out whether something won't have side effects is tricky at best, squeezed in as we are between eval, exuberant dynamism, and the Halting Problem. If one knows what variables are shared, some degree of side effect potential can be determined. But yes, in general, a tough problem. Brett // Carl -- B. Estrade estr...@gmail.com
Re: Parallelism and Concurrency was Re: Ideas for a Object-Belongs-to-Thread threading model
methods. Perl6 has a set of language primitives to support various aspects of concurrency. It is indeed interesting to consider how these map ot vastly difference computation platforms: OpenCl Vs OpenMP Vs Cloud. It deeps a little premature to be defining roles (e.g. RemoteInvocation) without defining the mapping of the core operators to these various models of computation. Dave. -- B. Estrade estr...@gmail.com
Re: Parallelism and Concurrency was Re: Ideas for a Object-Belongs-to-Thread threading model
On Fri, May 14, 2010 at 09:50:21AM -0700, Larry Wall wrote: On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote: ...snip But as you say, this is not a simple problem to solve; our response should not be to punt this to future generations, but to solve it as best as we can, and hope we can make some of the hard decisions right enough to allow future evolution. I am very glad to see several passionate but mostly-rational people thrashing this out here; the future is many-core, and none of us understand the implications of that well enough yet to write off the topic as a bikeshed, or to wish for the good old days of single core. Sure, it should be possible to write a Perl program in a single-threaded mindset, but while certain popular languages cling to the past and try to make single-threadedness a feature, Perl is more about embracing the future and about freeing the programmer from arbitrary restrictions. And as Perl 5 OO demonstrated, sometimes not picking a good default can be just about as damaging as picking the wrong one. The future is indeed multicore - or, rather, *many-core. What this means is that however the hardware jockeys have to strap them together on a single node, we'll be looking at the ability to invoke hundreds (or thousands) of threads on a single SMP machine. Then, inevitably, *someone will want to strap these together into a cluster, thus making message passing an attractive way to glue related threads together over a network. Getting back to the availability of many threads on a single SMP box, issues of data locality and affinity and thread binding will become of critical importance. These issues are closely related to the operating system's capabilities and paging policies, but eventually (hopefully) current, provably beneficial strategies will be available on most platforms. Brett Note also that the fundamental difficulty with doing threading in Perl 5 is not the exact model chosen, but rather that the fundamental underpinnings of locality were (for various historical reasons) poorly designed/evolved in the first place, so we ended up with far too much information having to be managed outside of its proper scope, for many different definitions of scope. This has been one of the secret sauces of the Perl 6 redesign, to hang every piece of information on the peg where it belongs, and not somewhere else. And that is why threading of *any* kind will work much better in Perl 6. Larry -- B. Estrade estr...@gmail.com
Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
On Fri, May 14, 2010 at 06:03:46PM +0100, nigelsande...@btconnect.com wrote: On Fri, 14 May 2010 15:05:44 +0100, B. Estrade estr...@gmail.com wrote: On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com wrote: On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl +nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com wrote: The support of threading should be completely optional. The threading support should not be active by default. I'd like to understand why you say that? Two reasons I can think of: 1: Performance. The perception that adding support for threading will impact the performance of non-threaded applications. I think that perhaps he's thinking of overhead associated with spawning and managing threads - even just one...so, if only 1 thread bound to a single core is desired, then I think this is a reasonable and natural thing to want. Maybe the core binding on an SMP box would be the more challenging issue to tackle. Then, again, this is the role of the OS and libnuma (on Linux, anyway)... Hm. Every process gets one thread by default. There is no overhead there. I am not sure I undestand the context under which one process gets 1 thread. And spawning 1000 (do nothing but sleep) threads takes 0.171 seconds? Assuming this is a latency cost per 1000 threads, this could substantially impact an application. The goal is always to minimize overhead, so this is where I am coming from. And there's overhead not just form spawning, but from anything that requires some number of threads be synchronized - barriers, critical sections, atomic updates to memory, etc. And depending on the consistency model one enforces, there could also be implicit calls for each thread to flush out its cache in order to ensure the most up to date version of a shared object is seen by all. So if one is running a single process only, I think is reasonable to be concerned that it not be subject to this overhead unnecessarily. An additional concern related to not just overhead, would be data locality issues - you don't want your *single process migrating do difference cores where it's data would have to follow. The OS needs to know it is a distinct process and not to be regarded also as a thread (I would think..) Brett Buk. -- B. Estrade estr...@gmail.com
Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com wrote: On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl +nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com wrote: The support of threading should be completely optional. The threading support should not be active by default. I'd like to understand why you say that? Two reasons I can think of: 1: Performance. The perception that adding support for threading will impact the performance of non-threaded applications. I think that perhaps he's thinking of overhead associated with spawning and managing threads - even just one...so, if only 1 thread bound to a single core is desired, then I think this is a reasonable and natural thing to want. Maybe the core binding on an SMP box would be the more challenging issue to tackle. Then, again, this is the role of the OS and libnuma (on Linux, anyway)... If you don't use threads, the presence of the ability to use them if you need to will not affect you at all. The presence of Unicode support will have a far more measurable affect upon performance. And it will be unavoidable. 2: Complexity. The perception that the presence of threading support will complicate non-threaded apps. Again, the presence of Unicode support adds far more complexity to the mix that that for threading. But with either, if you choose not to use it, you shouldn't even be aware of its presence. Do you believe that Unicode support should be dropped? See also http://www.ibm.com/developerworks/linux/library/l-posix1.html and fathom why Threads are fun reads to me like how a drug dealer lures you to at least try it once. To me, that reads far more like some of the advocacy I've seen for Giving Blood. If your squeamish, get a friend to distract you, or listen to some good music whilst they put the needle in. Rather fork-join! For platforms where fork is native, it doesn't go away just because threads support is present. (Do Perl_6 hyper-operators need pthreads?) Buk. -- B. Estrade estr...@gmail.com
Re: Second Version of Ideas for a Object-Belongs-to-Thread threading model
I might have some more to say about any threading model later, but for now I wanted to make everyone aware of a scripting language that is truly multi-threaded - you may want to check it out. Some of it's syntax is Perlish, whereas some is not - the point is that it is supposed to scale on SMP machines. It's called Qore - http://www.qore.org. I maintain the FreeBSD port for it and have played with it quite a bit. It's a nice interface - though traditional. And it does seem to scale pretty well. If the debate is shared memory threads vs message passing (ala Erlang), then I would suggest that they are not mutually exclusive (pun intended) and could actually provide some complementary benefits if deployed on a large scale distributed memory machine composed of SMP nodes. In otherwords, a mixed mode style of distributed programming where the SMP threads run on each node and the MP is used to connect these disjoint processes over the network. I know that the SMP threads is best implemented with a low level runtime (maybe even using a Qore backend?), but I have no idea how one might facilitate Erlang style remote processes - still, I believe offering both styles would be totally awesome :^). Cheers, Brett On Wed, May 12, 2010 at 09:50:19AM -0300, Daniel Ruoso wrote: Em Ter, 2010-05-11 ??s 21:45 -0300, Daniel Ruoso escreveu: The threading model topic still needs lots of thinking, so I decided to try out some ideas. After BrowserUK feedback and some more reading (including http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from there on, I decided to rewrite that ideas in a bit different model, but still with the same spirit. 0 - The idea is inspired by Erlang and the IO Language. Additionally to OS threads there are the Coroutine Groups. 1 - No memory is shared between Coroutine Groups, so no locking is necessary. 2 - A value and a coroutine always belong to a Coroutine Group, which should be assigned to a single OS thread, thus naturally implementing synchronized access to data. 3 - The interpreter implements a scheduler, which will pick one of the waiting coroutines that belong to the groups assined to the current thread. The scheduler may also suspend a coroutine in order to implement time-sharing. The scheduler should support blocking states in the coroutines. 4 - When comparing to Perl 5, each coroutine is an ithread, but memory is shared between all the coroutines in the same group, given that they will always run in the same OS thread. 5 - When a coroutine group is created, it is assigned to one OS thread, the interpreter might decide to create new OS threads as necessary, it might optionally implement one OS thread per coroutine group. 6 - In order to implement inter-coroutine-group communication, there are: 6.1 - A MessageQueue works just like an Unix Pipe, it looks like a slurpy array. It has a configurable buffer size and coroutines might block when trying to read and/or write to it. 6.2 - A RemoteInvocation is an object that has a identifier, a capture (which might, optionally, point to a MessageQueue as input) and another MessageQueue to be used as output. New coroutines are created in the target group to execute that invocation. 6.3 - An InvocationQueue is a special type of MessageQueue that accepts only RemoteInvocation objects. 6.4 - A RemoteValue is an object that proxies requests to another coroutine group through a RemoteInvocation. 7 - The coroutine group boundary is drawn by language constructs such as async, the feed operator, junctions, hyper operators. 8 - A value might have its ownership transferred to another group if it can be detected that this value is in use only for that invocation or return value, in order to reduce the amount of RemoteInvocations. 9 - A value might do a special ThreadSafe role if it is thread-safe (such as implementing bindings to thread-safe native libraries) In which case it is sent as-is to a different group. 10 - A value might do a special ThreadCloneable role if it should be cloned instead of being proxied through a RemoteValue when sent in a RemoteInvocation. 11 - The MessageQueue notifies the scheduler whenever new data is available in that queue so the target coroutine might be raised. 12 - Exception handling gets a bit hairy, since exceptions might only be raised at the calling scope when the value is consumed. 13 - List assignment and Sink context might result in synchronized behavior. comments are appreciated... daniel -- B. Estrade estr...@gmail.com
Re: Logo considerations
On Tue, Mar 24, 2009 at 09:16:01AM -0700, Larry Wall wrote: http://www.wall.org/~larry/camelia.pdf I gotta say, that these are the first 2 that I even remotely like. I especially like how the P and the 6 are in the wings. I think what appeals to me is that they are simple, easy to look at, and not overly complicated with meaning or cleverness. my $0.02. Brett -- B. Estrade http://www.loni.org
Re: 6PAN idea
On Wed, Dec 17, 2008 at 10:19:07AM -0300, Daniel Ruoso wrote: Em Qua, 2008-12-17 ??s 23:35 +1100, Timothy S. Nelson escreveu: On Wed, 17 Dec 2008, Daniel Ruoso wrote: Em Qua, 2008-12-17 ??s 15:00 +1100, Timothy S. Nelson escreveu: My basic assumption is that there's going to be some kind of packaging system written around 6PAN. Please take a look in some notes I've written some time ago: http://www.perlfoundation.org/perl6/index.cgi?DistributionFormat I guess I should also say that I'm assuming everyone has at least a vague familiarity with this: http://svn.pugscode.org/pugs/docs/Perl6/Spec/S22-cpan.pod In particular, I'm not sure that Daniel's ideas align with the Draft S22; I'm hoping Daniel will take a moment to see if they align. Indeed, for some reason I missed that document. But it's not entirely unaligned. The major difference seems to be having different packages for source and binary (or source and installable, as in S22). S22 mentions the difference, but doesn't split them in different packages. The most important argument, IMHO, to have them as different packages is to allow a binary/installable distribution without the need to recompile every module when installing. This should help when you have a target OS that is installed in several machines, then you can re-use the binary/installable package repository for that specific OS/version. It also allows one source package to generate different binary packages (for instance, having scripts, libs and docs splitted), and makes it easier to do an uninstall, because a binary/installable package would have a fixed list of files. One thing that is mostly aligned, is the idea that the building of the package is external to it, no more Makefile.PL or Build.PL. The package only lists metadata of which type of things it has, and the running system should realize how to build and install them. Althought, in my notes, I expanded the meaning of it a bit more. In summary, I think inheriting most of the concepts from Debian is something almost consensual, and there's much alignment in both documents in that respect. It would probably make sense to refactor S22 into a more spec-like document. I am sticking my neck out here, but don't forget that there are a multitude of package management systems out there, including FreeBSD's Ports /and/ Packages. A packages is probably more in line with where this discussion seems to be heading, but I wanted to mention both. Packages and Ports contain *a lot* of Perl modules, and although I have zero experience actually putting a Perl module into Ports or creating a Package (and dealing with the dependencies), the more easily this process could be automated against a 6PAN module, the better. Cheers, Brett daniel
