On Fri, Feb 22, 2002 at 03:08:58AM +, Alex Gough wrote:
> =item Division
>
> Under integer conditions, division is halted once the first fractional
> digit is calculated, with the result then being rounded to an integer
> and returned. ^
On Tue, Feb 26, 2002 at 10:57:45AM +, David Chan was heard to mutter:
> On Fri, Feb 22, 2002 at 03:08:58AM +, Alex Gough wrote:
> > =item Division
> >
> > Under integer conditions, division is halted once the first fractional
> > digit is calculated, with the result then being rounded to
At 1:59 AM -0500 2/23/02, Josh Wilmes wrote:
>I found a solaris 2.5 box with perl 5.004_04 and gcc 2.7.2. After
>installing a more modern perl, i got things to build, with a little
>tweaking. Turns out we were using a warning flag which doesn't exist on
>2.7. Simple tweak though:
Applied, than
At 6:32 PM -0600 2/22/02, Brian Lee Ray wrote:
>Fixes various warts in header files, such as:
>* macros
> -added parens to prevent problems with operator precedence
> -removed ; at end
>* removed SSIZE_MAX, since ssize_t is no longer used
>* removed some misinformation about NULL and function
At 8:47 PM -0500 2/23/02, Bryan C. Warnock wrote:
>On Saturday 23 February 2002 20:31, Dan Sugalski wrote:
>> Well, what I was thinking was we could have a section that marked all
>> the legitimate jump destinations. We could then vet this destination
>> table at load time for safe interpreters
At 8:10 PM -0800 2/23/02, Brent Dax wrote:
> typedef struct foo_t * FooPtr;
> typedef struct foo_t FOO;
Y'know, thinking about this, I don't like this trick. That should be
FOO, and FOO *.
We either typedef the struct, or the pointer to a struct. Not both.
--
At 8:35 PM -0800 2/23/02, Brent Dax wrote:
>The Magic Word in this case is "embedders".
>
>a) We can't reserve "any symbol starting with 'P'" to Parrot. That's a
>little too wide a scope.
>b) I'd rather not have embedders worrying about "is this a value type or
>a pointer type?". They don't *wan
At 7:09 PM + 2/24/02, Jonathan Stowe wrote:
>
>I assume this is a typo anyway :)
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 2:09 PM + 2/24/02, Jonathan Stowe wrote:
>
>I've sent this before, unless I am missing something this looks like it
>would give rise to a coredump at some point, unfortunately it doesn't stop
>the coredumps when running 'make testj' :(
Applied, thanks.
--
At 3:27 PM + 2/24/02, Jonathan Stowe wrote:
>I couldn't find anything on the list - if this is to stay for the time
>being perhaps we ought to skip the failing tests if we are doing 'testj' ?
It looks like its testing to see if the string register's null. Could
be wrong. I'm applying this on
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:10 PM -0800 2/23/02, Brent Dax wrote:
> > typedef struct foo_t * FooPtr;
> > typedef struct foo_t FOO;
>
> Y'know, thinking about this, I don't like this trick. That should be
> FOO, and FOO *.
>
> We either typedef the struct, or the point
Dan Sugalski:
# At 8:35 PM -0800 2/23/02, Brent Dax wrote:
# >The Magic Word in this case is "embedders".
# >
# >a) We can't reserve "any symbol starting with 'P'" to
# Parrot. That's a
# >little too wide a scope.
# >b) I'd rather not have embedders worrying about "is this a
# value type or
# >a
> Would it be good to say exactly what type of rounding this is? What
> is 19 / 5? How about 19 / -5? FWIW, here's what Perl
> currently thinks:
>
> 19 / 5 = 3
> (-19)/ 5 = -3
> 19 /-5 = -3
> (-19)/-5 = 3
On way to solve this is to provide two sets of division operators, ie
div/mod vs
Dan Sugalski:
# At 8:10 PM -0800 2/23/02, Brent Dax wrote:
# > typedef struct foo_t * FooPtr;
# > typedef struct foo_t FOO;
#
# Y'know, thinking about this, I don't like this trick. That should be
# FOO, and FOO *.
#
# We either typedef the struct, or the pointer to a struct. Not both.
Di
> >That's (potentially) an awfully big table. But maybe I'm missing the
point.
> >If we're not trusting the bytecode to be safe, and this table is part of
the
> >bytecode, how do we know the table is safe?
>
> We vet the table at load time to make sure it's safe. That way we
> avoid the cost of
At 10:30 AM -0800 2/26/02, Hong Zhang wrote:
> > >That's (potentially) an awfully big table. But maybe I'm missing the
>point.
>> >If we're not trusting the bytecode to be safe, and this table is part of
>the
>> >bytecode, how do we know the table is safe?
>>
>> We vet the table at load time
At 10:26 AM -0800 2/26/02, Brent Dax wrote:
>That'll just give us an explosion of wrapper types.
Not wrapper types, no. But 'different' types, yes.
Extenders will probably see things like:
typedef void PMC;
or
typedef char PMC;
rather than the actual struct.
>Like it or not,
>embedd
I have been concerned with the current parrot design for some time.
I don't see the clear direction for parrot.
If a vm is designed for JIT, it can be very simple on opcode system.
To real compilers, there is no difference between opcodes and regular
function calls. The compiler can inline the
At 10:31 AM -0800 2/26/02, Brent Dax wrote:
>Different scopes, different policies. Outside the core (and in places
>with external visibility) we use the Parrot_Foo-type pointer-to stuff;
>inside we use FOO. *This is the same policy we have now*, except for
>the outside the core part. I want tha
> >The KVM of Java includes pre-verify info, which serves similar purpose.
The
> >reason behind is Java bytecode verification is (kind of) NP-complete. By
> >using pre-verify info, the problem can be reduced to linear in most case.
(No one
> >prove it mathmatically, but you got the idea.)
>
> Hmm
Dan Sugalski:
# At 10:26 AM -0800 2/26/02, Brent Dax wrote:
# >That'll just give us an explosion of wrapper types.
#
# Not wrapper types, no. But 'different' types, yes.
#
# Extenders will probably see things like:
#
# typedef void PMC;
#
# or
#
# typedef char PMC;
#
# rather than the actu
Dan Sugalski:
# At 10:31 AM -0800 2/26/02, Brent Dax wrote:
# >Different scopes, different policies. Outside the core (and
# in places
# >with external visibility) we use the Parrot_Foo-type
# pointer-to stuff;
# >inside we use FOO. *This is the same policy we have now*, except for
# >the outsid
On Tue, Feb 26, 2002 at 11:15:59AM -0800, Hong Zhang wrote:
> > >The KVM of Java includes pre-verify info, which serves similar purpose.
> The
> > >reason behind is Java bytecode verification is (kind of) NP-complete. By
> > >using pre-verify info, the problem can be reduced to linear in most case
More questions on downwards binding,
> for @foo -> $a, $b { # two at a time
> ...
> }
Interpretation #1:
for @foo[0..$foo:2] -> $a,
@foo[1..$foo:2] -> $b
{ ... }
Interpretation #2:
for @foo -> $a { $b := $a; ... }
I like this second one, as a short-cut, but it's not wo
The when keyword can use a localizer that makes its target obvious but
slightly counter-intuitive.
given $x {
when /a/ { ... }
}
The problem is operations within the when-block that might expect to
use $_, the defaultdefault variable.
given $x {
when /a/ { s/a/A/; }
}
After all, I used a def
On and off we get hints that there's some wild pointer mashing going
on. Well, I'm working on the collector, and I can tell you for sure
that we're doing this somewhere. I don't supppose anyone's got some
hints as to where we're doing wild writes they might care to share?
--
On Tue, Feb 26, 2002 at 01:26:41PM -0800, Austin Hastings wrote:
>
> Possibility B- when-blocks accept a -> operator, which if used "naked"
> binds the current localizer to $_.
I think if I had a choice between
given $y -> $x {
when /a/ -> {...}
when /b/ -> {...}
...
}
Which, then, would you like:
To implicitly localize $_, losing access to an outer version,
or to have to change between implicit and explicit operations?
for @A {
for @B -> $x {
when /a/ { s/x/y/; }
}
}
What should that do?
=Austin
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> On Tu
Austin Hastings:
# --- Allison Randal <[EMAIL PROTECTED]> wrote:
# > On Tue, Feb 26, 2002 at 01:26:41PM -0800, Austin Hastings wrote:
# > >
# > > Possibility B- when-blocks accept a -> operator, which if used
# > "naked"
# > > binds the current localizer to $_.
# >
# > I think if I had a choice be
On Tue, Feb 26, 2002 at 02:20:48PM -0800, Brent Dax wrote:
> Austin Hastings:
> #
> # Which, then, would you like:
> #
> # To implicitly localize $_, losing access to an outer version,
> # or to have to change between implicit and explicit operations?
Well, I like the idea of having C and the C o
[EMAIL PROTECTED] writes:
: More questions on downwards binding,
:
: > for @foo -> $a, $b { # two at a time
: > ...
: > }
:
: Interpretation #1:
: for @foo[0..$foo:2] -> $a,
: @foo[1..$foo:2] -> $b
: { ... }
:
: Interpretation #2:
: for @foo -> $a { $b := $a; ... }
:
:
On Tuesday 26 February 2002 14:31, Brent Dax wrote:
> But they'll know about char* unless this is their first C program. I
> don't think we should expect them to know which of our types should be
> used as pointers and which shouldn't.
>
> Look at it this way. Pro: it makes things simpler for em
Bryan C. Warnock:
# On Tuesday 26 February 2002 14:31, Brent Dax wrote:
# > But they'll know about char* unless this is their first C
# program. I
# > don't think we should expect them to know which of our
# types should be
# > used as pointers and which shouldn't.
# >
# > Look at it this way. P
Dan Sugalski:
# On and off we get hints that there's some wild pointer mashing going
# on. Well, I'm working on the collector, and I can tell you for sure
# that we're doing this somewhere. I don't supppose anyone's got some
# hints as to where we're doing wild writes they might care to share?
Ju
Bryan C. Warnock:
# On Tuesday 26 February 2002 22:17, you wrote:
# > How is this the case? STRING ** and Parrot_String * are equivalent.
# > You can use & on both a STRING * and a Parrot_String to get
# a STRING**
# > (a.k.a. a Parrot_String *). I don't see where the problem is.
#
# Ah, except
35 matches
Mail list logo
