should be pretty straightforward to implement (assuming we have access
to the caller's lex pad for [upvar]). But I assume that that's why
things are implemented as they are.
--
matt diephouse
http://matt.diephouse.com
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> I don't think it is, no. ParTcl implements global/lexical storage
> rather naively at the moment (because I didn't understand that the lex
> opcodes worked this way when I implemented this over the summer).
> Right now we al
s a compiler writer, I see it as a
core feature. I always seem to forget that there are docs in
imcc/docs/ and end up grepping through docs/ instead (missing valuable
information).
--
matt diephouse
http://matt.diephouse.com
`P0 = ...` is the same thing as `assign P0, ...`?
Or, perhaps more accurately, `P1 := ...\n assign P0, P1`?
--
matt diephouse
http://matt.diephouse.com
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote:
> > Or, perhaps more accurately, `P1 := ...\n assign P0, P1`?
>
> No, PIR doesn't do that kind of thing (allocating P registers) behind
> your back. If a seque
After many months and lots of work, I'm happy to present you with the
latest namespace spec draft. Comments are most welcome: to quote Chip,
"The rest of the discussion would benefit from more eyes."
Thanks,
--
matt diephouse
http://matt.diephouse.com
Synopsis
- Languages
jerry gay <[EMAIL PROTECTED]> wrote:
> On 12/1/05, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > User Defined Namespaces
> > All HLLs should prefix any namespaces with the lowercased name of
> > the HLL (so there's no question of what to ca
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
>
> [ Just a few notes, more to come. I've to read it some more times. ]
>
> > Naming Conventions
>
> > HLL Private Namespaces
> > HLLs sh
e others to be all-lowercase too.
I was advocating having (2) and (3) be all-lowercase. I'm not sure
which are necessarily the same.
> 5. THE FINAL EXAMPLE
>
> In the final example, what is the purpose of this line:
>
>add_namespace ["perl5"; "Some"; "Module"], $P1
>
> As far as I can tell, the intent of the following line is to import
> tcl:Some::Module 'w*' into the _current_ perl namespace, not into
> ["perl5"; "Some"; "Module"]. Am I missing the point here?
No, I meant to take that line out but I forgot.
Thanks, Roger. Your email was helpful.
--
matt diephouse
http://matt.diephouse.com
rivate stuff. In that case, the HLL is responsible
> for keeping its own private stuff private, and there is no need for the
> spec to refer to unenforced private namespaces.
I don't think you'll really be interested in importing the guts of the
Tcl compiler into your program. But if that's what you really want,
I'm not going to stop you. (And neither should Parrot.)
--
matt diephouse
http://matt.diephouse.com
m missing the point, but I see these being used in the
> implementation of "import_into" as a way for the source HLL to tell the
> target HLL whether to treat each name as a sub, namespace, variable or
> method.
Yes, that's correct.
--
matt diephouse
http://matt.diephouse.com
ent matter. Python's function
may be variables, but Python still knows that they're functions. So
Python can use add_sub to add the function to Tcl's namespace. This is
both useful and necessary because function and variable names don't
overlap in Tcl.
> What am I missing?
I hope this clears things up a bit.
--
matt diephouse
http://matt.diephouse.com
dies with this error:
MMD function __i_multiply not foundfor types (1, -100)
--
matt diephouse
http://matt.diephouse.com
assignment fails with a "Null PMC access" error.
So what am I supposed to do? It appears that using `null` to mark
deleted/undefined variables won't work. But it's not clear to me that
using a Null PMC is a good idea (then we must perform `'isa` tests on
every read to see if that variable is undefined, which seems like it
would be expensive).
So what's the "correct" way to do this?
--
matt diephouse
http://matt.diephouse.com
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Diephouse wrote:
>
> > $alias = undef
> >
> > translates to
> >
> > null $P1
> > $P2 = getinterp
> > $P2 = $P2["lexpad"; 1]
> > $P2['$alias'] = $P1
>
>
on't have any comments here. If this can't be made to work, the
other option is to use an array of strings.
> *)export_to($P0, ...)
>
> Besides the va_list syntax the wild card support $P1.export_to($P0,
> 'w*') seems to belong into the HLL. OTO
ir own
types: compiler writers will have to write export code that uses the
typed interface anyway. So this won't generate less code, but it's
possible that it will improve interoperability (and possibly speed).
At this point, I'd probably say to just leave this until later. I'm
n
, I'd consider adding another opcode:
$P1 = get_namespace # this exists - get the current namespace
$P2 = get_namespace $P1, ["Foo"; "Bar"] # this doesn't - lookup
Foo::Bar in $P1 (the current namespace)
--
matt diephouse
http://matt.diephouse.com
1
real0m3.502s
user0m3.477s
sys 0m0.021s
GCC 4.0: time ./ack 11
Ack(3,11): 16381
real0m1.960s
user0m1.948s
sys 0m0.003s
I didn't use the custom PIR he posted (which is faster), so Parrot
didn't beat the GCC code.
--
matt diephouse
http://matt.diephouse.com
via RT Brad Bowman <[EMAIL PROTECTED]> wrote:
> The patch turns the mix of 4-tabs, 8-tabs and spaces in
> nativecall.pl into just spaces. Only whitespace changes.
Applied, thanks.
--
matt diephouse
http://matt.diephouse.com
ed for anything besides a
proof-of-concept. The only argument I can see for keeping them there
is that they're compiled by default, so the build breaks if they do.
And that's *my* 2ยข. :-)
--
matt diephouse
http://matt.diephouse.com
-sanity/01-tap.t
> line 1.
>
> (pugs isn't in any path on both machines)
> This make all tests failing.
On 10.4.6 (Intel) I get:
languages/perl6 mdiep$ perl t/harness t/01-sanity/01-tap.t
t/01-sanity/01-tapok
2/10 skipped: various reasons
languages/perl6 mdiep$ pugs
-bash: pugs: command not found
--
matt diephouse
http://matt.diephouse.com
bly modified
> after being freed, break at szone_error to debug
> # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error
> to debug
> # '
> # expected: '42
The test passes for me on 10.4.6 Intel.
--
matt diephouse
http://matt.diephouse.com
only one getting them.
>
> The iterator failures are odd. some of the tests just... stop
> iterating before they should:
>
> # Failed test (t/pmc/iterator.t at line 1019)
> # got: '10
> # 20
> # 30
> # ok
> # '
> # expected: '10
>
Will Coleda <[EMAIL PROTECTED]> wrote:
> I'm using gcc 4.0.1, an '--optimized' Configure, and perl 5.8.6
Ahh. When I do an '--optimized' Configure, I get a bunch of failed
tests. The hash tests are still passing, but that may be coincidental.
--
matt diephouse
http://matt.diephouse.com
g, then you can write your multis for
Integer and String (as chromatic did) and be done with it.
--
matt diephouse
http://matt.diephouse.com
Its author is no longer involved with Parrot. It's doubtful
that what's here would be of any use to anyone now.
If no one has any objections, I'll remove these towards the end of the
week or during the weekend.
--
matt diephouse
http://matt.diephouse.com
to build on Cygwin when build_dir
contains spaces.
How well does this play on other platforms?
Works on OS X. Applied in r12755.
Thanks,
--
Matt Diephouse
http://matt.diephouse.com
Matt Diephouse <[EMAIL PROTECTED]> wrote:
If no one has any objections, I'll remove these towards the end of the
week or during the weekend.
This is done as of r12807.
--
matt diephouse
http://matt.diephouse.com
;;depth]
unless_null lexpad, got_lexpad
# try again
inc depth
goto get_lexpad
got_lexpad:
variable = lexpad[variable_name]
.return(variable)
.end
Of course, that doesn't mean that I wouldn't like an opcode to do it for me. :-)
--
matt diephouse
http://matt.diephouse.com
via RT Matt Diephouse <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39597]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39597 >
The following code in line
x27;t add find_global variants
that lookup globals in HLL's? Right now we have find_global_p_p_s.
Adding find_global_p_s_p_s would let me reach into Tcl's private very
easily instead of having to crawl the namespaces myself.
$P0 = find_global '_tcl', ['Foo'; 'Bar'], "baz"
Thanks,
--
matt diephouse
http://matt.diephouse.com
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [.
able to get a namespace at runtime... which translates to the easiest
way for Tcl to use namespaces.
--
matt diephouse
http://matt.diephouse.com
)
$S0 = join "::", $P0
print $S0
print "\n"
end
.end
mini:~/Projects/parrot mdiep$ parrot test.pir
parrot
mini:~/Projects/parrot mdiep$
--
matt diephouse
http://matt.diephouse.com
I'd
prefer to have C< .namespace [] > so that we could also have the
matching C< find_global [], 'foo' >. Otherwise find_global becomes a
two step operation for finding globals in the root HLL namespace.
Oh, and I've committed some more failing tests. :-)
--
matt diephouse
http://matt.diephouse.com
rst, I think C< [] > *is* a name.
Second, any solution which involves giving the HLL namespace a
different name will have to either (a) add new opcodes, (b) add more
code for all the other cases by making all referencing originate at
the root, or (c) add a special syntax, none of which is simple.
--
matt diephouse
http://matt.diephouse.com
icates that most of the code belongs in that namespace, so it's
> likely that most of the variables do too. (There are variations, but
> that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
Works for me too. I'm not sure that I like the rename (I can't
decide), but the name itself doesn't matter much. The new opcodes (the
presence of get_cur_global) may actually make things easier for Tcl if
we ever compile to 100% inlined PIR.
This is a different route than I was trying to take us, but it should
be almost functionally equivalent, so I'm happy with it.
--
matt diephouse
http://matt.diephouse.com
ay technically.
>
> I've suggested that get_namespace follow exactly the same pattern, but
> so far she hasn't commented on that suggestion at all.
I really like both of these suggestions. We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the same effect.
You mean get_abs_global, actually. The proposed get_hll_global opcode
mirrors the existing find_global exactly. :-)
--
matt diephouse
http://matt.diephouse.com
g "too many .constants" instead of just
segfaulting?
Thanks again,
--
matt diephouse
http://matt.diephouse.com
ned being more clear in the svn log, but a comment would
really be the most useful.)
--
Matt Diephouse
http://matt.diephouse.com
chromatic <[EMAIL PROTECTED]> wrote:
On Tuesday 18 July 2006 19:43, Matt Diephouse wrote:
> I know I'm a little late to the game here, but in the future it would
> be useful to mention this sort of info in a comment in the source. :-)
> And a comment might be a nice additio
ork with Tcl and let them grow
organically.
Does this sound good? (Chip? Allison?)
--
Matt Diephouse
http://matt.diephouse.com
ial part of the typed interface?
--
Matt Diephouse
http://matt.diephouse.com
IMO, if it's doable. But it's a little out of
my reach as far as C goes, unfortunately. Otherwise I'd have fixed it
already. :-)
Thanks for taking a look at this.
--
Matt Diephouse
http://matt.diephouse.com
ax in both cases,
and there's probably some wins there.
Except this only works when the user is in the root HLL namespace or
when the user is executing code in the current namespace. That doesn't
mean it's not a valid option; just that it's not always valid.
--
Matt Diephouse
http://matt.diephouse.com
g for
Strings (and soon for other types as well).
So if anyone ever finds himself or herself in the same position, a
look at TclList's (languages/tcl/src/pmc/tcllist.pmc) assign_pmc
method would probably be in order.
--
Matt Diephouse
http://matt.diephouse.com
ted to use these as the basis for
their array classes. Would these each need to be split into 2 classes
as well? If so, we'd want to make multiple inheritance really work
with PMCs.
Any thoughts?
--
Matt Diephouse
http://matt.diephouse.com
Joshua Juran <[EMAIL PROTECTED]> wrote:
On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote:
> I would like to add some sort methods as well: quicksort(),
> mergesort(), etc. But as methods, there is potential for these to end
> up in a user-visible space.
>
> Say for
) You can't use :slurpy, :optional, or :named arguments. Even if
there's support under the hood, there's no way to write a PMC with
these arguments.
--
Matt Diephouse
http://matt.diephouse.com
t the problem
was, but none of my guesses of what's causing it were correct. I hope
I've given you enough information to fix it. If I haven't, let me know
what else I can provide.
Thanks,
--
Matt Diephouse
http://matt.diephouse.com
?
That *does* work. I haven't applied it because it's not
necessarily urgent that Tcl work in trunk. I'm okay with
waiting a couple days to see if an actual fix can be found - instead
of merely using a workaround. You can feel free to apply it yourself,
of course.
Bob Rogers <[EMAIL PROTECTED]> wrote:
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 20:21:32 -0400
Bob Rogers <[EMAIL PROTECTED]> wrote:
> Try the attached patch . . .
That *does* work. I haven't applied it because it&#
we handle subroutines? That is, why don't we
have a find_method opcode that returns a bound method? That simplifies
parsing for IMCC and makes PIR a little simpler.
obj.'abc'() # call 'abc' method of obj
obj.abc() # same as above
$P0 = find_method obj, ab
to any changes yet as Chip has
been kidnapped by his Real Life (tm).
I think the object model needs a thorough going over in general -- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO language has been implemented yet on Parrot; everything up to this
point has been either procedural or functional.
--
Matt Diephouse
http://matt.diephouse.com
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
> a relic of the past and I think it needs to change. I'm pretty sure
> that HL
Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
>> > This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
make transparent references
possible, but they weren't really specced out or desisign
ed properly. As such, they're a little broken and we'd like to remove them.
--
Matt Diephouse
http://matt.diephouse.com
Still, I'm curious to see what reasons there are for not attaching a
namespace to an :anon sub when (1) it seems convenient and (2) all of
Parrot's tests still pass. Does this break anything? Or did this just
signal to you that there may a problem here that needs its own
solution?
--
Matt Diephouse
http://matt.diephouse.com
I could argue it either way, but with the
other uses remaining tied to the namespace where they were defined,
let's default to your fix (consistency is good).
I was hoping you'd say that. :-)
Then for exporting (and other dynamic tricks), let's look into a feature
that allows you to change the namespace a compilation unit uses for
default lookups, after it's compiled.
That seems like a good idea.
--
Matt Diephouse
http://matt.diephouse.com
d to be updated. Replacing PerlInt with
Integer makes it work:
new P0, .Integer
set P0, 123
new P1, .Integer
set P1, 321
add P1, P1, P0
print P1
print "\n"
end
--
Matt Diephouse
http://matt.diephouse.com
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse:
> It also means that "string", "int", and "float" no longer work as MMD
> types -- you can't distinguish between native types and PMCs. I think
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Wed, Nov 29, 2006 at 04:43:59PM -0500, Matt Diephouse wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse:
> >> It also means that "string",
Matt Diephouse <[EMAIL PROTECTED]> wrote:
We've basically run into the fact that there's no spec for MMD. I'll
see if I can provide a patch that just makes "_" match native types,
but I think it'll be somewhat more involved than this one.
It ended up being
s were
PIR-level).
So the underlying problem is that constant strings are getting
collected when they shouldn't. The easy fix is to not collect *any*
constant PObj headers (see patch below). Is this correct? Or is there
a case when they should get collected? If it's th
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Dienstag, 5. Dezember 2006 20:39 schrieb Matt Diephouse:
> The portion of the assertion that
> fails is
>
> !(((s)->obj.flags) & b_PObj_on_free_list_FLAG
>
> which means that this string has been garbage collec
$P3 = $P3[4]
morph $P3, .Undef
assign $P3, $P2
If you're only assigning your own PMCs, you can drop the morph (which
isn't technically safe anyway).
--
Matt Diephouse
http://matt.diephouse.com
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Fri, Dec 08, 2006 at 05:05:00PM -0500, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >Does anyone have any suggestions about what sort of PIR
> >code and/or PMCs we need to be able to do make t
st returns 0 on success (and -1 on failure). I'd
like to change bind to return the port it's bound to on success. The
patch below adds this code for the unix sockets code. The windows code
looks like it'd be the same, but I can't test it so I'd have to find
someone to
. After these fixes, it worked.
Okay, I just changed the occurrences of PMCNULL to NULL. Things should work
now.
Hope this helps you further.
regards,
klaas-jan
It was very helpful, thanks!
--
Matt Diephouse
http://matt.diephouse.com
en a lot of it, so I appreciate the little things. :)
--
Matt Diephouse
http://matt.diephouse.com
ms. And yes, I would be willing to take a shot at it (realizing that I
may or may not be successful).
AFAICT, we're limited not just by volunteer labor, but also by the boxes
that are available to those volunteers.
--
Matt Diephouse
http://matt.diephouse.com
nly one? Does providing an init function for a
subclass of a PMC override both of the parent's init functions?
--
Matt Diephouse
http://matt.diephouse.com
y thought out -- some of the logic in
Sub.invoke() should be elsewhere.
--
Matt Diephouse
http://matt.diephouse.com
rrot_run_meth_fromc_args(interp, sub,
pmc, meth, "??", next);
return next;
}
I've tested it and it works with the original code that Richard gave. The
only thing left to do is handle return values; I'm still working on that. If
I can get return values working properly, I'll check in a fix.
--
Matt Diephouse
http://matt.diephouse.com
curious.
There's some of both, I think. I recently had to change a test to expect the
long name of a Sub because there was no way to get the short name.
--
Matt Diephouse
http://matt.diephouse.com
es) in
all languages (PIR, C, Perl). It's a fairly long list, but I think we can
get all the issues resolved in the next month.
Let the patching begin!
--
Matt Diephouse
http://matt.diephouse.com
Andy Dougherty <[EMAIL PROTECTED]> wrote:
Please avoid //-style comments. Older compilers don't understand
them.
Thanks. We have a test for //-style comments, but evidently it doesn't catch
all of our generated code. I've changed it to a C-style comment in r17692.
-
"),
("1b", "2b"),
("1c", "2c") );
If you can, the only case where I could see [1, 2, 3] being necessary is
in a sub call where the parameters are wrapped in parentheses.
md |- matt diephouse
iguous situations like:
print (1, 2, 3), "\n";
I don't know how many times I've done that and wanted it to print
"123\n". I know it's a feature, but it can be a bug in my writing. Now
it'd be unambiguous:
print [1, 2, 3], "\n";
--matt diephouse
Damian Conway wrote:
BTW, in thinking about it further, I realize that Dan is going
to have to tackle this issue anyway. There's fundamentally no
difference in the exigencies of:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I&#
go with it.
Does this mean private methods will be called like this?
./:method()
FWIW, I like the original spec best. I'm not sure that the problems
with it aren't being exaggerated. But I've not written much Perl 6 yet
either...
--
matt diephouse
http://matt.diephouse.com
Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
>
> > On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
> > : Does this mean private methods will be called like this?
> > :
> > : ./:method()
> >
> > No, I think th
p://www.sidhe.org/~dan/presentations/Parrot_Implementation.pdf
I have an old Perl 6 presentation, but it's at least 3 years old, very
badly out of date, and it wasn't a great presentation to begin with.
--
matt diephouse
http://matt.diephouse.com
(hex)
>
> and
>
> \u (unicode)
>
> Supplied as a patch as I know someone's in the middle of working on the
> parser right now.
That was me. I've just checked in this patch (slightly altered) as
part of my refactor (r8181). Thanks! :-)
--
matt diephouse
http://matt.diephouse.com
s this different from timeparrot? <http://xrl.us/f9oy>
> So we'd just need the benchmark code translated to PIR. I've here
> harmonic.pir and ack.pir (the latter sucks badly)
Adding .pasm, .imc, and .pir scripts to examples/benchmarks/ will
cause them to be benchmarked and graphed
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >> IIRC it was already mentioned here: http://shootout.alioth.debian.org/
> >> - the Computer Language Shootout.
&g
o (languages/tcl/), which
has PMCs inside of its classes/ directory. Using relative paths will
probably not work (Tcl is two directories deeper). Instead, use
${build_dir} to get the root parrot directory and build your paths
from there.
Thanks.
--
matt diephouse
http://matt.diephouse.com
uot;next"
# find_method class 'Iterator' method 'next': NCI
These GC issues with tracing have been pretty frequent. Please take a
look at languages/tcl/lib/commands/parray.pir to make sure the
iterator code is correct.
Thanks.
--
matt diephouse
http://matt.diephouse.com
e to be able to specify a compiler to use
along with a code block. In the immediate future, it'd be nice if we
could use PIR for these. That would allow us to throw exceptions to
catch parse errors.
--
matt diephouse
http://matt.diephouse.com
R versions of the PMCs
available for distributing bytecode? Should as much functionality as
possible be put into the core PMCs?
I'd like the ability to distribute bytecode without PMCs; I think it's
something worth working for. What's the best way to make this work in
light of PMCs?
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Diephouse wrote:
> > Dan wrote an entry on his blog yesterday entitled "WWIT: Universal
> > bytecode":
> >
> > http://www.sidhe.org/~dan/blog/archives/000421.html
> >
> > In it, he talk
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> === Bug Fixes
>
> * Call parrot with "-G" (CGP) instead of "-j" (JIT) runcore to avoid segfaults
Hopefully, you meant to write "-C" instead of "-G", as the first tells
parrot to use the CGP core an
As of r8617, the GC bug that ParTcl occasionally tickled has been
fixed. This is a relief as it caused some odd behavior and many hours
were spent by Will Coleda and Leo trying to debug.
Thanks to both of them for their efforts and thanks to Leo for finally
catching the bug!
--
matt diephouse
to say whether or not this is
confusing with adverb pairs, but I love the colon for private
methods/attributes and it's the one thing separating your new thinking
from my ideal Perl 6 OO.
--
matt diephouse
http://matt.diephouse.com
ative method
.param string value
self.SUPER::__set_string_native(value)
print "assign\n"
.end
I don't really care how it looks really, as long as it's possible. Any
thoughts? It'd be nice to get this specced so that it can be
implemented.
Thanks.
--
matt diephouse
http://matt.diephouse.com
IR. :-)
Thanks.
--
matt diephouse
http://matt.diephouse.com
sses
- Submethods
It's possible that there's a way to emulate these or that I've just
missed how they would be done.
Also, is rx.ops obsolete? PGE seems to be the new solution. If so, can
we get rid of rx.ops? Or is rx.ops still going to be used for
something?
--
matt diephouse
http://matt.diephouse.com
usr/src/parrot/build_tools/../classes/'
> at /usr/src/parrot/build_tools/pmc2c.pl line 281.
>
> The patch below seems to fix this.
Applied as r9126. Thanks.
--
matt diephouse
http://matt.diephouse.com
1 - 100 of 238 matches
Mail list logo
