(*** Sorry if this is the wrong list, I think it could interest you, as it
talks about
interface with the regexp subsystem -- that's a term a read here...
***)
Hello.
I have some ideas (actually a wishlist) for the regular expression
subsystem (that's what it'll be, right?). I would
On Fri, 5 Jan 2001 16:47:25 -0500, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'm less worried about long running ops (whose fix is just a SMOP,
DS after all... :) than I am blocked ops. We can be as clever as we
DS want with event dispatch and async handling
On Fri, Jan 05, 2001 at 09:42:12PM -0500, Brian Finney wrote:
generally speaking when you look a number and convert it into text you go through
some simble steps
say we start with this number
123,456,789
...
then we convert to words
On Fri, Jan 05, 2001 at 11:42:32PM -0500, Uri Guttman wrote:
SC 5x slowdown.
not if you just check a flag in the main loop. you only check the event
system if you have pending events or signals, etc. the key is not
checking all events on each pass thru the loop.
Which is exactly what
At 11:49 AM 1/6/01 +, Simon Cozens wrote:
On Fri, Jan 05, 2001 at 11:42:32PM -0500, Uri Guttman wrote:
SC 5x slowdown.
not if you just check a flag in the main loop. you only check the event
system if you have pending events or signals, etc. the key is not
checking all events on
On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
I think you misremember that number. IIRC it was somewhere between 3%-5%.
Gosh, really? I thought it was so significant that it didn't go in core.
If it was
Some of this ground does need to be revisited, since perl 6 isn't going to
be perl 5, and the tradeoffs are going to be different. (I'm still not sure
that checking for pending events every opcode is the way to go, either.
Piggybacking on the end of statement cleanup opcode might be a
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
I think you misremember that number. IIRC it was somewhere between 3%-5%.
SC Gosh, really? I
On Sat, Jan 06, 2001 at 01:06:51PM -0500, Dan Sugalski wrote:
At 04:01 PM 1/6/01 +, Simon Cozens wrote:
Gosh, really? I thought it was so significant that it didn't go in core.
If it was that small, why *didn't* it go in core?
Because a guaranteed 3-5% slowdown in the interpreter,
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 11:49 AM 1/6/01 +, Simon Cozens wrote:
On Fri, Jan 05, 2001 at 11:42:32PM -0500, Uri Guttman wrote:
SC 5x slowdown.
not if you just check a flag in the main loop. you only check the event
system if you have pending
At 04:01 PM 1/6/01 +, Simon Cozens wrote:
On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
I think you misremember that number. IIRC it was somewhere between 3%-5%.
Gosh, really? I thought it was so
At 01:02 PM 1/6/01 -0500, Uri Guttman wrote:
that is what i would expect form a simple flag test and every N tests
doing a full event poll. and even up to 5-10% slowdown i would think is
a good tradeoff for the flexibilty and ease of design win we get in the
i/o and event guts. but then, i have
Okay, here's a big question that ties the two major pains we have in perl
6--how do we tie threads and events together?
* Can all events be delivered to any thread?
* Will events be delivered only to the thread that caused them? If so, what
about threadless events? (Say, signals from the
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
Some of this ground does need to be revisited, since perl 6 isn't going to
be perl 5, and the tradeoffs are going to be different. (I'm still not sure
that checking for pending events every opcode is the way to go, either.
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. An interpreter can
RC then block while perl is free to do
On Sat, 06 Jan 2001 13:09:47 -0500, Dan Sugalski wrote:
Okay, here's a big question that ties the two major pains we have in perl
6--how do we tie threads and events together?
* Can all events be delivered to any thread?
Yes, but in practice events probably would only be delivered to
threads
Damian Conway writes:
I once wrote a C++-based regex engine (much simpler than Perl's!)
just like this.
I once brutalized Henry Spencer's engine into telling me when I was
on my way to a match. This was for a UI: I wanted to be able to say
that the input should only match this RE, and if they
On Fri, Jan 05, 2001 at 11:20:06AM -0600, Garrett Goebel wrote:
Visual Basic has been growing up too. And it's a whole lot easier to work
with the Win32 API, COM, ADSI, COM, etc. than Perl.
This is now firmly off-topic, but... DevKit?
--
UNIX was not designed to stop you from doing stupid
18 matches
Mail list logo
