Dan Sugalski wrote:
I'm about to do exceptions, and as such I wanted to give a quick warning
to everyone who does Odd Things. (Which would be in the JIT, mainly :)
Because of the way exceptions are going to work, we need to make sure
that the code emitted for each individual opcode is
On Wed, Nov 13, 2002 at 12:33:09PM -0800, Larry Wall wrote:
: 1_2_3_4__5___6 (absurd, but doable)
Nope, _ is allowed only between digits (counting a-f as digits in hex).
Larry
Does this mean that you can't use _ in numbers if the radix is higher than 16? (For
example, in base
If memory serves me right, Nicholas Clark wrote:
I believe that it can be done with just a C compiler. (no make tool or shell
needed). If we use an equipped machine to unroll the makefile into the correct
steps (in the correct order), and turn that into C code that runs each in
turn, then we
On Thu, Nov 14, 2002 at 03:09:54PM +0530, Gopal V wrote:
Also perl6c.pbc shouldn't really worry about trojaned stuff in it as you're
not using an external bootstrapper (unlike gcc using cc)
I don't think you're totally correct. You are still relying on an external
bootstrapper, although
Hi all. I missed out on the original RFC process; it was over before
I even heard of perl6. Anyway, there's something I want to contribute to the
Perl community. I've had an idea about control structures which I've never
seen anywhere else, so I guess I'm the inventor :). I hope
These are mostly not my ideas (except activate); hopefully not too
many of them have already been used.
In the same list as last, next, and redo, we should also have
- deeper (works with nest -- cf. II: loop)
- yield and resume (for co-routines)
Also useful
Here's the next part to the Control Structures message I sent before.
The next part is to apply the same idea to loop. Please note that
this syntax conflicts with stuff already in Perl, but it's a bit clearer what
I mean when I do it this way; the question is, do we scrap my
Quoted from Seven Deadly Sins of Introductory Programming Language
Design [1] by Linda McIver and Damian Conway:
We have shown over one thousand novice programming students
the C/C++ expression:
the quick brown fox + jumps over the lazy dog
and asked them what they believe the
Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation ...
Isn't there some nifty Unicode operator perl6 could enlist? ;)
How about concatenating adjacent operands? ANSI C does this
with string constants and it works very well. It would
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm about to do exceptions, and as such I wanted to give a quick warning
to everyone who does Odd Things. (Which would be in the JIT, mainly :)
Because of the way exceptions are going to work, we need to make
--- sub.c.orig
+++ sub.c Thu Nov 7 23:15:06 2002
-139,7 +139,13
PMC * pad_pmc = pmc_new(interp, enum_class_Scratchpad);
pad_pmc-cache.int_val = 0;
-if ((base depth base-cache.int_val) || (!base depth != 0)) {
+if (base depth 0) {
+depth = base-cache.int_val +
Daniel Grunblatt wrote:
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
What JIT needs to know is the location of the resume opcode, to mark it
as a jump target properly, so that processor registers can be setup
correctly.
Well, any opcode could be a target, so I suggest to
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18379]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18379
Hello,
I used Jonathan Sillito's patch [#18170] to implement functions in
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
What JIT needs to know is the location of the resume opcode, to mark it
as a jump target properly, so that processor registers can be setup
correctly.
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote:
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
What JIT needs to know is the location of the resume opcode, to mark it
as a
Nicholas Clark wrote:
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote:
Can any opcode be a resume target without knowing that it is a resume target?
If yes, we have a nasty time being a JIT.
The question is without knowing. I think the resume address is known
(somewhere
At 3:09 PM +0530 11/14/02, Gopal V wrote:
If the Parrot team can provide a current and working perl6c.pbc for the
compiler written in perl6 , it's cool with me ... But I've seen that idea
fail quite a few times when the published binary falls out of sync with
the runtime ... Well that's just
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
- Normal runloops don't have a problem with longjmp
- JIT could have it's own low level exception handler:
* gets jumped to, so registers are still ok
I am not clear how this works if the exception is triggered in a C function
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
But I have a proposal:
- Normal runloops don't have a problem with longjmp
- JIT could have it's own low level exception handler:
What happens when C code called from the JIT generated code generates an
exception ?
* gets
On Thu, Nov 14, 2002 at 05:55:21PM +0100, Leopold Toetsch wrote:
But above is only needed, if there are callee saved registers around
which hold parrot register values not already saved. So currently not,
because there are no unsaved registers, when calling external code and
jitted OPs
At 2:07 PM + 11/14/02, Jürgen Bömmels (via RT) wrote:
This patch obsoletes #17109 (which isn't applied yet).
Does it obsolete 18170?
--
Dan
--it's like this---
Dan Sugalski
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
- JIT could have it's own low level exception handler:
* gets jumped to, so registers are still ok
* saves processor registers to parrots
* then longjmps to parrot handler
I didn't finish my response...
The way I have thought
Jason Gloudon wrote:
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
But I have a proposal:
- Normal runloops don't have a problem with longjmp
- JIT could have it's own low level exception handler:
What happens when C code called from the JIT generated code generates an
-Original Message-
From: Dan Sugalski [mailto:dan;sidhe.org]
At 2:07 PM + 11/14/02, Jürgen Bömmels (via RT) wrote:
This patch obsoletes #17109 (which isn't applied yet).
Does it obsolete 18170?
No, it seems to depend on it.
-Original Message-
From: Jürgen Bömmels
Jason Gloudon wrote:
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
I didn't finish my response...
The way I have thought this would be done (given C opcode functions raising
exceptions) is to spill parrot registers back into the interpreter structure
from hardware
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
The question is without knowing. I think the resume address is known
(somewhere at least) because the exception handler has to be set up.
If I understand it correctly, the way recent Linux handles page faulting in
the kernel may
On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation, depending on the type of the operand
on the left?
I realise the answer is probably not, given the number/string
ambiguity of Perl variables:
On Thu 14 Nov, Michael G Schwern wrote:
On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation, depending on the type of the operand
on the left?
There have been times when I have wondered if
On Thu, Nov 14, 2002 at 09:10:07PM +, Richard Proctor wrote:
There have been times when I have wondered if string concatination could be
done without any operator at all. Simply the placement of two things
next to each other as in $foo $bar or $foo$bar would silently concatenate
them.
On 2002-11-14 at 16:47:15, Michael G Schwern wrote:
string concatenation operator - please stop
http://archive.develooper.com/perl6-language;perl.org/msg06710.html
BTW, the first link there - to the bikeshed story - is broken.
This is the correct link:
Michael G Schwern wrote:
Before this starts up again, I hereby sentence all potential repliers to
first read:
string concatenation operator - please stop
http://archive.develooper.com/perl6-language;perl.org/msg06710.html
The bike shed thing is like Godwin's Law. Only I don't know
which side
At 5:57 PM -0500 11/14/02, Ken Fox wrote:
Michael G Schwern wrote:
Before this starts up again, I hereby sentence all potential repliers to
first read:
string concatenation operator - please stop
http://archive.develooper.com/perl6-language;perl.org/msg06710.html
The bike shed thing is like
From: Dan Sugalski [mailto:dan;sidhe.org]
At 5:57 PM -0500 11/14/02, Ken Fox wrote:
Wasn't one of the main problems with Jarkko's juxtaposition
proposal that it would kill indirect objects? Have we chased
our tail on this subject after the colon became required for
indirect objects?
I
Luke Palmer asked:
When junctions collapse,
Sigh, not another one of those dreadful reality TV shows:
When animals attack
When drivers collide
When junctions collapse
Next we'll get:
When mailing lists explode
When threads perpetuate
When Piers summarize
When Larrys make puns
;-)
Micholas Clarke asked:
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
Absolutely nothing. And perfectly legal. You can even call that
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 07:05:26 +1100 (EST)
From: Timothy S. Nelson [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Hi all. I missed out on the original RFC process; it was
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 07:37:51 +1100 (EST)
From: Timothy S. Nelson [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Here's the next part to the Control Structures message I
Sorry for the one-month-old response, but this message fell between the
cracks and I was just reviewing all my old new mail
In a message dated Sun, 20 Oct 2002, Me writes:
Somebody fairly recently recommended some decent fixed-width
typefaces.
I think it may have been MJD, but I can't
It is interesting that no one has yet taken the time to start defining the
terms we're using.
For instance what is a literal?
Would everyone agree with the following definition?
A literal is the represention of a constant value. It is important not to
confuse the representation with the value.
0x00ff # hex value ff
'0x00ff'# integer value 0, with trailing 'x00ff'
I think ways to solve this should be open to discussion. Hopefully
Luke can give us some proposals, since he's writing that part.
The behavior described there should stay. If you want literal-like
$N ** Inf NaN
I'd expect Inf
Er... doesn't it depend on whether Inf is odd or even, and
therefore indeterminate and therefore NaN ?
R.
On (14/11/02 14:29), Garrett Goebel wrote:
From: Garrett Goebel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Glossary?
Date: Thu, 14 Nov 2002 14:29:38 -0600
It is interesting that no one has yet taken the time to start defining the
terms we're using.
For instance what is a literal?
Michael Lazzaro [EMAIL PROTECTED] wrote
exponential:
-1.23e4 # num
-1.23E4 # num (identical)
And now I know why we can't use C. as a floating point in base 16:
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
There would be an ambiguity as to the meaning of 'e', so it should probably
On Thu, Nov 14, 2002 at 07:40:38PM +0100, Angel Faus wrote:
I would preferer to limit the usage of letter notation to just base
11-36, and have n:F = n:f for every n.
OK, sounds good: being consistent wins. Only bases up to 36 may be
expressed with letters.
MikeL
On Thursday, November 14, 2002, at 11:58 AM, Jonathan Scott Duff wrote:
=section * Caveats when using BigNum/BigRats
All literal numbers are interepreted at compile-time,
before there is any information available about the type
of the variable that will store them.
Hmm. In your example,
Stéphane Payrard wrote:
On (14/11/02 14:29), Garrett Goebel wrote:
It is interesting that no one has yet taken the time to
start defining the terms we're using.
For instance what is a literal?
Would everyone agree with the following definition?
A literal is the represention
On Thu, Nov 14, 2002 at 01:12:52PM -0700, Luke Palmer wrote:
From: Tanton Gibbs [EMAIL PROTECTED]
Date: Thu, 14 Nov 2002 15:00:57 -0500
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Maybe I'm just
On Thursday, November 14, 2002, at 10:28 AM, Michael Lazzaro wrote:
W/ regards to numeric literals, here are a number of
examples/proposals that we should verify the behavior of. Anything I
missed?
Oh, this is ignoring the issue of floats in bases other than 10. I'm
not dissing the idea,
Date: Thu, 14 Nov 2002 16:23:00 -0600
From: Jonathan Scott Duff [EMAIL PROTECTED]
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Maybe I'm just wired wrong, but Inf is the same size as Inf (since
they are the same value) To me Inf is a textual representation of
a
On (14/11/02 16:21), Garrett Goebel wrote:
From: Garrett Goebel [EMAIL PROTECTED]
To: 'Stéphane Payrard' [EMAIL PROTECTED],
Garrett Goebel [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Glossary?
Date: Thu, 14 Nov 2002 16:21:23 -0600
Stéphane Payrard wrote:
On (14/11/02
bin/oct/hex literals:
0b0110 # bin
0c0123 # oct
0x00ff # hex
0x00fF # hex, == 0x00ff
0x00FF # hex, == 0x00ff
0xf_f # ok
0x_ff # ok
I thought that bin/oct/hex literals where deprecated in favour of
explicit radix
Michael Lazzaro escribió:
We should talk about this. My original proposal was to do this:
(Case 1) base 2-10: use 0..9
(Case 2) base 11-36: use (0..9, a..z), but allow A..Z such that
0x00ff == 0x00FF
which seems necessary, IMHO.
(Case 3) base 37-62: use (0..9,a..z,A..Z),
On Thursday, November 14, 2002, at 10:37 AM, Angel Faus wrote:
I thought that bin/oct/hex literals where deprecated in favour of
explicit radix notation. But maybe I am wrong. I am?
AFAIK, I don't think it has been decided. Some people like the old
format, some people like the radix format,
On Thu, Nov 14, 2002 at 11:02:02AM -0600, Jonathan Scott Duff wrote:
Now, it would be nice to have a subroutine that, given a number, could
output in any arbitrary base. Perhaps Perl6 could have a radix()
subroutine that returns a string representation thusly:
$base = 2;
$number
Hi all,
This is the numeric literals part, reformated to follow Michael's
outline.
It has some additions:
- Complex numbers
- Further explanation of NaN/Inf, with a tentative algebra table.
- Caveats when using BigInts/BigRats
There are some open questions, but I think I am finally not
Larry Wall escribió:
: 1_2_3_4__5___6 (absurd, but doable)
Nope, _ is allowed only between digits (counting a-f as digits in
hex).
Larry
Mmm.. I thought that the whole purpose of creating a new mailing list
was to prevent you from reading it.
Not that I am against your presence
On Thursday, November 14, 2002, at 11:07 AM, Angel Faus wrote:
Larry
Mmm.. I thought that the whole purpose of creating a new mailing list
was to prevent you from reading it.
(Dunno, I suspect that once we get our initial act together (i.e. posts
drop from 70 a day to more like 20), this
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Thu, 14 Nov 2002 10:28:38 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
Of course, a key issue is that, in perl5, the treatment of numeric
literals is not at all the same as the treatment of stringified
numerics. For example:
Does someone from internals want to take on the task of finalizing this
list? We need to decide if we want to support none, some, or all of
these types/aliases.
-
The Full List of Numeric Types
In addition to the standard int and num, there are a great number of
other numeric types
On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
01_._23 # wrong?
this one has to be wrong by Larry's decree that _ is only valid
between digits (hexits?)
1.23_e_4# ok?
Hrm. This one is annoying, but I think it should be okay.
20:1.G.K# base 20
On Thu, Nov 14, 2002 at 12:22:03PM -0700, Luke Palmer wrote:
The behavior described there should stay. If you want literal-like
interpretations of strings, use the Coct function. The name of that
function should probably be changed to something more appropriate.
Clit, Cliteral, Cnum
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote:
It works just like the standard scientific notation:
the left portion of the Ce is the coefficient, and the
right is the exponent, so a number of the form CC.CCCeEE
is actually intepreted as CC.CCC * 10**EE.
For example, the
On Thu, Nov 14, 2002 at 07:40:38PM +0100, Angel Faus wrote:
Michael Lazzaro escribió:
We should talk about this. My original proposal was to do this:
(Case 1) base 2-10: use 0..9
(Case 2) base 11-36: use (0..9, a..z), but allow A..Z such that
0x00ff == 0x00FF
which
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Inf * $N Inf
^^^
presumably you meant -Inf here
Why?
Tanton
From: Tanton Gibbs [EMAIL PROTECTED]
Date: Thu, 14 Nov 2002 15:00:57 -0500
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Inf * $N Inf
^^^
presumably you meant -Inf here
Why?
I'm prepared to start checking in Perl 6 tests on behalf of the Perl 6
documentation folks. These should be considered functional tests -- they are
exploring the behavior we expect from Perl 6. Anything that's not yet
implemented will be marked as a TODO test, and we'll figure out a way to
I replied to ticket #16941 a while back but I don't think I had RT
actually send any mail to anybody. Anyone have an opinion on the patch
I put in it? (I'm trying to clean out some local changes so I can
apply other people's patches more easily.)
Thanks.
Applied, finally. Thanks.
On Nov-01, Andy Dougherty wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18189]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18189
Not OK: This is a failure report for
On Nov-08, Leopold Toetsch wrote:
Andy Dougherty (via RT) wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18189]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18189
Not
Jason Gloudon wrote:
If the JIT allocates any parrot register contents to callee-save registers
(which we use strictly as such), and calls an external function that raises an
exception, you cannot restore the contents of those registers to Parrot
registers after the external function raises an
71 matches
Mail list logo
