We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Allison
Allison Randal wrote:
We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Location confirmed:
Urban Grind East
2214 NE Oregon St.
Portland, OR 97232
Saturday July 26th
Moritz Lenz wrote:
NotFound wrote:
To open another can of worms, I think that we can live without
character set specification. We can stablish that the character set is
always unicode, and to deal only with encodings.
We had that discussion already, and the answer was "no" for several reasons
After temporarily disabling the graph coloring register allocator, the
pdd25cx branch passes all Parrot tests. Please run the tests for your
language and report/debug any test failures that are different than the
test failures in trunk.
The plan is to merge the branch back into trunk on Friday
Moritz Lenz wrote:
I also get errors in parrot's PGE tests (I guess they are known already;
if not I can happily send the details)
I get no errors in PGE's tests on Mac OS X or Ubuntu as of r29552, so
please send the details.
Allison
Bob Rogers wrote:
The same Kea-CL tests are failing in pdd25cx revision 29565 as I
mentioned in this message:
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Tue, 8 Jul 2008 22:21:06 -0400
. . . I am seeing three test failures when it should execute a
pushaction sub, but does not. Two
Allison Randal wrote:
Moritz Lenz wrote:
I also get errors in parrot's PGE tests (I guess they are known already;
if not I can happily send the details)
I get no errors in PGE's tests on Mac OS X or Ubuntu as of r29552, so
please send the details.
Oh, but do make sure you
Bob Rogers wrote:
The attached patch (against the trunk) adds a case which fails in
pdd25cx but works in trunk. Should I go ahead and commit it, and if so,
to branch, trunk or both?
Looks like you forgot to attach the patch.
Allison
Allison Randal wrote:
Bob Rogers wrote:
The attached patch (against the trunk) adds a case which fails in
pdd25cx but works in trunk. Should I go ahead and commit it, and if so,
to branch, trunk or both?
Looks like you forgot to attach the patch.
Got it, thanks. That patch demonstrates
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 in Copenhagen on the 11th
Jonathan Worthington wrote:
Patrick and I will be hacking on the 12th and the 16th. If you've not
seen Copenhagen before, I could forgive you for wanting to spend a day
enjoying the city rather than hacking though - it's nice! :-)
I have, in fact, seen Copenhagen before, and if it weren't fo
I just merged in the pdd25cx branch. Resolving all the conflicts took
several hours (124 files, 1 minute or more per file...), but otherwise
it went smoothly.
The biggest changes you'll notice are the new exception system, a vastly
reduced usage of the remaining stack (though it's not complete
Jonathan Worthington wrote:
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 th
"Wherever two or more of you are gathered together..."
Bernhard and I are currently in the lobby at Hotel Centrum, 2 blocks
south-west from the main train station (Kobenhavns H) on the corner of
Istedgade and Helgolandsgade. Free wireless is available.
Will send an update if the location chan
We could use a few volunteers to port pages from parrotcode.org to the
new Parrot website. It's a simple repetitive task, view source on the
original page and paste the main HTML into the new CMS. (Ignoring any
pages automatically generated from Pod in the repository, because we'll
handle those
Will Coleda wrote:
I agree that any removed feature should have a deprecation cycle;
Here's my pitch for how we've already done that; the list of
deprecated features has RTs; the RT listed what was going to have to
happen for some time now; This covers us on the deprecation
notification.
I am w
The simple answer is Parrot won't do any automatic mapping of types
between HLLs. If you call a Python library function that returns a
Python Dictionary type, you'll get back a Python Dictionary PMC. You can
interact with it as a string keyed hash (because it implements the
string keyed vtable
I've posted the task list for the MMD branch to the wiki:
http://www.perlfoundation.org/parrot/index.cgi?pdd27mmd_tasklist
There's really only one task: merge the two MMD implementations into
one. But, I've split it out into a series of smaller tasks so we can
share the work and track progress
Klaas-Jan Stol wrote:
Therefore, my proposal is to remove the .globalconst directive;
whenever you need to have a global const, use .const outside of a
subroutine.
whenever you need to have a local const (in a sub), use .const inside a
subroutine.
If we're going to remove one, let's deprecate
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concatenate dot into "..", which looks
like it, but is more explicit, and will prevent such mistakes.
I agree that there should be some change. I've run into this problem
myself in the past, and i
Jeff Horwitz wrote:
i'd like to have an option in mod_parrot to clear all user-generated
data (globals, namespaces, subs, etc.) from an interpreter, leaving any
bytecode that has been loaded (e.g. compilers). the point here is to
eliminate problems caused by data persistence on hosted web serv
chromatic wrote:
On Thursday 07 August 2008 08:26:19 Bob Rogers wrote:
I once suggested a "null register allocator" that would do this
globally, but this is a better idea. The only use case I can think of
is debugging, particularly of the register allocator, but that's still
important.
In th
François Perrad wrote:
Ok, Lua tests pass, but the behavior has changed.
(The tests were written to check the exception message, not the full
back trace)
The pushaction allowed to retrieve the backtrace where the exception
occurred.
The backtrace from the exception handler is alway the same (d
Bob Rogers wrote:
From: Allison Randal <[EMAIL PROTECTED]>
The biggest changes you'll notice are the new exception system, a vastly
reduced usage of the remaining stack (though it's not completely removed
yet), and the fact that pushaction subs no longer fi
Bob Rogers wrote:
We're going to a completely stackless virtual machine.
But Parrot is already stackless. The dynamic_env slot to which I assume
you refer is really a tree with upward pointers.
To be clear, Parrot will have no *global* stack. The data structure
implementing the stack isn
Klaas-Jan Stol wrote:
On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concaten
Will Coleda wrote:
Any automatic mapping between multiple languages will fall down at some
point in a very ugly way. I imagine modules will be developed to allow you
to, for example, mask all Python types from within your Perl 6 code as Perl
6 types. But users will always have the ability to go
Andrew Whitworth wrote:
I created a new branch tonight, /branches/pdd09gc to try to continue
some of my GC work from the summer with a blank slate. I have a few
cleanup jobs I want to do first, so that it should be easier to add in
a new GC without having so many problems as I had. One thing I've
chromatic wrote:
If it's *close* (and mostly passing tests) we can always throw it back
into trunk immediately after a monthly release and give ourselves 4
weeks to clean it up.
The important thing to remember is that the GSOC project wasn't "revamp
the GC system to meet the new spec" it was
Will Coleda wrote:
Please open a ticket tracking this if we're not going to apply it
right now so we don't miss it for next release.
CPAN is great for distributing Perl modules, but simply can't handle
Parrot. As soon as we have the alternate FTP site up, we're done with CPAN.
Allison
Running 'make test' now fills the main directory of the repository with
junk files like:
test_98093.out
test_37653.c
test_98093.ldo
test_97159.c
The offending tests need to be modified to clean up after themselves.
Allison
Patrick R. Michaud wrote:
What I'm trying to do is to test the ability to resume after
exceptions thrown by C. The C sub above sets up
a handler to catch exceptions, then calls C. The handler
simply resumes any exception that is caught. The C sub
prints 'ok 1', throws an exception, prints 'ok
Klaas-Jan Stol wrote:
I'm sorry, but this is not the case. It is in fact valid:
running:
==
.sub main
newclass $P0, "foo"
$P1 = new "foo"
$P1 .hi() # note the space before the dot
$P1. hi() # note the space after the dot
.end
.namespace ["foo"]
.sub hi :method
pr
Reini Urban wrote:
As my number of patches is too big, and the size is too big,
I update them only in my public SVN repo, not in the tickets anymore.
And the order in which they should be applied is important.
See
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/pa
James E Keenan wrote:
Are these happening notwithstanding the patches I applied for RTs 57956,
57958 and 58036?
The stray test files are gone now, and not recreated by 'make test',
'perl Configure.pl', or 'perl Configure.pl --test=configure'.
Thanks!
Allison
[EMAIL PROTECTED] wrote:
>
> {WS}"."{WS} means concatenation (as in $P0 . $P1)
> {WS}"." means concatenation (as in $P0 .$P1)
> "."{WS} means concatenation (as in $P0. $P1)
> "." means method call (as in $P0.$P1)
You can simplify even further and make these two syntax errors:
{WS}"." means conc
Stephen Weeks (via RT) wrote:
There are some issues that need to be resolved for resumable exceptions.
The first issue I've run into is that Parrot_cx_find_handler_local marks
the exception handler as used when it finds it and ignores already-used
exception handlers.
This is an intentional fe
Reini Urban wrote:
The issue is not the CPAN SW, which can easily be fixed somewhen (no-index),
the CPAN mirror network and the popularity is what parrot should look
forward to, IMHO
For that purpose, we're better off targeting the much larger
distribution networks of Debian, Ubuntu, Red Hat,
Klaas-Jan Stol (via RT) wrote:
Parrot has an instruction called 'set_addr', that stores the address of a
label into an integer register.
IMCC (and pdd19_pir) defines a short-cut for this op, called 'addr'.
$I0 = addr XYZ
I propose to remove this shortcut; should anybody want to use it, just u
Moritz Lenz wrote:
On #perl6 somebody just asked if there were up-to-date windows builds of
parrot somewhere, he had googled for 'parrot windows'. The parrotwin32
project didn't show up in his search (but it's first for 'parrot win32').
I think we should improve that situation. Suggestions:
1)
Kevin Tew wrote:
I still think too much junk is in jit_emit.h
The patch attached shows how I would re-factor it.
That's a sane refactor. Thumbs up.
Allison
Reini Urban wrote:
Moritz Lenz schrieb:
Against which svn revision should I apply those patches for testing?
I'll try to be uptodate against HEAD with the patches in my SVN repo.
But things are changing fast over there.
config/gen/makefiles/root.in was changed by the ncigen merge yesterday.
Will Coleda wrote:
In general, I'm not a fan of the AUTHOR sections. As you've noted,
they can get stale or out of sync pretty easily.
A lot of this information is captured in the version control metadata,
CREDITS, and RESPONSIBLE_PARTIES, and if someone's looking to get a
question answered, we
Reini Urban wrote:
You want one patch only against HEAD? That's easy.
But I dislike the idea, as it violates the usage of single tickets.
This is different than the usual case as it's a collection of dependent
patches that can't be evaluated independently. Splitting them out is
actually more
Will Coleda wrote:
Moritz Lenz wrote:
Reini Urban wrote:
Actually I stumbled over quite a lot of dangling references in the docs.
Including, but not limited to, references to PDDS that still live in
draft/, but are references to be in docs/pdds/ directly.
What should we do with all these?
You
Reini Urban wrote:
In lib/Parrot/Configure/Compiler.pm, I agree that 'CONDITIONED_LINE' and
'INVERSE_CONDITIONED_LINE' aren't the clearest names, but '+' and '-' are
far less clear. Change them to something meaningful like 'SHOW_LINE_IF' and
'HIDE_LINE_IF'. We can note the change in DEPRECATED.
James Keenan via RT wrote:
3. For future reference, submit bug reports to:
[EMAIL PROTECTED] I recommend beginning Subject line with:
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).
Ge
On Mon, 25 Aug 2008, Reini Urban wrote:
To clarify my bold statement:
The ALGOL-like syntax is not "sane" because,
* it is hard to parse,
Not actually true. It's just different to parse. And, in general Parrot
optimizes for making code easy to *read* even if it is slightly harder
to parse. We
jerry gay wrote:
#+ and #- is lisp so I don't want to destroy #+ the syntax rules.
#IF(): is quite short and easy to read.
i know it was all caps before, but do we need to continue that trend?
i find it ugly.
All-caps is the Parrot coding standard for macros and #defines, and
these fall in
jerry gay wrote:
On Tue, Aug 26, 2008 at 9:16 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
jerry gay schrieb:
On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
I'll go now for something like
#IF(key1|key2&(key3&!key4))
To make sure, that means basically the same thing as
James Keenan via RT wrote:
On Mon Aug 25 13:15:16 2008, [EMAIL PROTECTED] wrote:
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters.
Well, since it's in the docs, I will withdraw the suggestion.
Howev
Reini Urban wrote:
I have one more draft.
chromatic told me write up such a thing, but it's not finished yet.
It could go to the cygwin070patches branch which is really a
parrot_install branch, but also to HEAD.
This needs some technical review because but I'm still a beginner
in what is possib
NotFound wrote:
Hello.
The current grammar for ATTR in pmc2c allows declarations of the form:
* varname
In the perl6multisub pmc we have the attribute candidates_sorted whose
intended type is candidate_info **, having two problems:
The current grammar allows a single pointer, not a pointer to
Bob Rogers wrote:
OK, here's my straw-man proposal for a language interoperability
framework; my apologies for sitting on it so long. It's still pretty
messy, but I'm sure it will benefit more from other viewpoints at this
stage than from polishing.
Thanks, added to trunk as pdd31_hll_inter
Allison Randal wrote:
Bob Rogers wrote:
OK, here's my straw-man proposal for a language interoperability
framework; my apologies for sitting on it so long. It's still pretty
messy, but I'm sure it will benefit more from other viewpoints at this
stage than from polishing.
T
[EMAIL PROTECTED] wrote:
Opcode names are not reserved words in PIR, and may be used as variable names.
For example, you can define a local variable named C. [See RT #24251]
+Note that by using an opcode name as a local variable name, the variable will
+I the opcode name, effectively making th
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term "unimethod" acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is "single dispatch", and "unimethod"
could thus be "single method".
Just "single dispatch". A method that's single dispatched, is... a method.
Allis
[EMAIL PROTECTED] wrote:
+PIR keywords, on the other hand, I reserved, and cannot be used as
+identifiers. Some opcode names (C, C) are, in fact, PIR keywords,
+which therefore cannot be used as identifiers.
If the PDD says the keywords are reserved, it also needs to say what the
keywords ar
Reini Urban wrote:
A new idea:
===
#IF(darwin):
#ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X
#ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@
Just a little too much complexity, for not enough benefit.
The POD for this change:
Looks good.
For legacy the old synta
Will Coleda wrote:
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the b
Patrick R. Michaud wrote:
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
That's backwards. Loading the language module is what registers the
compiler. The user never needs to access the compiler object for a
particular language directly unless they're compiling c
Geoffrey Broadwell via RT wrote:
What is the replacement for the old "regular" variants that use a
pre-existing destination?
A few years ago when I was doing copious Perl 5 PDL work, I found that
in certain loops I would get bottlenecked entirely by creation and
destruction of temporaries. I m
Bob Rogers wrote:
Just "single dispatch". A method that's single dispatched, is... a method.
True. Nevertheless, the two kinds of method are treated quite
differently by Parrot, both when being defined and when being called.
That is why it is awkward not to have concise names for both kinds
Bob Rogers wrote:
So you prefer the plain term "method" for "method that is not a
multimethod"? That seems prone to confusion. What do you suggest for
the generic term?
It's not prone to confusion. By definition, a "method" is a invoked on a
single invocant (an instance of the class that co
Reini Urban wrote:
Problem:
Most packages will not accept packages with /usr/bin/scheme,
/usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh
were these are the parrot implementations.
Of course we don't want to hijack existing language executables in the
distribution packages. But,
Reini Urban wrote:
I hope you know that this #+() syntax is the only existing syntax.
It is widely used since about 20 years.
The rest is something new we came up with.
It's high time for a little progress. Sheesh, in 1988 we were excited by
computers with 1 MB of RAM. ;)
Allison
Reini Urban wrote:
Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6
Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to
/usr/bin/parrot-perl6 then.
Currently there's only a /usr/bin/perl6 being installed.
This really should be made ready for the September release.
Will Coleda wrote:
It's important to keep in mind that for the most part, at least on
unix-related operating systems, executables for a particular language will
simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0
executable name information to set up certain configuration for the
Patrick R. Michaud wrote:
On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote:
2008/8/29 Allison Randal:
... the $0 handling will be built in to Parrot, so the
user could also easily create their own 'ln -s' aliases.
Within the PCT::HLLCompiler I assume.
PCT::HLLCompiler c
Reini Urban wrote:
And I'm tempted to add: Actually even the 1984 version of lisps are
still technically and syntax-wise far advanced over the perl and
parrot state of today. I see not much of a progress.
Philosophically, I agree. In my usual Parrot architecture talk there's a
slide right at
Klaas-Jan Stol (via RT) wrote:
The parentheses surrounding the arguments are mandatory. Besides making
sequence break more conspicuous, this is necessary to distinguish this
syntax from other uses of the C<.return> directive that will be probably
deprecated.
The open issue of the 'probably dep
Klaas-Jan Stol wrote:
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
Yes, it will be deprecated, or at least renamed. The C<.return> directive
without parentheses is an old convention for passing a single return result,
and must always be sandwiche
Bob Rogers wrote:
My sense of the usage on this list is that "multisub" means a MultiSub
PMC and a "multimethod" is what you add to the MultiSub when you define
a sub with the :multi keyword. Am I the only one who finds this a
useful distinction?
Oh, I see. No wonder this conversation has bee
Klaas-Jan Stol wrote:
This is another one of those muddy cases in PIR where words conflict when
they shouldn't. I can't think of any way that it's actually useful to have a
variable named 'add' prevent you from using the opcode 'add'.
.. but of course, I don't want to exclude it. If it is rea
Bob Rogers wrote:
Allison Randal wrote:
+Monkeypatching is certainly possible, but not encouraged.
Cool; a new term in Allison-speak! ;-}
As much as linguists love creating new words, I can't claim credit for
this one:
http://en.wikipedia.org/wiki/Monkey_patch
More later,
Allison
Bob Rogers wrote:
+{{ There seems to be an implied basic assumption here that language
+interoperability is the responsibility of the language
+implementor. It is not. We cannot require that language
+implementors design and implement their languages according to some
+global spe
Klaas-Jan Stol wrote:
This must make the following syntax rule illegal:
target = null
because if "null" is declared as a .local, you can't know whether you want
to nullify target, or want to set target's value to that of the .local
variable "null".
I take it this is no problem; just stick to
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are op
Klaas-Jan Stol wrote:
On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
I'm not clear on why we need to reserve 'if', 'unless' and 'null' either,
since they never appear in locations that could be confused with variables.
the
The new Parrot website http://www.parrot.org/ is now live. Please take a
look, create an account for yourself, and report any broken links you find.
Just creating an account will allow you to create wiki pages. If you'd
like to help out with content on other parts of the site, let me know
and
Moritz Lenz wrote:
Creating an account leads directly to the front page again, without any
indication if it was successful or not.
There should be a message just below the "mission statement" box and
just above the first story on the main page. Possibly we should make the
text red or put it
Alejandro Gómez de Argüello y de Laburu wrote:
The "How to Get Involved" page at https://www.parrot.org/dev/get-involved
has a broken link: clicking on "Report or fix a bug in this website" takes
me to https://www.parrot.org/dev/site.html -- which says "Page not found".
The page at https://www.p
Ronald Schmidt wrote:
I applied for an account and built what seems to me to be an appropriate
Parrot Testing Status page. My proposed link target is
http://www.parrot.org/wiki/some-testing-status-tools . If someone wants
to set me up as a site editor I will fix the link myself otherwise the
Christoph Otto wrote:
The non-draft PDDs are all passing t/codingstd/pdd_format.t as of
r30810, but two of the draft PDDs aren't. Since they're still drafts
and as such are very likely to change, it doesn't seem worthwhile to
bring them into compliance or to have a test depend on them.
I p
jerry gay wrote:
the sugar for what can be on the left side of an equals sign needs to
be changed. simply having a first parameter with OUT isn't enough. the
same thing happens for
$P0 = push $S1
which is legal pir syntax, but obscure at best.
ops must have some means of specifying (perhaps
Alejandro Gómez de Argüello y de Laburu wrote:
Following the instructions I found in "How to Get Involved" at the
parrot.org website, I hereby volunteer to help maintain said website
"by updating existing pages or adding new content", or in other ways
such as my skills and time allow.
Thanks fo
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
#parrotsketch unless there are any objections.
Excellent idea. T
Christoph Otto via RT wrote:
If there isn't a technical reason why this is necessary, there's no
reason to create such a limitation. If there is such a reason, just
pick something big and make the code enforce it.
The PDD should of course be kept in sync with reality, but that simply
entails a s
chromatic wrote:
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot__class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem with my vt
Christoph Otto via RT wrote:
Is this something we want to go ahead with or should this ticket be
rejected?
I've had it on my hiveminder todo list for over a month now. The problem
is, it's not only a matter of annoying fiddly bookkeeping work now, it's
also annoying fiddly bookkeeping work e
Christoph Otto via RT wrote:
I'll sign up to do the grunt work to fix the failing tests if someone
makes a decision on what the consistent behavior should be.
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
http
NotFound wrote:
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are candida
I've just committed an initial pass on the Installation PDD. It's
looking good, definitely a good start. I've included some comments to
seed further discussion and development of the draft.
Also, we'll need to include more details on the installation of Parrot
itself (the draft leans pretty he
jerry gay wrote:
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
Potentially, yes. In the case of the scalar PMC it
Google has graciously agreed to host the first ever Parrot Developer
Summit. November 15th and 16th, 2008 on Google's Mountain View campus.
You can find directions to the campus at:
http://code.google.com/events/visitors
More details to follow. Hope to see you there!
Allison
chromatic wrote:
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
The desired MMD sub should take two PMCs and returns an INTVAL (frame #5,
signature "PP->I"), but the invoked MMD sub takes two PMCs and returns a PMC.
The crash comes in convert_arg,
Patrick R. Michaud wrote:
Just for clarification: IIUC, the n_* opcodes and their semantics
aren't really "going away" -- they're simply being renamed to not
have the leading "n_" prefix. It's the existing "add", "sub",
"mul", "div", etc. opcodes that are being eliminated.
Yes. That is, c
Will Coleda wrote:
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
els
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used once in the
repository, in an STM macro.
Added to the I/O milestone tasklist.
Allison
NotFound wrote:
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it&
1 - 100 of 882 matches
Mail list logo