27; method" is better
without "data" and possibly without "(Haystack)".
Your personal note is probably fine since you know what you meant when you
wrote it. As documentation for a general audience, I'd say it's badly written
and needs significant edits. You should totally self-publish it anyway.
Probably in a public repository so that interested people will help you improve
it.
--
Rocco Caputo
ring the reader to the copy that already exists is better than duplicating
that information.
Redundancy is tedious to read and hard to maintain.
Making the manual more readable for people who won't look things up isn't worth
that.
--
Rocco Caputo
conditions. It's nice to have
the red flags pointing at some silly code, and maybe an improvement will
come later.
I don't advocate that the improvement appear in Perl or Devel::Cover.
On the contrary, logic errors like this should be pointed out to make
better code.
--
Rocco Caputo - http://poe.perl.org/
an hour when it skips back. However, you usually do want your
absolute-timed jobs to run when the wall clock says they should be.
Something to keep in mind.
-- Rocco Caputo - http://poe.perl.org/
own what happens when you
> bolt them on both internally and externally. It is not something we can
> leave for later.
Agreed.
> Cooperative multitasking, if you really want it, can be bolted on later or
> provided as an alternative backend to a real threading system.
Disagreement, but I've grown accustomed to it. Carry on.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
en purely in
> parrot assembly.
1. B::Parrot
2. Parrot.xs
3. Providing opcodes for libperl functions and linking it in.
I haven't suggested asm(), so technically I'm safe. Right? :)
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
ice a potentially larger pool of parrot interpreters.
Essentially, physical threads become execution pipelines for the
virtual machine. The limit on system threads can be tuned to
optimally spread execution across available CPUs. It could be as
small as 1 on single-processor systems that don't switch thread
contexts well.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
fricangrey.jpg
I can't seem to find a picture of a Norwegian Blue anywhere.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
e test.pbc".
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
--- assemble.pl-origFri Sep 14 11:20:05 2001
+++ assemble.pl Fri Sep 14 12:26:38 2001
@@ -59,7 +59,9 @@
# get opcodes from guts.
-open GUTS, "interp_guts.h";
+open(GUTS, &
e current assembler,
> which seems reasonable)
>
> There probably isn't a huge amount to do with the thing--maintain macro
> substitutions, handle local labels, manage sub definitions, and suchlike
> things.
>
> Anyone?
j0. I'll do it.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
ago I wrote a prototype of it
in C for perl6-internals to tinker with. It's called "phat", there is
some discussion about it in the list archive, and the working
prototype (for prototypical values of "working") is still at
<http://poe.perl.org/phat/phat.c>.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
ackpack is a lidded container
schwern is an actor
schwern's pants are clothing
schwern's fish is a thing
etc.
Hmm... perhaps I should include magic clothing: a template with
clothing, container and lidded properties.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
that these tend to be "survivable"
signals; only the interested threads will ever notice them even when
they're broadcast everywhere.
Apropos of Perl 5: I've experimented long and hard on the language
level in perl 5, and I have a test case for detect them without using
handle
On Mon, 8 Jan 2001 23:12:15 -0200, Filipe Brandenburger wrote:
>Rocco Caputo wrote:
>
>> ...
>> [ *** code *** ]
>>
>>This could very well be an event driven program, with all the tedious
>>mucking about with callbacks done under the hood. Regardless, it co
a DBI module running
in another. The client threads would be permitted to continue on,
eventually receiving DBI responses as asynchronous callbacks.
I think that's it. Thank you for reading.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
ototype is at <http://poe.perl.org/poe2/>.
current-snapshot.tar.gz in that directory is a tarball of the whole
tree. Design notes are in Readme, the notes directory, and source
comments.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
On Fri, 5 Jan 2001 23:46:33 -0500, Uri Guttman wrote:
>>>>>> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
>
> RC> With a tightly integrated event loop, blocking perl level I/O can be
> RC> implemented in terms of internal asynchronous I/O.
e
print $client $_; # async I/O inside
}
}
This could very well be an event driven program, with all the tedious
mucking about with callbacks done under the hood. Regardless, it could
run the same as long as either threads OR async I/O are available.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
f a sample
run are included after __END__.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org
On Mon, 27 Nov 2000 12:37:52 -0500, Dan Sugalski wrote:
>At 05:17 PM 11/27/00 +, Nicholas Clark wrote:
>> > >>>>> "ST" == Sam Tregar <[EMAIL PROTECTED]>
On Thu, 28 Sep 2000 23:46:44 -0500, David Grove wrote:
[RFC 343 v1]
A camel is a horse designed by committee. What do you get when you
design a camel by committee?
-- Rocco Caputo / [EMAIL PROTECTED]
20 matches
Mail list logo
