On Mon Jun 07 14:26:44 2010, cognominal wrote:
> bash-3.2$ git diff
> diff --git a/src/pmc/mutablevar.pmc b/src/pmc/mutablevar.pmc
> index 1e5d075..0d083ac 100644
> --- a/src/pmc/mutablevar.pmc
> +++ b/src/pmc/mutablevar.pmc
> @@ -19,7 +19,7 @@ needed as scalar containers forward to their
> content
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75594]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75594 >
bash-3.2$ git diff
diff --git a/src/pmc/mutablevar.pmc b/src/pmc/mutablevar.pmc
inde
On Mon, Feb 02, 2009 at 09:27:10AM -0800, Andrew Whitworth via RT wrote:
> On Wed Jun 04 16:04:07 2008, pmichaud wrote:
> > I'm just about to commit a change to namespace.pmc that allows
> > the 'add_sub' method to store MultiSub PMCs as well as Sub PMCs.
&g
Patrick R. Michaud via RT wrote:
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
There's nothing in this area I know of that needs addressing. I suggest
closing the ticket and if we find any specific issues relating to this,
we can open one w
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
Pm
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
Pm
Patrick R. Michaud via RT wrote:
Can (should) we do one or more of the following...?
1. Mark GC as a dependency for this ticket
2. Mark this ticket as "stalled" waiting for GC issues
3. Move this ticket to the new Trac ticket queue
This would help remove this from our "active ticket" queue,
Andrew Whitworth via RT wrote:
Since I'm monkeying around in the relevant code anyway, this might be
a good task for the next calling_conventions branch. Or, if you
prefer, we could create a second branch for this conversion and do the
work there.
The general consensus on this one is to wait un
Andrew Whitworth wrote:
Since I'm monkeying around in the relevant code anyway, this might be
a good task for the next calling_conventions branch. Or, if you
prefer, we could create a second branch for this conversion and do the
work there.
Looks like it can be part of lex2 branch.
--
Bacek
the partial conversion of contexts to PMCs that I
> did at YAPC::NA 2008. We found a quicker solution to the immediate
> problem, but this is still a change we'd like to make.
>
> - The patch probably won't apply cleanly (we've removed some code since
> then).
&g
surprise and makes it unnecessarily difficult to test
> > whether an element exists within an array.
> >
> > It would be much more logical if the array-like PMCs threw an
> > exception in this circumstance.
> >
> > .sub _main
> > .local pmc a
> &
> It turns out that the namespace was a red herring. The real problem is
> that when iterating over a hash, you cannot assign to a PMC register; it
> must be a string register. So if the base collection is a hash, this
> segfaults:
>
> $P0 = shift iterator
>
> But this works fine:
>
>
On Sat Sep 13 06:37:12 2008, coke wrote:
> Merged the two relevant tickets.
--
Will "Coke" Coleda
With this commit r30847, partcl & lua are broken.
$ ./parrot languages/lua/lua.pbc
Segmentation fault
#0 0xb7c93a03 in pmc_new_noinit (interp=0x804f040, base_type=86) at
src/pmc.c:300
#1 0xb7c4dd5b in Parrot_register_HLL_type (interp=0x804f040, hll_id=1,
core_type=17, hll_type=86) at src/hll.c:
# New Ticket Created by chromatic
# Please include the string: [perl #58636]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58636 >
Patrick's example code for RT #30843 creates an infinite loop (before the
workaround check
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #57968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57968 >
- awaiting .HLL capabilities
On Sat Dec 15 00:39:19 2007, [EMAIL PROTECTED] wrote:
> If you modify one of the Perl modules that turns .pmc files into .c files,
> then run make again, nothing happens. The .pmc rules should each have a
> dependency on the appropriate .pm file.
>
> This task requires a minor amount of Perl kn
'add_sub' method to store MultiSub PMCs as well as Sub PMCs.
However, the change I'm committing is a little naive in that
a subsequent call to add_sub will overwrite any existing
MultiSub. Instead, adding a MultiSub to a namespace symbol
that already contains a MultiSub should probably merge them
together.
Pm
r an element exists within an array.
>
> It would be much more logical if the array-like PMCs threw an
> exception in this circumstance.
>
> .sub _main
> .local pmc a
> .local string s
> a = new 'ResizablePMCArray'
> a['foo'] = '
ish thing and
implicitly converts s to an int. This violates the principle of least surprise
and makes it unnecessarily difficult to test whether an element exists within
an array. It would be much more logical if the array-like PMCs threw an
exception in this circumstance.
.sub _main
On Mon Mar 31 11:27:06 2008, [EMAIL PROTECTED] wrote:
> Building with make -j occasionally (about 20% of the time) causes the
> build process to fail. The problem seems to be an undeclared
> dependency beteen src/pmc/role.pmc and src/pmc/pmc_namespace.h.
> The error is below:
> ./src/pmc/role.pmc:
# New Ticket Created by "Christoph Otto (Volt)"
# Please include the string: [perl #52316]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52316 >
Building with make -j occasionally (about 20% of the time) causes the build
On Thursday 13 December 2007 19:32:11 Will Coleda wrote:
> For example, parrotclass.pmc, parrotobject.pmc.
>
> ... Should this file be auto-generated?
That's not easy, because config/auto/pmc.pm uses it to allow people to select
at configuration time which PMCs to include and exc
On Mon May 01 06:47:17 2006, bernhard wrote:
> In 'include/parrot/parrot.h' it quite sensibly says:
>
> /* Only parrot core files should include this file.
>Extensions should include .
>Programs embedding parrot should include .
> */
>
> However all d
more cleverness.
So, you're saying it is legal to invoke a setter on a constant PObj? In
what sense then is that PObj a constant?
That depends. Is a hash declared with:
.const Hash foo
.. constant as a reference or a referent or an aggregate or some combination
of all three
. Is a hash declared with:
.const Hash foo
... constant as a reference or a referent or an aggregate or some
combination of all three?
No fair; I asked you "What *is* the purpose of constant PMCs?" first.
;-} The purpose and the definition have to agree.
In fact, we've been
hat might
be the right approach altogether -- I like how it separates the
responsibility for purifying things out of object construction.
> So I gather that the purpose of read-only PMCs in the current design is
> something other than GC efficiency.
I think it *is* for GC efficiency,
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 17:22:19 -0800
On Sunday 24 February 2008 16:55:48 Bob Rogers wrote:
> Why do constant PMCs ever need to point to non-constant ones? In other
> words, why are those pointed-to PObjs not also constant?
T
articularly the "strange" part. I suspect that Kea-CL has
> been hard hit lately because it may do things differently. Is there
> something I should be looking out for?
The use of things freed inappropriately -- PMCs with vtable pointers of
0xdeadbeef or STRINGs where strstart and
arbage collector doesn't sweep the
constant pools to recollect them.
This is not normally a problem for most constant PObjs. It's mostly fine
for
strings, and it's fine for PMCs that do not have a special mark() vtable
entry.
PMCs that *do* need a special m
On Sunday 24 February 2008 07:33:30 Leopold Toetsch wrote:
> Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic:
> > PMCs that *do* need a special mark() are troublesome; they may contain
> > pointers to non-constant PObjs that *do* need live marking, lest they get
> >
Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic:
> PMCs that *do* need a special mark() are troublesome; they may contain
> pointers to non-constant PObjs that *do* need live marking, lest they get
> swept away during the second half of GC. If these constant PObjs don't get
>
), but the garbage collector doesn't sweep the
constant pools to recollect them.
This is not normally a problem for most constant PObjs. It's mostly fine for
strings, and it's fine for PMCs that do not have a special mark() vtable
entry.
PMCs that *do* need a special mark()
# New Ticket Created by chromatic
# Please include the string: [perl #48645]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48645 >
If you modify one of the Perl modules that turns .pmc files into .c files,
then run make a
# New Ticket Created by Will Coleda
# Please include the string: [perl #48587]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48587 >
For example, parrotclass.pmc, parrotobject.pmc.
... Should this file be auto-generated??
XXX This is the behavior of Parrot 0.4.3
# It looks like core PMCs never emit warning.
# Look in perlundef.t for a more sane test of 'warningson' in subs
Looking at the following test it seems as if the core PMCs aren't supposed
to emit warnings. Is this the correct behaviour?
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46641]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46641 >
In src/pmc/hash.pmc there is the todo item:
TODO: PMCs extending Hash should proba
Leopold Toetsch wrote:
This implies (for me), that whatever silly morph requests like above would be
issued, a PMC always has the needs of 'one size fits all'. This will preclude
any optimzations of creating smaller spezialised PMCs as well as it seems to
going the "PMC_data i
7;s mostly a summary of current state
- some new good things (roles) are defined, which aren't yet in src/role/
- the old "bugs", which IMHO, a rigid PMC structure and morph are, are still
present:
...
IMPLEMENTATION
Internal structure
All PMCs have the form:
...
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46123]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46123 >
In src/debug.c:PDB_cond() there is the todo item:
else if (condition->type & PDB_cond_
I just checked in (r21293) a substantial change to the PDD 17 section
"PMCs and high-level objects", detailing the inheritance strategy from
low-level PMCs to high-level classes.
We've been poking around the edges of the problem since we started the
new metamodel, but th
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45367]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45367 >
In the pdd03 design document there is the todo item (with context):
=item 5 C (P o
er issue I encountered with my workaround for my
previous problem. Ok, Parrot does not want me to generate an NaN by
doing 0.0/0.0, but that does not prevent me from storing NaNs in them
(which come from PjsNumber PMCs). But when $N0 is NaN, comparing $N0
<= $N0 gives inconsistent results. For the
Am Mittwoch, 13. Juni 2007 05:02 schrieb chromatic:
> PMC * const key = VTABLE_nextkey_keyed(interp, key_new(interp),
> ns, ITERATE_FROM_START);
>
> If a GC run happens in the rest of this function, it could collect the
> newly created Key -- PMCs created and held outsid
newly
created Key -- PMCs created and held outside of structures visible to GC are
vulnerable to collection.
Unfortunately, I can't reproduce the problem on Linux on x86. However, I do
think that storing the key temporarily in a place where it will get marked
appropriately may fix things.
If you have a Sub PMC (or subclass), you can invoke that PMC from C code using
Parrot_call_sub() or a similar function. Of course, if you want to pass
arguments to that PMC, something needs to translate those arguments from C's
calling conventions to Parrot's calling conventions.
That somethin
Leopold Toetsch wrote:
This is what the cstruct-Proposal is for. The cstruct is describing the
internals of a PMC (which happen to consist of C structure items)
Aye. For general information, these are the current draft PDDs that I'm
merging into 1 (or 2) PMC PDDs.
pdd02_vtables.pod
pdd04_d
Am Montag, 23. April 2007 23:18 schrieb Jonathan Worthington:
> Proposal: PMCs can have attributes just as classes in HLLs have
> attributes. This is somewhat related to variable sized PMCs; note you
> can leave PMC headers fixed size and just have a pmc_ext like structure
> that is
Jonathan Worthington wrote:
Hi all,
Here's my semi-coherent collection of random thoughts about PMCs.
Wonderful! Anyone else who has encountered problems with the current
implementation of PMCs, or wishes for features PMCs don't have yet (or
features that are only partially i
Hi all,
Here's my semi-coherent collection of random thoughts about PMCs, typed
up while sitting in a nice sunny park in London last week. A lot of
details will need hashing out with these ideas. I am primarily trying to
address:
* Interaction between PMCs and classes built with Class
# New Ticket Created by Will Coleda
# Please include the string: [perl #41781]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41781 >
from docs/BROKEN.pod
Give invokable PMCs a canonical way to store their associated
# New Ticket Created by Will Coleda
# Please include the string: [perl #41780]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41780 >
From docs/BROKEN.pod
"chromatic has a test case almost ready to show this."
# New Ticket Created by Will Coleda
# Please include the string: [perl #41374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41374 >
To replace removal of Perl PMCs* from core: still should test this
functionality.
# New Ticket Created by Jerry Gay
# Please include the string: [perl #41239]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41239 >
many, if not all, core pmcs are undertested. here's a brief survey of
obvious exam
# New Ticket Created by Jerry Gay
# Please include the string: [perl #41238]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41238 >
from DEPRECATED.pod:
=item Perl PMCs
The dynamic PMCS PerlString, PerlUndef,
Hi,
It could be useful to have a way to know the exact memory footprint of any
PMC.
For instance, suppose that each PMC must override/implement a method
get_allocated_size(), it could be used to
optimize programs that takes too much memory, or to debug/optimize PMC
implementation.
That method cou
Am Montag, 9. Oktober 2006 05:12 schrieb chromatic:
> I'm experimenting with better forms of OO in PIR. I want to add a
> get_parents() method on the Class PMC. Normally, I'd do something like the
> attached patch, but the attached example file I use for testing shows that
> it doesn't work for m
I'm experimenting with better forms of OO in PIR. I want to add a
get_parents() method on the Class PMC. Normally, I'd do something like the
attached patch, but the attached example file I use for testing shows that it
doesn't work for me.
I dug around a bit and couldn't find a reason for why
Am Sonntag, 8. Oktober 2006 04:25 schrieb chromatic:
> I'm doing more work on the embedding interface. Given that some Parrot
> functions may legitimately send and receive PMCs, what are the implications
> for garbage collection?
If a PMC isn't stored into some other stru
Hi there,
I'm doing more work on the embedding interface. Given that some Parrot
functions may legitimately send and receive PMCs, what are the implications
for garbage collection?
I don't worry too much about the Sub and variable PMCs I get back from the
find_global*() functions,
Leo and I just chatted on the phone for a bit. I'll summarize here.
We went over two proposals that he put together, one on variable-sized
PMCs and one on creating a shared base class for some of the common PMC
types. (He's checking the proposals into the repository, so you can all
On Tuesday 29 August 2006 19:51, Matt Diephouse wrote:
> It's been said that writing PMCs sucks. This is your chance to tell
> the world why. Because for things to get better, we have to know what
> sucks.
>
> I'll get things started:
>
> 1) pmc2c.pl is very
It's been said that writing PMCs sucks. This is your chance to tell
the world why. Because for things to get better, we have to know what
sucks.
I'll get things started:
1) pmc2c.pl is very fragile - when it gets input it doesn't like, it
just ignores it (see RT#39313)
2
On Sun, 6 Aug 2006, chromatic wrote:
> If my code depends on the undefinedness of certain symbols, and those symbols
> may or may not appear in some namespace somewhere due to something totally
> unrelated to my code, I have a problem.
Ah. I thought we were considering the namespace which the lang
On Sunday 06 August 2006 16:57, Martin Kealey wrote:
> The naive reaction to this is that if you define ['myHLL';'foo'] then
> whether ['parrot';'foo'] is defined (or later becomes defined) is of no
> concern.
If my code depends on the undefinedness of certain symbols, and those symbols
may or m
On Sun, 6 Aug 2006, chromatic wrote:
> > Any reason to treat HLL namespaces differently from classes, at
> > least in respect of being an inheritance hierachy?
> Preventative measures against future additions to 'parrot' breaking
> your code without your knowledge. It's the same reason many langu
On Sunday 06 August 2006 16:00, Martin D Kealey wrote:
> Any reason to treat HLL namespaces differently from classes, at least in
> respect of being an inheritance hierachy?
Preventative measures against future additions to 'parrot' breaking your code
without your knowledge. It's the same reaso
On Thu, 3 Aug 2006, Chip Salzenberg wrote:
> KNOWN FUTURE DEVELOPMENTS
>
> It's already decided that we're moving class PMCs into the normal namespace
> tree. This change will eliminate many uses of the class-lookup opcodes, but
> not all: There's a two-level search
between class names and class PMCs; merely being a PMC or not isn't enough
to distinguish the intent of specifying class vs. class name. (Keys are
PMCs.) This should be resolved in a general way for all class-accepting
opcodes.
CURRENT STATE OF PLAY
There are currently five distinct ways t
On Jun 16, 2006, at 17:29, Klaas-Jan Stol wrote:
Wouldn't it be an idea to have a property 'is_read_only' or something
like that? Then, when attempting to do a write action on a r/o PMC, an
exception is thrown. It would seem to me that this is a typical case
for using a property.
A "Parrot
On Fri, Jun 16, 2006 at 10:27:06AM -0700, chromatic wrote:
: On Friday 16 June 2006 08:29, Klaas-Jan Stol wrote:
:
: > Wouldn't it be an idea to have a property 'is_read_only' or something
: > like that? Then, when attempting to do a write action on a r/o PMC, an
: > exception is thrown. It would
On Friday 16 June 2006 08:29, Klaas-Jan Stol wrote:
> Wouldn't it be an idea to have a property 'is_read_only' or something
> like that? Then, when attempting to do a write action on a r/o PMC, an
> exception is thrown. It would seem to me that this is a typical case for
> using a property.
>
> Th
Leopold Toetsch wrote:
Recently on IRC:
@woggle> leo: So, for read-only PMC variants, I'm presuming that it's okay
to have the read-only
variants have their own type number and type name (like was
done for ConstSArray)...
My 2 c:
A distinct type number would cause e.g. dif
Recently on IRC:
@woggle> leo: So, for read-only PMC variants, I'm presuming that it's okay
to have the read-only
variants have their own type number and type name (like was
done for ConstSArray)...
My 2 c:
A distinct type number would cause e.g. different MMD behavior and I
On Sun, May 14, 2006 at 04:17:31PM -0400, Will Coleda wrote:
> Is it possible to load a languages PMCs and create the .PMCtype
> constants without using the .HLL pragma?
Try :immediate.
.sub _immediate :immediate
$P1 = loadlib 'tcl_group'
.end
.sub main :
Is it possible to load a languages PMCs and create the .PMCtype
constants without using the .HLL pragma?
.HLL mucks with namespaces, which I don't want to (am not prepared
to) deal with at the moment in APL. I do, however, want to
dynamically load a library containing a PMC for APL t
y parrot core files should include this file.
Extensions should include .
Programs embedding parrot should include .
*/
However all dynamic PMCs in src/dynpmc and most, if not all, language
PMCs are
also including 'parrot/parrot.h'.
So the dependencies on symbols not defined in 'extend.h' should go away.
> [guest - Sat Apr 22 18:25:09 2006]:
>
> The attached patch implements and tests divide by zero exceptions for
> BigInt and Complex PMCs.
>
> It also tests divide by zero exceptions for float PMCs. float and
> integer PMCs are already properly handling divide by zer
x27;complex'
type ...) and not targeted now.
2. "Reference Model" for value objects
In Parrot, this mostly amounts to unique read-only PMCs.
We'll have the read-only part, but the "unique" part, probably not.
Can I/we read this as: "morphing for Parrot
1.0 will _not_ have native support for anything like value types.
> > Parrot 1.0's type universe will consist entirely of [ISNP].
>
> A value PMC is just a PMC. I don't see a need to extend the type system,
> when supporting value PMCs. I see these more as just another PMC wi
lot of old behavior that makes it mostly worthless now, I
think.
Some of the other languages are in a similar boat. It'd be nice if
there was some policy for deleting unmaintained, unworking, and
unfinished languages. We're using source control -- it's trivial to
get them back if we want
On Apr 6, 2006, at 5:22 PM, Will Coleda wrote:
On Apr 6, 2006, at 5:08 PM, Patrick R. Michaud wrote:
On Thu, Apr 06, 2006 at 02:04:06PM -0700, Bernhard Schmalhofer via
RT wrote:
Hi,
as far as I see, the Perl* PMCs are no longer used in the Parrot
core.
Thanks, Bernhard.
There is
On Thu, Apr 06, 2006 at 02:17:21PM -0700, chromatic wrote:
> On Thursday 06 April 2006 14:04, Bernhard Schmalhofer via RT wrote:
>
> > 'punie' seems to be the only maintained language implementation using
> > Perl* PMCs.
>
> What about Ponie?
Ponie isn't using them.
Nicholas Clark
On Apr 6, 2006, at 5:08 PM, Patrick R. Michaud wrote:
On Thu, Apr 06, 2006 at 02:04:06PM -0700, Bernhard Schmalhofer via
RT wrote:
Hi,
as far as I see, the Perl* PMCs are no longer used in the Parrot
core.
Thanks, Bernhard.
There is still some usage in unmaintained language
On Thursday 06 April 2006 14:04, Bernhard Schmalhofer via RT wrote:
> 'punie' seems to be the only maintained language implementation using
> Perl* PMCs.
What about Ponie?
> Also some tests and examples are using the Perl* PMCs.
I agree that they probably shouldn't,
On Thu, Apr 06, 2006 at 02:04:06PM -0700, Bernhard Schmalhofer via RT wrote:
> Hi,
>
> as far as I see, the Perl* PMCs are no longer used in the Parrot core.
>
> There is still some usage in unmaintained language implementations:
>
> BASIC/compiler unmaintained
Hi,
as far as I see, the Perl* PMCs are no longer used in the Parrot core.
There is still some usage in unmaintained language implementations:
BASIC/compiler unmaintained ?
BASIC/interpreter unmaintained ?
forth unmaintained ?
miniperlunmaintained ?
parakeet
ist entirely of [ISNP].
Thus, any implementation (emulation?) of value semantics will be built on
PMCs like other types, and will thus continue to live in the GC universe,
all a la JValue.
On Sun, Mar 12, 2006 at 02:35:11AM +0800, Audrey Tang wrote:
> The easy workaround for now is to hav
On Mar 12, 2006, at 2:55, Joshua Isom wrote:
If the compiler goes through all the constants at compile time to find
identical ones, why not use ".const float number = 0.0"?
That covers only a small part of the problem. 'Const's are still
mutable, they still morph, an
, int, buf, str, num, complex...
"Value" classes: Undef, Ref, List, Bit, Int, Str, ...
"Container" classes: Scalar, Array, Hash, ...
Container classes are naturally PMCs.
We can map "int", "str" and "num" to registers, and "bit"/"
s great for eg. porting the Perl 6 macro system to Perl 5.
As a consequence, the release of v6.pm and Pugs::Compiler::Rule has been
delayed for one day, so that we can have more robust cross-validation
between .pm and .pmc files, and have them play nicely with other Filter::PMC
technologies.
I
kinds of classes in Perl 6:
"Native" classes: bit, int, buf, str, num, complex...
"Value" classes: Undef, Ref, List, Bit, Int, Str, ...
"Container" classes: Scalar, Array, Hash, ...
Container classes are naturally PMCs.
We can map "int", "
Hi all,
now the following should work:
.HLL "Foo", "Foo_group"
.HLL_map .Sub, .FooSub
.sub foo # typeof gives 'FooSub'
...
(given that the HLL 'Foo' has defined a 'FooSub', which C Sub [1])
Closures and coroutines should be mappable too now.
There is one test[2], which is
On Jan 12, 2006, at 12:46, Leopold Toetsch wrote:
The following PMCs wil be removed soon:
- FloatvalArray - use {Fixed,Resizable}FloatArray instead
- StringArray - use {Fixed,Resizable}StringArray instead
The latter is a dummy wrapper around ResizablePMCArray BTW.
These PMCs are gone now
The following PMCs wil be removed soon:
- FloatvalArray - use {Fixed,Resizable}FloatArray instead
- StringArray - use {Fixed,Resizable}StringArray instead
The latter is a dummy wrapper around ResizablePMCArray BTW.
leo
Updates for Integer, Float, Complex, BigInt PMCs are welcome.
leo
On Tue, Nov 15, 2005 at 10:30:38AM -0800, Chip Salzenberg wrote:
> [*] an inode may have as few as zero or as many as USHORT_MAX[**] names,
> and finding them all requires scanning a disks's entire directory tree
Although one should note that you can loose valid names off the top of your
dire
On Tue, Nov 15, 2005 at 10:17:30AM +0100, Leopold Toetsch wrote:
> Autrijus mentioned on #parrot that we'd need weak pointers at some
> time. Then we can reconsider callframe PMCs.
Ah, weak pointers. I remember a time without weak pointers. It was a
happy time. Birds chirped i
sider callframe PMCs.
interp."get_caller"(n_levels)# interpreter method or
sub_class = getclass 'Sub'
sub_class."get_caller"(n_levels) # class method 0 = this sub, 1 =
caller, ...
a_sub."get_caller"(nlevels) # obj method, if you alr
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
> On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
> > $P0 = callframe 1
>
> We already have this kind of introspection: $ grep caller t/pmc/sub.t
OK, the Interpreter PMC interface is certainly flexible enough to
handle the introsp
1 - 100 of 544 matches
Mail list logo
