Good point on the other special subscript values. The PIR as
currently being generated couldn't work anyway, since the subscript is
being put in an Int register instead of a PMC one.
On 9/30/08, Moritz Lenz <[EMAIL PROTECTED]> wrote:
> Mark J. Reed wrote:
>> I didn't see anything in the issue t
Mark J. Reed wrote:
> I didn't see anything in the issue tracker, nor did any tests fail,
There are failing (but TODOed) tests somewhere below
t/spec/S02-builtin_data_types/
> but am I correct in assuming that array slicing is simply not
> implemented yet in Rakudo?
Correct.
> $ ./perl6 -e 'my
I didn't see anything in the issue tracker, nor did any tests fail,
but am I correct in assuming that array slicing is simply not
implemented yet in Rakudo?
$ ./perl6 -e 'my @a = (1,2,3); say @a[0 .. 1];'
3
it takes the range in item context, which is the size of the range,
and uses that as an in
chromatic wrote:
If it's *close* (and mostly passing tests) we can always throw it back
into trunk immediately after a monthly release and give ourselves 4
weeks to clean it up.
The important thing to remember is that the GSOC project wasn't "revamp
the GC system to meet the new spec" it was
On Wed, Aug 20, 2008 at 01:22:33PM -0400, Will Coleda wrote:
> On Wed, Aug 20, 2008 at 1:15 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > The overall concepts of the incremental GC are solid, but a couple of
> > details
> > of the implementation need polishing. It's difficult to debug these type
On Wed, Aug 20, 2008 at 1:15 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 20, 2008 at 01:00:24PM +0300, Nikolay Ananiev wrote:
>
>> Today I saw Andrew's last post in his blog about the end of gsoc.
>> Since I could not find much information about the NCI and GC projects I'm
>> asking here
On Wed, Aug 20, 2008 at 01:00:24PM +0300, Nikolay Ananiev wrote:
> Today I saw Andrew's last post in his blog about the end of gsoc.
> Since I could not find much information about the NCI and GC projects I'm
> asking here: What's the status of these projects?
> Andrew's last post seems discouragi
gsoc_nci code is available in branches/gsoc_nci_001
jitted nci stubs works on i386 WIN32 and i386 LINUX
Its probably going to be merged this week.
Kevin
Nikolay Ananiev wrote:
Hey guys,
Today I saw Andrew's last post in his blog about the end of gsoc.
Since I could not find much information ab
Hey guys,
Today I saw Andrew's last post in his blog about the end of gsoc.
Since I could not find much information about the NCI and GC projects I'm
asking here: What's the status of these projects?
Andrew's last post seems discouraging. How much of the new GC is completed?
Are we going to have a
Allison Randal wrote:
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate point. Presumably
also the declining to handle an exception (the replacement for
rethrow) will cause the scheduler to move to the next exception
hand
chromatic wrote:
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate "rethrow".
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the sched
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate "rethrow".
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the scheduler that it has ha
I've been working on parsing the function prototypes in the
GL/GLU/GLUT/GLX headers, in preparation for generating bindings for all
of them during the Parrot build.
Currently my prototype parser is able to compute NCI signatures for all
but 14 out of the 1835 total prototypes found in my system's
chromatic wrote:
Regarding the function signatures in the vtable section: these should match
the calling conventions in PDD 07. I'm happy to patch them.
Go for it.
Regarding the mark vtable entry:
This method does not have
to call the "mark" method on any PMCs it marks--the
here is much left to implement!
Implementation isn't started yet. PDD 17 is scheduled for stub
implementation Jan 1.
I've got a couple of questions (or requests for clarification) so far.
1) Looking at the definition of role composition, it looks a little
different to what I had expecte
!
I've got a couple of questions (or requests for clarification) so far.
1) Looking at the definition of role composition, it looks a little
different to what I had expected.
"Composed vtable functions, methods, and attributes are not permitted to
have the same name as corresponding fea
Patrick R. Michaud wrote:
This ended up being discussed on IRC -- just to complete this thread
I'll note that we settled on the 'typeof' opcode to return the
class (or PMCProxy) object for a PMC:
$P1 = typeof $P0# $P1 is class object / PMC proxy of $P0
And committed on the pdd15oo bra
On Wed, Sep 26, 2007 at 01:57:10PM -0500, Patrick R. Michaud wrote:
> On Wed, Sep 26, 2007 at 01:39:51PM -0500, Patrick R. Michaud wrote:
> > This is primarily for Allison, but others can chip in
> >
> > 1. In PIR, if I have an Object in a PMC register, how do I
> > determine its correspo
On Wed, Sep 26, 2007 at 01:39:51PM -0500, Patrick R. Michaud wrote:
> This is primarily for Allison, but others can chip in
>
> 1. In PIR, if I have an Object in a PMC register, how do I
> determine its corresponding Class object? Is the "standard"
> mechanism to use the C opcode?
>
This is primarily for Allison, but others can chip in
1. In PIR, if I have an Object in a PMC register, how do I
determine its corresponding Class object? Is the "standard"
mechanism to use the C opcode?
$P1 = inspect $P0, 'class' # $P1 is class object of $P0
2. W
Regarding the function signatures in the vtable section: these should match
the calling conventions in PDD 07. I'm happy to patch them.
Regarding the mark vtable entry:
This method does not have
to call the "mark" method on any PMCs it marks--the DOD system
takes care of
On Friday 11 May 2007 21:26:42 Mike Mattie wrote:
> I am very interested in chromatic's pheme language. I have been reading
> through the code and looking at your TODO list. I thought I would tackle
> some of the easier issues to get a handle on PIR and help out a bit.
Great!
>
Hello,
I am very interested in chromatic's pheme language. I have been reading through
the code
and looking at your TODO list. I thought I would tackle some of the easier
issues
to get a handle on PIR and help out a bit.
questions:
1. Are you targetting r5 or r6 ? I think r6 would be a b
Will Coleda wrote:
On Apr 6, 2007, at 12:31 PM, Jonathan Worthington wrote:
Hi,
I'm adding the new vtable entries required for PDD15. A few questions.
1) become_parent we agreed should go. It appears to be completely
unused anywhere in the repository (languages included). Should we
On Apr 6, 2007, at 12:31 PM, Jonathan Worthington wrote:
Hi,
I'm adding the new vtable entries required for PDD15. A few questions.
1) become_parent we agreed should go. It appears to be completely
unused anywhere in the repository (languages included). Should we
take that as evi
On Fri, Apr 06, 2007 at 05:31:54PM +0100, Jonathan Worthington wrote:
> 1) become_parent we agreed should go. It appears to be completely unused
> anywhere in the repository (languages included). Should we take that as
> evidence enough to just kill it, or go for a standard deprecation cycle?
W
Hi,
I'm adding the new vtable entries required for PDD15. A few questions.
1) become_parent we agreed should go. It appears to be completely unused
anywhere in the repository (languages included). Should we take that as
evidence enough to just kill it, or go for a standard deprecation
On Tuesday 16 January 2007 16:56, Isaac Freeman wrote:
\
> So, for my purposes I need an embedding interface that allows for more
> control of the interpretter, e.g. the ability to inspect/modify
> namespace(s) and eventually control which opcodes are allowed, or
> register callbacks for opcodes (i
So, for my purposes I need an embedding interface that allows for more
control of the interpretter, e.g. the ability to inspect/modify
namespace(s) and eventually control which opcodes are allowed, or
register callbacks for opcodes (i.e. file access, etc) for security
purposes.
Tackling the first
On Tue, Oct 17, 2006 at 11:41:06PM +0200, Leopold Toetsch wrote:
> Anything that has the smallest smell of ever needing an extra statement after
> if or else shall use braces in the first place (IMHO).
Predicting the future is something humans are bad at, sadly.
--
Chip Salzenberg <[EMAIL PROTEC
On Nov 12, 2006, at 6:46 PM, Chip Salzenberg wrote:
char *p, q; /* not misleading, at least */
Here we see clearly expressed that both *p and q are of type char.
I think it IS misleading. I would do this as:
char *p;
char q;
As MJD says, it's better to look than to think.
On Tue, Oct 17, 2006 at 04:01:36PM -0500, Andy Lester wrote:
> if ( foo ) {
> bar();
> }
> else {
> bat();
> }
Well, that's not correct either: Our coding standards already say to omit
needless braces, and don't space inside the parens of if/while/etc. Thus,
this is the preferred format:
On Tue, Oct 17, 2006 at 02:33:55PM -0600, Kevin Tew wrote:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> > I view lines as a valuable resource. I like to fit whole functions on
> > the screen when possible so I'm more of a fan of
If you are out of lines:
$ perl -e'++$lines for 1..1000'
helps for some time, then pleae restart.
> > if (foo) b
Please, let's go with whatever's written in the PDD.
Coding standards discussions = much heat, little light.
I'm sorry I responded to anything in this thread in the first place.
Please.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> if ( foo )
> bar();
> else
> bat();
> if ( foo )
no spaces in the parens. No example in pdd07 is looking like this. There where
some ident rules in that pdd some time ago regarding that.
Above vs.:
if (foo) {
bar();
}
else {
Kevin Tew wrote:
> 1) *s should go right next to the type in function declarations and
> definitions
>
> /* incorrect */
> do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info)
> /* correct */
> do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info)
Disagree. Consider:
char* fo
Am Dienstag, 17. Oktober 2006 22:33 schrieb Kevin Tew:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable in th
Kevin Tew wrote:
Jerry thanks for finding the reference in pdd07.
Note I'm not trying to start a preference war here, I would just like
Chip to rule on some things that are not in the coding spec yet.
Thanks,
Kevin
Prvious mail should have read:
if ( foo )
bar();
else
bat();
I cant find
I cant find it in the spec pdd07 but I though Chip said no curlies on
single statements bodies of ifs
if ( foo )
bar();
else
bat();
I view lines as a valuable resource. I like to fit whole functions on
the screen when possible so I'm more of a fan of
if (foo) bar();
else bat();
Cu
On Tuesday 17 October 2006 14:01, Andy Lester wrote:
> On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
> >if (!info->thaw_result) info->thaw_result = pmc;
> >else *info->thaw_ptr = pmc;
>
> No, definitely not.
>
> if ( foo ) {
> bar();
> }
> else {
>
On 10/17/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
>if (!info->thaw_result) info->thaw_result = pmc;
>else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
if
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
1) *s should go right next to the type in function declarations and
definitions
I disagree; they should go right next to the name being declared,
since C declarations are designed to reflect the way the declared item
is later used: PMC *pmc, vi
While exploring Parrot internals I started cleaning up some code.
I'll post patches to the list, but here are some things that are not
defined by the coding standards, but of which I'm a fan.
So the question is are they acceptable in the parrot code base.
1) *s should go right next to the type
> To remove the deprecated C opcode does one simply remove
> the references to it in src/ops/object.ops (and other .ops files), and
> remove the function from src/ops/ops.num? Does one then move all of
> the ops numbers "up" so that there isn't a gap caused by removing the
> opcodes? Is this rel
Paul Cochrane schrieb:
Hi all,
I was having a poke around in DEPRECATED.pod and I've got a couple of
questions about the items therein:
.imc file extension paragraph:
There aren't any .imc files in parrot anymore as far as I can tell.
So, should this paragraph be in DEPRECATED.p
Hi all,
I was having a poke around in DEPRECATED.pod and I've got a couple of
questions about the items therein:
.imc file extension paragraph:
There aren't any .imc files in parrot anymore as far as I can tell.
So, should this paragraph be in DEPRECATED.pod anymore? If not, I ca
Am Dienstag, 3. Oktober 2006 01:58 schrieb Karl Forner:
> Hi,
>
> I coud not find detailed specifications for these PMCs, so I was wondering
> what should happen
> when they are (re)sized.
The Fixed* variants don't resize.
Yes unfilled are is set to the default value. See below
> For example:
>
Hi,
I coud not find detailed specifications for these PMCs, so I was wondering
what should happen
when they are (re)sized.
For example:
a = new FixedBooleanArray
a = 3
So a has been (re)sized in order to be able to hold 3 elements, but what
should be the value of these elements ?
Do they
On Tue, Aug 01, 2006 at 10:29:52PM -0500, Chris Dolan wrote:
> On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
>
> >While I'd been hoping that M::B had a public method for changing
> >'blib'
> >this appears not to be the case (just looking at the pod). If this
> >functionality were added we c
On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
While I'd been hoping that M::B had a public method for changing
'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [bu
On Tue, Aug 01, 2006 at 12:30:28PM -0700, chromatic wrote:
> On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote:
> > I'd say let Module::Build handle the install. The install process can
> > invoke Module::Build if it's to be part of the default install.
>
> How about when just building Parrot
On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote:
> On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote:
> > * What's the best way to integrate building this module from the main
> > Makefile? Should it be part of that process?
> That depends. Are any of the standard regression test
On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote:
> * What's the best way to integrate building this module from the main
> Makefile? Should it be part of that process?
That depends. Are any of the standard regression tests going to require
this module?
> * Where should the built modu
Hi all,
I've held off on adding Parrot::Embed to the Parrot repository, pending
satisfactory answers to a few questions. I have ideas, but I'd really love
to get input from any or all of Bernhard, Jerry, Will, Leo, and Chip. This
one's a bit weird, so I want to disrupt li
On Jul 21, 2006, at 1:12 PM, Mr. Shawn H. Corey wrote:
Chris Dolan wrote:
This would be a good entry for the FAQs for a cage cleaner.
If you're collect questions for the FAQ, here are some Andy Lester
answered for me:
I'm not, actually. :-(
Could you do one of the following, i
On Fri, Jul 21, 2006 at 02:12:57PM -0400, Mr. Shawn H. Corey wrote:
> Chris Dolan wrote:
> > 1. Do I need root privileges to install Parrot? Do I need it for Cage
> > Cleaners?
>
> You don't even need root at all. You can build in a local directory and
> not install.
In fact, for those who are d
-devel pacakages).
>>
>> Anyway, here's where I got it from:
>> ftp://ftp.software.ibm.com/software/globalization/icu/3.4.1/icu-3.4.1.tgz
>
> On a related note, I understand that ICU is recommended but not required
> for Parrot (right?). After searching in the Pa
On Tue, Mar 14, 2006 at 02:48:03PM -0800, chromatic wrote:
> On Tuesday 14 March 2006 14:14, Chip Salzenberg wrote:
>
> > What, you currently use "::" in your namespace names? On purpose? :-)
>
> I've had objects working in my PIR code before even Dan thought they
> worked. Once upon a time,
On Tuesday 14 March 2006 14:14, Chip Salzenberg wrote:
> What, you currently use "::" in your namespace names? On purpose? :-)
I've had objects working in my PIR code before even Dan thought they
worked. Once upon a time, that *was* the way to go.
Now get off my lawn!
-- c
On Tue, Mar 14, 2006 at 12:14:24PM -0800, chromatic wrote:
> On Tuesday 14 March 2006 08:03, Chip Salzenberg wrote:
> > PIR users: If namespace "foo" and global variable "foo" were no longer
> > distinct, so you had to rename one or the other in your code, would
> > you suffer any break
On Tue, Mar 14, 2006 at 08:03:02AM -0800, Chip Salzenberg wrote:
> (NOTE: I invite PIR users to read this msg, and especially item #5, and let
> me know whether you'll suffer any breakage when/if Parrot default namespaces
> go untyped, i.e. when you're no longer allowed to have a namespace and a
>
On Tuesday 14 March 2006 08:03, Chip Salzenberg wrote:
> PIR users: If namespace "foo" and global variable "foo" were no longer
> distinct, so you had to rename one or the other in your code, would
> you suffer any breakage in the first place, and if you did, would you
> have a har
Er, it's really early (excuse generator #17). So please ignore this:
On Tue, Mar 14, 2006 at 08:03:02AM -0800, Chip Salzenberg wrote:
> 1. Independent of other issues, you've prompted me to notice that I omitted
> namespaces themselves from the namespace typed interface. Hence the
> typ
(NOTE: I invite PIR users to read this msg, and especially item #5, and let
me know whether you'll suffer any breakage when/if Parrot default namespaces
go untyped, i.e. when you're no longer allowed to have a namespace and a
global variable with the same name but distinct. HLL-specific namespaces
On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
default should be entirely untyped.
Sorry I didn't catch this earlier, but I'm actually on the road today,
so
it's a good thing I caught it now before users could start co
On Fri, Mar 10, 2006 at 05:33:01PM +0100, Leopold Toetsch wrote:
> >a) Parrot's default namespace is untyped (raw). This means that a
> >variable/subroutine can't have the same name as a namespace. This
> >could break existing code.
> >
> >b) Otherwise, Parrot's namespace is (half-)typed, at leas
On Mar 8, 2006, at 14:30, Leopold Toetsch wrote:
2)
Default Namespace
The default namespace PMC will implement Parrot's current
behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending "\0" to namespace
n
Hi @chip,
1)
Namespace Opcodes
add_namespace $P0, $P1
The opcode signature looks a bit strange to me, especially when compared
to the 'add_namespace' method. Is the namespace name implied? And there
is of course again the question where to add the namespace: relative to
HLL or
On Mon, 2005-12-26 at 00:40 +0100, Leopold Toetsch wrote:
> On Dec 25, 2005, at 23:48, Steve Gunnell wrote:
[snip]
>
> > When using the Read/Readline opcodes how do we specify what encoding is
> > to be assumed for the incoming string?
>
> There is one output encoding filter currently:
>
>po
On Dec 25, 2005, at 23:48, Steve Gunnell wrote:
Hi People,
When you use $P0 = compreg, "PIR" is there any way to get an optimizing
compiler ( or not ) or do you always get a version that follows the
flags that were passed to Parrot?
Currently you can't pass any more arguments (like runcore o
Hi People,
When you use $P0 = compreg, "PIR" is there any way to get an optimizing
compiler ( or not ) or do you always get a version that follows the
flags that were passed to Parrot?
Is there any implementation of the Perl pack/unpack functions planned or
should we be using the Struct PMC?
Whe
On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
>
> What you're missing is that without the :outer information, Parrot
> wouldn't be able to decide *which* LexPads *should* be searched,
> either now (find_lex w/o LexEnv) or later (newclosure -> LexEnv).
Right and I see that this is consist
On Wed, Nov 30, 2005 at 03:58:28PM -0800, Jonathan Sillito wrote:
> On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > > 2. Should we provide a way for a compiler to provide depths to the
> > > find_lex and store_lex ops
On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > I have some clarification questions about the new pdd20
>
> > 1. What is expected to be in P0 in:
> >.lex "$a", P0
>
>
On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> I have some clarification questions about the new pdd20 on lexical
> variables -- likely stemming from my having been out of it for so
> long. Also I am happy to send a patch to pdd20 capturing these
> clarificatio
I have some clarification questions about the new pdd20 on lexical
variables -- likely stemming from my having been out of it for so
long. Also I am happy to send a patch to pdd20 capturing these
clarifications once I am sure I understand things correctly.
1. What is expected to be in P0 in
Philip Taylor <[EMAIL PROTECTED]> wrote:
> I've been working on a C-to-Parrot compiler (actually an IMC backend
> for the LCC compiler), tentatively named Carrot, over the past week. It
> can currently do some reasonably useful things, like running the Cola
> compiler (with only a very small amount
According to Philip Taylor:
> * I can usually handle unsigned numbers by pretending they're signed and
> using 'I' registers, but some things appear to be awkward without new
> ops - in particular, div and cmod, and le/lt/ge/gt comparisons. (As far
> as I can tell, those are the only ones C woul
I've been working on a C-to-Parrot compiler (actually an IMC backend
for the LCC compiler), tentatively named Carrot, over the past week. It
can currently do some reasonably useful things, like running the Cola
compiler (with only a very small amount of cheating), but it has raised
a few queries:
Bloves Mr <[EMAIL PROTECTED]> wrote:
> hi,folks.
> I am reading PMC C source code and reading some document("
> http://www.perl.com/pub/a/2002/01/30/pmcs.html";).
Despite that the text is rather old, it's remarkably valid still.
> Some questions:
> *this PM
hi,folks.
I am reading PMC C source code and reading some document("
http://www.perl.com/pub/a/2002/01/30/pmcs.html";).
Some questions:
*this PMC design have changed?
*any body offer some advice that learn PMC C source code and PMC's theory?
Thanks.
/*
p2p is a protocol or a compiler?
*/
theUser BL <[EMAIL PROTECTED]> wrote:
> But I see two problems:
> 1. the license
I can't comment on that, IANAL.
> 2. Parrot is written by Perl-people for Perl
No, definitely not. I'm for example just an occasional Perl user.
> I think it would be better, if there existing a group of 2 Perl pe
At 09:47 AM 3/11/2005, theUser BL wrote:
(with the languages Nice and Groovy) and .net, but written esecialy for
scripting-languages.
True, Parrot is slanted toward dynamic scripting languages that recompile
and eval themselves
on the fly, but it does provide low-level registers and features that
On Friday 11 March 2005 08:47 am, theUser BL wrote:
> I have already written this to perl6-all, but it seems, that it doesn't was
> send.
>
> I wanted to know, if any other scripting langue is plans to use parrot.
>
> Your plan of Parrot - as I have understood it - is to have not only a VM
> for Pe
>From one Perl6/Parrot lurker to another:
On Fri, 11 Mar 2005 14:47:14 +, "theUser BL" <[EMAIL PROTECTED]>
said:
> Your plan of Parrot - as I have understood it - is to have not only a VM
> for
> Perl. You want to have a VM for diffeent languages, like the JavaVM (with
> the languages Nice a
I have already written this to perl6-all, but it seems, that it doesn't was
send.
I wanted to know, if any other scripting langue is plans to use parrot.
Your plan of Parrot - as I have understood it - is to have not only a VM for
Perl. You want to have a VM for diffeent languages, like the Java
Is it possible to:
1) define methods for a PMC/Object in C that aren't vtable methods? How?
2) call subroutines defined in bytecode from C? How?
Simon Glover <[EMAIL PROTECTED]> wrote:
> 1) When we resize a Resizable*Array (where * = Integer, Float or String)
> by calling set_integer_native, we also set the PMC's active_destroy
> flag. However, we don't do this when resizing a ResizablePMCArray
> (which also has a different memory allo
1) When we resize a Resizable*Array (where * = Integer, Float or String)
by calling set_integer_native, we also set the PMC's active_destroy
flag. However, we don't do this when resizing a ResizablePMCArray
(which also has a different memory allocation strategy). Is this
because we don't stri
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Bill Coffman <[EMAIL PROTECTED]> wrote:
>> t/library/dumper.t5 1280135 38.46% 1-2 5 8 13
> I didn't look too close, but it's probably only the entry points:
> .sub _dumper
> _global_dumper()
Fixed.
leo
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Currently, here's how the register allocator is doing.
> Failed TestStat Wstat Total Fail Failed List of Failed
> ---
> t/library/dumper.t5 1280135 38.46%
Thanks Matt,
I hope I can help out. The patch I am submitting actually does
simplify register coloring a bit. I've been waiting for perl6 with so
much anticipation, I just couldn't stand it any more, and I had to
participate.
-Bill
On Thu, 28 Oct 2004 18:17:57 -0400, Matt Fowles <[EMAIL PROTE
At 3:08 PM -0700 10/28/04, Bill Coffman wrote:
It passes the other tests, plus the
randomized tests that I created, up to 150 symbols. At that range, it
still takes about 20x longer than g++ -O2, for equivalent programs to
compile (see gen4.pl).
Still, that's not bad.
Also, it is currently runnin
Bill~
I have to say that I am really impressed by all of the work that you
are doing, and if you can make the internals of imcc a little more
approachable, you would be doing a great service.
Thanks,
Matt
On Thu, 28 Oct 2004 15:08:23 -0700, Bill Coffman <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
Hi all,
Thanks for your continued comments. Btw, I usually read all the
parrot list, so don't think I'm not paying attention.
Currently, here's how the register allocator is doing.
Failed TestStat Wstat Total Fail Failed List of Failed
-
At 9:36 PM +0200 10/27/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:09 AM +0200 10/26/04, Leopold Toetsch wrote:
So, if you want that really super efficient, you would allocate
registers around function calls directly to that wanted register number,
which should be in the SymReg's want_reg
Dan Sugalski wrote:
At 11:09 AM +0200 10/26/04, Leopold Toetsch wrote:
So, if you want that really super efficient, you would allocate
registers around function calls directly to that wanted register number,
which should be in the SymReg's want_regno.
While true, in the general case leaving 0-15 a
At 11:09 AM +0200 10/26/04, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
> 1) In the existing parrot code, when a register is assigned, it uses
the following code:
int c = (color + MAX_COLOR/2) % MAX_COLOR;
Thus, it seems to prefer to use register #1
1 - 100 of 343 matches
Mail list logo
