per
communities, so feel free to pass this along to anyone you think might
be interested.
Thanks,
Allison
it, and as
far as I know wasn't the result of any conversations with anyone. It is
his own personal opinion, which he's entitled to hold, but does not
reflect any official policy of the Parrot project.
Allison
ill always be, made by open discussion between all
participants in the project. Jonathan has expressed his opinion, and
there are many legitimate reasons to disagree with his opinion.
Discussions will continue.
Allison
parrot-devel package Depends on),
but I don't think that quite catches all of them. We'll be helped by the
fact that Parrot recently had a thread about cleaning out the library
set, so we may have fewer to deal with. I'll follow up on that in a
separate thread.
> and I'd like to volunteer to write the dh_parrot
> script. Once this is done Parrot and Rakudo packging would become much more
> independant one from the other than they are now and make our lives easier
> too :)
Thanks!
Allison
ontain compiled bytecode, or
other version-dependent compiled output like dynpmcs, PMC .dump files,
dynops, output of pmc2exe, etc...).
Allison
uldn't force the project into a different
mindset. To give you an idea of what Debian packaging is looking for,
take a skim through the upstream guide:
http://wiki.debian.org/UpstreamGuide
> Also just to check - are you packaging Rakudo compiler releases, or
> Rakudo distribution releases (which are the ones we more intend for
> packaging)? Mostly asking due to the timing of the email; we didn't do a
> distribution release for March (so last interested one to package was in
> Feb), and the next one is due this month.
I'm not building the packages for Rakudo, so can't answer. I've CC'd the
Rakudo packaging team.
Allison
strictly depend on them.
Makes sense for the libraries that move to separate source packages.
But, would it be necessary for libraries in binary packages built from
the parrot source package?
Allison
ain compiled
bytecode, with a Depends on parrotapi-*.
Allison
exceptions are pain points for packaging (we've got one coming up for 4.3).
Allison
able to run on any Parrot release within the past year
(at least). The fact that it can't is a sign of poor software. We need
to figure out what's broken and fix it. I'm happy to help. Highly
motivated too, as it would remove a regular source of irritation.
Allison
hardcoded path to the parrot executable). Attached
git patch to fix the test target.
Allison
>From 90672654a8f2600dbc8b67f4f46286d1ed2b7279 Mon Sep 17 00:00:00 2001
From: Allison Randal
Date: Mon, 23 Feb 2009 18:03:30 -0800
Subject: [PATCH] Also fix t/harness to use installed Parrot executable when r
Author: allison
Date: Wed Jan 28 16:50:06 2009
New Revision: 36125
Modified:
trunk/docs/pdds/pdd28_strings.pod
Log:
[pdd] Add descriptions for 'compare' and 'equal' functions. Catch an
unconverted old function name.
Modified: trunk/docs/pd
Author: allison
Date: Tue Jan 27 20:35:00 2009
New Revision: 36076
Modified:
trunk/docs/pdds/pdd28_strings.pod
Log:
[pdd] Regularizing string API function names to fit the pattern of a
three-character subsystem identifier.
Modified: trunk/docs/pdds/pdd28_strings.pod
neric or abstract PMC type for that language (LuaAny
and TclObject, respectively). I'll get to work on a patch to propagate
ATTRs to children and post it here when it gets close to ready.
Sounds good. Thanks!
Allison
, "PMCType_foo"));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the
right inheritance tree.
This is overkill. Accessor macros already work on PMCs similarly to how
PMC_x_val is used.
Allison
s I've seen are), or can be cleanly substituted with
something else.
Allison
Christoph Otto wrote:
Allison Randal wrote:
(Actually, at the moment you're required to declare
all parent attributes in the ATTR list before the child attributes, so
inherited attributes *are* child attributes.)
When I say "attributes", I mean the things that are declared
h in all the core PMCs too. So, I'm
comfortable transitioning to just a PMC argument to morph.
Allison
as
bad as type IDs. And check the performance on the branch, as I'm not
sure how heavily PGE is using morph. We may need both integer and PMC
versions of morph for the internals, but only allow the PMC one to be
overridden from PIR.
Allison
n the same line of code, that
probably means it should really be a vtable function call instead of
direct access into the data struct.
Allison
re only a few possible email addresses I would
have used (and Firefox even remembered my first choice).
Your account had no email address associated with it.
I just deleted the old account, so re-register and I'll regrant you
permissions.
Allison
an automated
email about the update.
Allison
Allison Randal wrote:
Our trac admins report that this is caused by users who don't have their
email authenticated (that is, Trac sends you a test email, and you
confirm that you got it, so Trac knows the address is valid). When we
upgraded, existing users needed to re-authenticate their
Author: allison
Date: Sat Jan 10 19:55:39 2009
New Revision: 35378
Modified:
trunk/docs/pdds/pdd09_gc.pod
Changes in other areas also in this revision:
Added:
trunk/include/parrot/gc_api.h
- copied unchanged from r35374,
/branches/pdd09gc_part2/include/parrot/gc_api.h
trunk
t the upgrade process doesn't include resending the
authentication emails.
When you update your email address in trac, it should resend the
authentication request. Once you confirm the change, you'll be set.
Allison
Author: allison
Date: Tue Dec 30 18:53:27 2008
New Revision: 34684
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Log:
[pdd] Remove the 'HISTORY' section from expected documentation, as it is no
longer used. Be explicit on our policy about author information in individual
files
'binary_not', 'binary_nots') so they return
a new PMC, rather than morphing the existing destination PMC. (Many of
them already do this, so the 'n_*' variants were actually already doing
the same thing as the regular opcodes.)
Allison
to help guide anyone else who takes a crack at it.)
BTW, the other failing test in the remove_pic branch was simply because
there are fewer elements in the packfile directory now that 'pic_index'
has been removed. Fixed in r34401.
Allison
something as small as this.
Allison
ions refactors are non-critical (some will likely
land after 1.0), because the interface will stay the same, it's only the
internals that will change.
Allison
the dependencies. Clearly the release has
already happened without them, so they aren't really dependencies.
Allison
Author: allison
Date: Tue Dec 16 14:03:21 2008
New Revision: 33985
Modified:
trunk/docs/pdds/pdd22_io.pod
Log:
[pdd] Remove section on Deprecated Opcodes from I/O PDD, now that all of them
have been removed.
Modified: trunk/docs/pdds/pdd22_io.pod
Author: allison
Date: Mon Dec 8 21:16:33 2008
New Revision: 33695
Modified:
trunk/docs/pdds/pdd22_io.pod
Changes in other areas also in this revision:
Added:
trunk/src/io/core.c
- copied unchanged from r33691, /branches/pdd22io_part2/src/io/core.c
trunk/src/io/socket_api.c
Author: allison
Date: Mon Dec 8 19:45:45 2008
New Revision: 33688
Modified:
trunk/docs/pdds/pdd15_objects.pod
Log:
[pdd] Caught documented name inconsistent with implemented name.
Modified: trunk/docs/pdds/pdd15_objects.pod
Author: allison
Date: Mon Nov 24 23:41:10 2008
New Revision: 33181
Modified:
trunk/docs/pdds/draft/pdd14_numbers.pod
Log:
[pdds] Add interface definition for Integer PMC.
Modified: trunk/docs/pdds/draft/pdd14_numbers.pod
Author: allison
Date: Mon Nov 24 21:33:52 2008
New Revision: 33178
Removed:
trunk/docs/pdds/draft/pdd04_datatypes.pod
Log:
[pdds] Deleting the now completly redundant datatypes PDD (number 4 is
now available for reuse).
Author: allison
Date: Mon Nov 24 21:32:51 2008
New Revision: 33177
Modified:
trunk/docs/pdds/draft/pdd14_numbers.pod
Log:
[pdds] Descriptions of the native integer and float types.
Modified: trunk/docs/pdds/draft/pdd14_numbers.pod
Author: allison
Date: Mon Nov 24 20:30:27 2008
New Revision: 33174
Added:
trunk/docs/pdds/draft/pdd14_numbers.pod
- copied unchanged from r33169, /trunk/docs/pdds/draft/pdd14_bignum.pod
Removed:
trunk/docs/pdds/draft/pdd14_bignum.pod
Log:
[pdds] Renaming PDD 14, preparing for merge
recation of 'mmd_cvt_to_types' out into a separate ticket for
refactoring the unholy trio of 'mmd_cvt_to_types',
'Parrot_mmd_get_cached_multi_sig', and 'mmd_distance'.
Allison
Author: allison
Date: Wed Nov 19 17:50:32 2008
New Revision: 32918
Modified:
trunk/docs/pdds/pdd22_io.pod
Changes in other areas also in this revision:
Added:
trunk/include/parrot/io_portable.h
- copied unchanged from r32916,
/branches/pdd22io/include/parrot/io_portable.h
trunk
t it's good to have the status show that this
isn't a ticket in need of active work.
Allison
wait until after the GC refactor
(which is the next big branch after the I/O). Contexts are recycled so
rapidly, that the current GC would be really slow.
Allison
Will Coleda wrote:
Is the smoke server still used?
Can support for the smoke server be dropped?
+1 from me; I vote for smolder.
+1, on not maintaining two independent solutions for the same problem.
Allison
, etc).
Agreed. Once 2) and 3) are done, ticket can be closed.
Allison
ons of each.
pmc_new_init_str(PARROT_INTERP, INTVAL base_type, ARGIN(STRING *init))
Allison
es. But 99% of the time, the useful information is where
the exception was thrown, so the extra effort of tracking both doesn't
add enough value to be worth it. But, if someone did need to track both
(perhaps for a research project), they could just subclass the Exception
class and add a creation backtrace.
Allison
Will Coleda via RT wrote:
This appears to be the only .pragma; should we leave a placeholder or
just remove .pragma entirely when we remove this particular one?
Nuke it.
Allison
On Wed Oct 15 17:48:28 2008, Whiteknight wrote:
>
> With the pdd27mmd branch merged in now, what's the status of this request?
The MMD table is now just a namespace, and namespaces are shareable
between interpreters. So, resolved.
Allison
Patrick R. Michaud wrote:
On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote:
(I suppose technically we should stop calling this a "stack trace" since
it's not a stack. But "return continuation chain trace" is just too
verbose.)
"backtrace"
Will Coleda wrote:
Allison Randal wrote:
...you expect 'rethrow' to keep the stack trace of the original 'die'?
Yes.
The way to do this is to add stack trace information to the Exception's
'stacktrace' attribute when the exception is first thrown, a
D system). And it's not even really
the right speedup for 'get_params', 'set_args', and 'set_returns'.
There are also a pile of old, nasty MMD functions that should be deleted
and are only called from src/pic.c.
Allison
completely separate from the open source
group. Still, it's worth asking.
Allison
die "eek"
end
$ ../../parrot bar.pir
eek
current instr.: 'foo' pc 16 (bar.pir:9)
I don't understand the problem. Is it that you expect 'rethrow' to keep
the stack trace of the original 'die'?
Allison
ticket is too vague to be useful.
Ticket rejected, and comment removed from code in r32039.
Allison
> replaced with real_exception, if any.
In the process of changing 'internal_exception' to 'exit_fatal' we
reviewed those calls, and changed as many as possible to real
exceptions. (Basically, if it could be converted to an exception, it
was, if it couldn't be, it was left as 'exit_fatal'.)
Closing this ticket.
Allison
under parrotcode.org/docs in HTML format for easy access.
This would probably help productivity and maybe even attract new
developers.
Just my two cents...
we're moving to http://www.parrot.org/ ; I think Allison has said
we're going to automate this publishing process.
Yes,
replace all calls to
'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and
after a standard one release deprecation cycle remove the old function.
Allison
he branch for the next major or
minor release, so we don't have an insane rush to cram features in just
before a release.
Allison
chromatic wrote:
On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote:
With the attached patch, parrot builds and tests with no errors[0]. A
re-configure is necessary to regenerate a file.
[0] well, no additional or unexpected errors.
Works for me. +1 to apply.
+1
Allison
one change to see if it solves the
problem, but the n_mod and n_shl opcodes don't exist anymore.
Could you run the attached modified version of the test file and send me
the output?
Allison
## The PMC shl op will promote Integer to Bigint when needed. We can't stuff a
## BigInt
http://smolder.plusthree.com/app/public_projects/tap_stream/6316/163
What version of Darwin and what x86 hardware?
Allison
Andrew Whitworth via RT wrote:
After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the
".pragma n_operators" can disappear with them?
Yes. (The n_* opcodes aren't quite all gone yet, but nearly and soon.)
Allison
done? Are there any specific
changes in the code that have not yet been reflected in the documentation?
This ticket can be closed. We have a general documentation review pass
coming up preparing for the 1.0 release, and this is just part of that.
Doesn't need a separate ticket.
Allison
resuming after the exception is
handled. (Resuming by default, instead of only resuming when the resume
continuation is explicitly invoked.)
Allison
NotFound wrote:
Where to put a test for this? There is no t/ops/io.t and creating a
file for each io opcode seems excessive
Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one
on the list, which I'll create a branch for later this week).
Allison
respect
inherited vtable functions.
There was a VTABLE 'pow' in scalar that had previously been ignored in
Integer, but was now being used (it called 'set_number_native' which
morphed the destination to a Float). So, I changed scalar's 'pow' to a
MULTI in r31880, and it works fine.
Allison
Christoph Otto (via RT) wrote:
In response to a question about comparison operators in Pipp*, Allison
suggested that I add a variant cmp VTABLE function which returns a PMC instead
of an INTVAL. This patch adds such a function, named pmc_cmp. It's named
pmc_cmp rather than cmp_pmc t
. it seems natural
that we add spectest_regression to the 'test' makefile target.
additionally, this would have possibly prevented the 74 failures
post-mdd-merge, since allison didn't know about the additional test
target in the makefile.
well, if reading the README is too much ev
ialization of MULTIs
declared in a PMC. I was hoping to avoid all those C strings. But, try
r31879.
Allison
Author: allison
Date: Tue Oct 7 08:04:35 2008
New Revision: 31755
Modified:
trunk/docs/pdds/draft/pdd01_overview.pod
Log:
[pdd] New introduction for Overview PDD.
Modified: trunk/docs/pdds/draft/pdd01_overview.pod
Author: allison
Date: Sun Oct 5 04:30:01 2008
New Revision: 31668
Modified:
trunk/docs/pdds/pdd27_multiple_dispatch.pod
Changes in other areas also in this revision:
Added:
trunk/docs/multidispatch.pod
- copied unchanged from r31667, /branches/pdd27mmd/docs/multidispatch.pod
le entries" was another common old way of referring to
them, but I've been updating those to "vtable function" too, because
"entry" seems a little vague (though, it's technically accurate, because
the "vtable" is a whole set of functions (a "table" of functions) for
the PMC, so a single vtable function is an entry in that vtable).
Allison
type.
Yup. "vtable functions" is what I've been standardizing on everywhere I
find the old "vtable method".
Allison
urned from
'Parrot_build_sig_object_from_varargs' instead of as soon as it's
created in the function. That'd only be a few lines away with the
register and unregister the same function. But with the current garbage
collector, I feel safer registering the signature object as soon as it's
created.
Allison
Stephen Weeks wrote:
Commit 31294 implements this behavior. Can I get confirmation that it's
correct?
Just looked over the diff. Perfect. Thanks!
Allison
y any outer dynamic scope, not just the immediate surrounding
dynamic scope.
Allison
tionality.
H... yeah, I like that idea. Especially since 'break' and 'continue'
mean different things in different languages and different contexts
(like 'break' and 'continue' in gdb, for example).
Allison
ough that no one got around to it?
This looks interesting, if anyone's motivated:
http://www.methodize.org/nntprss/
Allison
iling list. (IIRC, I've been caught by this before.)
Thanks for forwarding it on, exactly as I asked. :)
Allison
my email client, so Jim,
could you forward this on?)
And only just now found that Jim had CC'd the parrot mailing list as
well as the news group that I wasn't able to reply to. I wouldn't be sad
to see NNTP go.
Allison
Patrick R. Michaud wrote:
On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote:
We'll likely end up with messages scattered between both lists for a
little while, but the perl6-internals/parrot-porters addresses are
deprecated and will be disabled after a sensible deprecation
Patrick R. Michaud wrote:
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be fixed.
Thanks, applied. I also updated parrot.org.
Allison
OTECTED]> on the message.
Allison
I as
the only parameter, and the return continuation stored within that
exception object.
--
Please revert the branch merge or make another update.
Thanks!
Allison
7;t nearly as zippy
as 'gather' and 'take', but they're more meaningful to a broader
audience, which may help the feature spread.
Allison
e answer is yes, it will never
return. So I'm hoping a 'can_handle' method that either returns false
or transfers control to somewhere else can be made to work.
For that, you would implement a catch-all handler (completely ignoring
'can_handle'), and then rethrow any exceptions you can't handle.
Allison
rinciple. The principle is that global things
should be language-agnostic, and not use terminology that's confusing to
all the other languages.
Allison
Christoph Otto via RT wrote:
On Mon Oct 22 07:01:59 2007, pcoch wrote:
In src/pmc/hash.pmc:thaw() there is the todo item:
/* TODO make a better interface for hash creation
... do this.
Where do we want to go with this?
Ax the ticket. Vague plans for future change aren't useful.
Allison
ative) vtable function defined.
(Ultimately, the storage for these PMCs should all be changed to ATTRs
and the accessors to GET_ATTR_* and SET_ATTR_*.)
Allison
dividual languages define their own. EXCEPTION_TAKE really
doesn't make sense for anything other than Perl 6. Not today, but someday.
Allison
* deprecated said particle on #parrot.
Thanks, approved for application in trunk.
Allison
, when receiving a NULL c string must be documented and
implemented, or we risk to plague the code base with lots of more
workarounds.
This should be submitted as a separate ticket with example code/error
messages.
Allison
Klaas-Jan Stol wrote:
Allison:
I made the following changes in pirc/new:
.arg -> .set_arg
.result -> .get_result
.return -> .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return -> .set_return (in long-style returning : .begin/end_return
.yield -
eep the generated flex/bison
files checked in.
Allison
nterface for checking
whether a particular handler will accept a particular exception. All
other checks should be hidden behind that method.
Any other thoughts or comments?
Make it so, Mr. Crusher. :)
Allison
hings
like call subs with 206 parameters. It's a design decision.
It certainly shouldn't segfault. But, the question is: why does it
segfault at 206 parameters? Throwing an exception to avoid an error we
don't understand isn't good for the long-term health of the VM.
Allison
lls should work identically.
Even more confusing, this code:
Yes, we need better error checking and better error reporting in named
argument handling. We need a general invocation refactor, but can do it
in small stages.
Let's go with defaulting to the same name as the .param on the bare :named.
Allison
uments throughout the system
(expensive and error-prone) or store it as global state information
(error-prone, and bad for a clean implementation of concurrency).
But, an individual HLL can store any arbitrary PMC value as the payload
of an exception object, and act as if it had thrown an arbitrary PMC as
an exception.
Allison
Author: allison
Date: Tue Sep 16 13:12:27 2008
New Revision: 31186
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
[pdd] Clarifying the description of the 'throw' opcode, and the necessary
interface of thrown exceptions.
Modified: trunk/docs/pdds/pdd23_exce
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 1208 matches
Mail list logo
