D'oh,
It looks like I missed a few cases and broken the test suite with this
patch. I will post a new patch shortly.
-James
James deBoer (via RT) wrote:
# New Ticket Created by James deBoer
# Please include the string: [perl #32769]
# in the subject line of all future correspondence about this
# New Ticket Created by Will Coleda
# Please include the string: [perl #32784]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32784 >
oolong:~/research/parrot coke$ perl t/harness t/dynclass/pybuiltin.t
t/dynclass/pyb
Michael Walter wrote:
Uh, C89 is an ANSI/ISO C.
I'm not enough of a language lawyer to know when various features came
into to the language, but
gcc -std=c89 test.c
does *NOT* warn about declaration ordering issues. At least not with
gcc version 3.3.4 (Debian 1:3.3.4-6sarge1)
- Sam Ruby
On Wednesday 01 December 2004 10:04 am, Dan Sugalski wrote:
<>
> And yeah, I'm throwing perl in here because it has what is reasonably
> considered a bizarre type system (it doesn't have integers or strings
> as types. It has "singular thing", "aggregate thing accessed via
> integer offset", and "a
Uh, C89 is an ANSI/ISO C.
On Thu, 02 Dec 2004 15:55:21 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>
>
>
> > Sam Ruby <[EMAIL PROTECTED]> wrote:
> >
> >> +void init () {
> >> +SUPER();
> >> +PMC *func_args = pmc_new(INTERP, dynclass_PyList);
> >
>
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
+void init () {
+SUPER();
+PMC *func_args = pmc_new(INTERP, dynclass_PyList);
Please be careful to avoid definitions after code. This doesn't compile
with C89 compilers like gcc 2.95.3
Sorry about that.
Stupid questio
All~
I must admit I am a little confused as to what the problem is. Given
that any continuation which was originally created as a return
continuation will restore its registers, all code which uses P/S
registers will work as expected. Furthermore, I/N registers will be
usable accross function ca
Matt Diephouse <[EMAIL PROTECTED]> wrote:
>> This patch will allow all the *.imc and *.pasm benchmarks to be
>> tested by running make testbench.
> Is there a reason this hasn't been applied?
Of course. There's always a reason. I forgot to apply it. Sorry for the
delay.
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I think Leo originally brought up the "labeling" idea,
Yes, one of the first ideas I had. I've tossed it later for similar
reasons you are showing here with the ruby example. It just doesn't
work. The second was refetching from lexicals. I tossed it later
Sam Ruby <[EMAIL PROTECTED]> wrote:
> +void init () {
> +SUPER();
> +PMC *func_args = pmc_new(INTERP, dynclass_PyList);
Please be careful to avoid definitions after code. This doesn't compile
with C89 compilers like gcc 2.95.3
leo
On Mon, 29 Nov 2004 18:22:03 -0800, via RT Justin DeVuyst
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Justin DeVuyst
> # Please include the string: [perl #32699]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32
Leopold Toetsch wrote:
OTOH when you have
math.sin(2)
Python emits:
6 44 LOAD_NAME0 (math)
47 LOAD_ATTR1 (sin)
50 LOAD_CONST 1 (2)
53 CALL_FUNCTION1
which actually is a method call on the "
On Tue, Nov 30, 2004 at 08:07:49PM +, mark sparshatt wrote:
: Sam Ruby wrote:
: >I know what a singleton is. I don't know what it means to "put the
: >object into a singleton anonymous subclass", or why you would want to do
: >such a thing.
: >
:
: I think that this is in order to supports
On Dec 1, 2004, at 10:27 PM, Bill Coffman wrote:
First, consider my original post in this thread:
http://www.nntp.perl.org/group/perl.perl6.internals/27383
To summarize:
Full continuations are powerful but expensive. They are like hidden
goto's and add arcs to the control flow graph. This cause
# New Ticket Created by James deBoer
# Please include the string: [perl #32769]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32769 >
Some calls to internal_exception will include a newline, others will
not. The effect
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Well, and that's not true. I've already shown the opposite:
>> Here are agains these numbers (-O3 build, AMD 800, 5 Meg operations):
>>
>> MMD add PerlInt PerlInt 0.693220
>> MMD add PerlInt INTVAL 0.609069
>> MMD sub PerlInt PerlInt
Leopold Toetsch wrote:
Sorry about that. These hacks of course include pieces like...
Cool. Peace.
Furthermore, it is
clear that operators like "sub_p_p_p" and "set_p_p_kic" will always
perform better than callmethodcc_sc "__sub__" and callmethodcc_sc
"__getitem__" respectively.
Well, and th
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> Point of order: discussions would be a lot easier if they didnt *start
> out* with perjorative terms like "ugly hacks". One of my goals is to
> eliminate the need for if (!Interp_flags_TEST(INTERP,
> PARROT_PYTHON_MODE)) sprinkled thr
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Anyway, so much for the 'outside world' view of objects as black box
things that have properties and methods.
[ ... ]
Almost everything we do here is going to be with method calls.
There's very little that I can see that requires any f
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Almost everything we do here is going to be with method calls.
Just one additional note:
$ python
>>> from cmath import sin
>>> print sin(2+3j)
(9.15449914691-4.16890695997j)
leo
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> after the recent update, which cleaned up globals in the IMCC parser, PAST
> files are no longer interpreted.
Ah yep. Thanks, applied.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Anyway, so much for the 'outside world' view of objects as black box
> things that have properties and methods.
[ ... ]
> Almost everything we do here is going to be with method calls.
> There's very little that I can see that requires any faster access
22 matches
Mail list logo
