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 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: 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, 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 shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Casey R. Tweten wrote: opinion 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: 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 Cpack("a*",...) 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 99 (v3) Standardize ALL Perl platforms on UNIX epoch
On Thu, 14 Sep 2000, Chris Nandor wrote: Well, Perl is about making things easy. What is the most common case, needing an arbitrary value of time that may or may not be used to transfer between platforms, or needing a value of time that is specific to a given platform? And I cannot think of a time when I have needed the actual Mac value to communicate with another Mac process or library. Well, my entire experimental temperature control system currently relies on just this communication. But I suspect my personal experience here is probably not the most common :-). -- 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
