Uri Guttman <[EMAIL PROTECTED]> writes:
>
>but the question remains, what code triggers a signal handler? would you
>put a test in the very tight loop of the the op dispatcher?
Not a test. The C level signal handler just fossicks with the variables
that very tight loop is using.
>
> n> But i
On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> I'm going to try really hard to avoid that particular pitfall, if for no
> other reason than you can set things on the VMS C compilers such that you
> have 64-bit pointers and 32-bit ints by default. (Takes some work, but it's
> do
On Fri, Jan 05, 2001 at 12:38:54PM +, Nicholas Clark wrote:
> On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> > I'm going to try really hard to avoid that particular pitfall, if for no
> > other reason than you can set things on the VMS C compilers such that you
> > have 64-b
Glenn Linderman <[EMAIL PROTECTED]> writes:
> David Cantrell wrote:
>
> > And in any case, I can think of three different ways of saying 1821 in
> > English alone.
> >
> > One thousand eight hundred and twenty one
> > One thousand eight hundred twenty one
> > Eighteen hundred and twenty one
> >
>
On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> I personally think that the relying on LGPL'ed code is completely
> reasonable. Some will disagree, so we need to come to a consensus on this
> as a community.
There are actually a couple of different mostly-independent issues, but
yes, we'll need to
On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
>
> There are ac
At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > step away from saying to hell with it all and going fully public domain.
> > (Or at least pushing for it, as I don't control
On Fri, 05 Jan 2001, Piers Cawley wrote:
> But, but... 0.21 is *not* 'point twenty one', it's 'point two one',
> otherwise you get into weirdness with: .21 and .210 being spoken as
> 'point twenty one' and 'point two hundred (?:and)? ten' and all of a
> sudden the '2' in that figure has gained an
At 08:18 PM 1/5/01 +, John van V wrote:
>I am supporting regular GNU licensing to relieve the pain I am hearing
>about in the commercial zone where folks are allegedly up to NG.
People who are going to steal the source will do so regardless of the
license on the source, and the people who
David Grove wrote:
>
> Ok, let's be pedantic.
Everyone is pedantic. And they're all *right*.
> The one thing that I learned in high school speech class was that, if you
> say it, and people understand you, it's correct. It may not be proper, but
> it's correct, because it serves its purpose.
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Fri, 05 Jan 2001, Piers Cawley wrote:
> > But, but... 0.21 is *not* 'point twenty one', it's 'point two one',
> > otherwise you get into weirdness with: .21 and .210 being spoken as
> > 'point twenty one' and 'point two hundred (?:and)? ten'
Hi, can you give me a hand...I am getting serious problem with my
Multithreaded Socket. Can you send me a simple code regarding this
issue. I'm under pressure to finish the code. Anyway I am sending my
code so you can pinpoint the error(TONS OF DEFUNCT PROCESSES ARE BEING
CREATED)
Tks in
At 06:02 PM 1/5/01 -0800, Andre Ferrari de Aquino wrote:
>Hi, can you give me a hand...I am getting serious problem with my
>Multithreaded Socket. Can you send me a simple code regarding this
>issue. I'm under pressure to finish the code. Anyway I am sending my code
>so you can pinpoint the er
Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>tell can be seek F, 0, SEEK_CUR
I initally had stdio like split seek/tell. I actually implemented
the merged form as you suggest - but it turned out to be a mistake
so they are currently separate again.
The reason it is a mistake is one wants seek(F
At 07:11 PM 1/5/01 +, [EMAIL PROTECTED] wrote:
>Nicholas Clark <[EMAIL PROTECTED]> writes:
> >> and maybe have the return data have some 'I/O complete' marker so
> async I/O
> >> will work out properly.
>
>Anyone that has experience in writing prefetch style code please weigh in
>with the pit
> "n" == nick <[EMAIL PROTECTED]> writes:
>> a single test flag which is set by a
>> variety of events is all that is needed. but we also should have an op
>> loop with no test as the code could use an event loop to handle all
>> events. then dispatching is not done inline. would it
> At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > > step away from saying to hell with it all and going fully public domain.
> > > (Or at least pushing for it, as I do
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It works pretty well, all things considered. Not the easiest way to
DS> program, but async code's always a big pain in the neck.
ahh, back to the days of rt-11 which had optional callbacks for all of
its i/o calls including files. n
>On Fri, Jan 05, 2001 at 12:37:39PM -0500, Dan Sugalski wrote:
>> I've been pretty much assuming we'd need:
>>
>>open
>>close
>>seek
>>tell
>>push_filter
>>pop_filter
>>read
>>unread
>>write
>>prefetch
>>
What abo
Uri Guttman <[EMAIL PROTECTED]> writes:
> n> Explain your counter idea some more (I will _read_ rather than skim
> n> the RFCs one of these days...)
>
> n> It seems to me that decrementing counter is extra inner-loop cost,
> n> and you still have the conditional branch delay when you test
> n
I am supporting regular GNU licensing to relieve the pain I am hearing about in the
commercial zone where folks are allegedly up to NG.
Also if we use the GNU license, then we dont have to worry about applications meant
for perl being written in some other less appropriate
language because of
> "FB" == Filipe Brandenburger <[EMAIL PROTECTED]> writes:
FB> What about pread and pwrite, for reading and writing to seekable files
FB> in multiple threads? pread and pwrite get as a parameter a offset that
FB> they use to seek the file before reading or writing, but doing it
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I've been pretty much assuming we'd need:
DS>open
DS>close
DS>seek
DS>tell
DS>push_filter
DS>pop_filter
DS>read
DS>unread
DS>write
DS>prefetch
DS> and maybe have the return
At 09:22 PM 1/4/01 +, [EMAIL PROTECTED] wrote:
>Simon Cozens <[EMAIL PROTECTED]> writes:
> >On Wed, Jan 03, 2001 at 11:03:08PM +, Nick Ing-Simmons wrote:
> >> I am willing to cast bleadperl5's PerlIO into the form of a _draft_ PDD
> >> for perl6 - i.e. "this is what it does now", not "this
On Fri, Jan 05, 2001 at 12:37:39PM -0500, Dan Sugalski wrote:
> I've been pretty much assuming we'd need:
>
>open
>close
>seek
>tell
tell can be seek F, 0, SEEK_CUR
(unless tell is intended to return some other information on unseekable
files. In which case internally one could
At 09:11 AM 1/5/01 -0600, Jarkko Hietaniemi wrote:
>On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> > On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> >
> > > I personally think that the relying on LGPL'ed code is completely
> > > reasonable. Some will disagree, so we need to come t
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> Screw Visual Basic, Perl should be the scripting language of
> choice for, well, everything! :)
Well... then someone needs to make it easier to dynamically access the Win32
API from Perl.
Visual Basic has been growing up too. And it's a whole l
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>> and where is the event test call made?
NI> It isn't. PL_next_op is set by C signal handler.
and that has to be memory and data structure safe.
NI> In practice I suspect we need the test :
NI> while (PL_op = (PL_sig_op) ? P
> "n" == nick <[EMAIL PROTECTED]> writes:
>> that is so we don't dispatch events between every op code.
n> Why not? - hardware does.
n> Also once event is posted we keep going into the decrement loop
n> for all the ops until we decide to do it.
n> I don't think despatching ever
Uri Guttman <[EMAIL PROTECTED]> writes:
>
> n>push(op_ptr);
>
>fake recursion. :) this is simpler, saving the old op to a stack. you
>need to also deal with popping that back when the handler is done.
Again using hardware as a model I would like an event "context switch"
to look like a "cal
> "n" == nick <[EMAIL PROTECTED]> writes:
n> It is my personal style to use non-NULL value as "flag" - it dates
n> back to "my" RTOS on TI's 16-bit micros where memory was precious -
n> having a flag and a value was wasteful.
in my rt-11 assembly and heavy c days i did it too. i pro
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>do you mean event_flag is set to the actual op to handle the event? cute
>>use of a value based flag.
>
>The problem there is that it gets in the way if multiple events are
>pending, unless there's exactly one possible routine we can call, in which
>cas
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>we are in violent agreement.
I think so too ;-)
>a single test flag which is set by a
>variety of events is all that is needed. but we also should have an op
>loop with no test as the code could use an event loop to handle all
>events. then dispatching
At 01:19 PM 1/5/01 -0500, Uri Guttman wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> >> and where is the event test call made?
>
> NI> It isn't. PL_next_op is set by C signal handler.
>
>and that has to be memory and data structure safe.
>
> NI> In practice I suspect
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> 1. What are the consequences for t
On Wed, Dec 27, 2000 at 01:00:14PM -0500, Dan Sugalski wrote:
> At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
> >--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Why? For variables, math is math--2+2=4 regardless of
> > > whether you're one or
> > > two's complement, or BCD-encoded, or use t
> "n" == <[EMAIL PROTECTED]> writes:
n> I have some sympathy with Uri's position here. Signals and event
n> loops are close cousins. What I am less clear about is whether we
n> want to go down the Tcl route, or do something even more radical
n> like making op despatch and the event
On Fri, Jan 05, 2001 at 07:39:36PM -0500, Uri Guttman wrote:
> the former means the ENTIRE guts of perl would be run on the event
> loop. this is a cool idea IMO. the perl interpreter IS an event loop.
>
> so tell me, is that nuts or what? :)
No, it's exactly what Perl 5 does.
This is the Perl
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
first we divide into sets of three
(123,000,000)+(456,000)+(789)
then we expand
(123*1,000,000) + (456*1,000)+(789)
and expand further
(((1*100)+(20+3))*1,
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
> first we divide into sets of three
> (123,000,000)+(456,000)+(789)
> then we expa
Nathan Torkington wrote:
>
> Here's a quote from Jim McCarthy's "Dynamics of Software Development"
> that seems relevant given the recent fracas on perl6-language-regexp:
>
> Someone once asked me, "What's the hardest thing about software
> development?"
>
> I didn't hesitate. "Getting people
> "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 other things, like say run other
RC> interpret
At 03:57 PM 1/5/01 -0500, Uri Guttman wrote:
> > "n" == nick <[EMAIL PROTECTED]> writes:
> n>op_ptr = event_flag; // it _is_ the ops we want to do
> n>event_flag = NULL;
>
>do you mean event_flag is set to the actual op to handle the event? cute
>use of a value based flag.
The pr
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> do you mean event_flag is set to the actual op to handle the event? cute
>> use of a value based flag.
DS> The problem there is that it gets in the way if multiple events
DS> are pending, unless there's exactly one possible routin
> "n" == <[EMAIL PROTECTED]> writes:
>> I'm less worried about long running ops (whose fix is just a SMOP, after
>> all... :) than I am blocked ops. We can be as clever as we want with event
>> dispatch and async handling but it won't do us a darned bit of good if the
>> interpre
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> This is the Perl interpreter:
SC> while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
SC> PERL_ASYNC_CHECK();
SC> }
SC> The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
SC> do anything.
Hello.
I have some ideas (actually a wishlist) for the regular expression
subsystem (that's what it'll be, right?). I would appreciate if
perl6's regexp engine exposes the maximum possible interfaces, and
I'll expose why I think this would be nice.
1. I think it should be possible to have ``i
47 matches
Mail list logo
