Daniel Grunblatt wrote:
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
what if we just don't want to implement that opcode in this specific
architecture?
Prefered: provide a native function doing the e.g. "div" and call this
function from within the emi
Jason Gloudon (via RT) wrote:
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #18520]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18520 >
This patch just adds a new control flow flag to op.h a
Steve Fink wrote:
Looks like somebody gave the TD-* machines the correct input. Yay! We
can actually see some green again!
t/op/interp.t 1 256 21 50.00% 2
unimp restart on PPC
t/op/lexicals.t6 1536 66 100.00% 1-6
t/pmc/scratchpad.t
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Steve Fink) wrote:
[snip]
> ### glastig (Mac OS X 10.1) ###
>
> I've seen this message before, but I thought it was fixed now:
> "find_type returned 0 for illegal wanted -68". The next failure is
> similar: "Sub PMCs should be type 17 but have i
On Mon, Nov 18, 2002 at 10:57:10AM -0800, Michael Lazzaro wrote:
>
> --- Numeric Literals ---
>
> bin/oct/hex notation:
>
> 0b0110 # bin
> 0c0123 # oct
> 0x00ff # hex
> 0x00fF # hex, == 0x00ff
> 0x00FF # hex, == 0x00ff
I would assume that 0B0110, 0C0
At 21:33 on 11/19/2002 PST, Steve Fink <[EMAIL PROTECTED]> wrote:
> ### galactic-lcc (Debian x86, lcc 4.1) ###
>
> Failed the "mod_n" test in number.t, and the "pushn & popn (deep)"
> test in stacks.t.
Not sure what the story is with pushn/popn, but the mod_n failure is normal
for lcc- it appear
At 9:33 PM -0800 11/19/02, Steve Fink wrote:
### glastig (Mac OS X 10.1) ###
I've seen this message before, but I thought it was fixed now:
"find_type returned 0 for illegal wanted -68". The next failure is
similar: "Sub PMCs should be type 17 but have incorrect type 16".
That's a test I added wh
On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
> Michael Lazzaro writes:
> > Let's summarize some of the string-to-num issues:
> >
> >my int $i = literal "0xff"; # 255
> >
> >
> > (3) -- We want to be able to parse a string as a number using a very
> > _specific
Looks like somebody gave the TD-* machines the correct input. Yay! We
can actually see some green again!
On the other hand, everything else is still failing. I tried compiling
on a Solaris box, but the darned thing worked flawlessly. Here's a
summary of what's going wrong on the various tinderboxe
> # I am thinking one should have to predeclare
> # in a sub's preamble that such a trick will
> # be going on.
> #
> # Thus something like:
> #
> # sub foo [&bar] { ... }
> #
> # is (part of what is) required to be allowed
> # to create a bar sub in the context of the
> # caller of foo.
>
>
On Nov-17, Robert Spier wrote:
> chromatic writes:
> >My plan is to funnel all Perl 6 test patches through the normal
> >process, so they may start showing up on this list. (If people
> >object, we can find something else.)
>
> The perl6 queue is not currently active in RT. Since development is
Me:
# I am thinking one should have to predeclare
# in a sub's preamble that such a trick will
# be going on.
#
# Thus something like:
#
# sub foo [&bar] { ... }
#
# is (part of what is) required to be allowed
# to create a bar sub in the context of the
# caller of foo.
So how does Exporter
> # I'm uncomfortable [that]
> # one can reach in to the caller's lexical
> # context from any place in a callee's body.
>
> We need that capability if we're going to
> have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
c
On Tue, Nov 19, 2002 at 10:59:02AM -0800, Michael Lazzaro wrote:
: OK, back to this, so we can finish it up: we have a number of proposals
: & questions re: string-to-num conversions, and from Luke we have some
: initial docs for them that need completing. Can I get more feedback on
: these iss
Me:
# > > Elements of this shared vocabulary might be
# > > called 'locals' or 'yours'.
# >
# > I like the 'yours' idea from the point of
# > view of the callee:
# >
# > my $inherited = your $_;
#
# I like that syntax, but I'm uncomfortable
# with an underlying principle, which is that
#
Me wrote:
> > c) the ability to break lexical scope
>
> Well, I could argue that c) already exists
> in the form of passing parameters in parens.
>
> Of course, that doesn't feel like "breaking"
> anything.
Formal parameters are lexically scoped.
Lexical scope: references to the established ent
> > Elements of this shared vocabulary might be
> > called 'locals' or 'yours'.
>
> I like the 'yours' idea from the point of
> view of the callee:
>
> my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the ca
On 2002-11-19 at 16:44:49, Me wrote:
> Elements of this shared vocabulary might be
> called 'locals' or 'yours'.
I like the 'yours' idea from the point of view of the callee:
my $inherited = your $_;
However, I also like the idea of having to mark shareable lexicals
explicitly in the call
> inheriting a caller's topic isn't going to be
> that common a thing that it needs such a short
> name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
> c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like "breaking"
anything.
So instead I'll argue that the word "break"
is perhaps prejudicially perjorative.
I'd say, to steer away from be
--- Deborah Ariel Pickett <[EMAIL PROTECTED]> wrote:
> Ah . . . one message with two things I wanted to talk about. Good.
>
> Allison wrote:
> > On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
> > > So what's wrong with:
> > >
> > > sub foo($param is topic //= $= // 5)# Sho
Austin wrote:
> > > The idea of $= as CALLER::_ is good, though.
> >
> > Though C is a nasty sequence.
>
> Final // only required for "another default":
> //= $= // 5 # Default to $CALLER::_, or 5
Aye, it's just a worst case scenario. C and C<= $=> are still
line-noisy. It's a trade-off betw
On Monday, November 18, 2002, at 04:54 PM, Larry Wall wrote:
: (B) Need to know the root of the numeric types
:
: Option 1:
: numeric (mostly abstract base class)
: - num
: - int
:
: Option 2:
:
: num (floating point 'num' is the base class)
: -
On Tue, Nov 19, 2002 at 03:40:33PM -0300, Daniel Grunblatt wrote:
> On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
> > We could do it like parrot (dest, src, src) too, but I want really a
> > unique naming convention.
> >
> > leo
>
> Cool, let's do it like parrot.
Good call.
I think
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
> > So what's wrong with:
> >
> > sub foo($param is topic //= $= // 5)# Shorter form with $=
> > sub foo($param is topic //= $CALLER::_ // 5)
> >
> > It doesn't really seem like
Ah . . . one message with two things I wanted to talk about. Good.
Allison wrote:
> On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
> > So what's wrong with:
> >
> > sub foo($param is topic //= $= // 5)# Shorter form with $=
> > sub foo($param is topic //= $CALLER::_ // 5)
On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
> So what's wrong with:
>
> sub foo($param is topic //= $= // 5)# Shorter form with $=
> sub foo($param is topic //= $CALLER::_ // 5)
>
> It doesn't really seem like we can make it much shorter. Yes, we could
> convert //= into
Austin wrote:
>
> For methods, will that be the invocant or the first other parameter?
>
> $string.toLanguage("french")
>
> Topic is $string, or "french" ?
It is the invocant.
Allison
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> Larry wrote:
> > I'm trying to remember why it was that we didn't always make the
> first
> > argument of any sub the topic by default. I think it had to do
> with
> > the assumption that a bare block should not work with a copy of $_
> from
> > the
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with $=
sub foo($param is topic //= $CALLER::_ // 5)
It doesn't really seem like we can make it much shorter. Yes, we could
convert //= into a single character, but why? People will understand
//=.
The idea of $= as C
Larry wrote:
> I'm trying to remember why it was that we didn't always make the first
> argument of any sub the topic by default. I think it had to do with
> the assumption that a bare block should not work with a copy of $_ from
> the outside.
I dug through the archives. We were considering al
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #18520]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18520 >
This patch just adds a new control flow flag to op.h and extracts the
additional infor
To summarize, we're discussing 3 features:
a) the ability to set the topic with a block (sub, method, etc)
b) the ability to set a default value for a parameter
c) the ability to break lexical scope
1) for $_ only
2) for any variable
Each of these features already have syntax that allows
On Mon, Nov 18, 2002 at 11:22:00AM -0800, Michael Lazzaro wrote:
: Here are some issues we need the design team to decide.
I shall presume that I can speak for the design team. :-)
: (A) How shall C-like primitive types be specified, e.g. for binding
: to/from C library routines, etc?
:
: Op
On Mon, Nov 18, 2002 at 07:39:43PM +, Graham Barr wrote:
: On Mon, Nov 18, 2002 at 10:59:07AM -0800, Larry Wall wrote:
: > I'm thinking at the moment that I'd like to go back to the Ada notation
: > and use # for the radix, and rather that using dots, use colons. So
: > an IP address would act
Michael Lazzaro said:
> (A) Unification of Literal <--> Stringified Numeric Behaviors
>
> An old proposal that I can't find anymore suggested that strings should
> be converted to a number according to the exact same rules as literals,
> such that:
>
> 0123 == "0123"
> 0xff == "0xff
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> OK, back to this, so we can finish it up: we have a number of proposals
> & questions re: string-to-num conversions, and from Luke we have some
> initial docs for them that need completing. Can I get more feedback on
> these issues, plz, and any other
>
> (E) We need to finalize what happens when a string isn't a number,
> or has additional trailing stuff. Damian gave his initial
> preference, but we need to verify & set in stone:
>
> my int $i = 'foo'; # 0, NaN, undef, or exception?
> my int $i = '5foo'; # 5, NaN, undef, or exce
OK, back to this, so we can finish it up: we have a number of proposals
& questions re: string-to-num conversions, and from Luke we have some
initial docs for them that need completing. Can I get more feedback on
these issues, plz, and any other String -> Number proposals/questions?
(A) Unifi
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
>
> > The problem is when you want to implement an opcode like div, which is
> > easy in ppc but not in arm ideas?
>
> I don't know arm, but this belongs to jit_emit.h, how it's done there is
> a different issue
> Larry wrote:
>
> So you can do it any of these ways:
>
> for <$dance> {
>
> for $dance.each {
>
> for each $dance: {
>^ note colon
1- Why is the colon there? Is this some sub-tile syntactical new-ance
that I missed in a prior message, or a new thing?
2- Why i
Damian Conway writes:
> David Wheeler asked:
>
> > How will while behave?
>
> C evaluates its first argument in scalar context, so:
>
>
> > while <$fh> {...}# Iterate until $fh.readline returns EOF?
>
> More or less. Technically: call <$fh.next> and execute the loop
> body i
> >> $_ # current topic
> >> $__ # outer topic
> >> $___ # outer outer topic
>
> [not sufficiently visibly distinct]
> [too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
--- Numeric Literals ---
62:zZ # base 62 (?)
62:z.Z # base 62 (identical?)
62:z_Z # base 62 (identical?)
62:Zz # base 62 (not identical?)
Doh! That shouldn't be in there anymore... for bases
At 6:56 AM -0500 11/19/02, Tanton Gibbs wrote:
> How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
Unfortunately, or maybe fortunately, that is impossible to read correctly
without having to move the cursor and count how many underscores
At 6:09 PM +1100 11/19/02, Damian Conway wrote:
Dan Sugalski wrote:
We're definitely going to need to nail the semantics down. Would
one thread throwing an exception require all the threads being
aborted, for example?
I would imagine so. You can't reasonably build a junction out of values
tha
Daniel Grunblatt wrote:
I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
Good idea.
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a dif
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Iain 'Spoon' Truskett wrote:
>
> >>> @a ???+??? @b
> >>> @a ???+??? @b
> >
> > Y'know, for those of us who still haven't set up Unicode, they look
> > remarkably similar =)
>
> "Think Of It As Evolution In Action"
>
> ;-)
This coming from som
I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm ideas?
I was sort of going in that direction, mips/core.jit is almost like
ppc/core.jit (If everything is on schedule I'll find s
Currently all architecures have there own core.jit. These are very
similar, e.g. checking for MAPped registers, but differ depending on
the processor architecure: basically we have 3 register machines
(alpha, arm, ppc, sparc) and a 2 register machine (i386).
My proposal is to write a universal cor
Damian Conway said:
>> Is it illegal now to use quotes in qw()?
>
> Nope. Only as the very first character of a <<...>>.
Paging Mr Cozens. ;-)
> So any of these are still fine:
>
> print << "a" "b" "c" >>;
> print <<\"a" "b" "c">>;
> print «\"a" "b" "c"»;
Presumably without
> How about this:
>
>$_ # current topic
>$__ # outer topic
>$___ # outer outer topic
>
Unfortunately, or maybe fortunately, that is impossible to read correctly
without having to move the cursor and count how many underscores exist.
It seems to me, that in English, it i
Larry Wall wrote:
> So I was thinking it'd be better to use something different to
> represent the outer topic...
How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
...etc...
I also wondered if $= might be a suitable alias to the current ite
Steve Fink wrote:
... it
just replaces make's timestamp-based dependency check with a
checksum-based check.
Ah, then it's ok.
leo
> > don't understand when one could do the
> > 'is given($_)' and not do the ($_ = $_).
>
> Any time that the caller's topic isn't
> supposed to be explicitly passed as an
> argument, but is still used within the
> subroutine.
>
> [example]
>
> And, yes, I could make it an optional
> argument, but
55 matches
Mail list logo
