Licenses on CPAN

(This is a carryover from the p5p list.) I do not think we should encourage ANY specific licensing terms for CPAN content, except that it should be an open source license of some kind. Bradley Kuhn wrote: >However, the Artistic license isn't legally sound enough to hold water >as a free software

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

So I thought of a serious problem with part of this RFC. The bit about using indirect object syntax... > Instead, this RFC proposes that C's operation become much more > fundamental, simply translating functions via the existing indirect > object syntax: > >tie Transaction %t

Re: RFC 39 (v3) Perl should have a print operator

On Fri, Sep 08, 2000 at 03:31:54PM -0400, Chaim Frenkel wrote: > Could someone enlighten this poor soul and tell me what I _can_ do > with an error return from a print or close? Surely you'd want to know if your output can't be output (print) and for close, take a look at this: http://ww

perl 5.6.0 stdlib stats

In an effort to avoid organising YAPC::Europe, I went through the 126 modules with documentation in Perl 5.6.0's lib/ directory and documented what kind of interface they provided. Not all of them follow perlstyle, and I think perl6's standard libraries should. But anyway, here goes... BTW I'm no

Re: perl 5.6.0 stdlib stats

Leon Brocard writes: > In an effort to avoid organising YAPC::Europe, I went through the 126 > modules with documentation in Perl 5.6.0's lib/ directory and > documented what kind of interface they provided. Not all of them > follow perlstyle, and I think perl6's standard libraries should. But > a

Re: The Future - grim.

Thanks for that grim view, Alan. I've been looking around for someone to act as the Devil's Advocate and say what might go wrong, so I was happy to see this. Your message seems to have two points: that the current brainstorming phase is so chaotic that it's hard to see how anything good can come

Project documents

I know it seems at first like a lot of mindless paperwork, but it will serve to make us agree on what we're doing and how we're going to do it. I resisted all this at first, too, but the chaos of this brainstorming phase will kill us if it persists into design and implementation. I've got some p

Re: The Future - grim.

On Sun, 10 Sep 2000, Alan Burlison wrote: > Unfortunately the greatest volume on the various p6 sublists tends to be > coming from the least experienced people. The comments based on common > sense and long experience tend to be lost in the hubbub of uninformed > noise. I think the chaotic bra

Re: The Future - grim.

Andy Dougherty wrote: > I think the chaotic brainstorming on -language has been very necessary. We > need a forum that encourages new radical ideas. Sure, most of them > probably won't pan out or prove worthwhile, but I'm hopeful that there > will ultimately be a few new things in perl6 that gr

Re: RFCs for thread models

--- Chaim Frenkel <[EMAIL PROTECTED]> wrote: > > "SWM" == Steven W McDougall <[EMAIL PROTECTED]> > writes: > > SWM> If you actually compile a Perl program, like > > SWM> $a = $b > > SWM> and then look at the op tree, you won't find the > symbol "$b", or "b" > SWM> anywhere in it. The

one question about vtbls

I have one question about vtbls that I have not been able to figure out an answer to: How does using a vtbl get rid of the switch(sv->sv_flags) with multi-valued scalars running around? That is, how does one write a vtbl function that can cope with the perl6 equivalent of perl5's sv_setiv(s

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

Michael G Schwern wrote: > > So I thought of a serious problem with part of this RFC. The bit > about using indirect object syntax... > > There's a nasty inconsistency there. Consider the following. > > package Foo; > sub lock { > flock $_[0], LOCK_EX; > } > lock $trans

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

Michael Fowler wrote: > > > =head3 Merge C, C, and C into C > > I'm not so sure about this. I'm not either anymore. This will probably be removed from the next version. > > Instead, this RFC proposes that C's operation become much more > > fundamental, simply translating functions via the exist

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

I *still* think it should be "unmerge"! ;-) Damian

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> I *still* think it should be "unmerge"! ;-) Hrmpf. It should be reshape. (Which would be its own inverse and saves a keyword.) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED]

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

Chaim Frenkel wrote: > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes: > > DC> I *still* think it should be "unmerge"! ;-) > > Hrmpf. It should be reshape. > > (Which would be its own inverse and saves a keyword.) > reshape() has already been proposed (RFC 148): http://dev.perl.org/rf

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

Jeremy Howard wrote: > However I like the Numeric Python reshape() semantics better: > > http://starship.python.net/~da/numtut/array.html Is that in any significant way different from PDL's reshape? http://pdl.sourceforge.net/PDLdocs/Core.html#reshape > PS: How does one pronounce 'hrmpf'?

Re: RFCs for thread models

> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: >> Now where >> sub recursive() { my $a :shared; ; return >> recursive() } >> would put $a or even which $a is meant, is left as an >> excersize >> for someone brighter than me. BS> %P6-E-MEANINGLESS, "my $a : shared" is a meaningless

Re: one question about vtbls

> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: BS> I have one question about vtbls that I have not been able BS> to figure out an answer to: BS> How does using a vtbl get rid of the switch(sv->sv_flags) BS> with multi-valued scalars running around? That is, how does BS> one write a v

Re: Licenses on CPAN

>The AL is not known to be legally a free software license ^ I was unaware that the Courts had ever defined that term, nor that they had adjudged it applicable to *any* licence that's out there. If you know otherwise, please explain. I'm

Re: An attempt to be constructive

At 19:02 -0600 2000.09.10, Tom Christiansen wrote: >>In more of an attempt to be constructive, what if we identify the key >>aspects to the AL that people like and then, for Perl 6, find legal >>counsel to review and help draft a precise legal license with those key >>features? > >Here's what I li

Re: Licenses on CPAN

At 16:42 -0700 2000.09.10, Russ Allbery wrote: >Chris Nandor <[EMAIL PROTECTED]> writes: > >> However, I feel the need to emphasize that licenses are not necessarily >> legal documents. > >I think this is a key point of disagreement. If the license is not a >legal document, it's not a *license*;

Re: Licenses on CPAN

>No, it is absolutely not patently false. It's entirely accurate. Perhaps >you've missed what the FSF says about the Artistic License (used by >itself), an opinion that I've heard is backed up by their legal counsel: > The Artistic license. > We cannot say that this is a free software lic

Re: Licenses on CPAN

>That is the opinion of the FSF (and their legal counsel, who I'm not >inclined to trust anyway), Gee, Christ, whyever wouldn't you be quick to trust the word of someone with the temerity to claim that where we've previously used the word "encumbered", we must now instead use the word "free"? Af

Re: Licenses on CPAN

>Like it or not, we do have to deal with the law. I see no evidence of that. --tom

Re: An attempt to be constructive

>In more of an attempt to be constructive, what if we identify the key >aspects to the AL that people like and then, for Perl 6, find legal >counsel to review and help draft a precise legal license with those key >features? Here's what I like: *LARRY AND LARRY ALONE* gets to say what happens to t

Re: The Future - grim.

Nathan Wiger wrote: > Well, as I suggested once before (but it was probably premature at the > time), I think people should start retracting RFC's that they don't > think are wins, or that the general consensus is against. I'm going to > retract 3 of my own today. Good for you. That is a very c

RFC - Prototype RFC Implementations - Seperating the men from the boys.

I've an idea to cut down and weed out the huge number of RFCs we have. Its written out below. =pod =head1 TITLE Prototype implementations for RFCs. =head1 VERSION Maintainer: Michael G Schwern <[EMAIL PROTECTED]> Date: Mon Sep 4 21:11:56 EDT 2000 Version:1 Mailing Lis

Re: The Future - grim.

On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote: > I don't believe in magic. I'm an engineer by profession, not an > astrologer. However, I will predict endless arguments when some of the > less than coherent proposals are rejected. The RFC process was intended to bring out both

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: MGS> =head1 ABSTRACT MGS> RFCs should be followed by a prototype implementation of their MGS> proposal which provides something concrete to develop the RFC from and MGS> helps to avoid endless discussion. At this point, I think this i

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

On Mon, Sep 11, 2000 at 12:57:47AM -0400, Chaim Frenkel wrote: > > "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: > > MGS> =head1 ABSTRACT > > MGS> RFCs should be followed by a prototype implementation of their > MGS> proposal which provides something concrete to develop the RFC from

Re: New Perl rewrite - embedded Perl

At 09:40 PM 9/9/00 +0100, Matthew Gillman wrote: >Basically, my comment is that a lot of commercial applications seem to be >mixing and matching languages together (like C++ and Perl), so it would be >really great if the issues such as Purify errors for embedded Perl were >addressed (I realise

Re: RFCs for thread models

At 10:26 PM 9/9/00 -0400, Steven W McDougall wrote: >RFC 178 proposes a shared data model for Perl6 threads. In a shared >data model >- globals are shared unless localized >- file-scoped lexicals are shared unless the thread recompiles the > file >- block scoped lexicals may be shared by > - p

Re: A tentative list of vtable functions

At 07:58 PM 9/9/00 +, Nick Ing-Simmons wrote: >Ken Fox <[EMAIL PROTECTED]> writes: > >Short > >circuiting should not be customizable by each type for example. > >We are already having that argument^Wdiscussion elsewhere ;-) > >But I agree variable vtables are not the place for that. As do I,

Re: RFC 178 (v2) Lightweight Threads

At 09:43 PM 9/9/00 -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> Right, but databases are all dealing with mainly disk access. A 1ms lock >DS> operation's no big deal when it takes 100ms to fetch the data being >locked. >DS> A 1ms lock operation *is*

Re: RFC 178 (v2) Lightweight Threads

Chaim Frenkel wrote: > Please elaborate. How deep do you go? $h{a}{b}{c}{d}{e}{f} This is my last mail on this subject - it is a half-assed idea, and this whole thread is becoming too tedious for words. Actually, I'd extend that to the whole p6 process. In fact I think I'll just unsubscribe.

Re: The Future - grim.

Nathan Torkington wrote: > Thanks for that grim view, Alan. I've been looking around for someone > to act as the Devil's Advocate and say what might go wrong, so I was > happy to see this. Glad to be of service ;-) > I agree that the current brainstorming is chaotic. I feel like that's > the

Re: The Future - grim.

> > What we're doing about that: > > * pushing the output through Larry > > [Yes, this addresses only part of the problem. Any suggestions for > > other ways to solve this?] > > The RFC mountain is way, way too high to be climbed by just one person, > let alone the output of the various mailing

Re: Project documents

risks.html 1. Minimized by another culling phase after the RFC freeze 2. Minimized by the sub-working groups. You will notice that the discussions on the sub-groups are quite localized in people and discussions are limited. Some groups are noisy but what you are witnessing is an ongoing

The Future - grim.

Nathan Torkington wrote: > We're lucky to have the experience of Chip to draw upon (he's already > blazed some of the trails we'll be turning into fully-paved four-lane > highways with Waffle Houses and Conocos), as well as a lot of people > who've worked with perl5. They know what works and wha

Re: Licenses on CPAN

At 16:24 -0700 2000.09.10, Russ Allbery wrote: >Then I guess we'll have to agree to disagree, as in my opinion you didn't >prove anything, I absolutely proved that the software licensed AL-only is known to be free software. I also accept that some, maybe many, people think it is not. But that do

Re: An attempt to be constructive

At 16:32 -0700 2000.09.10, Russ Allbery wrote: >In more of an attempt to be constructive, what if we identify the key >aspects to the AL that people like and then, for Perl 6, find legal >counsel to review and help draft a precise legal license with those key >features? I think that's a good idea

Re: Licenses on CPAN

Chris Nandor <[EMAIL PROTECTED]> writes: > However, I feel the need to emphasize that licenses are not necessarily > legal documents. I think this is a key point of disagreement. If the license is not a legal document, it's not a *license*; it may be a statement of permission or something else

Re: Licenses on CPAN

Chris Nandor <[EMAIL PROTECTED]> writes: > I do not think we should encourage ANY specific licensing terms for CPAN > content, except that it should be an open source license of some kind. I agree with this as a statement of general "official" policy; however, I'll certainly encourage people who

Re: Licenses on CPAN

At 14:05 -0700 2000.09.10, Russ Allbery wrote: >Chris Nandor <[EMAIL PROTECTED]> writes: > >> I do not think we should encourage ANY specific licensing terms for CPAN >> content, except that it should be an open source license of some kind. > >I agree with this as a statement of general "official"

Re: Licenses on CPAN

It seems pretty clear from this response, Chris, that you're not actually interested in discussing licensing. That's certainly your perogative; I don't particularly enjoy having to work out the legal intricacies either. You are instead interested in discussing the fact that you dislike the law, t

Re: Licenses on CPAN

At 15:31 -0700 2000.09.10, Russ Allbery wrote: >It seems pretty clear from this response, Chris, that you're not actually >interested in discussing licensing. That's not true. >You are instead interested in discussing the fact that you dislike the >law, the way the law is applied and interprete

Re: Licenses on CPAN

Chris Nandor <[EMAIL PROTECTED]> writes: > Well, if you want to bring up specifics, you can. But you (and Bradley) > said some things that were provably false, and I proved them false. Then I guess we'll have to agree to disagree, as in my opinion you didn't prove anything, simply asserted that

Re: Licenses on CPAN

At 19:10 -0400 2000.09.10, Chris Nandor wrote: >No, I am interested in both. The fact that you didn't understand that >could be my fault, but I think I made it clear enough. You know, I think I want to make this more clear. I am interested in how various licenses will be interpreted legally. I

An attempt to be constructive

I'm sorry about my last two messages; they may have helped me vent my spleen, but they weren't accomplishing anything productive. In more of an attempt to be constructive, what if we identify the key aspects to the AL that people like and then, for Perl 6, find legal counsel to review and help dr

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

On Sun, Sep 10, 2000 at 04:00:30PM -0700, Nathan Wiger wrote: > > Normally, the Foo::lock() subroutine in the current package will be > > called. However, if %trans is a tied hash to a class which defines a > > lock() method (let's call it Lock::Ness) the meaning of the program > > radically and u

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

On Mon, Sep 11, 2000 at 01:31:39PM +1100, Damian Conway wrote: > Or, better still, pass a reference to the actual variable being tied. Good idea. > Also notice that I suggested the TIE be called as a method, > so that it can be inherited if necessary (maybe you had that idea > already???) The

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

Michael G Schwern wrote: > > >sub lock { print "Hello!" } > >$trans = new Lock::Ness; > >lock $trans; # $trans->lock > > That's not right. You're correct. Sorry for not double-checking my examples. > the same reasons I've already pointed out. You don't want adding a > method to

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

> > Also notice that I suggested the TIE be called as a method, > > so that it can be inherited if necessary (maybe you had that idea > > already???) > > The tie *can* currently be inherited. Yes, I was aware. It's just that you wrote: >tie Some::Class $foo, @args;

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

On Sun, Sep 10, 2000 at 09:22:39PM -0700, Nathan Wiger wrote: > Regardless of my huge error above, this doesn't change the fact that > this is exactly what tie() does currently in Perl 5. That is: > >tie @a, 'Matrix'; >push @a, $stuff; > > Now changes the meaning of push() in the current

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

> > It may make sense to pass a leading argument to TIE which is the type > > of variable being tied. > > > > tie Some::Class $foo, @args; > > > > would produce: > > > > TIE('SCALAR', 'Some::Class', @args); Or, better still, pass a reference to the actual variab

Re: RFC 127 (v1) Sane resolution to large function returns

Chaim Frenkel wrote: > > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes: > > GL> Chaim Frenkel wrote: > >> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) > >> > >> Actually, looking at it like that makes it an ugly situation. The 'new' > >> expectation would be to have it

Re: Beefier prototypes (was Re: Multiple for loop variables)

> >> my_while { pred() } { # don't gimme no Tcl flac. > >> ... > >> } # no semicolon needed here! > > DC> Just added to the RFC :-) > > How would the parser handle this? Some '}' would need ';' some don't. The trailing C<&> parameter specification tells the parser that there

RE: RFC 199 (v2) Another question...

> Would it be possible to expand the function prototypes so that a function > could be defined to take a loop block instead of a code block? I'm not sure what you mean here. Damian

Re: RFC 114 (v2) Perl resource configuration

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> but that is the user's to set. PERL_PRELOAD TC> is there for the user to unset. >> allows the admin to globally >> set (in the system shell rc file) the rc files that perl will load. TC> And what sorts of things might the admin car

Re: $a in @b

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> grep { $_ == 1 } 1..1_000_000 >> grep doesn't short-circuit. TC> I never did figure out why "last" {w,sh,c}ouldn't be made to do TC> that very thing. Hey, I suggested that a while ago, but Randal shot it down. Something about the bl

Re: $a in @b

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> I would propose that the C operation should short-circuit if the DC> block throws an exception, with the value of the expection determining DC> whether the final invocation of the block should accept the element it DC> was filtering: Wh

Re: $a in @b

> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes: > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >>> grep { $_ == 1 } 1..1_000_000 >>> grep doesn't short-circuit. TC> I never did figure out why "last" {w,sh,c}ouldn't be made to do TC> that very thing. Chaim> Hey, I suggeste

Re: $a in @b

> Quantum::Superpositions provides this in a more flexible way by adding the > 'any' and 'all' keywords. > > Superpositions.pm> > > One of Damian Conway's many promised RFCs will cover in

Re: RFC 179 (v1) More functions from set theory to manipulate arrays

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> But, Do you really think that all these ingenuities, to not use another >> term, are really natural and easy to understand to novice programmers ? TC> Until you start thinking of terms of hashes, you aren't thinking TC> in Perl. It s

Re: Beefier prototypes (was Re: Multiple for loop variables)

On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote: >PS> Yes, please. I view the flattening of lists as a feature, not a bug, and >PS> it has made Perl a lot easier to understand IMHO. > >I view it as a mis-feature. I'm sorry to disagree. But flattening of argument lists is one of those things

Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence

Nathan Wiger wrote: > Bart Lateur wrote: > > Why interpolate "$obj->method" and not "Class->method"? > > This is a decent point worth considering. > > I think another way to look at it which is more accurrate is that -> is > special in many cases already: > >/$foo->{blah}/ # -> special