Re: Instance attributes collision
Luke Palmer skribis 2006-02-13 9:36 (+): > That's a compile time error. Both "has" declarations generate a > method "a", so it is a method conflict. Doesn't normally double declaration end in the later masking/overriding the earlier declaration, with a warning, but not an error? I'd expect has $.a; has @.a; To result in both $.a and @.a, but only one method .a, which is an accessor for @.a Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Instance attributes collision
On 2/13/06, Juerd <[EMAIL PROTECTED]> wrote:
> Luke Palmer skribis 2006-02-13 9:36 (+):
> > That's a compile time error. Both "has" declarations generate a
> > method "a", so it is a method conflict.
>
> Doesn't normally double declaration end in the later masking/overriding
> the earlier declaration, with a warning, but not an error?
Does it?
role Foo {
method bar() { "x" }
}
role Bar {
method bar() { "y" }
}
class Baz {
does Foo;
does Bar; # does this count as double declaration?
}
I'd say we're going more toward the conflict side of things. That is,
I'd expect:
sub foo() { 1 }
sub foo() { 2 }
To be an error. However, I'd expect:
sub foo() { 1 }
&foo ::= sub () { 2 };
Not to be.
Luke
Re: Instance attributes collision
On 2/13/06, Yiyi Hu <[EMAIL PROTECTED]> wrote:
> For perl 6,
> Array and Scalar are in different namespace.
> So,
> class A { has $.a; has @.a };
>
> what will A.new.a return by default?
That's a compile time error. Both "has" declarations generate a
method "a", so it is a method conflict.
Luke
Re: Typo Alert: Synopsis 5
On 2/13/06, Amos Robinson <[EMAIL PROTECTED]> wrote:
> I think there's a typo in synopsis 5, "Indirectly quantified subpattern
> captures:"
> [ (\w+) \: (\w+ \h+)* \n ]**{2...}
> I have a feeling the \h should be *, not +.
It looks like you're right. Thanks, fixed.
Luke
Re: Instance attributes collision
Luke Palmer skribis 2006-02-13 9:46 (+):
> class Baz {
> does Foo;
> does Bar; # does this count as double declaration?
> }
I'd put composition and inheritance in a slightly different category
than accessor *generators*.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [perl #38468] [TODO] modify copyright info in parrot repo
On 2/10/06, jerry gay <[EMAIL PROTECTED]> wrote: > On 2/8/06, via RT jerry gay <[EMAIL PROTECTED]> wrote: > > ~ copyright text in each text file will be replaced with the new > > keyword for expansion > > ~ committers will be instructed on setting their environments to > > understand this custom keyword grr. my expectations of the latest subversion release were not met. custom keywords have been promised since 1.1, but has been pushed back just before each release. release 1.3 was no different, so we're limited to using the predefined svn keywords. unfortunately, this means that although we can add a 'Copyright' keyword (DONE,) it won't obey keyword expansion rules. therefore, this ticket is stalled until necessary subversion features are implemented. i'll keep it on my watch list, and pick it up again when svn is ready. for future reference in this ticket, here's a link to the subversion ticket related to this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=890 DONE, but disabled, as there's no point now: > > ~ tests will be designed to detect differences between the official > > copyright text (README) and text files in the repository, with an > > exception list for files that do not contain the copyright message > > ~ these tests will be run before every release tests can be found in t/distro/file_metadata.t still TODO: > > ~ a script will be made available to add or otherwise maintain the > > copyright info in all files > > ~jerry
Re: OS.pmc patch to add 'ls'
On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. Certainly, it would aid performance to have parrot-level support for commonly used idioms like directory slurping, but the price is more work for the languages. It's kind of a CISC vs. RISC argument. Again, this is an outsider opinion. Apologies in advance if I'm off- base or misunderstood the proposal. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
On Fri, 10 Feb 2006, Allison Randal wrote:
> On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
> >
> > I too had seen this memory problem before on Solaris/SPARC, but I'm
> > pretty sure I saw it even when running t/past_node_5.pir directly.
> > However, trying again today, I'm happy to report that that particular
> > problem seems to be gone.
>
> Excellent.
>
> > Of course an awful lot of the tests still
> > fail, but I don't know if that's expected or not.
>
> All of the test should be passing (at least, they are on other platforms).
> Could you send me more details on the failing tests? Some of the generated
> .out and .pir files would be a good start (running with POSTMORTEM=1).
I don't pretend to remotely understand what the code is attempting to
do, let alone how it's failing, but the failures vaguely seem to be fairly
similar. It looks like 'node.set_node' doesn't actually end up doing
anything. So for t/past_2.pir, for example, we have
.sub _main
load_bytecode 'languages/punie/lib/PAST.pir'
.local pmc node
node = new 'PAST::Code'
$P0 = new PerlString
$P0 = 'bar'
$P1 = new PerlArray
push $P1, $P0
node.set_node('foo', 42, $P1)
$P1 = getattribute node, 'source'
print $P1
print "\n"
$P1 = getattribute node, 'pos'
print $P1
print "\n"
$P2 = getattribute node, 'children'
$P3 = $P2[0]
print $P3
print "\n"
.return ()
.end
and for t/past_2.out, we have
1
1
bar
The other one that looks significantly different is t/past_op_1.pir. The
pir file is
.sub _main
load_bytecode 'languages/punie/lib/PAST.pir'
.local pmc node
node = new 'PAST::Op'
node.set_node('foo', 42, 'bar')
$P1 = getattribute node, 'source'
print $P1
print "\n"
$P1 = getattribute node, 'pos'
print $P1
print "\n"
$P1 = getattribute node, 'op'
print $P1
print "\n"
.return ()
.end
and the output file is
Null PMC access in get_string()
current instr.: '_main' pc 20
(/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir:7)
Here's the full output of 'make test'. It accurately reflects the .out
files (well, I didn't exhaustively check them all, but the ones I did
check matched up.)
perl5.6 -Ilib t/harness t/*.t
t/base_condok
t/base_if..ok
t/base_lex.ok
t/base_pat.ok
t/base_termok
t/io_print.ok
t/op_goto..ok
t/past.
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Looks like you failed 6 tests of 7.
dubious
Test returned status 6 (wstat 1536, 0x600)
DIED. FAILED tests 2-7
Failed 6/7 tests, 14.29% okay
t/past_nodeok
t/past_op..
# Failed test (t/past_op.t at line 7)
# got: 'Null PMC access in get_string()
# current instr.: '_main' pc 20
(/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir:7)
# '
# expected: 'foo
# 42
# bar
# '
# './parrot
"/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir"' failed
with exit code 43
# Failed test (t/past_op.t at line 30)
# got: ' => {
# 'source' => undef,
# 'pos' => undef,
# 'op' => 'bar',
# 'children' => []
# }
# '
# expected: ' => {
# 'source' => 'foo',
# 'pos' => '42',
# 'op' => 'bar',
# 'children' => []
# }
# '
# Looks like you failed 2 tests of 2.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
t/past_val.
# Failed test (t/past_val.t at line 7)
# got: '42
# 42
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past_val.t at line 30)
# got: ' => {
# 'source' => '42',
# 'pos' => '42',
# 'value' => 'bar',
# 'valtype' => undef,
# }
# '
# expected: ' => {
# 'source' => 'foo',
# 'pos' => '42',
# 'value' => 'bar',
# 'valtype' => undef,
# }
# '
# Looks like you failed 2 tests of 2.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
t/post.
# Failed test (t/post.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/post.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Looks like you failed 2 tests of 3.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED
Re: [perl #38300] Another guy who deserves svn ci privs
From: "Robert via RT" <[EMAIL PROTECTED]> Date: Sun, 22 Jan 2006 09:27:44 -0800 Passing to Ask to look at the bitcard issue. Turns out this was a cookie problem; my browser was accepting cookies from bitcard.org, but I wasn't aware that it was rejecting perl.org cookies. I discovered this because this configuration results in a redirect loop if you tick the "remember login" box. I haven't tried SVN yet, but at least RT now lets me change tickets (as I assume I ought to be doing). -- Bob Rogers http://rgrjr.dyndns.org/
Re: OS.pmc patch to add 'ls'
On Mon, Feb 13, 2006 at 09:28:40AM -0600, Chris Dolan wrote: > On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: > > >It would also be 'really nice' have a glob(3) like method that is > >implemented as a wrapper around *dir methods so the semantics are > >portable. > > My outsider opinion is that parrot should focus on exposing basic OS > functions (opendir, readdir, closedir) and leave the high-level > functions (ls, glob) to the languages or libraries. My justification > for that opinion is security lockdown. If there are more op-level > ways of accessing the system, then there are more features that > sandboxes like Safe.pm have to disable. Even more critical is the > potential for creep. If sandboxes have to follow a moving target, > then it could make it challenging to make security promises. I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes while glob(3) would be implemented in the OS.pmc. For all intents and purposes PMCs can fill the role of what you referred to as libraries. Doc pointers: http://www.parrotcode.org/docs/ops/ http://www.parrotcode.org/docs/pmc/ Cheers, -J -- pgpaQH6o2RsPs.pgp Description: PGP signature
Re: OS.pmc patch to add 'ls'
On Feb 13, 2006, at 1:20 PM, Joshua Hoblitt wrote: On Mon, Feb 13, 2006 at 09:28:40AM -0600, Chris Dolan wrote: On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes while glob(3) would be implemented in the OS.pmc. For all intents and purposes PMCs can fill the role of what you referred to as libraries. Thanks for the clarification. Apologies for the spam! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: OS.pmc patch to add 'ls'
"Joshua Hoblitt" <[EMAIL PROTECTED]> wrote: I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes I thought The Plan was to have all the I/O stuff done with PMCs rather than ops in the end. There's no real benefit in having ops - the delays that you get through doing I/O make the time difference between an op and a PMC method call insignificant. Security wise, the PMCs can be implemented to ensure that sufficient privs are available to perform the operation being requested of them. I agree with Chris on minimising the amount of places we do security stuff as far as is sensible. However, I would think that the interface for doing sandboxing style stuff would allow restriction of certain types of operation (e.g. filesystem access) rather than individual operations though, so as to help eliminate the moving target issue. Ah, and note that this is all conjectural on my part, and not The Design. :-) Jonathan
[perl #38515] [TODO] test all PMC types
# New Ticket Created by jerry gay # Please include the string: [perl #38515] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38515 > all PMCs (src/pmc/*.pmc) should be tested. the basic types, as defined in PDD17 (docs/pdds/clip/pdd17_basic_types.pod) should be given higher priority, so tests should be developed first to cover these. not surprisingly, basic types have a number of tests already, but there are holes in test coverage that should be plugged. after basic types are well-tested, remaining PMC types distributed in the parrot core should be targeted. this is a job that requires the ability to read c source, and read and write pir and/or pasm test code. however, deep knowledge of these languages is not required. takers most welcome. ~jerry
Re: OS.pmc patch to add 'ls'
On Mon, Feb 13, 2006 at 08:09:45PM -, Jonathan Worthington wrote: > "Joshua Hoblitt" <[EMAIL PROTECTED]> wrote: > >I think your slightly confusing OPs and PMCs. Presumably the *dir > >functionality would be implemented as OP codes > > > I thought The Plan was to have all the I/O stuff done with PMCs rather than > ops in the end. There's no real benefit in having ops - the delays that > you get through doing I/O make the time difference between an op and a PMC > method call insignificant. Security wise, the PMCs can be implemented to > ensure that sufficient privs are available to perform the operation being > requested of them. That implies enforcing a security policy on two different fronts. > I agree with Chris on minimising the amount of places we do security stuff > as far as is sensible. However, I would think that the interface for doing > sandboxing style stuff would allow restriction of certain types of > operation (e.g. filesystem access) rather than individual operations > though, so as to help eliminate the moving target issue. It's pretty clear from this thread that we are underspeced on both the I/O and security subsystems. Hopefully Chip can chime in on this... -J -- pgp4pOEzNc5TQ.pgp Description: PGP signature
Implementation of :w in regexes and other regex questions
Hello everyone,
This is my first post to the actual mailing list and not to Google Groups
(yeah, took me a bit to figure out they're not the same). I have a few
questions about the rules in Perl 6, and hopefully I'm not repeating stuff
that's already been brought up before. (I searched through the archive a bit,
but didn't see anything.)
==Question 1==
macro rxmodinternal: { ... } # define your own /:x() stuff/
macro rxmodexternal: { ... } # define your own m:x()/stuff/
With this, I can make my own adverbs then? Like :without, or :skip, and
describe what each does? If so, then maybe the rest of my major questions have
a very simple answer: make it yourself. If that is the case, I'll try to
figure out how to do it with pugs, if possible.
==Question 2==
I finished reading E05 and A05, and I really like the idea of the :w modifier
being able to essentially skip over certain parts of the text. Right now A05
states:
> can't decide what to do until it sees the data. It still does the
> right thing. If not, define your own and :w will use that.
So is :w invoking a rule that just skips whatever it matches? What I'm
wondering about is how I can create a mechanism that acts like :w, but can be
combined for nested rules. For instance, say I'm trying to pull out date from
(html) text:
...
Jan had a great birthday on F e b 5, 2003.
Her older sister, May, turned 23 on Ma r 5, 1998
Their younger sister, June, will be going home on Apr 5,
2006
April is their mother, and she's buying a car on Feb< / B > 7,
2006
I don't know when Roger, their father, is going to buy his guitar.
...
The grammar becomes messy when I have to account for things that the rules
don't allow me to just easily skip:
grammar Date {
rule tag_B_beg:w:i { \ }
rule tag_B_end:w:i { \<\/B\> }
rule tag_B:w:i { | }
rule month_english:w:i {
J*a*n | F*e*b | M*a*r
| A*p*r | M*a*y | J*u*n*e
| J*u*l*y | A*u*g | S*e*p
| O*c*t | N*o*v | D*e*c
}
rule year:w:i { (\d?\d?\d?\d) }
rule month:w:i { > () > }
rule day {
>
( >? <[1..9]> | 3<[0..1]> ) +
>
}
rule date {}
}
I don't want to just skip tags wholly, because they do serve a purpose,
but only in a particular context. (Can be changed back to a "default" if
changed to include html tags?) I was thinking about maybe using a closure
at the beginning of the rule (to change the string about to be processed) and
then a closure at the end of the rule (to change it back to its pre-processed
form) to make it work:
grammar Date {
rule tag_B_beg:w:i { \ }
rule tag_B_end:w:i { \<\/B\> }
rule month_english:w:i {
{ $/ ~~ s/// }
[ Jan | Feb | Mar | Apr
| May | June | July | Aug
| Sep | Oct | Nov | Dec
]
{ $/ ~~ $/.pretext }
}
rule year:w:i {
{ $/ ~~ s/|// }
(\d{4})
{ $/ ~~ $/.pretext }
}
rule month:w:i { > () > }
rule day {
>
( >? <[1..9]> | 3<[0..1]> ) +
>
}
rule date {}
}
That's okay to do right? It looks a lot cleaner to me, but I'm wondering if
there's a better way to skip a rule match in another rule (another adverb
like :skip, with :w being a built-in shorthand for :skip()). Or am I
making this too complex when it really isn't? Any pointers on how to do stuff
like this more simply?
==Question 3==
I'm also curious about exclusions. Right now, to do a general exclusion, I'm
thinking I would probably do something like:
rule text_no_date {
{$/ !~ // }
^ [.*] $
}
Would something like below be easier to decode for a human reader?
text:without() {
^ [.*] $
}
If that adverb were available, then I could have a rule that doesn't include
two other rules:
line:without(&&) {
^^ [.*] $$
}
The rule above would match a line with a or , but not a line with
both. Like I said before, I don't know if this is the best way to do stuff
like this, or if I'm thinking about these problems the wrong way, so *any*
help would be great.
Thanks,
David
Re: OS.pmc patch to add 'ls'
On Feb 13, 2006, at 6:28 PM, Joshua Hoblitt wrote: On Mon, Feb 13, 2006 at 08:09:45PM -, Jonathan Worthington wrote: I agree with Chris on minimising the amount of places we do security stuff as far as is sensible. However, I would think that the interface for doing sandboxing style stuff would allow restriction of certain types of operation (e.g. filesystem access) rather than individual operations though, so as to help eliminate the moving target issue. It's pretty clear from this thread that we are underspeced on both the I/O and security subsystems. Hopefully Chip can chime in on this... -J IO's underspeced, docs/ROADMAP.pod lists many TODO's regarding the IO subsystem(and is outdated). Socket support isn't speced, and directory handling isn't speced at all. The security pdd is outdated and seems more concept and imagining possibilities than saying how it should be implemented. In essence, from what I can tell, if it's not implemented yet, it seems as though it's underspeced for how it should be.
Re: RetContinuation promotion, closures, and context leakage
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 5 Feb 2006 02:21:19 +0100
On Feb 4, 2006, at 22:04, Bob Rogers wrote:
[detailed plan]
>Sound good? Unless I've missed something, this seems like a win
> across the board . . .
Sounds very good.
Unfortunately, I may not be the person to follow through on this. I've
spent the equivalent of a day on it, and am still very much stuck, so I
think I need to give up, at least for now. However, I would like to
submit the attached patch for review, which contains three good things
that I would like to salvage:
1. Closure still needs a destroy method, and having one is in fact
sufficient to reclaim contexts that would otherwise be lost.
2. In order to prove this (not to mention for debugging of
RetContinuation hackery), I added a fair amount of new CTX_LEAK_DEBUG
trace code, centralized it in interpreter.h, and put all of this output
under control of PARROT_CTX_DESTROY_DEBUG_FLAG so that it could be
turned on/off without recompiling.
3. While I was at it, I flushed most of the "#if CHUNKED_CTX_MEM"
code in src/register.c -- this code has serious bit-rot, and having two
implementations of Parrot_free_context et. al. tended to get in the way,
especially since M-. usually found the wrong one. (Though you could
argue that I didn't go far enough in flushing all of the CHUNKED_CTX_MEM
stuff . . .)
It is possible to show that Closure:destroy does something useful by
taking t/op/lexicals_28.pir (the 'closure 3' case), adding "debug 0x80"
as the first line in "main", and running it with and without the
src/pmc/closure.pmc hunk. I toyed with the idea of making a regression
test by adding some Perl postprocessing magic to make it less dependent
on build and version, thus:
[EMAIL PROTECTED]> ./parrot t/op/lexicals_28.pir 2>&1 | perl -pe
's/0x[\da-f]*/"0x#".($X{$&}||=++$n)."#"/ge'
[alloc ctx 0x#1#]
[alloc closure 0x#2#, outer_ctx 0x#1#, ref_count=2]
[invoke cont0x#3#, to_ctx 0x#4#, from_ctx 0x#1# (refs 2)]
[alloc ctx 0x#5#]
[free ctx 0x#5# of sub 'anon']
8
[alloc ctx 0x#5#]
[alloc closure 0x#6#, outer_ctx 0x#5#, ref_count=2]
[invoke cont0x#7#, to_ctx 0x#4#, from_ctx 0x#5# (refs 2)]
[alloc ctx 0x#8#]
[free ctx 0x#8# of sub 'anon']
23
[alloc ctx 0x#8#]
[free ctx 0x#8# of sub 'anon']
11
[alloc ctx 0x#8#]
[free ctx 0x#8# of sub 'anon']
27
[destroy closure 0x#6#, context 0x#5#]
[destroy cont0x#7#, to_ctx 0x#4#, from_ctx 0x#5#]
[free ctx 0x#5# of sub 'foo']
[destroy closure 0x#2#, context 0x#1#]
[destroy cont0x#3#, to_ctx 0x#4#, from_ctx 0x#1#]
[free ctx 0x#1# of sub 'foo']
[destroy closure 0x#9#, context (nil)]
[EMAIL PROTECTED]>
But even that seems too sensitive to internal changes, so I didn't take
it any further. At least this gives me a chance to provide a sample of
the output. (Thanks to Uri Guttman, whose tiny templater provided the
inspiration for the one-liner.)
In any case, I will wait a few days for comments before attempting to
commit any of this (as three separate changes). TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 11532)
+++ src/ops/core.ops(working copy)
@@ -548,6 +548,10 @@
if (PMC_cont(ccont)->address) {
/* else its from runops_fromc */
caller_ctx = PMC_cont(ccont)->to_ctx;
+ if (! caller_ctx) {
+ real_exception(interpreter, NULL, INVALID_OPERATION,
+ "null caller_ctx for ccont %p", ccont);
+ }
parrot_pass_args(interpreter, ctx, caller_ctx,
PARROT_OP_get_results_pc);
}
Index: src/register.c
===
--- src/register.c (revision 11532)
+++ src/register.c (working copy)
@@ -58,7 +58,9 @@
* The pointer C holds the next usable
* location. With (full) continuations the C pointer can't be
* moved below the C, which is the highest context pointer
- * of all avtive continuations.
+ * of all active continuations.
+ * [the code for this is incomplete; it had suffered some bit-rot and was
+ * getting in the way of maintaining the other case. -- rgr, 4-Feb-06.]
*
* TODO GC has to lower this threshold when collecting continuations.
*
@@ -89,55 +91,12 @@
*/
#if CHUNKED_CTX_MEM
-static void
-new_context_mem(Interp *interpreter, context_mem *ctx_mem)
-{
-ctx_mem->data = mem_sys_allocate(CTX_ALLOC_SIZE);
-ctx_mem->free = ctx_mem->data;
-ctx_mem->threshold = NULL;
-ctx_mem->prev = NULL;
-}
+#error "Deleted code removed."
+#endif
void
destroy_context(Interp *interpreter)
{
NCI 'v' vs '' in function parameter signatures
What's the difference between 'v' and '' for NCI function parameters?
Here, for example, is the code for 'fv' and 'f':
static void
pcf_f_v(Interp *interpreter, PMC *self)
{
typedef float (*func_t)(void);
func_t pointer;
struct call_state st;
float return_data;
Parrot_init_arg_nci(interpreter, &st, "v");
pointer = (func_t)D2FPTR(PMC_struct_val(self));
return_data = (float)(*pointer)();
set_nci_N(interpreter, &st, return_data);
}
static void
pcf_f(Interp *interpreter, PMC *self)
{
float (*pointer)(void);
float return_data;
struct call_state st;
pointer = (float (*)(void))D2FPTR(PMC_struct_val(self));
return_data = (float)(*pointer)();
set_nci_N(interpreter, &st, return_data);
}
The code is a little different but it's not clear (to me) if there's any
practical difference.
I ask because both 'fv' and 'f' are in src/call_list.txt
In fact there are several 'duplicated' signatures:
Ignored signature 'cv' on line 52 (previously seen on line 49)
Ignored signature 'dv' on line 58 (previously seen on line 54)
Ignored signature 'fv' on line 85 (previously seen on line 82)
Ignored signature 'iv' on line 150 (previously seen on line 87)
Ignored signature 'lv' on line 162 (previously seen on line 155)
Ignored signature 'pv' on line 187 (previously seen on line 170)
Ignored signature 'sv' on line 190 (previously seen on line 189)
Ignored signature 'tv' on line 202 (previously seen on line 192)
Ignored signature 'vv' on line 217 (previously seen on line 204)
Those warnings come from a version of tools/build/nativecall.pl I've
modified to 'normalize' the signatures to use 'v' and detect duplicates.
(As a side effect the nci.o file dropped from 354K to 347K.)
Also, what's the protocol for adding signatures to call_list.txt?
I've at least one I want to add ('p itl' for mysql_real_connect)
and may have more soon. Should I just post a patch here?
Tim.
