Darren Duncan schreef:
> Each time a context (a code block, either a routine or a syntactic
> construct like 'try' is) is entered that is marked 'is atomic', a new
> transaction begins, which as a whole can later be committed or rolled
> back; it implicitly commits if that context is exited normal
However, as has been pointed out regarding MS Word, most users only
use a very tiny subset of its functionality. The problem is that the users
are using different subsets. I've done huge amounts of HTML parsing and
can't recall having used GDBM_File.
It all comes to *different* subsets
I
I think that the "distribution" approach is a good way to go. I also
think that there could be value in a set of "core" modules for some basic
functions. The only reason to do this, however, would be to design those
modules to work especially well together. These modules could follow
tighte
Does anyone out there have any phone numbers for key contacts at The
Perl Foundation that you could send to me off-list? So far, I've not
heard back from anyone there. TIA.
Best regards,
Conrad Schneiker
http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)
www.AthenaLa
On Wed, May 31, 2006 at 06:56:14PM -0400, Josh Wilmes wrote:
> Of course there's still the question of what modules would belong in such
> a list. I think that modules for debugging, compilation and deployment,
> exception handling, threading, basic I/O (which includes LWP nowadays) would
> p
Hi,
However, as has been pointed out regarding MS Word, most users only
use a very tiny subset of its functionality. The problem is that the
users
are using different subsets. I've done huge amounts of HTML parsing and
can't recall having used GDBM_File.
It all comes to *different* subset
Hi Conrad,
I run the grant committee for the Perl Foundation and I sit on the steering
committee, so I suppose I can discuss your proposal (there are some other TPF
folk here, too, so that's why this is a public email). Also, the following
stuff is just off the top of my head and is in no way
On Jun 1, 2006, at 6:45, Ovid wrote:
In any event, if you can come up with a solid set of contest rules,
TPF can consider whether or not we can officially run the contest.
It sounds like a nice idea, I just don't know what's involved.
I wouldn't claim to entirely comprehend the rules, but
Hi,
Hi Conrad,
I run the grant committee for the Perl Foundation and I sit on the steering
committee, so I suppose I can discuss your proposal (there are some other TPF
folk here, too, so that's why this is a public email). Also, the following
stuff is just off the top of my head and is in
How about something a little less mercenary - a 1000$ donation to the
Perl Foundation/Perl 6 development in the winner's name from Athena Labs?
Might take out some of the difficulty and, who knows, get you a better
wiki (you know, the less immediately reward driven programmer or something
On Apr 23, 2006, at 3:43, Will Coleda (via RT) wrote:
.sub unicode:"\u"
print "ok\n"
.end
This should be ok now as well as calling the sub, sub.t is passing
again with r12863. More tests e.g. method calls are very welcome.
leo
On May 30, 2006, at 22:44, Andy Dougherty wrote:
I will be stepping away from Parrot for the foreseeable future.
Many thanks for all the contributions to parrot.
leo
On Thu, Jun 01, 2006 at 11:52:59AM +1200, Sam Vilain wrote:
: The lock on entry approach will only be for non-threaded interpreters
: that don't know how to do real STM.
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you po
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the locks in virtual time such that they still make sense. Then you
jus
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
> Larry Wall wrote:
> >The way I see it, the fundamental difference is that with ordinary
> >locking, you're locking in real time, whereas with STM you potentially
> >have the ability to virtualize time to see if there's a way to order
* Adrian Howard <[EMAIL PROTECTED]> [2006-05-31T10:55:20]
> In short
> * Yes running one test method at a time is a sensible things to do.
> * No - there currently isn't a simple way of doing this
> * Good news - Ovid has submitted a patch to make it easy
> * Bad news - I've been too bone idle to a
16 matches
Mail list logo