[EMAIL PROTECTED] wrote:
(When you extend an existing class, it actually creates
+a new class, that replaces the old class in the Namespace, but the old
+class can't be thrown away if it has objects instantiated in it. The old
+objects still point to the old class and do their method
Theodore Katseres wrote:
I managed to get parrot to build on aix-ppc-gcc4.0.0
smoked too ;)
Excellent! :)
Allison
See attached output of prove -v. I have not encountered these
failures before tonight.
Updated to revision 17318.
[parrot] 526 $ prove -v t/pmc/smop_*.t
t/pmc/smop_attribute1..5
# Failed test (t/pmc/smop_attribute.t at line 26)
# got: 'sh: line 1: ./parrot: No such file or
Author: jonathan
Date: Sun Mar 4 02:19:10 2007
New Revision: 17322
Modified:
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
Describe new class and object layout for objects. We now push a lot into the
class and make objects really lightweight, since you will usually instantiate
many objects
Author: allison
Date: Sun Mar 4 02:30:36 2007
New Revision: 17323
Modified:
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
[pdd]: Objects, a few clarifications.
Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
Bram Geron (via RT) wrote:
Tail calls from within v-table methods are broken, the tail-called sub
(or method) will not return correct values.
When method A tailcalls sub B, B's set_returns stores its opcode
number (and with it, which registers should be returned), but the
low-level vtable code
Author: allison
Date: Sun Mar 4 03:40:00 2007
New Revision: 17326
Modified:
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
[pdd]: Review of updates from 2am design session on object structures.
Modified: trunk/docs/pdds/draft/pdd15_objects.pod
Sam Vilain wrote:
Is it intended that if languages need to make changes to the behaviour
of existing obejcts through their type, that something may follow up
after this and replace the old objects with objects of the new type?
Yes. Some languages will want that behavior, and some won't, so
hi,
I'm trying to compile parrot on cygwin, but it won't compile:
mpilers/imcc/parser_util.o compilers/imcc/pcc.o -lcrypt -lgmp -lreadline
compilers/imcc/main.c
/usr/bin/perl.exe tools/build/parrot_config_c.pl --mini \
src/null_config.c
src/null_config.c
gcc -o miniparrot.exe
Von: Thomas Wittek [EMAIL PROTECTED]
That's, well, elegant! Yes.
Because and but it's tricky.
Nothing where I'd say wow, thats an easy solution to my problem!.
It's a bit complicated, because you have to understand and combine
several concepts. That's elegant. But not easy, I think.
I
herbert breunung wrote:
Von: Thomas Wittek [EMAIL PROTECTED]
That's, well, elegant! Yes.
Because and but it's tricky.
Nothing where I'd say wow, thats an easy solution to my problem!.
It's a bit complicated, because you have to understand and combine
several concepts. That's elegant. But
Jonathan Lang wrote:
Seconded. I would favor allowing an else block to be attached
following any loop block, with the semantics being that the else block
only gets triggered if the loop block doesn't run at least once. I'd
do this instead of a block trait (such as FIRST or LAST) because of
the
Darren Duncan schrieb:
At 11:17 PM +0100 3/3/07, Thomas Wittek wrote:
Larry Wall:
: if ($item = 'foobar') {
== of course ;)
If you actually wrote that, then you'll always find that the first
item has the value 'foobar'. :)
Care to try a third time?
I don't think the
# New Ticket Created by James Keenan
# Please include the string: [perl #41695]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41695
I am opening this ticket as a way of logging various Parrot hackers'
efforts to
# New Ticket Created by Elizabeth Mattijsen
# Please include the string: [perl #41693]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41693
Robert Ennals' paper doesn't live at the indicated link anymore, even
his
From: Elizabeth Mattijsen (via RT) [EMAIL PROTECTED]
Date: Sun, 04 Mar 2007 05:15:43 -0800
# New Ticket Created by Elizabeth Mattijsen
# Please include the string: [perl #41693]
# in the subject line of all future correspondence about this issue.
# URL:
On 3/3/07, Theodore Katseres [EMAIL PROTECTED] wrote:
I managed to get parrot to build on aix-ppc-gcc4.0.0
smoked too ;)
indeed, wonderful news. is this something that can be set up more
regularly so we can track portability there?
also, i can't seem to find the smoke results at
[EMAIL PROTECTED] via RT wrote:
Hi,
Applied in 17281, thanks.
For your question, strdup is fine since these are not garbage
collectable strings (STRING*), just normal C char*'s. There is loads of
them used in IMCC. Unfortunately though, there is an issue in that we
don't free a load of 'em, or
On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
I'd like the For::Else behaviour more. Especially as I remember
numerous
times writing an if clause to check if a list is empty before
processing it.
That's crazy. If the list is empty foreach still does the right thing
- there's no benefit in
For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it allows for
multiple, concurrent object systems. This goal is mentioned in PDD 15, in
What The Bytecode Sees. Why tie programmers into the default way of doing
I'm almost done with a different patch that preserves the parent context for
the purpose of returning values into it. All further tailcalled contexts
are freed as normal. That's pretty vague, but it's easier just to see the
code. I just haven't had time to finish and release it.
Thanks,
Alek
This week on the Perl 6 mailing lists
'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-)
-- Larry Wall
Obviously it generates a function so anonymous that it can't even
refer to itself. I
I vote against this proposal.
More exceptional rules in a language are bad in itself.
Those exceptions force people to more to learn more stuff
and lead to confusion for those who don't know every detail
of this language. So, there should be an important reason
for that or it's a silly idea.
What about this?
given @foo {
for $_ - $x { ... }
when .empty { ... }
}
You can reverse the order if you want:
given @foo {
when .empty { ... }
for $_ - $x { ... }
}
I don't like C$_, but I can't think of a way to get rid of it.
--
Daniel Brockman [EMAIL
Here are some notes which I have made which may prove useful in the
refactoring of Parrot::Distribution. I hope that I have grepped and
acked accurately, but I'm not guaranteeing 100% accuracy.
kid51
NAME
Parrot::Distribution refactoring notes
ANALYSIS OF PACKAGE
* used by:
*
On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:
For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it
allows for
multiple, concurrent object systems. This goal is mentioned in PDD
15, in
What The Bytecode Sees. Why
James Keenan wrote:
The patch attached is really two patches in one:
1. A resubmission in patch form of my refactoring of tools/build/
ops2c.pl into lib/Parrot/Ops2c/Utils.pm and lib/Parrot/Ops2c/
Auxiliary.pm, along with a test suite in t/tools/ops2cutils/.
2. 4 new files which provide
Author: jonathan
Date: Sun Mar 4 14:47:00 2007
New Revision: 17336
Modified:
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
s/variable/value/ - bob rogers++
Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
---
On Sunday 04 March 2007 15:41, Sam Vilain wrote:
James Keenan wrote:
Those patches and new files haven't been reviewed yet. When I went
to my next round of submissions, I wanted to get it done quickly
(I've been dealing with eye infections the last several days and am
tiring
Steve Lukas writes:
On the other hand, there is no important reason for it because C
for @rray - $el {}
if ! @rray {}
should work. It's short and easy to understand.
But it involves repeating C@rray -- which for more complex expressions
(results from function calls, delving deep into
The text of S02, S03, and S04 still contain references to the
now-defunct statement_modifier grammatical category.
Also, what's the reasoning behind specifically disallowing _all_
statement modifiers to do blocks (as opposed to forbidding just
looping statement modifiers)? Is this legacy from
Just kidding! Here's the patch, for real this time.
On 3/4/07, Alek Storm [EMAIL PROTECTED] wrote:
That's because the patch refers to a function that is now outdated because
of #41549. I've attached an updated version of the patch.
Thanks,
Alek Storm
On 3/2/07, [EMAIL PROTECTED] via RT
Hmm, no, these deal with normal object attributes. I believe you're
thinking of properties. I'll put together some sketch code with what
I already have and post that.
Thanks,
Alek Storm
On 3/5/07, chromatic [EMAIL PROTECTED] wrote:
On Sunday 04 March 2007 19:13, Alek Storm wrote:
In fact,
AFAICT, there's nothing in the documentation to explain how one would
define a statement or operator with syntax along the lines of if ...
else ... or ... ?? ... :: ... Admittedly, the only cases I know of
where this is still an issue are the two listed above: for statements,
all other perl 5
Larry Wall wrote:
On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: Rick Delaney wrote:
: Smylers wrote:
:for @invoice
:{
: .process;
:} or fail 'No invoices to process';
:
: If that actually works then I'm happy.
:
: It's dependent on .process not returning a
On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: : Rick Delaney wrote:
: : Smylers wrote:
: :for @invoice
: :{
: : .process;
: :} or fail 'No invoices to process';
: :
: : If that
On Sun, Mar 04, 2007 at 08:55:28PM -0800, Jonathan Lang wrote:
: The text of S02, S03, and S04 still contain references to the
: now-defunct statement_modifier grammatical category.
Yes, there are several similar issues that need to be cleared up
as soon as
On Sun, Mar 04, 2007 at 09:25:31PM -0800, Jonathan Lang wrote:
: AFAICT, there's nothing in the documentation to explain how one would
: define a statement or operator with syntax along the lines of if ...
: else ... or ... ?? ... :: ... Admittedly, the only cases I know of
: where this is still
On Sun, Mar 04, 2007 at 09:38:05PM -0800, Larry Wall wrote:
: grammar and override the rules as you see fit. Macros and user-defined
s/user-defined/user-defined operators/
Larry
Larry Wall wrote:
On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: : Rick Delaney wrote:
: : Smylers wrote:
: :for @invoice
: :{
: : .process;
: :} or fail 'No invoices to process';
Larry Wall wrote:
: Finally: when used as a statement modifier, is given considered to
: be conditional or looping? (Gut instinct: conditional.)
Why does it have to be one or the other? It's just a topicalizer.
One implication of replacing statement_modifier with
statement_mod_cond and
Larry Wall wrote:
Jonathan Lang wrote:
: Larry Wall wrote:
: : Finally: when used as a statement modifier, is given considered to
: : be conditional or looping? (Gut instinct: conditional.)
:
: Why does it have to be one or the other? It's just a topicalizer.
:
: One implication of replacing
On Mon, Mar 05, 2007 at 04:13:16PM +1030, Tom Lanyon wrote:
: Sounds like the following will work, but it doesn't seem 'nice'.
:
: for @invoice
: {
: .process;
: 1;
: } or fail 'No invoices to process';
Still think if there's no invoices it logically should be tested first.
If you don't want
Larry Wall wrote:
Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:
@invoice or fail 'No invoices to process'
== for @() {
.process
}
or equivalently
@invoice or fail 'No invoices to
44 matches
Mail list logo
