Re: Lessons to learn from ithreads (was: threads?)
On Tue, Oct 12, 2010 at 3:46 PM, Tim Bunce tim.bu...@pobox.com wrote: On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote: On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg ben-goldb...@hotmail.com wrote: If thread-unsafe subroutines are called, then something like ithreads might be used. For the love of $DEITY, let's please not repeat ithreads! It's worth remembering that ithreads are far superior to the older 5005threads model, where multiple threads ran with an interpreter. [Shudder] It's also worth remembering that real O/S level threads are needed to work asynchronously with third-party libraries that would block. Database client libraries that don't offer async support are an obvious example. Hi, I'm showing up only because I happened to check my Perl 6 inbox. For various work related reasons, I'd peeked my head into a couple other language VMs threading implementations. Seems relevant to mention more possibilities: ruby-1.8: - green threads - single actual process - scheduling handled by switching to something else after N opcodes are dispatched - system() and other blocking system calls are implemented as non-blocking alternatives - C extensions must also use non-blocking code and be written to call back to the scheduling core - able to share data easily without onerous user-level synchronization because there's really no such thing as being concurrent ruby-1.9 + python: - real threads - global interpreter lock over the core so they're not CPU concurrent - don't have the story for C extensions - able to share data easily without onerous user-level synchronization because there's really no such thing as being concurrent jruby: - Java - real threads - fully concurrent - mostly can't use C extensions - able to share data easily without onerous user-level synchronization because ... ? Java magic? Those implementations all do very well for tasks where actual CPU concurrency isn't needed. A common sweet spot are web services and other things that divide time over IO waiting. They also do well by not having to instantiate separable VMs per thread. They also don't require the user (as in Perl 5) to carefully mark their data as shared because by default everything is shared (but then they don't have actual concurrency either). They do poorly when expected to take advantage of multiple cores. When using this kind of concurrent software for web services, I've compensated by just running enough processes to keep my CPUs busy. I got the advantage of having something that behaved like threads but was extremely easy to work with. This is very unlike my experience with Perl 5 threads which I still fear to work with (mostly because I worry of dangling pointers from difficult to spot miscellaneous magic attachments). Our own threading story could use tricks from the above and include more than just what you've mentioned. Josh
Re: IO Multiplexing
On Nov 12, 2:21 pm, stefa...@cox.net (Stefan O'Rear) wrote: On Thu, Nov 11, 2010 at 05:47:46PM -0800, Ben Goldberg wrote: I would like to know, is perl6 going to have something like select (with arguments created by fileno/vec), or something like IO::Select (with which the user doesn't need to know about the implementation, which happens to be done with fileno/vec/select), or only an event loop. I will be unhappy if Perl 6 doesn't provide all three. However, the spec in question doesn't really exist. The IO synopsis is garbage and should be deleted and rewritten from scratch by someone who knows what they're talking about. I would recommend that there NOT be any sort of fileno exposed to the user, unless he goes out of the way to get it -- any function (in particular, posix functions) should simply take a perl filehandle, and that function in turn would pull out the fileno (or fail appropriately, if the filehandle doesn't have a fileno). If users want to know if filehandles correspond to the same underlying file, then there could be a method -- perhaps $fh.uses_same_desciptor($fh2), or somesuch. This goes without saying. One caveat - it should be possible to pass integer file descriptors. For functions in the posix module, sure; but for everywhere else, if the user wants to pass integer file descriptors to a function which is expecting an IO object, maybe not. But it should be easy (maybe even trivial) to create a new IO object from an integer file descriptor. If there's a select() builtin (and I'd much rather that there not be -- it should be hidden away in a class, like perl5's IO::Select), I'd very much hope that it would take and return Sets of filehandles, not vec packed strings. I'd prefer there not be one[**] Absolutely not. TIMTOWDI. There will be a select() function (in the POSIX module, not the default namespace!), and it will take parameters as close as possible to POSIX.1's definition. Perl without system calls is not Perl. I'm totally fine with discouraging casual use, though, which is why it shouldn't be in the default namespace. +1 :) If there's something like perl5's IO::Select, it should be able to just work regardless of whether the perl filehandles are sockets, regular files, or user-created pure-perl filehandles (which might never block, or which might use one or more normal filehandles internally, which in turn might potentially block). This is what I'd prefer. That is a good doctoral thesis topic. Require that IO objects provide a uniform interface by means of which the multiplexer object can determine blockability. Any user-defined IO handle which doesn't wait on external events will never block, and it can say so. A user defined IO handle which waits on a built in IO handle can say what handle it will need to wait upon, and what operation it will need to wait for. A user defined IO handle which waits for a signal can say what signal it is waiting for. A user defined IO handle which waits for a condition variable can say what variable it's waiting on, and what kind of state change it's looking for. Given the complexity of looking for other things (in particular, IPC that doesn't use streams), the simple solution is to require that they write a class for it, and have that class (internally) create a kernel thread which will block on the desired IPC, and write a byte to a pipe... this allows the perl level IO handle to say to the multiplexer that it's waiting on the read end of that pipe. This is roughly the same technique that we would use to safely detect signals. Lastly, if perl6 has an efficient enough built-in event loop, and sufficiently lightweight coroutines (or maybe I should say fibers?), then we might not need to have any kind of explicit multiplexing. TIMTOWDI. Perl without system calls is not Perl. Yeah, but if it's more efficient to not directly use those system calls, then what's the point of having them? For example, any time user code does a read operation on a handle that isn't (from the user code's point of view) in nonblocking mode, the filehandle implementation would tell the the event loop to yield to it when the handle becomes readable, then it would yield to the event loop, then (once it gets back control) read from the handle.[*] This is why S16 is junk - too much blue-sky thinking, not enough pragmatism and practical experience. S16 has almost nothing in it about actual IO (it does talk about how STDIN, STDOUT, STDERR, and ARGV will be replaced with $*IN, $*OUT, $*ERR, and $*ARGFILES, and how they will be dynamically overrideable). Did you mean to say S32::IO? While S32::IO describes what methods and roles IO objects will have/ do, the only thing it says about multiplexing is that both of perl5's select() operators will disappear. It's fairly obvious that select() / select(EXPR) will be replaced with the dynamically overrideable
IO Multiplexing
I would like to know, is perl6 going to have something like select (with arguments created by fileno/vec), or something like IO::Select (with which the user doesn't need to know about the implementation, which happens to be done with fileno/vec/select), or only an event loop. I would recommend that there NOT be any sort of fileno exposed to the user, unless he goes out of the way to get it -- any function (in particular, posix functions) should simply take a perl filehandle, and that function in turn would pull out the fileno (or fail appropriately, if the filehandle doesn't have a fileno). If users want to know if filehandles correspond to the same underlying file, then there could be a method -- perhaps $fh.uses_same_desciptor($fh2), or somesuch. If there's a select() builtin (and I'd much rather that there not be -- it should be hidden away in a class, like perl5's IO::Select), I'd very much hope that it would take and return Sets of filehandles, not vec packed strings. I'd prefer there not be one[**] If there's something like perl5's IO::Select, it should be able to just work regardless of whether the perl filehandles are sockets, regular files, or user-created pure-perl filehandles (which might never block, or which might use one or more normal filehandles internally, which in turn might potentially block). This is what I'd prefer. Lastly, if perl6 has an efficient enough built-in event loop, and sufficiently lightweight coroutines (or maybe I should say fibers?), then we might not need to have any kind of explicit multiplexing. For example, any time user code does a read operation on a handle that isn't (from the user code's point of view) in nonblocking mode, the filehandle implementation would tell the the event loop to yield to it when the handle becomes readable, then it would yield to the event loop, then (once it gets back control) read from the handle.[*] This provides lots of convenience, but it would resemble Java IO before the NIO -- except with one fiber per handle instead of one thread per handle. Coroutines/green threads/fibers are much lighter weight than real threads, but often aren't as fast as a well-written select() loop specially written for the user's task. Thus, I'd hope for perl6 to have an IO::Select, and automatically- yielding [*] blocking IO, and not have a select() builtin. [**] [*] This is a simplification: A) If a user explicitly marks a filehandle as not yielding to other coroutines, it would do a blocking read (or whatever) instead of going through the event loop rigmarole. B) If perl6 was compiled with an asynchronous IO library (or is on windows and is not using stdio and has (Read|Write)FileEX support), then it might start the Async IO operation, tell the event loop to wake it when the operation completes, then yield to the event loop. C) Depending on circumstances, it *may* be more efficient to have the event loop itself do the reading or other IO itself, and schedule the fibers for which the IO was done, than to have the fibers do the IO. TMTOWTDI. This would be especially important if perl is compiled with async IO -- the event loop might first wait for the fds to be readable/ etc, *then* start the async IO for those fds, then schedule the fibers for which the performed IO has completed, thus minimizing the number of outstanding async io operations. [**] The main reason I'd prefer that perl6 not have a select() builtin is that every time it's called perl would need to convert user-level Sets of filehandles into the underlying implementations' versions of them (fd_sets on unixy, fd_sets and/or an event queue handle on windows), and then back to perl Set objects, and free up the implementation version of the filehandle set... this is inefficient. A well written IO::Select-like object could create (potentially empty) versions of the OS's set of filehandles when it's created, add to that set as needed, and NOT destroy that implementation-specific set until the IO::Select object itself is destroyed. Perl5's IO::Select does this with the packed bitsets that it creates to pas to select. It could do improve it's efficiency by using fd_sets instead of bitstrings, and not use the perl select(), but the C select(2) instead. Better still would be epoll. In this case, avoiding repeated setup makes an object multiplexer model enormously more efficient than something like select(). Similarly, on windows, if we WSAEventSelect or WSAAsyncSelect to create readability/ writability/ etc events for IO operations we want to wait on, and [WSA]WaitForMultipleEvents as the blocking operation, then having an object multiplexer (which keeps events between one call to the next) is far better than a simple subroutine (which needs to cancel those events after it blocks and before it returns).
Re: Tweaking junctions
On Oct 22, 6:41 pm, dam...@conway.org (Damian Conway) wrote: Dave Whipp wrote: When this issue has been raised in the past, the response has been that junctions are not really intended to be useful outside of the narrow purpose for which they were introduced. Hmm. There are intentions, and then there are intentions. I know what I intended when I invented the original idea, and it wasn't just the narrow purpose for which they were added to Perl 6. :-) Problem 2 could be solved by defining a new (and public!) C.eigenstates method in the Junction class. [...] I think that you're proposed solution is a bit too specific: That's because I didn't explain Part B of my nefarious plan! namely that, if you'd only give me proper eigenstates, I'd give you an even nicer alternative. I actually think that the meta doesn't belong on the operator at all (though I have no problem with that idea in itself). Instead, I think the meta should be placed on the data (which, of course, is what any(), all(), one(), and none() already do). So I'm going to go on to propose that we create a fifth class of Junction: the transjunction, with corresponding keyword Cevery. [snip] I'm probably missing something, but wouldn't it have been easier to write that module by using eval STRING to create all of those infix operators? Start with a list of the names of the operators, generate a string containing all four argument variations for each operator, then eval it.
Lazy Strings and Regexes
I know that perl6 has / will have lazy strings, since (in S32::Containers) the List role defines a cat method, which returns a Cat object, which does the Str interface, but generates the string lazily. First, are Cat objects documented anywhere else? Secondly, if a regular expression match is done on a lazy string, is that lazy string turned into a normal string? If we can efficiently match against a lazy string, and if this doesn't turn the lazy string into a (large) normal string, then the best way to process a file might be something similar to: my $fh = open ... err die; my $contents = cat($fh.lines); , followed by matching on $contents. Better still would be to provide a way for filehandles to be directly asked to produce a lazy Str which reflects the file.
threads?
Has there been any decision yet over what model(s) of threads perl6 will support? Will they be POSIX-like? ithread-like? green-thread-like? It is my hope that more than one model will be supported... something that would allow the most lightweight threads possible to be used where possible, and ithread-like behavior for backwards compatibility, and perhaps something in-between where the lightest threads won't work, but ithreads are too slow. 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. If an otherwise-reentrant subroutine calls other subs which have been labelled by their authors as thread-safe, then that top subroutine can also be assumed to be thread-safe. This would be when the intermediate weight threads might be used. If thread-unsafe subroutines are called, then something like ithreads might be used. To allow the programmer to force perl6 to use lighter threads than it would choose by static analysis, he should be able to declare methods, subs, and blocks to be reentrant or threads safe, even if they don't look that way to the compiler. Of course, he would be doing so at his own risk, but he should be allowed to do it (maybe with a warning).
Re: cb8c84: [S06] s/tail-recursion/recursion/
On Oct 6, 1:28 pm, nore...@github.com wrote: Branch: refs/heads/master Home: http://github.com/perl6/specs Commit: cb8c8487fa0ab7156fecffdc8a52bf75d4290c1b http://github.com/perl6/specs/commit/cb8c8487fa0ab7156fecffdc8a52bf75... Author: Carl Masak cma...@gmail.com Date: 2010-10-06 (Wed, 06 Oct 2010) Changed paths: M S06-routines.pod Log Message: --- [S06] s/tail-recursion/recursion/ Because you can use ?ROUTINE calls in a non-tail position (and execution still carries on afterwards), it's really just normal recursion. Shouldn't that also apply to ?BLOCK, too?
Re: unusual invocants
Quoth tho...@sandlass.de (TSa (Thomas =?utf-8?q?Sandla=C3=9F?=)):
Here is a direct syntax for the freeze feature of the paper:
class C does T1 does T2
{
freeze T1::x for foo;
freeze T2::x for bar;
method x {...} # for all other methods
}
The implementation is strait forward: on entry to foo and bar
the dispatch table of the invocant is temporarily patched to
contain the right x. After the call the original is restored.
Isn't this just sugar for something like
class C does T1 does T2
{
method foo {
my $tmp = self but role {
method x { return self.T1::x }
};
return $tmp.foo;
}
method x { ... }
}
(Excuse me if I have any syntactic details wrong.)
The most important detail here is that the *class* gets to pick which
imported methods need to be wrapped. Most of the time you want a method
x in the class to be called from a method foo in the role: that's the
point.
What this doesn't fix is that some other code (outside the class) will
be expecting C::x to have T1::x semantics, and some will be expecting it
to have T2::x semantics. If these are contradictory, there is no way to
write an x which works. That's where the 'hats' idea comes in, so you
could write something like
class C does T1 does T2
{
method T1::x { ... }
method T2::x { ... }
}
and have callers that thought they were getting a T1 call the
appropriate override. However, there's still a problem with callers that
know they have a C: which method do they get?
AFAICS the only real solution to this is something like COM, where you
say 'I would like to talk to this object as though it were a T1 now'.
Might it be possible to use the type system to make this less painful
than it usually is?
Ben
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Quoth markjr...@gmail.com (Mark J. Reed):
I still like the double-bracket idea. I don't much mind the extra
character; 5 characters total still beats the 7 of HTML/XML.
I much prefer double-bracket to double-#: double-# gets caught out when
you do s/^/# on code which already includes line-starting # comments.
However, I would much rather see a general syntax like
(# ... )
{# ... }
[# ... ]
with no whitespace allowed between the opening bracket and the #: this
doesn't seem to conflict with anything. Allowing # ... in rules would
also be nice.
Ben
Re: Clarification of S04 closure traits
Sorry for the delay in replying, but I was busy with other things and I
wanted to give other people a chance to reply. Since noone has, might it
be possible to get the attached patches committed? I'm not familiar with
the protocol for such things so, again, I'm sorry if I've got it wrong.
Ben
--- S04-control.pod.orig 2009-08-11 08:43:36.0 +0100
+++ S04-control.pod 2009-08-11 09:03:42.0 +0100
@@ -1232,6 +1232,21 @@
before CBEGIN, CCHECK, or CINIT, since those are done at compile or
process initialization time).
+If an exception is thrown through a block without a CCATCH block, the
+CLEAVE, CUNDO and CPOST blocks will be run at that point, with
+C$! set to the in-flight exception. If there is no in-flight
+exception when these blocks are run, C$! will be Cundef. The last
+exception caught in the outer block is available as C OUTER::$! ,
+as usual.
+
+An exception thrown from an CENTER block will abort the CENTER
+queue, but one thrown from a CLEAVE block will not. The exceptions
+thrown by failing CPRE and CPOST blocks cannot be caught by a
+CCATCH in the same block, which implies that CPOST blocks are not
+run if a CPRE block fails. If a CPOST fails while an exception is in
+flight the CPOST failure doesn't replace C$! but goes straight into
+C$!.pending.
+
For blocks such as CKEEP and CPOST that are run when exiting a
scope normally, the return value (if any) from that scope is available
as the current topic. (It is presented as a CCapture object.)
Index: S04-closure-traits/enter-leave.t
===
--- S04-closure-traits/enter-leave.t (revision 27955)
+++ S04-closure-traits/enter-leave.t (working copy)
@@ -2,7 +2,7 @@
use Test;
-plan 11;
+plan 19;
# LS04/Closure traits/ENTER at every block entry time
# LS04/Closure traits/LEAVE at every block exit time
@@ -92,4 +92,92 @@
}), 1, 'leave triggers LEAVE {}';
}
+{
+my $str;
+try {
+ENTER { $str ~= '(' }
+LEAVE { $str ~= ')' }
+$str ~= 'x';
+die 'foo';
+}
+is $str, '(x)', 'die calls LEAVE blocks';
+}
+
+{
+my $str;
+try {
+LEAVE { $str ~= $! // 'undef' }
+die 'foo';
+}
+is $str, 'foo', '$! set in LEAVE if exception thrown';
+}
+
+{
+my $str;
+{
+LEAVE { $str ~= (defined $! ? 'yes' : 'no') }
+try { die 'foo' }
+$str ~= (defined $! ? 'aye' : 'nay');
+}
+is $str, 'ayeno', '$! not set in LEAVE if exception not thrown';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+ENTER { die 'foo' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '()', 'die in ENTER caught by try';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+LEAVE { die 'foo' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '(x)', 'die in LEAVE caught by try';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+ENTER { $str ~= '['; die 'foo' }
+LEAVE { $str ~= ']' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '([])', 'die in ENTER calls LEAVE';
+}
+
+{
+my $str;
+try {
+ENTER { $str ~= '1'; die 'foo' }
+ENTER { $str ~= '2' }
+}
+is $str, '1', 'die aborts ENTER queue';
+}
+
+{
+my $str;
+try {
+LEAVE { $str ~= '1' }
+LEAVE { $str ~= '2'; die 'foo' }
+}
+is $str, '21', 'die doesn\'t abort LEAVE queue';
+}
+
# vim: ft=perl6
Index: S04-closure-traits/pre-post.t
===
--- S04-closure-traits/pre-post.t (revision 27955)
+++ S04-closure-traits/pre-post.t (working copy)
@@ -9,7 +9,7 @@
# TODO:
# * Multiple inheritance + PRE/POST blocks
-plan 18;
+plan 25;
sub foo(Num $i) {
PRE {
@@ -125,4 +125,82 @@
lives_ok { $pt.test(2) }, 'POST receives return value as $_ (succeess)';
dies_ok { $pt.test(1) }, 'POST receives return value as $_ (failure)';
+{
+my $str;
+{
+PRE { $str ~= '('; 1 }
+POST { $str ~= ')'; 1 }
+$str ~= 'x';
+}
+is $str, '(x)', 'PRE and POST run on ordinary blocks';
+}
+
+{
+my $str;
+{
+POST { $str ~= ')'; 1 }
+LEAVE { $str ~= ']' }
+ENTER { $str ~= '[' }
+PRE { $str ~= '('; 1 }
+$str ~= 'x';
+}
+is $str, '([x])', 'PRE/POST run outside ENTER/LEAVE';
+}
+
+{
+my $str;
+try {
+{
+PRE { $str ~= '('; 0 }
+PRE { $str ~= '*'; 1 }
+ENTER { $str ~= '[' }
+$str ~= 'x';
+LEAVE { $str ~= ']' }
+POST{ $str ~= ')'; 1 }
+}
+}
+is $str, '(', 'failing PRE runs nothing else';
+}
+
+{
+my $str;
+try {
+{
+POST { $str ~= 'x'; 0 }
+LEAVE { $str ~= 'y' }
+POST { $str ~= 'z'; 1
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
At 6PM +0200 on 11/08/09 you (Moritz Lenz) wrote:
Ben Morrow wrote:
However, I would much rather see a general syntax like
(# ... )
{# ... }
[# ... ]
with no whitespace allowed between the opening bracket and the #: this
doesn't seem to conflict with anything. Allowing # ... in rules would
also be nice.
That severely violates the principle of least surprise. To me [#...]
looks like an array ref which contains a comment, which is *not* what
you propose (I think).
No, it wasn't. The idea was modelled after TT2's [%# ... %] syntax, and
other languages that mark comments just inside the delimiters.
It also feels like a step backwards. In Perl 6 we try to make things
clear from the beginning, not only from the second char on. Regex
modifiers at the, anybody? or (?#...) as comments in regexes in Perl 5?
In all other cases of quote like constructs are the semantics are
explicit first (think of Q, qx, m, , «), the delimiter comes later.
Changing that all of a sudden seems very unintuitive and wrong.
This appears to be leading to a :comment modifier on quotables, with
some suitable shortcut. Perhaps 'q#'? Or are we not allowed mixed alpha
and symbols?
Ben
(I really want to suggest £, just to teach USAnians '#' isn't called
'pound'... :) )
Re: Clarification of S04 closure traits
Moritz Lenz wrote: Ben Morrow wrote: - Presumably when an exception is thrown through a block, the LEAVE and POST queues are called (in that order). POST was inspired from the Design By Contract department, and are meant to execute assertions on the result. If you leave a block through an exception you don't have a result, so I don't think running a POST block makes sense. OK, if POST is only for asserting on the return value that would make sense. But I thought POST was also supposed to be able to assert that global state had been left as it should, in which case it should be run even on exceptional exit? I'm not sure how any given POST block is supposed to distinguish between an ordinary undef return and an exception, though, to avoid checking the return value. Some sort of guarantee that $! is undef in a POST block unless an exception is currently being thrown might be helpful, but I'm not sure how that interacts with the Perl 6 exception model as a whole. I'm not sure about running LEAVE blocks either, because that's what CATCH blocks are for. LEAVE blocks I am certain *should* be run, no matter how the block is exitted (well, unless a PRE fails: see below). They are equivalent to 'finally' blocks in other languages, and AIUI they are for cleanup: closing files, tearing down database connections and the like. What if a PRE block fails: is the POST queue on the same block called? (Do you have to satisfy your post-conditions even if your pre-conditions failed?) I'd say that if a PRE block fails, nothing else is run (neither LEAVE nor POST nor ...) I agree that none of ENTER, LEAVE or the main body of the block should be run. However, if a POST block is asserting, say, that a global holds a valid value, shouldn't that still be checked even if your preconditions failed? I admit I haven't read much about DBC. - If a POST block is called as a result of a thrown exception, and it fails, which exception 'wins'? Question obsoleted by previous answer ;-) ...maybe :). - Can a try block catch an exception thrown from its own ENTER or LEAVE queue? Yes. OK. What about PRE/POST? It seems wrong somehow to be able to catch failure of your own pre-/post-conditions: they are meant for the caller to catch. Does that seem right? Ben
Clarification of S04 closure traits
I'm iworking on a patch for Perl 5 that implements the Perl 6 closure
traits (ENTER/LEAVE/...) as special blocks. There are several details
that aren't clear to me from either S04 or the spec tests; I apologize
if these have been discussed before, as I haven't been following p6l.
I'm also not subscribed, so if people could keep me in the CC that would
be appreciated.
- Presumably when an exception is thrown through a block, the LEAVE and
POST queues are called (in that order). What if a PRE block fails: is
the POST queue on the same block called? (Do you have to satisfy your
post-conditions even if your pre-conditions failed?)
- If a POST block is called as a result of a thrown exception, and it
fails, which exception 'wins'?
- Presumably if an ENTER block dies, the rest of that ENTER queue is
abandoned. Does that also apply to the LEAVE queue? What should
{
LEAVE { say leave1 }
LEAVE { say leave2; die foo; }
}
print? Similarly POST: once one post-condition has failed, are
subsequent post-conditions checked?
- Can a try block catch an exception thrown from its own ENTER or LEAVE
queue? For example in this case:
try {
try {
ENTER { die foo }
CATCH { default { say caught inside } }
}
CATCH { default { say caught outside } }
}
which CATCH block gets the exception? What about PRE/POST: can you
CATCH failure of your own pre-/post-conditions?
- Does it make any difference in any of the above if 'die' is replaced
by 'exit'?
Ben
Re: [RFC] CPAN6 requirements analysis
On Fri, May 29, 2009 at 10:02:20PM +1000, Timothy S. Nelson wrote: On Fri, 29 May 2009, Mark Overmeer wrote: IMO, that discussion should go in the direction of additional services: the CPAN archive distributes what authors publish. The install tools (CPAN.pm/CPANPLUS/successors) make that code fit in specific operating systems. As a service, other people can publish the results of their specific module installation via package-managers to the world, such that those people can use they platform native software management tools. Just like search.cpan.org is an independent additional service on the CPAN archive. Are you arguing here for eg. a yum/apt/whatever repository on Pause6? I believe he is arguing that whatever we end up doing needs to make it easy for an external package-manager to find out what files CPAN6.pm is going to install, and where, and what the dependencies were (both Perl and system libraries). So that the various distributions can make native packages from perl packages automatically (or at least as close to automatically as possible, it gets a little uglier when external libraries are involved). So if there is program foo that is written in Perl that Fedora wants to distribute, they want to be able to list the dependencies when they make the package for foo. If foo requires a few packages, then they just want to say that and then when foo is installed, pull in those packages and any that those depend on, including any non-perl ones that are needed by the perl packages. -ben
Re: Fatal/autodie exception hierarchies for Perl 5
On Sun, Jun 1, 2008 at 7:31 PM, Paul Fenwick [EMAIL PROTECTED] wrote:
Currently, when testing exceptions from autodie, we can use:
given ($@) {
when (undef) { say No errors here }
when ('open') { say Open died }
when (':file') { say Some sort of file error }
when (':io') { say Some other error }
when (':CORE') { say Some other CORE error }
when (':USER') { say A non-CORE error }
when (':all') { say Any autodie exception at all. }
default{ say Not an autodie exception. }
}
If you're going to write that into some documentation, I wish you'd
make default say that it's exception suicide.
given( my $_ = $@ ) {
...
default { say '$@ committed suicide' }
}
Semi-recently at work I found that a few buggy exception objects in
the global $@ were clearing themselves out of $@ as a side effect of
examining them for truth. It's quite annoying and mysterious when it
happens.
Josh
Re: Smooth or Chunky?
Quoth [EMAIL PROTECTED] (Larry Wall):
I should also mention I did (briefly) consider the null reduce
operator:
[] zip(1,2;3,4)
to mean slap [] around each element, but it runs into ambiguity with
the existing [] form indicating an empty list.
Would using [[]] instead work? This is (at least to me) nicely visually
indicative of 'build a list of lists'. It is a little punctuation-heavy,
of course; though we could always allow \x{27E6}\x{27E7} as an
alternative :).
Ben
--
Although few may originate a policy, we are all able to judge it.
Pericles of Athens, c.430 B.C.
[EMAIL PROTECTED]
Re: renaming grep to where
Quoth [EMAIL PROTECTED]: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. I would second that strongly. Perl6 is already different enough from Perl5 for good reasons; making it different for bad reasons seems to me a really bad idea. If this sort of change is on the cards, then for consistency a serious effort should be made to remove *all* Unixisms from Perl (unlink, flock, fork, and all the signal stuff spring to mind; a case could be made for the filetest ops as well). I think that that level of culture- and history-loss would be a real shame; I can see however that others may think it more important to make Perl more platform-agnostic in character as well as in implementation. Ben -- 'Deserve [death]? I daresay he did. Many live that deserve death. And some die that deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends.' [EMAIL PROTECTED]
Re: === and array-refs
Quoth [EMAIL PROTECTED] (Mark J. Reed): On 8/17/06, David Green [EMAIL PROTECTED] wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; So $a, $c, and $d may all have the same *value* (or snapshot, when evaluated all the way down through nesting and references), i.e. they might be eqv, but only $a and $c are === because they have the same contents [unevaluated contents] and $d doesn't. In this case, it seems like [===] @$a, @$c would do what you want, yes? It would return true, while [===] @$a,@$d would return false... In the general case - well, I think the thread demonstrates that it's hard to define a general case for what you want to do. Based on your example, I assumed you wanted one-level dereferencing, regardless of the contents. But it sounds like what you want is infinite dereferencing as long as the referent is anonymous, and no dereferencing if the referent is a named variable? Surely that's a meaningless distinction? A named variable can become anonymous if its name goes out of scope; an anon can be bound to a name. Just to make sure I've got all this straight: =:= compares names === compares containers eqv compares values So given an array @W, my @X := @W;# @X =:= @W my @Y = @W;# @Y === @W but @Y !=:= @W my @Z = @W.clone; # @Z eqv @W but @Z !=== @W ? This seems like a useful set of distinctions to me... lurk Ben -- The cosmos, at best, is like a rubbish heap scattered at random. Heraclitus [EMAIL PROTECTED]
