chromatic wrote:
On Monday 19 January 2009 14:13:22 Bob Rogers wrote:
Do you think that would be fast enough? The usual way for dynamic
languages to get fast compiled numeric code is to bind variables to
hardware types at compile time, and then inline numeric operations in
order to use that
Patrick R. Michaud wrote:
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer.
This is true AFAIK too.
We now have the 'copy' opcode to do what the morph workaround was doing (and
I don't think copy is using VTABLE_morph).
IIRC, copy once used to, but
Ovid wrote:
- Original Message
In the pir, doesn't the s = self line copy self, thus ensuring that I'm changing s and not self?
No, it's binding.
Or do I need s = clone self (or however it's written).
Yeah, but also note that substr would return a copy...
Can't say I
Klaas-Jan Stol via RT wrote:
On Thu Dec 13 04:35:13 2007, pmichaud wrote:
On Sat Sep 29 08:57:28 2007, kjs wrote:
A few months ago, the #line directive was implemented.
I'm wondering what the reason was why it looks like a comment (as #
will
start a comment).
Is there any
Klaas-Jan Stol wrote:
Minor detail:
.file does not actually exist, except in PIRC.
Well, I guess we can add it...
I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as
.line indicates, ehm, the line :-) Specifying a filename by .line is a bit
weird. Con:
Patrick R. Michaud wrote:
Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)
Just a
James Keenan (via RT) wrote:
We appear to have a coding standard which limits us to 32 characters
in a file's basename. This particular test file has 33 characters.
Oh, coding standards tests, how I love thee... (To note why I've not
been bothering to run them the last couple of days, they
Hi,
Rakudo is currently failing t\spec\S12-class\attributes.t. This turns
out not to be an issue with attributes, but rather exceptions. The test
does:
my $c = Counter.new();
try {
$c.x
}
ok($!, 'no public accessor for private attribute');
And fails because the Exception PMC does not
Hi,
I've just been looking at the time op, and what it returns is somewhat
platform specific.
* On Win32, it's the number of seconds since January 1, 1601
* In other codepaths, it appears to be the number of seconds since
January 1, 1970.
I'm thinking we should correct the Win32 version
Will Coleda wrote:
Being allowed to poke inside your caller's register set seems... evil?
It's the Parrot equivalent of the .Net CLR allowing you to take
references to stuff in caller's stack frames.
Can you provide a working PIR example that shows this functionality?
It was
Will Coleda wrote:
So, again, do we in parrot want to support the ability to dig into our
callers register set and pull out a particular register since we have
no way to say which register that is when we're using PIR? Even
unique_reg just says 'the register doesn't change', not it's PMC
Klaas-Jan Stol wrote:
I think basically the question remans; is there any way we could do
without the :unique_reg?
Yes:
1) Add the reference-taking op and register reference PMC to the Parrot
core.
2) Make IMCC specially aware of this op so that it never re-uses this
register.
Thanks,
Allison Randal wrote:
The Exception PMC never had a get_bool vtable function implemented,
but it did previously inherit one from ResizablePMCArray. So, that
test was relying on an implementation artifact.
OK, then that was certainly a wart, agreed.
Under what circumstances should an
jerry gay wrote:
seems to me this is trying to test whether there's a defined value in
$!.
Testing truth falls back to definedness, yes.
however, you've jumped straight into blaming parrot's Exception
PMC, without considering the expected perl 6 behavior.
Well, I was more blaming the
Ron Blaschke wrote:
Jonathan Worthington wrote:
I've just been looking at the time op, and what it returns is
somewhat platform specific.
* On Win32, it's the number of seconds since January 1, 1601
If I remember correctly, some parts of Windows use 100ns ticks since
1601 to represent time
Will Coleda wrote:
Can you describe a situation where this occurs that isn't a bug in the
register allocator?
Yes. IIRC, it was added when I was working on the .Net bytecode
translator, and it needed to take references to registers in callers. If
you're doing that, you need to know that the
Will Coleda wrote:
On Thu, Jul 31, 2008 at 6:12 PM, [EMAIL PROTECTED] wrote:
Additionally, it's scary that Parrot was segfaulting as a result of using a
string set with null $S0 style code and then using such a string with the open
op. Not sure what the right answer is, but the current
Allison Randal wrote:
Bernhard Schmalhofer wrote:
We could always do the 12th AND the 16th, just for fun and bonus
productivity (if everyone isn't exhausted from a day of hacking and
three days of conference)? ;-)
I'm also flexible. 12th and 16th sounds good to me.
I've booked to arrive
Hi all,
Patrick R. Michaud wrote:
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
This is certainly not the case for recursive subs. Consider the
attached example, a lightweight Perl 5 dumper. (It is slightly
artificial to break the
Patrick R. Michaud wrote:
Yes, the translation helps a lot.
OK, good.
But what you came up with is almost exactly what I would expect PCT/Rakudo to be generating _now_ for this code example (modulo a few minor details).
I tried to write it so it wouldn't be far off what Rakudo would produce
Hi,
So before, this would not work out because it found the wrong outer:
--
.sub main
outer()
.end
.namespace [ 'Foo' ]
.sub outer
say oops
.end
.namespace []
.sub outer
$P0 = new 'Integer'
$P0 = 42
.lex '$a', $P0
test()
.end
.sub test :outer('outer')
$P0 = find_lex '$a'
Hi,
Ovid wrote:
http://rt.perl.org/rt3/Ticket/Display.html?id=56108
This is related to Rakudo starting to use dynops (dynamic op libraries)
today. I managed to mess up the makefile by forgetting to stick in the
cleaning stuff, meaning that it could sometimes also fail with a realclean.
Ovid wrote:
Nope. Same error :(
Ouch. :-(
../../parrot -o perl6.pbc perl6.pir
src/interpreter.c:1030: failed assertion 'interp-op_count ==
core-op_count'
make: *** [perl6.pbc] Abort trap
At revision 28566
OK, that's in the dynops loading code. I'm be interesting to see what:
prove
chromatic wrote:
On Wednesday 04 June 2008 11:28:58 Geoffrey Broadwell wrote:
The op '$P0 = iter $P1' doesn't work if $P1 is a ResizableStringArray.
I haven't tested, but I suspect the same may be true of the some other
*Array PMCs as well.
This should be fixed up, so we can move the 'iter'
chromatic wrote:
On Thursday 05 June 2008 06:14:22 [EMAIL PROTECTED] wrote
Log:
[rakudo] Get is ro, is rw and is copy, with ro being the default, working
on parameters to subs. This time, we get just one failure in
spectest_regression (on Win32), which is a result of a Parrot GC bug.
Moritz Lenz wrote:
Attached patch adds a few more files to the 'make spectest_regression'
target. All of them pass.
Applied in r27783.
Thanks!
Jonathan
Moritz Lenz wrote:
rakudo's make spectest suffers from too much noise in its output.
The attached patch adds a spectest_regression target to Makefile that
uses whitelisting to run only those tests that are known to pass.
This is really useful! Applied in r27708, thanks. :-)
Jonathan
Hi,
In Perl 6 we need to be able to have Parrot subs take on a range of
different types. For example, those that are methods should be of type
Method, others of type Block, Submethod and so forth.
I'd like to propose a type adverb for subs.
.sub 'foo' :method :type('Submethod')
...
.end
Bob Rogers wrote:
From: Jonathan Worthington [EMAIL PROTECTED]
Date: Sat, 17 May 2008 00:25:35 +0200
Hi,
In Perl 6 we need to be able to have Parrot subs take on a range of
different types . . .
Is the idea sane, and is the name of the adverb OK? If so, I'll go ahead
NotFound wrote:
Looking a this, I discovered that the subclass function in default.pmc
contains a call to Parrot_single_subclass, but this function is not
present in default.c and there is no error nor warning about that
fact. Is this a behavior expected?
Anyway, the attached patch removes it.
Allison Randal wrote:
Will Coleda schrieb:
Can we get an idea of how many parrot hackers are planning on
attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on
13-15 August 2008.)
[...]
Bernhard Schmalhofer wrote:
Is there enough critical mass that would warrant a
Patrick R. Michaud wrote:
Rakudo doesn't use the line numbering feature of imcc because
the line numbering feature of imcc doesn't work.
See RT#43269 - setline is tied to PIR source.
I wouldn't say it doesn' work per se, it just doesn't do what you want
it to do. :-) There's something
chromatic wrote:
On Sunday 06 April 2008 16:05:45 [EMAIL PROTECTED] wrote:
Modified:
trunk/languages/perl6/src/builtins/guts.pir
trunk/languages/perl6/src/parser/actions.pm
trunk/languages/perl6/src/parser/grammar.pg
Log:
[rakudo] Add type-checking of parameters to subroutines and
chromatic wrote:
You're right. I started from the wrong point in my bisect.
No worries.
I can't reproduce the problem with any revision before or after the 0.6.1
release.
But the 0.6.1 release had a problem? If I'm understanding correctly, the
current revision doesn't show the
Patrick R. Michaud wrote:
There's currently a problem in that
class Foo { }
doesn't create 'Foo' as a subclass of Object.
Hmmmthat's odd, since I can do:
class Foo { }
if Foo ~~ Object { say yes }
yes
if Foo.new() ~~ Object { say yes }
yes
I know that it doesn't explicitly do
chromatic wrote:
It helps the PIR Ackerman benchmark by 4.67%. parrot_pass_args gets more
expensive, but next_arg_sig and everything else except for
Parrot_init_arg_indexes_and_sig_pmc gets called much, much less. I played
with the patch a little bit, but didn't get it much faster.
So is
Hi,
chromatic wrote:
3) PCC argument processing is slow. I've looked over Parrot_pass_args and
Parrot_process_args several times in the past few months, and I didn't see
any obvious speedups or tricks. However, we do spend a lot of time shuffling data back and forth, and something (instinct,
Hi,
We have a couple of bits of OO stuff missing in Parrot.
The callmethodsupercc op isn't implemented. I'm thinking for this we
need a variant of find_method, which does the required skipping over the
current class?
We'll also need to work out how to do callmethodnextcc too, which is
chromatic wrote:
Based on my reading of the documentation for get_namespace, this behavior
isn't surprising, but based on what I want to do with the code, this behavior
is very surprising:
works.pir:
.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
Will Coleda wrote:
Can we get an idea of how many parrot hackers are planning on
attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on
13-15 August 2008.)
http://www.yapceurope2008.org/ye2008/
I am actually a maybe at this point.
It's very likely I'll be there.
Jonathan
James Keenan via RT wrote:
On Sat Dec 16 21:56:15 2006, allison wrote:
Adequately covered by PDD 13. Leaving ticket to Jonathan to close when
implemented.
Your cage cleaner wants to know ... has this been implemented?
No, not yet.
Jonathan
James Keenan via RT wrote:
Jonathan: You took this RT some time back. Could you give us an update
on its status? (It's the oldest outstanding RT.)
Resolved; PDD13 specified doing it a Different Way and that bit of PDD13
is one of the bits I've gotten around to implementing too, so this is
chromatic wrote:
To recap, I think this bug will require a substantial refactoring and
cleanup of the packfile code. For now, I believe it's a non-trivial bug
(except, perhaps, for someone with a more thorough understanding of the
packfile code).
Agreed.
Same here.
I believe Jonathan
Hi,
We have for testing isa relationships both:
INTVAL isa_pmc(PMC* lookup)
INTVAL isa(STRING* _class)
However for the does test, we have just:
INTVAL does(STRING* method)
I'm thinking we should have a does_pmc variant too? Also, I'm not sure
why the name of the string taken there is
tuxdna wrote:
src/oo.c:Parrot_remove_parent()
Why should anyone remove a parent of any class? I believe it will break the
hierarchy.
The default class system only allows you to modify the inheritance
hierarchy of a class by cloning the class. That means that any new
instances get the
chromatic wrote:
+=item CPMC* inspect_str(STRING* what)
The star should go on the variable name (at least for incoming parameters).
That way we avoid the problem of:
char* foo, bar; /* oops, bar isn't a pointer! */
Yeah, I know that convention and try to stick with it. I
chromatic wrote:
On Friday 28 December 2007 07:09:24 Andy Lester wrote:
Should we be allowing negative in the PMC elements() functions? Seems
to me they'd be more appropriate as UINTVALs.
I can't think of any reason they could be negative. Can you make a patch to
convert them and
Klaas-Jan Stol wrote:
maybe it'd be useful to allow introspection for that as well? maybe a sub
can be requested for i ts complete signature, which then returns a some
object describing that signature. (how many params, is it a vararg function,
how many optionals, etc)
Writing a method to
Hi,
Just given this a quick read over; looks pretty good. The only thing I
don't see is a way to get the Sub PMC that is going to be invoked
without actually invoking it. Invoke does the lookup and then the call,
but what if I want to supply the arguments, and then just work out what
will be
Klaas-Jan Stol wrote:
looks good as far as I can tell. W.r.t. the selection part, the don't care type is
missing, which is _ IIRC.
My guess is that if you can specify which parameters are invocants, with
:invocant, then the need for an any type goes away, since you just
don't mark them as
Nicholas Clark wrote:
Do the structures actually overlap, or is this necessary band aid for a subtly
broken compiler?
I think the compiler is to blame. It only happens when compiling the
code in the computed goto core. I *suspect* the compiler backs out of a
lot of analysis and transforms
--
Lebennin
Silver flow the streams from Colos to Erui
In the green fields of Lebennin!
Tall grows the grass there. In the wind from the Sea
The white lilies sway,
And the golden bells are shaken of mallos and alfirin
In the green fields of Lebennin,
In the wind from the Sea!
--
On
Paul Cochrane wrote:
Unfortunately, I wish I could say the same. I'm getting the following error:
(Debian, gcc 4.1.2, r24008)
Configure with --cgoto=0 for now, and I'll ci a workaround in the code
later today. We'll revisit it to work out a Good Solution after the
release, but this
Jeff Horwitz wrote:
unfortunately, chromatic's memcpy patch still generated the compiler
error, perhaps because gcc is optimizing it back to the original code
it was replacing.
using memmove fixes this issue. it performs the copy, but it's not
optimized in the same way because it deals with
Allison Randal wrote:
Jonathan Worthington wrote:
I suspect re-writing it to do a memcpy would solve the
problem...anyway, sleep calls...
See the thread from earlier this year:
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/f50d1057d4855b7f/93fdb2d7e24e35f5
Having
Hi,
At the top of the NCI PMC, there are these comments:
--
Invoking an NCI function changes some registers according to PDD 3.
The caller has to preserve registers if needed.
--
Am I right in thinking that's no longer true?
Thanks,
Jonathan
Hi all,
It's fallen to me to do the release this month, and I'm lucky enough to
get to do the one that falls on Perl's birthday. The rest of the world
is unlucky enough that, unless I recieve a better suggestion, I'm
considering naming the release Happy Birdday, which is about the worst
pun
Hi,
Basically, it appears to me that the failure happens with some versions
of GCC when you're doing (once you look through the macros):
*d = *s;
Where d and s are PMCs. I can only conclude that the compiler is
generating all the reads, then all the writes, which of course requires
chromatic wrote:
On Thursday 06 December 2007 15:49:45 Jonathan Worthington wrote:
What it implemented (when I get chance, which should be this weekend) as
an arity method on the Sub PMC?
That would be much nicer
Implemented in r23598 for the Sub PMC.
(which doesn't make sense
metavery behind on everything while moving apartment and country, but
here's a start on catching up.../meta
chromatic wrote:
If there isn't a better way to do this, how would I get the arity of a
subroutine?
I'm not sure you can from PIR, which I've argued is a problem. I think
Will Coleda via RT wrote:
r23011 added code to config/gen/languages.pm to configure dotnet when configuring parrot
instead of (as before) manually, after parrot was built.
This isn't ready to happen yet. Reverting 23011 in spirit, dotnet is on its own
again.
Certainly, the .Net
Mehmet Yavuz Selim Soyturk wrote:
We could maybe assume that the ordering is well defined between the
instances of a PMC class. But cmp needs to compare instances of
different PMC classes as well, for which a well defined ordering is
less probable.
I would not be surprised if in some dynamic
Hi,
Back at OSCON, under the influence of beer, I agreed to take a crack at
implementing junctions in Perl 6 on Parrot. I've started working on
making good on that. I've not got any of this in a state where I'm happy
to send in a patch for people to play with, and it's my first time
hacking
Hi,
As far as I remember, and can see in PDD15, if you want to modify a class
after it has been instantiated you should clone it and do the
modifications to the clone. Therefore, #46097 and #46093 are resolvable by
removing the comment that dates back to before the decision and changing
the
Hi,
There are a handful of failing tests in languages/perl6/ that fail with
the following error:
Object must be created by a class.
I've done some digging into what's going on. Basically, the Perl 6
compiler generates code that makes an Undef PMC, for a new lexical, and
then assigns to it. That
Hi,
In my reading through the PDDs, I came across the new PAST one, which I'm
happy to see. I noticed that there is not any class and role definition
related PAST nodes. I don't know if that's by design or just because
nobody has written a spec and implementation yet. I think that since many
Hi,
I've only been notable in Parrot for the last month by my absence. It's
partly been down to a lack of time, though even when I've had the time
I've just not had the energy or been far from in the right state of mind
to have the concentration Parrot guts needs. Nobody here is to blame for
Allison Randal wrote:
We need a new syntax for the new metamodel. I'm thinking of:
setattribute obj, [Foo], j, $P4
That works for me.
It uses the familiar keyed access syntax to allow multi-level parent
class names. We would need to add two additional vtable entries
get_attr_keyed and
Will Coleda via RT wrote:
This appears to be nothing more than someone forgetting to update
MANIFEST. The file was checked in at least a few revs ago, it was then
deleted.
Geck, that was me last night. Sorry all. (For those wondering where
fingerprint_c.pl is going, I'm working on implementing
James Keenan (via RT) wrote:
...enables you to trace the evolution of the Parrot::Configure object over the
56 configuration steps. Methods are provided to (a) track the development of a
single attribute over the configuration steps, and (b) take a snapshot of the
object's state at the
Andy Lester wrote:
On Jul 17, 2007, at 7:36 PM, Allison Randal wrote:
Saturday, July 28th, we'll have a Parrot hackathon in Portland. The
location is to-be-determined (chromatic's house if there aren't more
than 10 of us). Drop me a note if you plan to join and I'll update
you with details.
Hi,
Just looking at the Class and Object PMCs and a couple of things concern me.
1) Inside the method finding code I see this has been added:
if ( ! PMC_IS_NULL(namespace)
VTABLE_exists_keyed_str(interp, namespace, name)) {
PMC *ret =
Allison Randal wrote:
There currently isn't any way to add vtable overrides to the class's
list of vtable overrides, so this is temporary (and actually, I
thought you put it in).
That was implemented earlier today. I wrote the email before I'd
implemented it. I think I've implemented what you
Patrick R. Michaud wrote:
This presumes that every PMC class also has a Namespace PMC associated with it
that points to the class. I'm not sure that's true for Parrot PMC classes.
It's what I've implemented, though whether it's The Design is another
question that I'm not clear on the
chromatic wrote:
Classes are PMCs. Are there benefits to pushing them one step further and
making them Objects as well?
A PDD15 class is an object in so far as it's an instance of a PMC. A PMC
is a class, just written in C rather than PIR.
Jonathan
Hi,
Allison Randal wrote:
It looks like every low-level PMC is creating a proxy object for
itself and these proxies are stored in the interpreter global
parrot_interp_t.
That's what's implemented, yes. I pondered hanging them off the v-table
too. That's perhaps more desirable.
I intended
Patrick R.Michaud (via RT) wrote:
The 'setline' opcode doesn't do what I expect it to do, which
is to associate runtime errors with lines in HLL source.
Currently HLL debug info stuff is spec'd, but not implemented. Well, OK,
the storage of it in bytecode is spec'd, the exact PIR syntax for
Hi,
GDR! wrote:
I'm new here so I'll say hello - I'm GDR!.
Welcome! :-)
I was looking at the Parrot project recently and I'd like to
implement the VM in hardware. I'm not deeply into the project,
however, so I'd like to ask you if the Parrot bytecode is now stable
enough to begin
chromatic wrote:
I wonder if changing the Namespace PMC to store all vtable methods in such a
way that an indexed lookup will work is a benefit. It might simplify the code
even further.
Yes, I'd like to see this. I did the groundwork for it already, by
refactoring the NameSpace PMC so
Mark Glines wrote:
I tried the perl6 testsuite on freebsd at Coke's request, and
discovered a test that fails on freebsd but succeeds on linux. The
test seems to be a GC-related assertion failure; parrot -G does not
crash, parrot without -G does crash.
...
Assertion failed: (s-encoding
Hi,
At the moment, under Win32, virtually all of the Perl 6 test suite fails
unless run with -G (disabling garbage collection). The problem for at
least one of them is that the free list appears to be corrupted.
First, a few notes on the free list. Parrot allocates large chunks of
memory,
Hi,
I built Parrot for the first time in a while today and got errors like:
src\extend.c(78) : error C2375: 'Parrot_PMC_get_string_intkey' :
redefinition; different linkage .\include\parrot/extend.h(60) : see
declaration of 'Parrot_PMC_get_string_intkey'
If you use PARROT_API in a C
Will Coleda (via RT) wrote:
This doesn't:
.sub zero_check
push_eh one
$N1 = 3 / 0.0
snip
Guessing that imcc is doing constant folding without the guards that
the ops use.
Aye, and the trouble is, I think, that we don't actually have ops that
only take two constants; if I
Andy Dougherty wrote:
2. Garbage collection really slows the program down (I observed factors of 10
difference in speed with and without -G), and I have a vague unsupported
suspicion that the slowdown grows faster than linearly with the allocated
memory.
I remember tracing through a load
Allison Randal wrote:
Nicholas Clark wrote:
I guess that the most obvious current thing that ties Parrot to the Perl
community is that Parrot requires a copy of Perl to bootstrap, and
all the
build tools are written in Perl 5.
This is slated to change before the 1.0 release.
I guess that
Jonathan Worthington wrote:
I guess that doing so will involve re-writing a lot of the current
Configure system and build tools into something that compiles down to
PBC (and then just ship something very basic that can run a PBC).
Whoa. I meant, have some kinda miniparrot that can run a PBC
James E Keenan wrote:
File src/pmc/classobject.h was added very recently:
r18244 | jonathan | 2007-04-16 19:26:34 -0400 (Mon, 16 Apr 2007) | 1 line
Aye.
I'm wondering why it was added in directory src/pmc/. Previously,
that directory held only files with names ending in .num or .pmc:
Oops, forgot to Reply To All...
---BeginMessage---
James E Keenan wrote:
I stumbled across it because I was re-running the build tools tests in
t/tools/pmc2cutils/*.t.
[parrot] 502 $ prove -v t/tools/pmc2cutils/00-qualify.t
t/tools/pmc2cutils/00-qualify1..9
ok 1 - use
chromatic wrote:
Jonathan, can you help us figure out why deleting these lines out of init()
fixes the problem? Are they vestigial?
/* turn on marking of the class_data array */
PObj_data_is_PMC_array_SET(self);
I saw those before and thought they were very suspect;
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 (but
chromatic wrote:
On Monday 16 April 2007 17:04, Jonathan Worthington wrote:
We're still missing a couple of vtable
methods it'd be nice to have in there (does, isa), which I ain't got
time for now (need slp), but hopefully somebody may.
In as of r18258.
Great.
Note
Alek Storm (via RT) wrote:
The following code causes a segfault:
.sub main :main
$P0 = new Object
$P0.'foo'()
.end
This is because the vtable methods in Object assume a valid pointer to
the object's internal representation, which is only initialized in
init_pmc.
That probably has to change
Alek Storm (via RT) wrote:
The following code demonstrates the reversed output of Object.can():
...
I've attached a patch to fix this.
Applied in r18239.
Thanks!
Jonathan
chromatic wrote:
On Sunday 15 April 2007 15:52, Jonathan Worthington wrote:
Sorry, I didn't get to adding one yet, but this should do it:
$P0 = new 'Class'
addattribute $P0 'foo'
Hm, it segfaults for me (and rightly so) if I instantiate a non-class
(try 'Hash' for some fun
Jonathan Worthington wrote:
What should happen: Class manufactures an object and init and init_pmc
of Object both throw exceptions. That means creating a new Object PMC
in the new method of Class using pmc_new_noinit (IIRC) and setting up
its guts from within Class.
Implemented this now
Of the things I was hoping would be sorted out before release...
Jonathan Worthington wrote:
* addattribute segfaults if passed a PDD15 class. I'll fix that
tomorrow, if nobody beats me to it
Done by chromatic++. :-)
* Oh, and the Role PMC doesn't do the name/namespace stuff right yet;
it's
Hi,
With much of PDD15 implemented, I thought it'd be good to explain how
far along we are (and aren't) as the next release approaches. Here's
some code examples.
---
# You can initialize a class with a hash...
$P0 = new 'Hash'
# Set name Will also associate with Monkey namespace nested in
chromatic wrote:
On Sunday 15 April 2007 15:28, Jonathan Worthington wrote:
* addattribute segfaults if passed a PDD15 class. I'll fix that
tomorrow, if nobody beats me to it
If there's a test case, I can probably fix it. That'll free you up to
implement new things.
Sorry, I
Hi,
This patch broke the build on some platforms (Win32 with MSVC++ included).
INTVAL
PIO_poll(Interp *interp, PMC *pmc, INTVAL which, INTVAL sec, INTVAL
usec)
{
+if (pmc == PMCNULL) {
+ real_exception(interp, NULL, E_ValueError, Can't poll NULL
pmc);
+}
ParrotIOLayer *
Hi,
I just backed out one small part of this patch because it broke the
build using MS VC++ on Win32.
Steve Peters (via RT) wrote:
ndex: src/exec_save.c
===
--- src/exec_save.c (revision 18179)
+++ src/exec_save.c
1 - 100 of 391 matches
Mail list logo
