Re: Apocalypses and Exegesis...
* Alberto Manuel Brandão Simões [15 Aug 2003 00:36]: On Thu, 2003-08-14 at 15:19, Iain Truskett wrote: [...] Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. Yeah. I would like to read it. But as I think syntax will change, I'm not thinking on buying it.. ;-/ Safari. http://safari.oreilly.com/0596004990 Of course, you need a Safari subscription, but they quite useful things. I imagine purchasing it physical copies would be more common on p6-internals as over half the book is Parrot and related goodness. cheers, -- Iain.
Re: Apocalypses and Exegesis...
* Jonathan Scott Duff ([EMAIL PROTECTED]) [15 Aug 2003 00:16]: [...] Besides you could always provide online updates to your book as the language changes. The first (dead tree) edition would be the rough cut, and later editions would be closer to reality as the language stablizes. Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. cheers, -- Iain.
Re: Perl6 Daydreams (on topic but frivolous)
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]: Iain Truskett [EMAIL PROTECTED] writes: Not the only one. And with Parrot being able to execute Z-code, it might be sane to port Inform to Parrot! Did you mean port Inform to run on Parrot, or port Inform to compile to parrot? The former. I was thinking more of Parrot being a portable interactive fiction platform for reading and creating games. cheers, -- Iain.
Re: what's new continued
* Damian Conway ([EMAIL PROTECTED]) [08 Jul 2002 10:27]:
[...]
given my Doberman $sis is female = .dog[0] but pregnant - $mother {
for my Doberman @puppies = new Doberman x $mother.littersize
I'd have thought you'd need:
for my Doberman @puppies = (new Doberman) x $mother.littersize
Is it just my reading or would that return the same Doberman as each
puppy? i.e. Doberman.new is only called once and then duplicated?
cheers,
--
Iain 'Spoon' Truskett. http://eh.org/~koschei/
Re: Apo-Ex arhive
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [05 Apr 2002 00:34]: hi, I thought it will be good if on dev.perl6.org we have an arhive with all Apo's and Ex's, so anyone can get them in pack... (prefebaly printed version) Throught the links I got all except Apo1. Anyone to have the link nearby Don't know about this dev.perl6.org thing, but dev.perl.org has all the Apocs and Exeges on it. Look at the sidebar. Even has Apoc1. cheers, -- iain. http://eh.org/~koschei/
Re: Apoc 4?
* Bryan C. Warnock ([EMAIL PROTECTED]) [20 Jan 2002 05:33]: On Saturday 19 January 2002 12:20, iain truskett wrote: [...] It's a worry. Also odd is that Slashdot hasn't picked it up yet. Developers' section. /me fossicks through configuration. Ah. Didn't have 'Collapse Sections' enabled. This also explains why there's only 4 comments. Time I removed more of the crud sections. Cheers for that. -- iain. http://eh.org/~koschei/
Re: Apoc 4?
* Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]: On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html [...] I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. It's a worry. Also odd is that Slashdot hasn't picked it up yet. I don't know about most people, but I saw the announcement on http://use.perl.org/ cheers, -- iain. http://eh.org/~koschei/
Re: What will be the Perl6 code name ?!!
* raptor ([EMAIL PROTECTED]) [20 Oct 2000 00:53]: hi, Most of the software projects has their code name f.e. : [...] Red Had Version 7 (Guinness) Obviously Red Hat had partaken in quite a sampling of Guinness when they decided to release 7. [...] What will be the Perl6 code name ? even the perl books has some animal to represent the main idea behind... or just for the fun. Perl 6 sounds good. I suspect some people would be leaning towards a gem, given Topaz and Sapphire. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Define the universe. Give three examples.
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]: On 28 Sep 2000, at 21:36, iain truskett wrote: [] It's a case of: if you're going to have the output order, then you should provide for the input to be ordered. *As well as* unordered. Sorry, I don't follow your line of reasoning. Why should having the output ordered influence what I want to see the input as? They're two different things; the output is aimed for the HTTP user agent, and the input is aimed (at the web server and then) for me. Two different sets of requirements. You accepted that output should be ordered, in case of new HTTP protocol versions that may have a particular order requirement for headers. Surely such a requirement of output headers would also be a requirement for input headers? The order of them is just as important as the output headers. [...] However, the protocol on incoming headers is mainly significant between the HTTP user agent and the web server; once it gets to me, I don't care about the protocol any more -- the web server took care of that already. So the input headers can be unordered for all I care. For all your care, yes. Others may have different requirements, and those requirements may change with new HTTP revisions. Again, I don't do CGI much -- there may be people who want the exact headers in the exact order. For me, knowing what the "User-Agent:" header and what the "Accept-Charset:" header (or whatever) say is sufficient, and I don't care whether one is before or after the other. Again --- that's you. This RFC is for all of us. At the very least, include the opposing arguments so that Larry can see that there were multiple factions. I'm thinking a $headers_in and a $headers_out type thing is needed No comment on this one. Might be good, might not be; don't want to evaluate it right now. I just didn't want to snip it. =) Objects are good (in some respects). Having a %HTTP and a @HEADERS is rather simplistic and not really that accommodating for potential modifications to the protocols for HTTP and CGI. Possibly true. However, I believe that headers will still follow the "Key: Value" style, so @HEADERS should not be affected (if the programmer has to specify the order, that is -- then she can still do so in the future). And %HTTP may not need to be ordered. So you're saying that @HEADERS (the output one) can quite happily be ordered (which it is by default) or unordered, erring on the side of ordered; while on the other hand you're saying that %HTTP (input) may not need to be ordered (just as it may need to be ordered), erring on the side of unordered. Don't take this the wrong way, but you are being hypocritical in your treatment of input and output headers. In other words, the input has an order (the order in which the user- agent sent the headers), but I'm not necessarily interested in it (frequent CGI programmers may have different needs); Precisely. So theoretically, we should provide for both situations. Well, if you provide it ordered, you *are* providing for both situations -- those who want it ordered have it ordered, and those who don't care about the order will be happy, too. After all, I didn't say "I explicitly want it unordered" or "ordered according to the hash of each header field". But a %HTTP is the only variable you're giving us, which (by its nature) is unordered. I still free that objects are the way to go. At the very least both array and hash variables should be exposed; ideally two scalars that are object references. cheers, -- iain truskett, aka Koschei. http://eh.org/~koschei/ You know you are addicted to coffee if: 12 You don't sweat, you percolate.
Re: RFC 288 (v2) First-Class CGI Support
* Nathan Wiger ([EMAIL PROTECTED]) [29 Sep 2000 02:14]: A future protocol could well require things in order. Hence you're having the output headers in order. Therefore you should have the input ones available in order as well. I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't both be supported. Neither can I =) [...] Having a %HTTP and a @HEADERS is rather simplistic and not really that accommodating for potential modifications to the protocols for HTTP and CGI. I'm not sure I agree. The goal is to make this stuff easy for the majority of cases. We're certainly not going to get everybody's needs with this simple pragma. Indeed not. In some cases, not even our basic needs. The idea is to make it so "use cgi" lets you write a simple CGI script. One that can fluidly parse every header and is fully extensible per the newest HTTP/6.73 spec? Nope, then it's module time. Such as good ol' CGI.pm, or the appropriate mod_perl module. I'm still failing to see the point of most of this RFC. It doesn't really appear to do anything that isn't done better elsewhere and I'm on the school of thought "If you have good stuff, then don't add not-so-good stuff". Stuff that's in the core should be building blocks off of which other stuff can be based. Providing @HTTP and %CGI is great, because then modules can just "use cgi" and parse those thing up, without having to read from STDIN and do all the GET/POST special stuff. Or they can just grab stuff using CGI.pm... Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ A library is a hospital for the mind. Anonymous
Re: RFC 288 (v2) First-Class CGI Support
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]: [...] Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, has ideas about this? Does it really matter since it's a textarea? Typically you know which fields are only going to have one value and can just not split the field at tabs. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ I Xander: But we were going to have a romantic evening! Anya: We were going to light lots of candles and have sex near them!
Re: RFC 288 (v2) First-Class CGI Support
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:55]: On Sat, 30 Sep 2000, iain truskett wrote: Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC this? Do you think Mr. Stien would think us pushy? If you want and no, respectively. Mind you, I'd be more inclined just to ask Mr Stien and forego Yet Another Perl RFC. I feel the Perl 6 RFCs should just track stuff that is specific to Perl 6. These CGI::* modules should be quite capable of being used in Perl 5. IMHO this thread is discussing the implementation of a module, lets have an RFC that frames it that way. Sounds good. The less that is in core and the more that is in modules, the better, I think. Core doesn't need to split up CGI stuff. That could be tortuous if future HTTP protocols change their requirements (which is quite possible). Someone posited that perl6 should be the final version of perl (with versions converging on 2*pi iirc). The more that is in modules, the more easily this is accomplished. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Q: How do I block warnings? A: The simplest way is to do: close STDERR; -- perliaq.
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
On 27 Sep 2000, at 23:48, iain truskett wrote:
So surely you'd want %HTTP (the input headers) to also be an array
rather than a hash, since they'd be required in order as well?
I don't care, because I don't work with this much.
It's a case of: if you're going to have the output order, then you
should provide for the input to be ordered. *As well as* unordered.
And I don't know whether I'd need to bear in mind the protocol which
requires the order; I'd probably want to access them randomly. But
that I send out has to follow the protocol.
A future protocol could well require things in order. Hence you're
having the output headers in order. Therefore you should have the input
ones available in order as well.
I'm thinking a $headers_in and a $headers_out type thing is needed where
things are a Headers object that can either return a given header
my $type = $headers_in-value('Content-Type');
or process things sequentially
foreach my $header_key ($headers_in-keys)
{
}
and of course add and remove things
while ($headers_in-keys)
{
my $headerline = $headers_in-shift;
my ($key, $value) = ($headerline-key, $headerline-value);
}
$headers_in-add('Breakfast-Food', 'Bagel');
and so on.
Flexible. Transparent. You could even tie things if you want, so things
are slightly more transparent. Combine operator overloading with some of
Damian's 'want' and Quantum::Superpositions stuff and things become
rather interesting.
Having a %HTTP and a @HEADERS is rather simplistic and not really that
accommodating for potential modifications to the protocols for HTTP and
CGI.
In other words, the input has an order (the order in which the user-
agent sent the headers), but I'm not necessarily interested in it
(frequent CGI programmers may have different needs);
Precisely. So theoretically, we should provide for both situations.
the output also has an order, and *someone* has to provide for that
order, and I believe it is not good for Perl to do so (for the reasons
given before).
I would agree.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
2 You sleep with your eyes open.
Re: RFC 288 (v2) First-Class CGI Support
* Perl6 RFC Librarian ([EMAIL PROTECTED]) [27 Sep 2000 18:36]: [] [...] When this pragma is loaded, it should replace the print coderef with a function that will print out all headers in the @HEADERS queue, print out the desired output, and restore the print coderef. It should also ensure that the filehandle it is printing to is STDOUT, not something else. Otherwise if we fork to print stuff to, say, SENDMAIL, then things will go screwy. Was something to go happen about that headers() function or Headers module, or did you decide we'll go for the latter and just write and distribute it on CPAN? What format does @HEADERS entries take? Are they straight "xxx: yyy" or would it be better to have a function neatly join things so people don't felch up their syntax quite so easily? Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ You know you are addicted to coffee if... 6 You've worn out your third pair of tennis shoes this week.
Re: perl6storm #0050
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 19:54]:
On 26 Sep 2000, Johan Vromans wrote:
[...]
By the same reasoning, you can reduce the use of curlies by using
indentation to define block structure.
What an idea! I wonder why no language has tried this before.
I realise you're being sarcastic here, but my serious reply is "because
it reduces readability".
It forces the concept that all statements are equal.
Do you really want to see:
@sorted = sort
$b cmp $a
@lines;
Hmm. Not entirely sure how that indenting went. Let's try again:
@sorted = sort
$b cmp $a
@lines;
Maybe:
@sorted = sort
$b cmp $a
@lines;
I know!
@sorted = sort { $b cmp $a } @lines;
Works brilliantly!
People are probably thinking "no: just for for() while() and so on."
I'm thinking "consistency is the key to everything, including my tomato
soup". Do it one place, it should be eligible everywhere.
And maybe I want to write simple accesors like:
sub title { $_[0]-{'title'} }
Not as clear as
sub title
{
my $self = shift;
return $self-{'title'};
}
But clearer than
sub title
my $self = shift;
return $self-{'title'};
Which really needs something to end it with (such as 'endsub') otherwise
for more complicated routines it is hard to see where your function is
ending. Those { } do have more than just a syntactic use. They provide a
visual aid to the delineation of blocks.
Anyway. That was my irrelevant rant for the day. Erm. I'll go away now.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
7 Your eyes stay open when you sneeze.
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 22:51]: On Wed, 27 Sep 2000, iain truskett wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the [...] Better to have something that's either (a) pluggable without having to replace all of Perl, or (b) header-agnostic, so you have to specify your own ordering -- which also means you *can* specify your own ordering. So surely you'd want %HTTP (the input headers) to also be an array rather than a hash, since they'd be required in order as well? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ The best effect of any book is that it excites the reader to self activity. Thomas Carlyle
Re: RFC 288 (v2) First-Class CGI Support
* Nathan Wiger ([EMAIL PROTECTED]) [28 Sep 2000 05:33]: Philip Newton wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the Toast: light|medium|dark header, which has to come after the new Breakfast: header Wait, you're both right! ;-) More or less, yeah =) Personally, I'd like to see a simple version of CGI::header be embedded in core. HTTP-type headers are widely used in many applications. So you could have: @HEADERS = header(content-type = 'text/html', toast = 'medium', # not too crispy breakfast = 'yes'); Under normal life, @HEADERS would just be some variable. But the "use cgi" pragma could simply flush @HEADERS out ahead of time before your [insert "STDOUT"] output stream. If @HEADERS is empty, the "use cgi" pragma just prints out "Content-type: text/html\n\n"; Personally speaking, I'd prefer a headers object. Just so that things could be extended more easily in the future (in case headers ever need to get slightly more complicated than a simple order array). (Plus it means things could be slightly more easily kept track of in the implementation: it's quite probable that you won't want duplicate keys in the array and this is best served by having a hash behind the scenes (possibly with an ordered array of keys) but you can probably see where I'm aiming at now? Extensibility.) [...] Ziggy, are you interested in this idea enough (at all?) to stick a note about the 'header' function into the RFC? Or should I RFC it separately? I'd say RFC it separately. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ The book to read is not the one which thinks for you, but the one which makes you think. James McCosh
Re: RFC 288 (v1) First-Class CGI Support
* Greg Boug ([EMAIL PROTECTED]) [25 Sep 2000 17:46]: [...] The RFC should just be a little more specific on what's being included and not included. Are any of the functions like header(), h2(), footer()? What about %ENV manipulation functions? What do people think? I think that the current CGI module functionality should perhaps be maintained, though not necessarily in its current form... Yes. It'd be far better having the XML stuff working in a more 'first class' fashion than assorted h2() etc functions. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ "Debugging involves backwards reasoning ... Something impossible occurred, and the only solid information is that it really did occur." --- Kernighan and Pike, "The Practice of Programming"
Re: RFC 263 (v1) Add null() keyword and fundamental data type
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]: no strict; $a = undef; $b = null; Perl already has a null string: "". Looks more like a string of no length than a null string. -- iain.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
iain wrote:
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
Looks more like a string of no length than a null string.
Well, it's not. That's a null string. You're thinking of "\0", a
true value in Perl.
Ah. I wasn't thinking of that, but I had gotten something else confused.
This will teach me to write emails at 6am.
Here are the canonical definitions:
NULL STRING:
A string containing no characters, not to be confused with
a string containing a null character, which has a positive
length.
NULL CHARACTER:
A character with the ASCII value of zero. It's used by C
and some Unix syscalls to terminate strings, but Perl allows
strings to contain a null.
NULL LIST:
A list value with zero elements, represented in Perl by ().
And a NULL SCALAR:
A scalar value of no value, as distinct from a scalar value of
undefined value.
cheers,
--
\def\Koschei{Iain Truskett}% http://eh.org/~koschei/
\def\WhoAmI#1#2#3#4#5#6{\tt#2#3\it#4#5\bf#6\sl!}\def\i{I}\def\f{i}\def\I
{\if\i\f\f\else\i\fi}\def\Am{am} \WhoAmI?\I\ \Am\ \Koschei\bye!
Re: RFC 263 (v1) Add null() keyword and fundamental data type
* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]: Jonathan Scott Duff [EMAIL PROTECTED] writes: Yep, this is bad IMHO. Your concern is valid I think, but your "solution" isn't a good one. Why not just use a module like Damian's Quantum::Superpositions? No offense to Damian, but I tried to read and understand his documentation and I thought I was back in grad school. I don't think it's the fault of the writing either; I think that Quantum::Superpositions is trying to do something that's rather too complicated to explain clearly to the average programmer. It's a neat idea, but I don't expect to see it ever widely used. I had a thorough read of it yesterday morning, after having been using it at a basic level for a few weeks. I was quite impressed by it. I'm really quite impressed by it. Mostly, I've been using it for validation of data (usually where the data already exists in an array and building a regexp from the array would be too annoying). In fact, I had to translate some code that used it into code that didn't use it, and it went from 3 lines to being about 15. In other words, it simplifies some operations, thus reducing the likelihood of errors. I'm not great at either maths or physics (in fact, most people will happily tell you that I suck at both, including myself), but I can see what the module does. The main trick is getting the average programmer to actually read the documentation. Hence, it's mostly a case of putting more 'practical' examples of its use in the manual. Of course, I would be interested in seeing a version of Q::S that worked with threads and/or multiprocesses. I'll be interested to see Damian's paper when it comes out. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ You know you are addicted to coffee if... 24 You get a speeding ticket even when you're parked.
Re: RFC 76 (v2) Builtin: reduce
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Builtin: reduce
[...]
Separation:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
[[],[]],
@numbers;
I don't understand this one.
$sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
Hence: given an array of two arrays, put odd numbers (i.e. x % 2 == 1)
in the second array, and even numbers (i.e. x % 2 == 0) in the first one
(the zeroth array). Then return the new (filled out) pair of arrays for
the next number.
I like it.
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
16 Instant coffee takes too long.
Re: Devils advocacy (Re: RFC 84 (v1) Replace = (stringifying comma) with =)
* John Porter ([EMAIL PROTECTED]) [17 Aug 2000 03:02]: Nathan Torkington wrote: John Porter writes: I really don't feel that strongly about it! If you think something is good, then argue for it. If you don't, don't. I *do* think it's good. I'm arguing for it because it's something I'd like to see happen. But I'm not passionate about it. Additionally, someone else may take to the idea and then argue passionately for it. They just may not have thought enough about the topic to come up with the idea. How often have you ever said "Hey! That's cool! Wish I'd thought of that!"? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. -- Anonymous.
Re: RFC 96 (v1) A Base Class for Exception Objects
* Perl6 RFC Librarian ([EMAIL PROTECTED]) [12 Aug 2000 18:44]: tag severity message debug file line object sysmsg You'll need something for backtraces, if you're going to have 'file' and 'line'. One needs to know what route the program took to get to that file and line. Maybe a 'trace' variable that's a list of file = line pairs? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Q: How do I block warnings? A: The simplest way is to do: close STDERR; -- perliaq.
Re: RFC 90 (v1) Builtins: zip() and unzip()
* Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]: [...] Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave' too--although I'm still unsure about that one... Weave is too much like Knuth's tangle and weave pair of programs for his WEB idea. *sigh* All the good names are taken =) BTW, I've seen no discussion of RFC 82 (Make operators behave consistently in a list context), so I'm not sure what to do with it... Is that because everyone thinks it's great, or that it's stupid, or just that no-one's got any idea what I'm trying to say? I glanced through it and thought it seemed fine. If people think something is stupid, they'll email. If people want something changed, they'll email. If something is good, they won't =) cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. -- Anonymous.
Re: RFC 90 (v1) Builtins: zip() and unzip()
* Jarkko Hietaniemi ([EMAIL PROTECTED]) [14 Aug 2000 00:15]: On Sun, Aug 13, 2000 at 06:54:10PM +1000, iain truskett wrote: * Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]: [...] Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave' too--although I'm still unsure about that one... Weave is too much like Knuth's tangle and weave pair of programs for his WEB idea. *sigh* All the good names are taken =) That, however, is nowhere as well known (=confusion causing) as 'zip'. Pretty much every English verb must have by now been taken as a name of a piece of software, we have to draw the line somewhere... True, but we can still look. qw/fuse unite spin zigzag entwine/ etc. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Xander: But we were going to have a romantic evening! Anya: We were going to light lots of candles and have sex near them!
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
* Philip Newton ([EMAIL PROTECTED]) [13 Aug 2000 04:10]:
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Philip Newton wrote:
So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
'Feb') or qw(dummy Jan Feb)... oh well.
Far better, use the new builtin object methods:
$d = date;
print "today is ", $d-date('%A'); # Friday
This doesn't solve the problem for those who want 'F', or 'Fri', or
even 'Freitag' or 'Vendredi'.
Well, Fri can be catered for using %a (as in strftime at present). Check
out 'man strftime':
%a The abbreviated weekday name according to the current locale.
%A The full weekday name according to the current locale.
%b The abbreviated month name according to the current locale.
%B The full month name according to the current locale.
%c The preferred date and time representation for the current locale.
Note the 'current locale' bit. That takes care of Freitag, Vendredi or
Kinyoobi (in UTF-16, natch).
As for F? Use substr.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
Strings selected at random are much more likely to be
syntactically correct Perl programs than they are to be C or Lisp
programs, and in fact have positive probability of being correct.
-- http://www.plover.com/~mjd/perl/idiocy/RandProg.html
Re: println() ... printbr()
* Peter Bevan ([EMAIL PROTECTED]) [09 Aug 2000 20:08]:
To: "raptor" [EMAIL PROTECTED]
[...]
print @array;
must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_BR"};
not like at the moment :
foraeach (@array) { print $_};
This I totally disagree with. The use of an array in scalar context
does (and I believe should always) return it's length. It is one of
Perl's single most usful features (in my expirience)...
Almost. print @array is a list context.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
Q: How do I block warnings?
A: The simplest way is to do: close STDERR; -- perliaq.
