Thanks! Applied.
-Original Message-
From: Bryan C. Warnock
To: [EMAIL PROTECTED]
Sent: 10/6/2001 12:43 PM
Subject: [PATCH] non-init var possibility
mask and max_to_alloc are unitialized if the size requested is less that
1.
(Which it could be, since INTVAL is signed.) Of course, if i
Oops, on-list again.
On Monday 08 October 2001 12:12 am, Michael Fischer wrote:
>
> It is generated as a pass over basic_opcodes.ops, just as the function
> definitions in basic_opcodes.c are done. I figured the philosophy was
> "Don't hack the output, hack the template" if you want to change the
On Oct 07, "Bryan C. Warnock" <[EMAIL PROTECTED]> took up a keyboard and banged out
> On Sunday 07 October 2001 10:51 pm, Michael Fischer wrote:
> >
> > Questions, comments, criticisms?
>
> It looks like you're implementing this as a full, solitary switch.
>
> while (*pc) {
> switch (*pc) {
On Sunday 07 October 2001 10:51 pm, Michael Fischer wrote:
>
> Questions, comments, criticisms?
It looks like you're implementing this as a full, solitary switch.
while (*pc) {
switch (*pc) {
}
}
I don't see (on simple inspection) a default case, which implies that all
functions would
At 03:21 PM 10/6/2001 +0100, Simon Cozens wrote:
>On Sat, Oct 06, 2001 at 09:01:34AM -0500, Gibbs Tanton - tgibbs wrote:
> > which doesn't look that bad. Really, I would imagine all of this would be
> > autogenerated by process_opfunc.pl so it doesn't matter what the longhand
> > looks like.
>
>N
At 01:27 PM 10/6/2001 -0400, Bryan C. Warnock wrote:
>On Saturday 06 October 2001 01:13 pm, Michael Maraist wrote:
> > So would it be something like(ultimtaely put into a macro):
> > AUTO_OP add_p_p_p {
> > if (!P1)
> > CREATE_PMC(P1);
> > if (!P2 || !P3)
> > throw exception; // howeve
At 01:32 PM 10/6/2001 -0700, [EMAIL PROTECTED] wrote:
>ps. have to figure how to get the WinCVS thing work...
>can't seem to be able to access cvs.perl.org. I've used
>the following set up:
>
>CVSROOT = :pserver:[EMAIL PROTECTED]:/home/perlcvs
>Authentication = passwd file on the remote host.
>
>a
Ok, this is a big one. Over 500 line diff, plus a new module
for parrot/Parrot.
This patch adds a prompt to Configure.pl to allow the choice
of DO_OP() as a function dereference (current behavior) or
as a C switch() statement.
Current up until Gregor applied 2 of Bryan's patches this evening.
I
[This is short, since it's a bit late for me. A full, non-cranky,
response'll come tomorrow]
On Mon, 8 Oct 2001, V Vinay wrote:
> It is reasonable to expect these two quantities to be within a factor of 2
> or thereabouts. This measure directly says something about the quality
> of the instruct
On Sunday 07 October 2001 08:22 pm, Gregor N. Purdy wrote:
Thanks.
> > http:[EMAIL PROTECTED]/msg05429.html
>
> I don't see a problem, but I'd like to leave this one up to Dan or
> someone else.
That's fine. It's a temporary hush up until we get unsigned vals
introduced. (Currently, we're al
Bryan --
On Sun, 7 Oct 2001, Bryan C. Warnock wrote:
> I know it's my Dilemma and all, but can I get a yea/nay, commit/comment on
> these patches? My code's forked a little more than I like.
Sorry for the delays. I know the feeling. I still have four or five
sandboxes with various patches th
I know it's my Dilemma and all, but can I get a yea/nay, commit/comment on
these patches? My code's forked a little more than I like.
http:[EMAIL PROTECTED]/msg05428.html
http:[EMAIL PROTECTED]/msg05429.html
http:[EMAIL PROTECTED]/msg05430.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
Dear Dan,
You are doing a wonderful job and my intension is not to pass judgements on
any one's technical abilities on this list. We have a bunch of very
talented people here that would be difficult to match in any other group.
:> The interpreter is way too slow and we all admit to that.
:
:No,
On Sun, 7 Oct 2001, Andy Dougherty wrote:
> On Sat, 6 Oct 2001, Alex Gough wrote:
> > I've modified Configure.pl to take defaults from a previous build (if
> > there was one). This should play nicely with hints, and '--defaults'
> > by doing the Right Thing. I've added a '--nopolicy' option to d
On Sat, 6 Oct 2001, Gregor N. Purdy wrote:
> After the bytecode is loaded, but before it is executed, put it through
> a stage of processing that requires about as much information as a
> disassembler would (which is why my op_info stuff from one of my previous
> patches is required).
>
> This pr
Dear Simon,
:On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
:> This is my first mail to the list; I am a compulational complexity theorist
:
:Aaah, theorists... :)
Am Doomed, ain't I :)
:> (It is not ansi C complaint: it works on any gcc port however.
:
:The entire point of Parrot
On Sunday 07 October 2001 12:24 pm, Brent Dax wrote:
> If GCC has this great feature, maybe we should use it if the compiler is
> GCC and fall back to something else otherwise. It's not gonnna hurt on
> other compilers, and it could help significantly on GCC.
I'm already assuming that we will ha
On Sun, Oct 07, 2001 at 11:08:56AM -0500, Gibbs Tanton - tgibbs wrote:
> I guess the question with native strings is will it always be ASCII or will
> it be Shift-JIS etc...?
Can I just say: locales.
--
Ah the joys of festival + Gutenburg project. I can now have
Moby Dick read to me by Steph
On Sun, Oct 07, 2001 at 11:59:51AM -0400, Gregor N. Purdy wrote:
> The only difference here is that any time this happens (i.e., when we
> run into an 'end' op), before we return all the way out we examine
> interpreter->resume_addr. If this is not NULL, we are supposed to
> re-enter *a* core loop
In message <[EMAIL PROTECTED]>
Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> This is good, unless someone has objections I'll commit this. However, we
> also need the ability to do unicode in the assembler (I'll do this later
> today if no one beats me to it), and we need some way
Simon Cozens:
# On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
# > This is my first mail to the list; I am a compulational
# complexity theorist
#
# Aaah, theorists... :)
#
# > (It is not ansi C complaint: it works on any gcc port however.
#
# The entire point of Parrot 0.0.2 was to remi
This is good, unless someone has objections I'll commit this. However, we
also need the ability to do unicode in the assembler (I'll do this later
today if no one beats me to it), and we need some way to communicate the
encoding number between the C and the Perl code.
I guess the question with n
Simon --
> > * runops() itself is changed to have a while() loop in it so that
> > any time we drop out of the core, we'll resume if we have an
> > interpreter->resume_addr set (after reselecting the core, though).
> >
> > * process_opfunc.pl has a new "macro": RESUME(), that sets up
On Sun, Oct 07, 2001 at 11:28:18AM -0400, Gregor N. Purdy wrote:
> * runops() itself is changed to have a while() loop in it so that
> any time we drop out of the core, we'll resume if we have an
> interpreter->resume_addr set (after reselecting the core, though).
>
> * process_opfunc
All --
I've committed the patch after fixing it up based on my recent commit
of the simplified DO_OP work. Here's what just went in:
* Two new ops, trace_ic and bounds_ic that twiddle bits in
interpreter->flags and set interpreter->resume_addr.
* Two new runops core variants, so now we
The attached patch is a first stab at implementing string transcoding
and the unicode string types.
The transcoder will currently only map one UTF type to another - there
is no attempt to implement mapping to or from native strings as I wasn't
sure what the plan was for that. Presumably we will h
Dan --
> >I've continued to play with the DO_OP simplification patch I posted
> >before.
>
> Looks good, at least as far as I can tell from the diff. Go ahead and apply
> it, and I'll probably tweak from there.
I just committed this. It still wins vs. stock on my machine, I hope
YMDV too much.
On Sun, 7 Oct 2001, V Vinay wrote:
> I do not understand all the
> issues thought I have sampled the discussion over the last six months.
You may need to go back further, then.
> The interpreter is way too slow and we all admit to that.
No, we don't, actually. The benchmarks show us running ar
On Sat, 6 Oct 2001, Bryan C . Warnock wrote:
> What are our short- and long-term goals for handling printf formats for
> configurable types?
Well, the first goal was deciding what range of configurable types
would be allowed (e.g. would we even allow 'long long'). Since we're
allowing 'long lo
On Sat, 6 Oct 2001, Alex Gough wrote:
> I've modified Configure.pl to take defaults from a previous build (if
> there was one). This should play nicely with hints, and '--defaults'
> by doing the Right Thing. I've added a '--nopolicy' option to disable
> this.
I haven't thought this through to
On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
> This is my first mail to the list; I am a compulational complexity theorist
Aaah, theorists... :)
> (It is not ansi C complaint: it works on any gcc port however.
The entire point of Parrot 0.0.2 was to remind developers that the world
This is my first mail to the list; I am a compulational complexity theorist
(yes, NP - Completeness and such things :) and immensely enjoy perl
programming. I have been following parrot for the last two weeks and felt
compelled to join the discussions yesterday. I do not understand all the
issues
32 matches
Mail list logo
