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
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!
> questions:
>
> 1.
> 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.pod anymore? If
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:
>
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
On Fri, 2004-08-13 at 23:47, Leopold Toetsch wrote:
> Hildo Biersma <[EMAIL PROTECTED]> wrote:
> > - How do I define a class with constant values that are accessible to
> > other classes?
> I'd just create an include file with the constants. The dot isn't
> allowed in identifiers, so you would
On Sat, Aug 14, 2004 at 12:26:23AM -0400, Michael Stone wrote:
: Finally, (and I'm just thinking about charset stuff here), exceptions
: frequently involve a bit of string processing. So if the
: charset/encoding code starts throwing exceptions, how do we write the
: string processing that thos
Hildo Biersma <[EMAIL PROTECTED]> wrote:
> This thread got side-track with perl5 issues, so let me ask again:
> - Are there any examples of creating a PMC class that maps to a C
> structure, with the PMC class (in C) setting defaults and adding
> accessor methods?
The UnmanagedStruct PMC all
> "Nick" == Nicholas Clark <[EMAIL PROTECTED]> writes:
Nick> On Mon, Aug 09, 2004 at 08:53:27AM -0400, [EMAIL PROTECTED] wrote:
>> - MQ has constants. Thousands of them. In the perl module, these get
>> mapped to perl XS subroutines (which bloats the symbol table no
>> end). For parrot, I'd
At 7:17 PM +0100 8/9/04, Nicholas Clark wrote:
The code is messy and needs refactoring so that it can be subclassed to
generate lookup tables that return other sorts of structures, such as
potentially the token lookup in the perl5 core, and the NCI signature
lookup in nci.c, which is currently a li
On Mon, Aug 09, 2004 at 01:18:32PM -0400, [EMAIL PROTECTED] wrote:
> Not sure. I'm not lookig for advice on evolving this module for
> perl5; it's gross and cumbersome, but I am not about to make deep
> changes to it. I'd much rather do it right for parrot, specially
> since I won't have to supp
On Mon, Aug 09, 2004 at 08:53:27AM -0400, [EMAIL PROTECTED] wrote:
> - MQ has constants. Thousands of them. In the perl module, these get
> mapped to perl XS subroutines (which bloats the symbol table no
> end). For parrot, I'd prefer to use two big hash tables of the type
As in at load ti
Chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-05-24 at 03:43, Leopold Toetsch wrote:
>> Yep. The main problem is that by far not all internal code paths are
>> using exceptions so that you could interfer the exit handling. This
>> needs of course being fixed somewhen.
> Is this as simple an
On Mon, 2004-05-24 at 03:43, Leopold Toetsch wrote:
> Yep. The main problem is that by far not all internal code paths are
> using exceptions so that you could interfer the exit handling. This
> needs of course being fixed somewhen.
Is this as simple and tedious as replacing all Parrot_exit() cal
Paul Querna <[EMAIL PROTECTED]> wrote:
> I have started work on building a new Apache 2.0 Module to run Parrot.
> 1) Parrot_exit() - This is used in many places after an error occurs.
> This function calls any exit callbacks previously entered, and then
> calls exit(). This is horrible from
At 09:55 PM 1/12/2004 +0100, Stéphane Payrard wrote:
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote:
> Which brings up a question. What's the difference between .local and .sym?
> --
Currently, there is none. So I went for the shortest:
grep -n -e LOCAL imcc.l
imcc.l:181:".sym"
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Which brings up a question. What's the difference between .local and .sym?
They are equivalent for plain code. *But* C<.local> was already used for
local labels inside macros of assembler.pl - so is it now - and it was
used for declaring variables in imcc
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote:
> At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote:
> >Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> >> Example:
> >
> >>.sym scalar var
> >>new var, .Perlint # the instance is a substype of C
> >
> > .sym pmc var
> >
> >is as g
Dan Sugalski wrote:
Which brings up a question. What's the difference between .local and .sym?
I was hoping someone would ask this.
Harry
At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote:
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
Example:
.sym scalar var
new var, .Perlint # the instance is a substype of C
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
Which brings up a quest
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> Example:
>.sym scalar var
>new var, .Perlint # the instance is a substype of C
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
> My understanding is that we already have that. C types
> define m
On Mon, Jan 12, 2004 at 10:05:51AM +0100, Leopold Toetsch wrote:
> Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> > Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
> > because one needs them as base pmcs so as to declare
> > pseudo-registers. This is a prerequisite to add pmc type check
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
> because one needs them as base pmcs so as to declare
> pseudo-registers. This is a prerequisite to add pmc type checking
> to imcc.
I don't think that we need the type names of abstract PMC
Simon Glover <[EMAIL PROTECTED]> wrote:
> 1. What is supposed to do?
Probably setup a new PMC *and* attach the passed properties.
> 2. What, precisely, do and do?
C does kind of a subroutine call on the PMC. The functionality
depends on the class implementing the method. C is AFAIK
unuse
Peter Gibbs wrote:
Clinton A. Pierce wrote:
LOOP: new P1, .PerlHash
branch LOOP
This is simply a long-standing GC bug. Try the attached patch and see if
it helps.
Thanks for clarifying this. Actually, when introducing GC_IS_MALLOC I
was bug compatible too ;-)
Patch included in Parrot_
Clinton A. Pierce wrote:
> LOOP: new P1, .PerlHash
> branch LOOP
> What happens is that memory gets chewed up
> quickly. Do I have the wrong idea of how the Px registers are used to
point
> to things (god, I hope not) or is there some GC that needs to happen that
> isn't (and I can expect it t
At 8:55 AM -0600 8/9/02, Jonathan Sillito wrote:
>On Tue, 2002-08-06 at 20:11, Sean O'Rourke wrote:
>> On Tue, 6 Aug 2002, Dan Sugalski wrote:
>>
>> > At 12:57 PM -0600 8/6/02, Jonathan Sillito wrote:
>> > >Can a prototyped sub take a variable number of parameters (ie can it
>> > >have 'rest'
On Tue, 2002-08-06 at 20:11, Sean O'Rourke wrote:
> On Tue, 6 Aug 2002, Dan Sugalski wrote:
>
> > At 12:57 PM -0600 8/6/02, Jonathan Sillito wrote:
> > >Can a prototyped sub take a variable number of parameters (ie can it
> > >have 'rest' params?). If so, should there be some way for the caller t
At 12:21 PM 3/2/2001 -0800, Hong Zhang wrote:
>I believe we should use low bits for tagging. It will make switch
>case much faster.
That's pretty much what I intended. The only reason not to have them as the
low bits is if there's some other field that uses multiple bits, and
optimizing for th
I believe we should use low bits for tagging. It will make switch
case much faster.
If you still emphasize on speed, we can make
0x05 => UTF-8
0x06 => UTF-16
0x07 => UTF-32
#define IS_UTF_ANY(a) \
(((a)->flags & 0x07) >= UTF-8)
However, I don't believe it is needed.
Hong
> If your inter
If your interest is in speed alone, then adding UTF_16 might offer options as
well:
FORMAT (enc_flags):
7|6|5|4|3|2|1|0
x x 0 0 1 x x x = UTF_8
x x 0 1 0 x x x = UTF_16
x x 1 0 0 x x x = UTF_32
then:
#define UTF 56
utf_encoding = UTF & enc_flags;
if( utf_encoding ) {
cout << "String is UTF_"
At 07:12 PM 3/2/2001 +, Nicholas Clark wrote:
>On Fri, Mar 02, 2001 at 02:01:35PM -0500, Dan Sugalski wrote:
> > At 02:01 PM 3/2/2001 -0500, wiz wrote:
> > > > =item BINARY (0)
> > > > =item ASCII (1)
> > > > =item EBCDIC (2)
> > > > =item UTF_8 (3)
> > > > =item UTF_32 (4)
> > > > =item NATIV
On Fri, Mar 02, 2001 at 02:01:35PM -0500, Dan Sugalski wrote:
> At 02:01 PM 3/2/2001 -0500, wiz wrote:
> > > =item BINARY (0)
> > > =item ASCII (1)
> > > =item EBCDIC (2)
> > > =item UTF_8 (3)
> > > =item UTF_32 (4)
> > > =item NATIVE_1 (5) through NATIVE_3 (7)
> >
> >A little more complex, but wh
At 02:01 PM 3/2/2001 -0500, wiz wrote:
> > =item BINARY (0)
> > =item ASCII (1)
> > =item EBCDIC (2)
> > =item UTF_8 (3)
> > =item UTF_32 (4)
> > =item NATIVE_1 (5) through NATIVE_3 (7)
>
>A little more complex, but why not use bits 3-7 as actual flags:
>7|6|5|4|3|2|1|0
>0 0 0 0 1 x x x = UTF && U
> =item BINARY (0)
> =item ASCII (1)
> =item EBCDIC (2)
> =item UTF_8 (3)
> =item UTF_32 (4)
> =item NATIVE_1 (5) through NATIVE_3 (7)
A little more complex, but why not use bits 3-7 as actual flags:
7|6|5|4|3|2|1|0
0 0 0 0 1 x x x = UTF && UTF_8
0 0 0 1 1 x x x = UTF && UTF_32
x x 1 0 1 x x x =
On Fri, 2 Mar 2001, Dan Sugalski wrote:
> At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote:
> > > Integer data types are generically referred to as Cs. There is an
> > > C typedef that is guaranteed to hold any integer type.
> >
> The intention is that if you need to deal with integers in an abstrac
At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote:
> > Integer data types are generically referred to as Cs. There is an
> > C typedef that is guaranteed to hold any integer type.
>
>Does such thing exist? Unless it is BIGINT.
I'm confused here, looks like you're missing some words from those sentence
46 matches
Mail list logo
