Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
[ calculating registers to save ]
>> ... once per sub per location where the sub is called from. But there
>> isn't any knowledge that a sub might be called. So the cost is actually
>> more per PMC instruction t
# New Ticket Created by chromatic
# Please include the string: [perl #29521]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29521 >
Hi there,
This one-line change to t/pmc/nci.t demonstrates an apparent bug
somewhere in
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>>
>>>Not quite for this case. Or in theory yes, but... As calling the
>>>subroutine mustn't have any changes to the caller's registers, it's just
>>>simpler to save these registers th
On Tuesday 11 May 2004 10:13 pm, Larry Wall wrote:
> On Tue, May 11, 2004 at 08:31:55PM -0400, Andrew Rodland wrote:
> : On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> : > Hi
> : >
> : > Is there any chance that in perl6 there will be the possibility to
> : > write if/else statements withou
On Tue, May 11, 2004 at 08:31:55PM -0400, Andrew Rodland wrote:
: On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
: > Hi
: >
: > Is there any chance that in perl6 there will be the possibility to write
: > if/else statements without {}s with the condition at the beginning?
: >
: > Like
: >
: >
I have committed a small set of changes to the svn repository, here are
the details:
For sake of consistency throughout all the tests, I have set the
she-bang line on all to be:
#!perl -w
NOTE: I have not removed any instances of $^W=1 in the tests although
it really is no longer neede
On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> Hi
>
> Is there any chance that in perl6 there will be the possibility to write
> if/else statements without {}s with the condition at the beginning?
>
> Like
>
> if (condition)
> statement;
>
> In order not to break traditional C culture
Hi
Is there any chance that in perl6 there will be the possibility to write
if/else statements without {}s with the condition at the beginning?
Like
if (condition)
statement;
In order not to break traditional C culture. Is there any technical
reason why it wasn't done in perl5?
Regar
The fact is that not all the tests are consistent, so it is less change
for change-sake and more for consistencies-sake.
Tim has decided now anyway
On May 11, 2004, at 6:16 PM, Tim Bunce wrote:
It's sufficient. And no, don't remove it and don't change to "use
warnings:";
Tim.
So I will ma
On Tue, 2004-05-11 at 15:19, stevan little wrote:
> If 5.6.1 is the official minimum, then maybe this brings back up the -w
> vs. warnings issue? Since Ovid pointed out that 5.6 was the minimum for
> the warnings pragma, and 5.6.1 is your "official" minimum, it seems
> maybe the choice is back
If 5.6.1 is the official minimum, then maybe this brings back up the -w
vs. warnings issue? Since Ovid pointed out that 5.6 was the minimum for
the warnings pragma, and 5.6.1 is your "official" minimum, it seems
maybe the choice is back on the table.
Tim, its your baby, what do you say?
Steve
O
On Tue, May 11, 2004 at 05:44:39PM -0400, stevan little wrote:
> A question for the class:
>
> Is specifying the -w flag in the she-bang line sufficient? Or should we
> also include $^W = 1 at the top of every file as well?
It's sufficient. And no, don't remove it and don't change to "use warnin
Tim,
I see a few issues crop up with -T in the she-bang line (I made the
change to my working copy to see), but when I do 'prove -T' I see the
same issues crop up, plus then the zvpp* stuff fails (it basically
fails to load the regular test file).
I think this makes sense, the zppp* files shoul
On Tue, May 11, 2004 at 05:13:19PM -0400, stevan little wrote:
> On May 11, 2004, at 2:47 PM, Andy Lester wrote:
>
> >>One concern just popped into my head... I'd like to not have to
> >>depend on very recent versions of Test::More. Can you look into
> >>that and make recommendations about what ve
On Tue, May 11, 2004 at 01:48:47PM -0500, Andy Lester wrote:
> On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little ([EMAIL PROTECTED]) wrote:
> > Should we put the -T flag in all the test files? I can do that if so.
>
> I'd like to. I'd like every module to think about taint-safety. DBI
> es
A question for the class:
Is specifying the -w flag in the she-bang line sufficient? Or should we
also include $^W = 1 at the top of every file as well?
Steve
On May 11, 2004, at 5:39 PM, Ovid wrote:
--- stevan little <[EMAIL PROTECTED]> wrote:
If this will break things prior to 5.6 then I revers
--- stevan little <[EMAIL PROTECTED]> wrote:
> If this will break things prior to 5.6 then I reverse my proposal and
> say that we should *not* use the warnings pragma and instead use the -w
> flag.
I always find it easier to roll back unwritten code :)
Cheers,
Ovid
=
Silence is Evil
As I said, my perl experience only goes back to 5.6 so I have never
known a world without the warnings pragma :)
If this will break things prior to 5.6 then I reverse my proposal and
say that we should *not* use the warnings pragma and instead use the -w
flag.
Steve
On May 11, 2004, at 5:26 PM
--- stevan little <[EMAIL PROTECTED]> wrote:
> I would also like to propose that we remove all -w flags, and convert
> them to use the warnings pragma.
Does that mean you don't want to support versions of Perl prior to 5.6? I would think
that should
be up to Tim.
Cheers,
Ovid
=
Silence is
Andy, Tim,
I think Andy is right, we should use the -T flag.
I would also like to propose that we remove all -w flags, and convert
them to use the warnings pragma. I assume this will be backwards
compatible enough, but my perl experience only goes back to 5.6 so I
may be missing something.
Do y
Steve Fink wrote:
>
> I suspect a slight variant of the above may work best. Rather than
> doing a full-out LALR(1) parser for the bottom-up components, you'd do
> a somewhat more naive but still table-driven (shift/reduce) parser,
> carefully limiting what it is assuming about the FIRST() etc. of
On Tue, May 11, 2004 at 01:47:46PM -0500, Andy Lester wrote:
> I've committed my t/41 and t/42 changes to subversion. They are not the
> same as what I submitted to the list.
>
> > Is there any reason to now use skip_all? (Remember, you're wearing
> > the official "Test Expert" hat now so you nee
On May 11, 2004, at 2:47 PM, Andy Lester wrote:
I've committed my t/41 and t/42 changes to subversion. They are not
the
same as what I submitted to the list.
Yes, that slightly confused me, which is why I asked. I assumed there
was a reason why you had chosen to not use skip_all, so I thought I
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> None of this is set in stone, but take a look and see how everyone feels
> about this.
> I'll get to IO after, since the two are pretty tightly intertwined, and
> changes to this will affect the IO stuff too.
> >Snip here<---
> Eve
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Not quite for this case. Or in theory yes, but... As calling the
subroutine mustn't have any changes to the caller's registers, it's just
simpler to save these registers that the subroutine might change.
But generating the save signat
> "mab" == mark a biggar <[EMAIL PROTECTED]> writes:
mab> You wrote:
>> i don't think there is a need for all those variants. why would alarm
>> need any special opcode when it is just a timer with a delay of abs_time
>> - NOW? let the coder handle that and lose the extra op codes.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> i disagree with the two classes. how can you handle an unexpected event
>> without know it could happen? effectively all events are expected, some
>> are more expected than others. :)
DS> The terminology there's a bit strained, and
Dan Sugalski wrote:
> chromatic wrote:
>
> > So for SDL, I'd start a separate thread that blocks on
SDL_WaitEvent,
> > creating and posting events when they happen. My main program would
> > handle the events as normal Parrot events. Standard producer
consumer
> > stuff.
> >
> > Since it's blo
The Perl 6 Summary for the week ending 2004-05-09
Ooh look. Stuff's been happening in perl6-internals again. Will wonders
never cease?
Building NCI by default
Bernhard Schmalhofer posted a patch to turn on building libnci.so by
default so that the tests in t/pmc/nci.t would get
On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little ([EMAIL PROTECTED]) wrote:
> Should we put the -T flag in all the test files? I can do that if so.
I'd like to. I'd like every module to think about taint-safety. DBI
especially, since we're dealing with tainted data if it comes from a DB,
Dan Sugalski wrote:
> At 10:33 AM -0700 5/11/04, chromatic wrote:
> >On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
> >
> >> >I'm also curious how to write an interface to an
> existing event system.
> >> >Being able to write it all in PASM is a bonus.
> >>
> >> I don't think it can be all-P
I've committed my t/41 and t/42 changes to subversion. They are not the
same as what I submitted to the list.
> Is there any reason to now use skip_all? (Remember, you're wearing
> the official "Test Expert" hat now so you need to weigh up the
> issues and make recommendations :)
We can't use sk
On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little wrote:
> Tim, Andy,
>
> Should we put the -T flag in all the test files? I can do that if so.
>
> Also, i noticed in the most recently checked in versions, that the
> 'skip_all' code was not included from the patches Andy sent for
> 41prof
On Tue, 2004-05-11 at 11:23, Dan Sugalski wrote:
> >Since it's blocking, it won't eat up too many resources -- that's nice.
> >It'd be nice to have the SDL event thread ignore events I don't care
> >about though, instead of creating event PMCs I'll just throw away later.
>
> You can always Get Ho
At 11:18 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
That'll still need some C. The event system as it stands is all
active--all event sources put events into the system, rather than
having the event system go looking at event sources for events. You'd
ei
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
> That'll still need some C. The event system as it stands is all
> active--all event sources put events into the system, rather than
> having the event system go looking at event sources for events. You'd
> either need to queue up regular timer
At 1:10 PM -0400 5/11/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Event Classes
DS> =
DS> There are two main classes of events, which we'll call expected and
DS> unexpected.
DS> An expected event is one that your program is specifically e
Tim, Andy,
Should we put the -T flag in all the test files? I can do that if so.
Also, i noticed in the most recently checked in versions, that the
'skip_all' code was not included from the patches Andy sent for
41prof_dump.t and 42prof_data.t. Are we not using 'skip_all'? If so, I
will remove
> "c" == chromatic <[EMAIL PROTECTED]> writes:
c> On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
>> >I'm also curious how to write an interface to an existing event system.
>> >Being able to write it all in PASM is a bonus.
>>
>> I don't think it can be all-PASM, except maybe (an
At 10:33 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
>I'm also curious how to write an interface to an existing event system.
>Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe (and maybe not...)
with a separate
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
> >I'm also curious how to write an interface to an existing event system.
> >Being able to write it all in PASM is a bonus.
>
> I don't think it can be all-PASM, except maybe (and maybe not...)
> with a separate thread for the existing event sour
At 10:09 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
Thinking we might want:
waitall Parray_of_events
waitany Parray_of_events
?
I certainly do!
Fair enough.
I'm also curious how to write an interface to an existing event system.
Being able to wri
> "SG" == Simon Glover <[EMAIL PROTECTED]> writes:
SG> One quick point: unless I'm misunderstanding something, there seems to
SG> be no easy way to wait on multiple events to complete if those events
SG> can occur in any order. For instance, suppose we have 5 events, P1 - P5
SG> If
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
> Thinking we might want:
>
> waitall Parray_of_events
> waitany Parray_of_events
>
> ?
I certainly do!
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
-- c
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Event Classes
DS> =
DS> There are two main classes of events, which we'll call expected and
DS> unexpected.
DS> An expected event is one that your program is specifically expecting
DS> to get as a result of a requ
Top-down and bottom-up are not mutually exclusive. At least not
completely. But self-modifying parsers are *much* easier to do with
top-down than bottom-up, because the whole point of bottom-up is that
you can analyze the grammar at "compile" (parser generation) time, and
propagate the knowledge th
At 12:20 PM -0400 5/11/04, Simon Glover wrote:
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will occ
[EMAIL PROTECTED] (Simon Cozens) writes:
> I remember reading a transcript of a talk Larry gave sometime which mentioned
> a conversation between Heidi Wall and Damian Conway, in which Heidi said
> something like "But what is the future apart from a succession of tomorrows?"
Ziggy and Kurt both fo
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will occur in some specified order (say
1-2-3-4-5), t
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> - if it calls a PASM routine, registers have to be preserved. Which
>>> registers depend on the subroutine that actually gets called (ok, this
>>> informat
On May-10, Joseph Ryan wrote:
>
> The Parse::RecDescent in parrot/lib is a hacked version that removes
> a bunch of stuff (tracing code, iirc) from the outputted grammer so
> that it runs many orders faster than the regular version. Or, to
> put it another way, it increases P6C's runspeed from "i
None of this is set in stone, but take a look and see how everyone feels
about this.
I'll get to IO after, since the two are pretty tightly intertwined, and
changes to this will affect the IO stuff too.
>Snip here<---
Events, another design sketch
Overview
Event
I apologise for asking this here, but I can't think of anywhere better for
it, and I have a feeling what I'm looking for was in a Perl 6-related talk,
so...
I remember reading a transcript of a talk Larry gave sometime which mentioned
a conversation between Heidi Wall and Damian Conway, in which
All~
Speaking as a mathematician it is pretty useful, but this is the sort of
thing that could be coded in pure PASM using I registers. After jit it
would be likely fast enough for any application. Recall that in
cryptographic stuff this is never the bottle neck as this algorithm is
already s
All~
If I recall my dragon book correctly, shift reduce parsers (which are
what most compilers use) can actually parse a larger class of grammars
then recursive descent parsers which can only parse LL(k) grammars. So
that is another good reason to have it. Perhaps Perl 6 grammars should
provi
At 2:15 PM -0500 5/10/04, Allison Randal wrote:
Dan Sugalski wrote:
I think the first step here is to get the low-level perl operations
defined, and their parrot translations worked out. For this I mean
that we need to have a list of:
Perl:
a = b + c;
Parrot:
add a, b, c
I
At 10:27 PM +0200 5/10/04, Jens Rieks wrote:
Hi,
I have written a gcd op that takes 5 arguments (3 out, 2 in)
gcd d, x, y, a, b
and returns the gcd (in d) of a and b, as well as x and y so that
d = gcd(a,b) = x*a + y*b
This op can be useful for some cryptographic stuff, should I check
At 1:02 PM -0700 5/10/04, Brent 'Dax' Royal-Gordon wrote:
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... As such I've started a FAQ in
docs/compiler_faq.pod.
When I read that file name, I though about gcc, Win32 compilers usable
for Parrot. Could be misleading ...
Index: docs/co
At 12:40 PM -0700 5/10/04, TOGoS (via RT) wrote:
This patch adds some more questions (which I,
personally, would like to know the answers to but
don't) to docs/compiler_faq.pod. It also puts them in
nice categories. Well, I think they're nice...
Looks good--applied, thanks. Now I've more work cut o
At 1:24 PM -0500 5/10/04, Allison Randal wrote:
Dan Sugalski wrote:
I'm not so sure about that. (Not that it won't be replaced, but that
it needs the grammar engine) I'm pretty sure that grammars as Larry's
defined 'em are recursive-descent, and if that's true then I've this
really nasty feelin
Bob Diertens <[EMAIL PROTECTED]> wrote:
> I found the following two bugs with the use of macro's in IMC.
Good. Thanks, applied.
leo
# New Ticket Created by Bob Diertens
# Please include the string: [perl #29502]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29502 >
Hi,
I found the following two bugs with the use of macro's in IMC.
The first bug ha
# New Ticket Created by TOGoS
# Please include the string: [perl #29488]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29488 >
OK, this is my first patch EVAR, so feel free to chew
me out if I totally screwed it up :)
On Mon 10 May 2004 19:40, stevan little <[EMAIL PROTECTED]> wrote:
> I have committed my first set of changes to the DBI svn repository. I
> am mostly still working on converting the scripts to use Test::More,
> but I have managed to slip in some additional tests here and there. The
> changes ar
64 matches
Mail list logo
