* the separate native type MMD enums are gone:
MMD_ADD_INT => MMD_ADD
* the native types INTVAL..PMC occupy types 0..3
* this almost halfs the MMD_table size
* enum_type_PMC serves as Any
* the special PMCs delegate, Ref and alike don't register
MMD functions any more
* get_mmd_dispatch_type
During class registration of classes that define a MMD_init table,
several new things happen:
1) a MultiSub PMC is created in the "__parrot_core" namespace once
2a) if there is just one MMD variant:
a NCI method is created in the classes namespace
2b) if there are more then one MMD variants
Please have a look at the tests in t/pmc/mmd.t
More tests welcome,
Thanks,
leo
In the following snippet (from t/pmc/mmd.t) the two function calls
dispatch to the correct subroutine:
.namespace ["main"]
.sub main @MAIN
p("ok 1\n")
p("-twice", "ok 2\n")
.end
.namespace [""]
.sub p @MULTI(string)
...
.sub p @MULTI(string, string)
* the two multi subs "p" in the same na
1) the PASM and PIR assemblers are now extended to understand arbitrary
PMC constants:
.const .Integer P0 = "42" # PASM
.const .Integer i = "42"# PIR
.const Integer i = "42"# PIR
Caveat: don't use this yet, the PMC constants vanish after the first GC
sweep. See below.
The two plain subroutine calls C and C with
objects "f isa Foo" and "b isa Bar" are calling the subroutines Foo.foo
and Bar.foo respectively. See the last test in t/pmc/mmd.t.
Not much more will work currently as function signatures are still missing.
The MultiSub object "foo" in the global name
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:19 PM +0100 3/19/05, Leopold Toetsch wrote:
>>1) builtin methods are living in a class namespace e.g.
>>
>> Float."cos"
>> ParrotIO."open" # unimplemented
> I'm way out of the loop and may have been dealt with in prior mail,
> but are we doing re
At 5:19 PM +0100 3/19/05, Leopold Toetsch wrote:
1) builtin methods are living in a class namespace e.g.
Float."cos"
ParrotIO."open" # unimplemented
I'm way out of the loop and may have been dealt with in prior mail,
but are we doing real method calls for cos() and suchlike things?
That seem
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>2) these methods can be called in various ways:
> This doesn't seem to be working for me.
Oops. I did obviously some changes in classes/nci.c instead of the pmc
file.
Thanks for reporting - fixed,
leo
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sat, 19 Mar 2005 17:19:49 +0100
. . .
2) these methods can be called in various ways:
Px = cos Py # opcode syntax
cos Px, Py # same
Px = "cos"(Py) # function call
1) builtin methods are living in a class namespace e.g.
Float."cos"
ParrotIO."open" # unimplemented
2) these methods can be called in various ways:
Px = cos Py # opcode syntax
cos Px, Py # same
Px = "cos"(Py) # function call
Px = Py."cos
I've committed a patch that currently fixes the t/dynclasses/*.t errors
with gcc 3.3.3 and possibly others.
While I wasn't able to fully track down the real problem, it seems that
dynamic library loading doesn't stand a DOD run, which is artificially
triggered by string_compare, when --gc-debug
After Dan's string patch got merged to head (thanks to Will Coleda for
sending me a diff), I've put in some more string stuff with these new
opcodes:
* charset, charsetname, find_charset
* is_whitespace, is_digit, is_wordchar, is_punctuation, is_newline
* find_whitespace, find_digit, find_wordch
I've now committed the source of the generational mark & sweep GC system.
Some remarks:
- it's by far not finished
- fails still a lot of tests [1]
- to turn it on set PARROT_GC_SUBSYSTEM to 2 in settings.h
- you might also turn on GC_GMS_DEBUG when hacking on the code
- it should be documented suf
Sam Ruby wrote:
Developers could declare such a dependency
with a IMCC macro, something like this:
.lib python_group
That could be
.class_mapping "Py", "python_group"
OTOH when the classes are built in dynclasses, we can as well hard-code
the entries. We'll see.
This would enable JITs to
Leopold Toetsch wrote:
1) There is a new opcode new Px, Sc:
new P0, "PyInt"
2) If the given class doesn't yet exist, Parrot_autoload_class is called
which has hardcode mapping for "Py" => "python_group", "Tcl" =>
"tcl_group". A bit hackish but working ...
Perhaps longer term, a change to the p
1) There is a new opcode new Px, Sc:
new P0, "PyInt"
2) If the given class doesn't yet exist, Parrot_autoload_class is called
which has hardcode mapping for "Py" => "python_group", "Tcl" =>
"tcl_group". A bit hackish but working ...
3) The pybuiltin.__load__() function is automatically called
On Sat, Dec 11, 2004 at 04:42:54AM +0100, Leopold Toetsch wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>
> > Just as C returns its first non-false argument, the interpretation
> > of C would be that it returns its single non-false argument, or 1 if
> > both (all?) arguments logically eva
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Just as C returns its first non-false argument, the interpretation
> of C would be that it returns its single non-false argument, or 1 if
> both (all?) arguments logically evaluate to false.
Yep, except *0* if both evaluate to either true or false.
On Fri, Dec 10, 2004 at 01:28:10PM -0500, Sam Ruby wrote:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of
[ From p6i ]
Patrick R. Michaud writes:
> On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> > Not quite. It gives one value if one is true or 0 (false). This is more
> > information then the perl5 implementation returns. The returned value (if
> > any) is still true but usable, if
Sam Ruby writes:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of Perl I have installed, I get "day" as the
On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> >> We need language lawyers ;)
>
> > IANAL, but I am a mathematician.Because C necessarily always
> > depends on *both* its arguments, analogies with C and C are
> > inappropriate.C cannot short-circuit, and it is not sensi
Mike Guy <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote
>> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
> has a different opinion then Parrot (or Perl6?).
> inline op xor(out INT, in INT, in INT) :base_core {
> $1 = ($2 && ! $3) ? $2 : ($3 && !
Mike Guy wrote:
Perl5 C always returns a "standard" boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Try:
perl -le "print 'day' xor 'night'"
On the version of Perl I have installed, I get "day" as the result.
- Sam Ruby
Precedence.
print("day\n" xor "night\n");
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]
Sent: Friday December 10, 2004 13:28
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject
Leopold Toetsch <[EMAIL PROTECTED]> wrote
> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 && ! $3) ? $2 : ($3 && ! $2) ? $3 : 0;
goto NEXT();
}
> We need la
Eirik Berg Hanssen <[EMAIL PROTECTED]> wrote:
> Which Perl5 (xor, undef) would this be? It does not look like the
> result is undef around here:
> [EMAIL PROTECTED]:~$ perl -le 'print defined($_)?"defined":"undef", ": «$_»"
> for map {(undef xor $_), ($_ xor undef), (undef ^ $_), ($_ ^ undef)}
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Sam Ruby <[EMAIL PROTECTED]> wrote:
>
>> I took a look into this. Apparently, in Perl5, the result of xor'ing
>> undef with anything is undef. I'm not suggesting that this is either
>> right or wrong (it actually was surprising to me),
>
> Yep. It do
Eirik Berg Hanssen wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of x
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I took a look into this. Apparently, in Perl5, the result of xor'ing
> undef with anything is undef. I'm not suggesting that this is either
> right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of xor, nor does it
Leopold Toetsch wrote:
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong
inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
I took a look into this. Apparently, in Perl5, the r
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
leo
* PerlInt isa Integer now - most is inherited
* try to improve MMD setup but failed
MMD table creation looks now at parent and tries to install inherited
MMD functions. But that's error prone and bulky and I'm too dumb to do
it right.
Currently one test (t/pmc/pmc_43.pasm) is failing due to wron
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Excellent!
Welcome.
> Question: what is the difference (conceptually) between "new" and
> "instantiate"? If they are different, these differences should be
> highlighted. If not, the opcode should be named the same in both cases.
$ perldoc -F ops/pmc.ops
Leopold Toetsch wrote:
I've added a few ops and methods:
* pow MMD function and opcodes
* hash vtable and opcode
Both aren't yet implemented in classes/*
The "new_extended" opcode and vtable got renamed to the more appropriate
"instantiate". classes/complex.pmc has an implementation of this method
If a name is stored into a namespace that starts with two underscores,
the method cache is invalidated now.
The follwing program runs now as expected:
.sub main @MAIN
.local pmc o, cl
newclass cl, "Foo"
subclass cl, cl, "Bar"
$I0 = typeof cl
o = new $I0
print o
$P0 = g
I've added a few ops and methods:
* pow MMD function and opcodes
* hash vtable and opcode
Both aren't yet implemented in classes/*
The "new_extended" opcode and vtable got renamed to the more appropriate
"instantiate". classes/complex.pmc has an implementation of this method,
the default is a fal
* namespace (class) names are now prepended with a NUL char
* fix globals ops that take a namespace
* some tests in t/pmc/globals.t
.sub Foo
.end
.namespace ["Foo"]
...
can now bew used, The two names don't collide any more.
leo
I've moved a lot of the globals into the imc_info structure. The PASM
and PIR compilers are basically re-entrant now (there are likely some
issues with line numbers in error reports).
To achieve this a lot of functions got an interpreter argument, which
unfortunately makes the patch rather big.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... This patch broke a lot of my code.
All opcode permutations [1] are still valid. Can you please provide a
PASM snippet that doesn't work anymore.
[1] except abs I, N which was the only opcode with an integer result for
a float argument and lcm N,I,I w
At 8:32 PM -0500 11/29/04, Michael Walter wrote:
There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.
Oh, absolutely. In this case the issues are personal taste (Leo
doesn't like the big list) and issues with specif
There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.
Back-to-reading-mode-ly yours,
Michael
On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:29 AM +0100 11/28/04, Leopold Toetsch
At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
Thomas Seiler <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
When is
Thomas Seiler <[EMAIL PROTECTED]> wrote:
> Another change that need more thought:
> * (is)?g[t,e] N, P variants are *not* redundant
Ops with PMCs aren't changed at all.
,--[ ABI_CHANGES ]-
| The compare and branch opcodes gt, ge, isgt, and isge for
Leopold Toetsch wrote:
[...]
Just if you had 32 N regs used before. It's using only one additional
register.
[...]
I did not touch any PMC ops.
You are of course right, maybe I hadn't had enough coffee this morning.
Sorry for the bother, and keep up the good work.
tom (who is going back into shy-
Leopold Toetsch wrote:
Thomas Seiler <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
[...]
Then there are changes that need more thought:
* replacing *_i_n with *_n_n uses a N-register and might
put stress on th
Leopold Toetsch wrote:
>I've checked in intial support for anonymous subroutines.
>
> .sub foo @ANON
>
>creates an anonymous subroutine.
On a semi-related note, can I get a classoffset without doing a hash
lookup? That is, can I store the class number I get assigned somewhere
for quick fetching?
Luke Palmer wrote:
On a semi-related note, can I get a classoffset without doing a hash
lookup? That is, can I store the class number I get assigned somewhere
for quick fetching?
It *could* be something like the example below. But that doesn't work
yet. Currently subroutines denoted with @IMMEDIA
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I can't seem to combine it with "non_prototyped".
.sub "foo" @ANON, non_prototyped
> - Sam Ruby
leo
Thomas Seiler <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>>
>>> See also subject "Too many opcodes".
>>>
> >> [...]
> >>
>> Could you undo this please? Now is not the time to be trimming ops out.
When is the time? After another 1000 opc
Leopold Toetsch wrote:
I've checked in intial support for anonymous subroutines.
.sub foo @ANON
creates an anonymous subroutine.
Cool.
I can't seem to combine it with "non_prototyped".
- Sam Ruby
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
OTOH, it won't hurt anyone and it is already in.
So why bother, unless of course there is a technical reaso
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered a
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 27, 2004 at 10:34:17AM +0100, Leopold Toetsch wrote:
>> 1) Almost half of the non-PMC compare and branch opcodes according to:
>>
>> lt a, b, L1 => ge b, a, L1
*g*
> I read this and thought of a subtle problem. So I tried some code, and
On Sat, Nov 27, 2004 at 10:34:17AM +0100, Leopold Toetsch wrote:
> 1) Almost half of the non-PMC compare and branch opcodes according to:
>
> lt a, b, L1 => ge b, a, L1
I read this and thought of a subtle problem. So I tried some code, and I
surprised myself. I don't think that your logic is
See also subject "Too many opcodes".
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered and shuffled - please recompile your PBCs [1]
* ops/
1) the new sequence to install an exception handler now is:
push_eh catch_label
2) Please replace code using set_eh, e.g.:
newsub Px, .Exception_Handler, catch_label
set_eh Px
with the new one-liner.
3) The set_eh opcode will remain valid until the next opcode cleanup.
Thanks,
leo
I've checked in intial support for anonymous subroutines.
.sub foo @ANON
creates an anonymous subroutine. It's available with the normal call syntax:
x = foo(y)
in the same module[1], as this syntax translates roughly to:
set_p_pc P0, foo
invoke
where "foo" is a visible clue for the inde
I've now removed the code that preserved P0, P1, P2 around calls. All
code that assumes P0 is the current sub ... now just breaks.
Please use the syntax construct described in the deprecation warning.
Currently failing tests: t/library/streams.t11, 14, 17, 19
leo
At 5:39 PM +0100 11/12/04, Leopold Toetsch wrote:
In that thread I also asked:
POSTCOMP subs are executed as soon as compilation is done, once again
with no parameters. Whether they do a whole lot is up in the air, but
that's not my problem, and it'll be useful for compile-and-go systems.
Can th
As outlined by Dan in [1] subs marked IMMEDIATE are run during
compilation, as soon as the compiler (in pbc.c) sees the end of that
subroutine.
There are a lot of caveats, nothing is checked currently: if that sub
does load_bytecode you'll have much fun ...
In that thread I also asked:
> POSTCO
There is of course no "eval" in Parrot. Anyway:
* the signature of a Parrot compiler PMC is now "PIt" - it returns
a Sub PMC directly - or more precisely an Eval PMC, which is a
Closure
* attached onto this Closure is the compiled bytecode
* this Closure's are named EVAL_n (n = 1...)
* it can (
Piers Cawley <[EMAIL PROTECTED]> wrote:
> And, dammit, making a full continuation isn't something a programmer
> should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
(call
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>$P1 = interpinfo .INTERPINFO_CURRENT_CONT
>>$P1 = clone $P1
>>
>>I'm still inclined to make this sequence an opcode, though. The
>>cloning is still necessary, as the return continuation is returned.
> Hrm. I think the returned continuation should b
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
>>All~
>>
>>I don't like the idea of having to dig down through the entire return
>>chain promoting these guys. Is there a reason not to use DOD/GC to
>>recycle continuations?
>
> Yes. Speed.
>
> While you can
At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Yes. Speed.
While you can skip some of the digging (since you can stop at the
first pro
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to re
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to real continuations by changing the
vtable. This
Ok, next is committed. The existing constant syntax is extended:
.const var_or_ident = "initstring"
Currently only subroutine constants are supported, e.g.
.const .Sub $P0 = "foo"
.const .Sub func = "foo"
The actual opcode emitted is "sub_p_pc" with the index of the subroutine
constant a
A first patch is in CVS. Imcc now understands the syntax:
set_p_pc P0, 0 # load PMC constant no. 0
The explicit arguments are necessary to disambiguate
set P0, 0 # assign integer 0 to P0
This isn't much useful per se, as a compiler/you doesn't know the
constant index of a PMC co
On Thu, Oct 28, 2004 at 10:06:05AM +0200, Leopold Toetsch wrote:
> * all JIT platforms except ppc and i386 are broken
>
> Takers wanted for JIT fixes. See jit/ppc/* for necessary changes.
This patch fixes JIT for the sparc platform (make testj passes
except for the streams and gc_10.pasm where it
I've now committed the new (internal) calling scheme. On the surface
nothing has changed, at least, if the code obeys to the rules in
docs/pdds/pdd03_calling_conventions.pod.
If you are using PIR code and the function call directives all will
still work. PASM code or handcrafted calls have to t
Thanks to Jeff, who pointed at that, Parrot's JIT system now explicitely
supports JITed functions that call into Parrot, like e.g. most string
functions do.
Here are the steps to use this functionality:
1) Arrange mappable registers like this:
char val_map[] = { non-volatiles, volatiles }:
2)
Dan Sugalski wrote:
What're we looking at for performance impact on mops.pasm and the other
simple benchmarks?
I've now JITted mops.pasm (and other code) running with indirect
register access. It did slow down, but not because the additional
indirection (all inner loop code is still in register
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What're we looking at for performance impact on mops.pasm and the
> other simple benchmarks?
I didn't look yet. Compiling optimized takes ages here :) Anyway:
Estimate performance impact:
JIT mops.pasm 0 (i386, PPC)
CGP mops.pasm 0 - 1%
plain mo
At 3:33 PM +0200 10/22/04, Leopold Toetsch wrote:
A serious of patches has now eliminated all direct usage of Parrot
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
ind
A serious of patches has now eliminated all direct usage of Parrot
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
indirect access of Parrot registers through a pointer
Nicholas Clark wrote:
The convention for perl5's tests isn't quite settled yet, but it seems to be
evolving to PERL_CORE being in the environment for the test scripts
Parrot now checks the env var PARROT_TEST. If it's defined, the runtime
--prefix is ignored.
leo
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 07, 2004 at 11:25:49AM +0200, Leopold Toetsch wrote:
>> Short version: an installed Parrot is now able to locate its ICU data.
>>
>> The longer story: During "make" a new file src/parrot_config.c is
>> created holding currently just one entry:
On Thu, Oct 07, 2004 at 11:25:49AM +0200, Leopold Toetsch wrote:
> Short version: an installed Parrot is now able to locate its ICU data.
>
> The longer story: During "make" a new file src/parrot_config.c is
> created holding currently just one entry: the install --prefix directory.
> During stri
Short version: an installed Parrot is now able to locate its ICU data.
The longer story: During "make" a new file src/parrot_config.c is
created holding currently just one entry: the install --prefix directory.
During string_init that directory is stat()ed and when the *directory*
exists, ICU dat
I added a --prefix argument to Configure.pl, to set the installation prefix
for make install. Previously make install seemed to work just fine, but you
had to override PREFIX at make time, which isn't great. This way, parrot's
configure & build system behaves like that of most other open source Uni
* if there is a snprintf() PARROT_HAS_SNPRINTF gets defined [1]
* if it's C99 compliant, PARROT_HAS_C99_SNPRINTF is defined too
* if it returns -1, PARROT_HAS_OLD_SNPRINTF is defined
* src/spf_render.c did check for HAS_SNPRINTF which is neither tested
nor defined
* I don't know, if we have platfo
$ cd languages/python
$ cat hello.py
print "Hello AST"
$ ./ast2past hello.py > hello.past
$ cat hello.past
# generated by pie-rate on Sun Aug 1 17:59:03 2004
Src_File("f.py")
Py_Module(
Stmts(
Py_Print(
Const('Hello PAST')
) # Py_Print
Py_Print_nl()
) # Stmts
) # Py_Module
# en
I've checked in some objects changes that allow subclassing of
(non-ParrotClass) PMCs:
.local pmc MyInt
getclass $P0, "Integer"
subclass MyInt, $P0, "MyInt"
.local pmc i
. $I0 = find_type "MyInt"
i = new $I0
i = 5# builtin set_integer_native
print i # overridden __get_string
On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 22 Jun 2004, Leopold Toetsch wrote:
>
> >>old_limit = $P0."recursion_limit"(new_limit)
>
> > That's fine. We should add this (and anything else we do this way) to the
> > interpinfo op so the valu
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jun 2004, Leopold Toetsch wrote:
>>old_limit = $P0."recursion_limit"(new_limit)
> That's fine. We should add this (and anything else we do this way) to the
> interpinfo op so the values can be fetched back out, both by bytecode and
> via th
On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> b1.py calls recursively functions, the depth is limited by the
> interpreter, which throws a RuntimeException at recursion depth 1000. So
> does Parrot now.
>
> The limit can be change by:
>
>$P0 = getinterp
>.local int new_limit
>.local in
b1.py calls recursively functions, the depth is limited by the
interpreter, which throws a RuntimeException at recursion depth 1000. So
does Parrot now.
The limit can be change by:
$P0 = getinterp
.local int new_limit
.local int old_limit
new_limit = 4711
old_limit = $P0."recursion_lim
Michael Fischer <[EMAIL PROTECTED]> wrote:
> On Jun 18, Leopold Toetsch <[EMAIL PROTECTED]> took up a keyboard and banged out
>> Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
>>
>> (The space between a number and ".." is needed, the lexer would parse
>> "1." as a float - workarounds welcome)
> if th
On Jun 18, Leopold Toetsch <[EMAIL PROTECTED]> took up a keyboard and banged out
> Slice iterators for arrays[1] and PerlStrings are working now.
>
> 1) create a slice iterator
>
> Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
>
> (The space between a number and ".." is needed, the lexer would par
Single slice values for PerlHash are functional too.
PIter = slice Phash["a", "b", "c"]
For slice ranges we probably need the perl5ish string increment and
decrement of strings.
leo
Slice iterators for arrays[1] and PerlStrings are working now.
1) create a slice iterator
Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
(The space between a number and ".." is needed, the lexer would parse
"1." as a float - workarounds welcome)
2) Reset iterator
PIter = .ITERATE_FROM_START
3) Loo
I've added a test for AIO to the config system. You can watch this
config step by running:
perl Configure.pl ... --verbose-step=AIO
I don't know, how linux-specific it is. Success/failure reports and
patches for other posixish platforms welcome.
leo
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Proposal:
> - create a new string layer that does this {en,de}coding
> - change the prototypes of PIO_Read to return a STRING*
> - change the prototypes of PIO_Write to get a STRING*
> - layer push and pop functions for ParrotIO
Done that now for the o
I've put in some changes to io:
- interface to query existing layers
- move various things around
Not much yet. But:
IO does currently translates to/from utf8 by default, so we need some
tweaking here:
Proposal:
- create a new string layer that does this {en,de}coding
- change the prototypes of
At 5:11 PM +0200 5/10/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:36 PM +0200 5/10/04, Leopold Toetsch wrote:
Interesting is the dispatch inside objects. These have a delegate
vtable which runs a PASM function. But it could be redispatched
before by installing an appr
1 - 100 of 520 matches
Mail list logo
