Re: Parrot 2.10.1 released!
On Thu, 18 Nov 2010, Gerd Pokorra wrote: > On behalf of the Parrot team, I'm proud to announce Parrot 2.10.1 > "(bugfix release)." Parrot (http://parrot.org/) is a virtual machine > aimed at running all dynamic languages. > > Parrot 2.10.1 is available on Parrot's FTP site, or by following the > download instructions at http://parrot.org/download. > > New in 2.10.1 > - This is a bugfix release to run "perl Configure.pl" without noise > from git_describe and SHA1 Thank you for doing this. Incidentally, the actual problem wasn't the noise (for example there's been similar @noinline@ noise for a while). The serious problem is that (if the user has git installed) Configure.pl exits with an error status. This will stop various build tools, such as ones that one might use to make a .deb or .rpm package. Hence building packages is likely to be broken. Unfortunately, there still seems to be an error in the package (some confusion over 2_10_0 vs. 2_10_1). It needs my patch in TT #1856 in order to build. Even after that, rakudo is still unhappy and won't build off an installed parrot-2.10.1 built from the tarball. See TT #1852 for the error messages. I don't know whether rakudo is querying the wrong key for a release or parrot is not supplying the correct key, but it ought to be straightened out. -- Andy Dougherty dough...@lafayette.edu
Re: Tying & Overloading
On Wed, 25 Apr 2001, James Mastros wrote: > I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY > PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? It might be prudent to avoid rushing to judgment until the bigger picture becomes clearer. We have yet to see what changes might be in store for how, when, and why we'll be using method calls in perl6 vs. perl5. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Sun, 15 Apr 2001, David Grove wrote: > Add Solaris 8 1/01 to the list of OS's that have > completely rejected 5.6, as I discovered last night, This is quite unfair. Sun has supported perl nicely and Sun employees have actively contributed to 5.6.0 and beyond. That Solaris 8 included 5.005_03 and not 5.6.0 is due to a range of factors, including the very long lead time for *any* such bundling to be developed and tested. The timescales of corporations like Sun are not the same as those commonly encountered in the open software arena. It is quite possible that 5.6.1 will be included in future versions of Solaris. > corporate interests now in firm control of Perl 5. I don't think this is accurate either. I certainly don't see any evidence of Jarkko pressing any particular corporate interest. Nor is this list the appropriate place to make such charges. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Thu, 12 Apr 2001, Dave Storrs wrote: > We could then just add a -7 flag. That's not necessarily bad; > Perl 7 will probably face the same issue...it needs to be able to eat Perl > [567] code without barfing, but it needs to know what it's getting. Also, > the flag would be a good choice in that it's very human-readable. More readable than the already-supporrted -M7 ? Do we *really* need a new command-line option that is one character shorter than an existing command-line option that can do exactly the same thing? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote:
> >I'm still trying to figure out why the flag needs to change. What's wrong
> >with -e? It seems perfectly serviceable.
>
> Because Larry said that by default Perl 6 would assume that its input was
> in Perl 5...? So we need a way to tell it that it isn't.
perl -M6 -e ...
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: [ -e vs. --cmd vs. -6] > Whatever we come up with, let's figure out how to avoid having to change it > the next time we change Perl. I don't think this is getting us anywhere useful. What happens if perl7 is sufficiently different from perl6 in such a way that you could imagine needing to distinguish for a one-liner between perl6 and perl7? This would be exactly the perl5/perl6 problem we face now. And, I hasten to point out, this is very similar to the perl4/perl5 problem we faced some time ago. Like most challenging design issues, there is probably no single ideal solution, and it's rather pointless to endlessly debate it in a vacuum. One needs to consider each issue individually against the larger backdrop of the goal of being mostly compatible. Perl's history is rich with examples of both keeping and breaking compatibility. Perl6 is likely to continue in that tradition. Let's leave -e alone for now and worry about handling specific incompatibilities when we in fact have some specific incompatibilities to worry about. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Michael G Schwern wrote: > One-liners run on a Perl 6 binary should just be Perl 6 code. Do we > really have to worry about backwards compatibility with one liners? [ . . . ] > Hmm... programs that have perl one-liners inside them might be > troublesome. Yes, precisely. I often have one-liners embedded in larger shell scripts. Most of those survived the perl4->perl5 transition intact. I'd hope the same can be said for the perl5->perl6 transition. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Fri, 16 Feb 2001, Stephen P. Potter wrote:
> How about a perl6-install list? This discussion really doesn't fit into
> any of the current top level lists, so we can make a new top level and
> cover other installation issues as well. Ask, can you make this, if the
> name is agreeable.
There already is a perl6-build list. Perhaps you can just use that?
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Tue, 13 Feb 2001, Branden wrote: > Hello. > > I'm working on the PDD for par. I would like to propose a standard directory > structure for the files inside the archive, but I realise this depends > greatly upon the directory structure of Perl itself. > > How does Perl 5 manage its directory structure? See the INSTALL file supplied with Perl5.6.0 or later. If you have any questions after that, let me know and I'll try to answer them. > in. And Perl 5's directory structure is rather clumsy, I think we should set > platform-independent conventions for that too, where it's possible. You might want to build on top of some of the ideas hinted at in perl-5.6.0's "installstyle" Configure variable. See Porting/Glossary for the full definition. The directory structure may also be affected by the goal of allowing the simultaneous installation of multiple versions of modules. (I don't recall the relevant RFC offhand, but I think there's was also a similar idea in Larry's Atlanta speech.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Sat, 10 Feb 2001, Branden wrote: > Another advantage I see on tar and gzip is that they are used by GNU, so I'm > pretty sure there probably wouldn't be any licensing issues, and I'm not > quite sure .zip doesn't use LZW, the same compression method of GIF... Zip uses the same compress method as gzip. In fact gzip's author, Jean-loup Gailly, is also a prominent contributor to InfoZip -- the group behind Zip and Unzip. I don't see any licensing advantage to gzip over zip or vice-versa. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Simon Cozens wrote: > God gave man two ears and one tongue so that we listen twice as much as > we speak. > -- Arab proverb ...but alas on the net we have 10 fingers to type but only 2 eyes to read. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Casey R. Tweten wrote: > > Not that there needs to be any discussion on this but IMHO things that > can reasonably live outside the core should. I heard somewhere that > most people think this way too. This is why there hasn't been much discussion on it -- there's not really much to discuss. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Bart Lateur wrote:
> On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:
>
> >Why the urge to move it out of the core? Should perl6 be like Python,
> >where you first need to do a gazillion imports before you can do anything
> >useful? Say goodbye to quick one-liners then.
>
> It doesn't have to be like that. Functions that are not in the core can
> still be automatically loaded, but only if your code actually uses them.
> That could make the perl kernel a lot smaller than it is now, and
> hopefully, make it load faster.
This is a persistent myth. Moving such functions out of the core may
indeed make the perl kernel cleaner, but I seriously doubt it will make
it "a lot smaller" or have any significant impact on load time. You
can try it and see with perl5, or search the perl5-porters archives for
my previous reports on the subject.
For example, removing time() from the perl5 core means excising the
following from pp_sys.c:
PP(pp_time)
{
djSP; dTARGET;
XPUSHi( time(Null(Time_t*)) );
RETURN;
}
and replacing it by the appropriate auto-loading glue. This is not a big
space savings.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Why does atan2 take 2 arguments?
On Tue, 17 Oct 2000, Jorg Ziefle wrote:
> I wondered since quite a time why atan2 takes 2 arguments.
Because otherwise it would be atan1? :-)
Two arguments allows the function to gracefully handle infinite slope.
It also allows the function to unambiguously assign the correct quadrant.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent toRFC #0101)
On Wed, 27 Sep 2000, Nathan Wiger wrote: > Russ Allbery wrote: > > > > I've found the use of use English in code I had to maintain to be annoying > > and unhelpful, and to actually degrade the maintainability of the code > Y'know, I couldn't have said this better myself. :-) I've always felt > that "use English" was a waste of time and effort, a bandaid trying to > act as a tourniquet. Well, I think it has some limited uses. Remember that not everyone programs in perl all day everyday. Many competent people are only occasionally perl programmers. I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $< $> $( and $). I'd have to look them up. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 208 (v2) crypt() default salt
On Thu, 21 Sep 2000, Mark-Jason Dominus wrote: > And the problem you describe is not really a problem. There has never > been any guarantee that a program would produce the same sequence of > random numbers after a change to the Perl binary. > random numbers after a change to the Perl binary. More recent > versions of Perl use random() or drand48() if they are available, Well, there effectively was such a guarantee for perl1.000 .. perl5.005_03. The drand48() change went in with 5.6.0. This was actually a very big issue for me. I put loud warnings into perldelta.pod and Jarkko and I put hooks into Configure to enable users to preserve the old pre-5.6.0 behavior if necessary. Further, we might eventually want to include our own PRNG into perl6 anyway, if only to work around the really lousy one commonly encountered on Win32. Still, even for me, I have never encountered a case where I wanted to maintain the same rand() sequence and also use a one-arg crypt(). > I will add a note aboput this to the RFC. If there are no other > comments, I will freeze it in 24 hours. I agree this is a non-issue for this RFC.[*] -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 [*] I'm assuming we'll leave the salt example in the documentation, and that anyone sophisticated enough to rely on getting repeatable values from rand() can also use the example from perlfunc.
Re: RFC 258 (v1) Distinguish packed binary data from printablestrings
> Perl should be able to distinguish between printable strings and > packed binary data stored as strings (presumed to not be printable > text) All strings are "printable" in perl, since print just calls fwrite(). I can and do use perl to "print" binary data. print $a is perfectly fine even if $a is a packed binary thing. In fact, since there is no other way to call fwrite() [write does format things, and syswrite bypasses stdio, which may not be appropriate] print $a is probably the best way to output a packed binary thing. > If anyone knows of common constructs/idioms which would break under > this scheme and where it's too painful to add C or > C<"..."> as appropriate ... well I don't have to ask to have them > pointed out, do I? :-) The only cases I've been able to think of are > JAPHs or code samples. "too painful" is, of course, a judgment call. I do use the read/unpack/modify/pack/print cycle a fair amount dealing with image data. I guess I'd say working around RFC 258 might be annoying but not painful. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 226 (v2) Selective interpolation in single quotish context.
> Perl6 should allow scalars and arrays to be tagged such that they are
> interpolated in single quotish context.
How do you turn it off? I want to keep a way to specify stuff without any
interpolation whatsoever. I see the usefulness of this sort of quoting,
but I also see the usefulness of being absolutely able to turn all
interpolation off.
This seems mostly an issue in heredocs (though I appreciate your
generalization to all single quotish contexts.)
I wonder if perhaps it might be possible to combine some of the ideas
from the white-space heredoc discussion and join them to this one and
come up with a nice syntax for a sort of modified here-doc.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: RFC 216 (v1) POD should tolerate white space.
> POD should tolerate white space where it now requires empty lines [...] > =head1 IMPLEMENTATION > > Seems like it should be just a regexp stuck in somewhere I think this is a specific problem calling for a more general solution. I can think of two possible ones: 1. A standard library function to safely but forgivingly read in a "paragraph". I have cc'd perl6-stdlib since this strikes me as a sensible candidate for the standard library. 2. Allowing $/ (or its successor, perhaps set on a per-filehandle basis) to be a regular expression, not a string. (Surely there's an RFC on that somewhere.) Once either of those solutions is implemented, then then it's a simple matter for pod tools using it instead of $/ (or whatever). Since you made this proposal, would you be willing to pursue either of these options further? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 114 (v2) Perl resource configuration
On Fri, 1 Sep 2000, Tom Christiansen wrote: > >it can be used for system specific @INC paths without > >recompiling perl > > That's what PERL5LIB is for. PERL5LIB is available for the individual user to use, set, unset, change, etc., at will. As sysadmin, you can't set it in /etc/profile and be sure that your setting will stick. Actually, you can't even guarantee that every process will be run under a shell that sources /etc/profile or indeed under a "shell" that sources any configuration file at all under /etc. Even if you could, however, there's still a maintenance issue. For "configuring" one package, perl, does it really make administrative sense to have to maintain N /etc/*profile files (one for each possible shell?) This would mean that every shell upgrade could potentially require manual intervention to retain the perl customization. If (please note I said "If" here--I'm not arguing for or against the proposal) it would be useful to configure perl, then I strongly would argue that such configuration ought to be localized to just a very few files under perl's control. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Do we really need eq?
On Tue, 29 Aug 2000, David L. Nicol wrote: > I'd like to see every number bundled with a "precision" attribute. While that might be useful for simple calculations, I expect it would simply get in the way and slow things down for larger, more complex calculations. Alas I don't think there's any shortcut for actual analysis of the underlying data and algorithms. Andy Dougherty [EMAIL PROTECTED]
Re: RFC 79 (v1) Code which is both executable and POD.
On Wed, 9 Aug 2000, Michael Mathews wrote: > To be fair, neither of these are examples of using a comment function for > "comments" though, but rather using a comment function to disable sections > of code and I suppose that makes as much sense as using POD to disable code. This is another instance where a macro preprocessor might be useful. (My previous example was an alternative to some of the higher-level function proposals.) In cpp (though I'd not recommend that particular "language" for Perl): #if 0 ..disabled code... #if 0 ..older disabled code... now in nested disables #endif ..more disabled code #endif Just hoping that looking at it from another skewed viewpoint may inspire someone, Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 23 Higher order functions -- macros instead?
In RFC 23, Damian Conway <[EMAIL PROTECTED]> proposes a syntax for
"higher-order functions". One example given is related to a proposed
switch statement (RFC 22). A trimmed version is:
> sub beverage {
> switch (shift) {
> case sub{ $_[0] < 10 } { return 'milk' }
> case sub{ $_[0] < 20 } { return 'coke' }
> else{ return 'milk' }
> }
> }
which it is proposed could be re-written as:
> sub beverage {
> switch (shift) {
> case __ < 10 { return 'milk' }
> case __ < 20 { return 'coke' }
> else { return 'milk' }
> }
> }
While I appreciate and applaud the attempt to solve a specific problem
with a generalized mechanism, it occurs to me that another general way to
attack this same problem might be through some sort of macro language.
As a trivial example, using CPP (*not* what I'd propose for perl6),
the switch example could be written
#define arg_lt(X) sub{ $_[0] < (X) }
sub beverage {
switch (shift) {
case arg_lt(10) { return 'milk' }
case arg_lt(20) { return 'coke' }
else { return 'milk' }
}
}
I submit this is at least as clear as the __ version.
So I'd like to encourage folks to consider whether adding some sort of
(optional) macro language (perlpp ?) to perl6 would be worthwhile.
Folks with experience with a variety of macro languages would be more
qualified than I to develop an RFC on the subject, but I think it's
worth pursuing.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: RFC 23 Higher order functions
Quoting RFC 23:
> That is, the expression:
>
> $check = __ < 2 + __ * atan($pi/__) or die __;
>
> is equivalent to:
>
> $check = sub (;) {
> $_[0] < 2 + $_[1] * atan($pi/$_[3]) or die $_[4]
> };
It strikes me that this is very fragile and limited (unless I
misunderstand, which is quite possible). For one thing, it appears to
only be useful if your subroutine uses each argument exactly once. If
you need to use any of the arguments more than once, you can't use this
notation. For example, you might want to check $_[3] to be sure
$pi/$_[3] didn't end up dividing by zero. I don't see how to to that
with the __ version.
Further, if you find you need to revise the check function in a way
that changes the order in which the arguments are used, but you don't
want to replace all the calls to $check elsewhere in your code, I
don't see how you can do that with the __ version.
Thus it seems to me that this notation doesn't really buy us very much.
It's only useful for a very specialized set of subroutines. Of course you
have to realize I had never heard of either "higher order functions" or
"Re-currying deferred expressions" prior to reading this RFC, so it's
quite possible I'm missing something.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Philip Newton wrote: > On Mon, 7 Aug 2000, Tim Jenness wrote: > > > Is localtime() used often enough to justify being part of > > the language? > > You're kidding, right? No, not at all. > We wouldn't have had all those script kiddies complaining about year 19100 > bugs and month-being-off-by-one errors if localtime() wasn't being used > all of the time, whether in CGI code or not. Yes, obviously it has been used by many. That means that the equivalent functionality needs to be provided somehow in the complete standard perl6 distribution. It doesn't mean localtime() has to be a keyword with its very own opcode that is part of the core language. It could be part of a module. In fact it already is in perl5: POSIX::localtime. POSIX::localtime() (or some descendent of it) will almost surely continue to be available. It's quite possible that other date/time functions may be part of the standard library too. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Glenn Linderman wrote: > Me too, and I'm _not_ an astronomer. > > Tim Jenness wrote: > > > Also, I would vote for a method to return the Julian date (yes I am an > > astronomer...) :-) But surely not as a part of the core language? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Johan Vromans wrote: > strftime sounds like a real Unixism to me. 'set_format' and 'format' looks > more neutral and at least as effective. strftime is and will likely continue to be available through the POSIX module (or its successor). I see no point in re-inventing strftime (perhaps well, perhaps badly) as a perl language core element. I certainly see great benefit in including a nice date/time module, but that's a topic for [EMAIL PROTECTED], not this list. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Wed, 2 Aug 2000, Chaim Frenkel wrote: > If it is decided (and I hope not) that localtime and its kin are verboten, > it should not exists _at all_ in Perl6 and any existance at all would be > only as a support module for Perl5 backward compatiblity. Well we should still have POSIX::localtime(). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
