Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On Tue, Jul 1, 2008 at 7:17 AM, Will Coleda via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Jun 26 11:01:00 2008, [EMAIL PROTECTED] wrote:
>> chromatic wrote:
>>
>> > T::H 3 is only a requirement for people who want to type 'make
>> smolder' (and
>> > eventually I hope 'make smoke'), so probing for it without bundling
>> it seems
>> > eminently sensible to me.
>>
>> Agreed. That's what we do with TAP::Harness::Archive.
>>
>
> Based on recent emails to the list, apparently 'make test' in trunk
> seems to now require T::H 3. (not just for 'make smolder').
>
> If we can do without T::H 3 for simple 'make test', that would be nice.
> If we need it, then we need to have a graceful exit message on make test
> and not the error we get now.
>
T::H 3 has been listed as a required dependency for many test-related
enhancements, such as parallel testing, aggregated testing, and smoke
testing. let's make it a requirement, rather than an optional
dependency. if it proves too burdensome for folks to upgrade, we can
rollback.
> We also need to add a config probe to test for the version of T:H
> available, and if it is NOT the minimum version, warn the user that
> 'make test' will fail to work for them.
>
> We also need to see if we can require a specific version in
> Bundle::Parrot. I'm not sure that's possible. particle?
>
yes, it's possible. easy, even. it's done is svn, and i can release to
cpan on short notice.
> I don't particularly mind requiring T::H 3 even for 'make test', but we
> definitely need to be careful about it. We should probably declare this
> in our requirements in the tarball we post to CPAN as well so that don't
> automatically fail most of our cpan testers.
>
that's what Makefile.PL is for. if we require Bundle::Parrot there, we
can make sure cpan testers have what they need. if we do the same in
Configure.pl, then we can make sure svn users have what they need,
too.
something like:
eval { require Bundle::Parrot };
if ($@) {
die "Bundle::Parrot has not been installed, Configure.pl cannot continue.";
}
that is, if Bundle:: modules get registered with perl. i'm not sure
that's the case. anyone know better?
~jerry
Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Sun, Sep 7, 2008 at 2:07 PM, Andy Dougherty <[EMAIL PROTECTED]> wrote: > On Sat, 6 Sep 2008, Christoph Otto via RT wrote: > >> On Wed May 10 11:01:34 2006, stmpeters wrote: >> > >> > I'm taking a look at it. I should have something working this evening >> > for the configs. Adding the HAS_BLAH's will take some additional time. >> > >> > Steve Peters >> > [EMAIL PROTECTED] >> >> >> "when useful" is vague does not indicate why the extra configuration >> machinery is justified by whatever benefit we'd get from using these >> functions. If someone would like to make the requirements a little >> tighter or make the case for implementing this request (or even >> implement it), they'd be encouraged. Otherwise this ticket isn't very >> useful. >> It would be good to either go somewhere with this or reject this request. > > These functions are typically used in place of the plain sprintf and > strcat family as a way to be explicitly careful about buffer overflows. > Plain sprintf and strcat are both widely used in the parrot source. > Replacing them when it would ease future maintenance and help ensure > parrot is not susceptible to buffer overflows is a quite sensible path > forward. > > As you correctly observe, no one has actually done anything about it yet. > That doesn't mean it's not worth doing, however. > > I'd say it should simply stay as an open ticket. > +1 ~jerry
[perl #49762] [BUG] present but unconfigured svk is hanging build.
On Tue Jun 03 13:05:37 2008, [EMAIL PROTECTED] wrote:
>
> I wonder if setting the SVKROOT environment variable to something
unlikely
> would help simulate this.
>
> $ENV{SVKROOT} = 'you must be kidding me';
>
I tried this tonight in two locations: my iBook, where I once tried to
install SVK and failed; and a Debian Linux box, where I know SVK has
never been installed.
There were no obstacles to build in either location and no test failures
(except those that were failing for other reasons).
Is there any reason to keep this ticket open?
Thank you very much.
kid51
Re: Beta of web services to fulfill smoke "Queryability" requirements.
I updated the wiki a little about this. http://www.perlfoundation.org/parrot/index.cgi?rfp_parrot_needs_better_smoke_reports
Re: [PATCH][perl #58030] Bugfix of "Named parameter passing errors"
On Sun, Aug 17, 2008 at 9:20 AM, mhelix <[EMAIL PROTECTED]> wrote: > The first named parameter isn't set if optional parameters are missing. The > function Parrot_process_args didn't > save the value of the argument. I used memcpy to copy the UnionVal. If > there's a neater way to do that please > fix my fix :) . > > It only adds a couple of lines to src/inter_call.c. Here's the diffstat > output: Patch applied with some style changes in r30870 Looks like it solves several known problems, good job! -- Salu2
[perl #55846] [BUG]: realclean fails to remove ./src/asmfun.s in Parrot v0.6.2
Since there have been no complaints or further discussion about this issue in nearly 3 months, I am resolving the ticket. kid51
[perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
This ticket has not been addressed since early July. Re-reading it now, it seems to have two major discussion threads: one specific to Test::Harness 3 and one relating more generally to the versions of CPAN modules needed to configure, build and test Parrot. May I ask for those who have posted to this ticket to comment on where we stand? Thank you very much. kid51
[perl #55372] [BUG] Segfault/double free when manually running "perl6"
On Thu Jun 12 10:23:06 2008, [EMAIL PROTECTED] wrote: > On Thursday 12 June 2008 10:01:21 NotFound wrote: > > > Some more details: adding: > > > > Parrot_set_flag(interp, PARROT_DESTROY_FLAG); > > > > in src/main.c it segfaults also when executing with perl6.pbc, and > > also a lot of parrot test fails. > > > > So it looks like there is a general problem of interpreter destruction > > in exits from the exception handler. > > That's why I added the flag in the fakecutables; I figured we'd never catch > these problems unless we tested for them frequently. > > -- c > I'm no longer seeing a double-free (linux/x86). The test in question still fails, but it doesn't fail quite as horribly. If there are no objections, I'll close this ticket before the next #parrotsketch.
[perl #55954] [PATCH]: Add 'make smolder_test' target
No one objected to resolving this ticket, so I am doing so now. New Smolder issues? Open a new RT.
Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Sat, 6 Sep 2008, Christoph Otto via RT wrote: > On Wed May 10 11:01:34 2006, stmpeters wrote: > > > > I'm taking a look at it. I should have something working this evening > > for the configs. Adding the HAS_BLAH's will take some additional time. > > > > Steve Peters > > [EMAIL PROTECTED] > > > "when useful" is vague does not indicate why the extra configuration > machinery is justified by whatever benefit we'd get from using these > functions. If someone would like to make the requirements a little > tighter or make the case for implementing this request (or even > implement it), they'd be encouraged. Otherwise this ticket isn't very > useful. > It would be good to either go somewhere with this or reject this request. These functions are typically used in place of the plain sprintf and strcat family as a way to be explicitly careful about buffer overflows. Plain sprintf and strcat are both widely used in the parrot source. Replacing them when it would ease future maintenance and help ensure parrot is not susceptible to buffer overflows is a quite sensible path forward. As you correctly observe, no one has actually done anything about it yet. That doesn't mean it's not worth doing, however. I'd say it should simply stay as an open ticket. -- Andy Dougherty [EMAIL PROTECTED]
[perl #58438] [PATCH] nci can't pass NULL string arguments
No objections and no problems, closing ticket.
Re: [perl #42693] [BUG] method overload in pir subclass of pmc pccmethod leaves object undefined
coke says: > The PIR code in this ticket now causes a Bus error on osx/386 (r25175) Also segfaults in linux/386 for me. I added an assertion that catch the fault in r30859 -- Salu2
[perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Wed May 10 11:01:34 2006, stmpeters wrote: > > I'm taking a look at it. I should have something working this evening > for the configs. Adding the HAS_BLAH's will take some additional time. > > Steve Peters > [EMAIL PROTECTED] "when useful" is vague does not indicate why the extra configuration machinery is justified by whatever benefit we'd get from using these functions. If someone would like to make the requirements a little tighter or make the case for implementing this request (or even implement it), they'd be encouraged. Otherwise this ticket isn't very useful. It would be good to either go somewhere with this or reject this request.
[perl #57610] [PATCH] Resumable exceptions
On Tue Aug 05 04:09:14 2008, tene wrote: > pdd23: > > Exception handlers can resume execution immediately after the > "throw" opcode by invoking the resume continuation which is stored > in the exception object. That continuation must be invoked with no > parameters; in other words, "throw" never returns a value. > > Exception.pmc has the following attributes: > > ATTR INTVALid; /* The task ID in the scheduler. */ > ATTR FLOATVAL birthtime;/* The creation time stamp of the > exception. */ > ATTR STRING *message; /* The exception message. */ > ATTR PMC *payload; /* The payload for the exception. */ > ATTR INTVALseverity; /* The severity of the exception. */ > ATTR INTVALtype; /* The type of the exception. */ > ATTR INTVALexit_code;/* The exit code of the exception. */ > ATTR PMC *stacktrace; /* The stacktrace of an exception. */ > ATTR INTVALhandled; /* Whether the exception has been > handled. */ > ATTR PMC *handler_iter; /* An iterator of handlers (for > rethrow). */ > ATTR Parrot_Context *handler_ctx; /* A stored context for handler > iterator. */ > > None of these is a continuation. > > The throw opcode passes the address of the next opcode to > Parrot_ex_throw_from_op, but Petfo only uses it in: > > address= VTABLE_invoke(interp, handler, dest); > > and the ExceptionHandler PMC's invoke() does not use that parameter > at all. > > > This first draft of a patch adds an attribute to the exception pmc to > hold a return continuation, creates a retcontinuation pmc in the throw > opcode and assigns it to that attribute, and patches > new_ret_continuation to initialize the new continuation's from_ctx > attribute in the same way new_continuation does. > > This last item is there to fix a segfault. I don't understand > parrot's > continuations well enough yet to have any idea why they were > different, > so I just guessed. I don't know if it's wrong, but it doesn't seem to > fail any extra tests. > > Added a simple test case. It looks like Allison applied your patch in r30123 but forgot to close this ticket. Now seems like a good time to resolve it. Thanks for the patch.
[perl #58374] [TODO][PDD19] Decide on maximum identifier length and implement this.
On Tue Aug 26 18:39:55 2008, rgrjr wrote: >From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]> >Date: Tue, 26 Aug 2008 04:46:56 -0700 > >From PDD19: > >Identifiers don't have any limit on length at the moment, but some >sane-but-generous length limit may be imposed in the future (256 >chars, 1024 chars?). > > If the code already supports arbitrarily long identifiers, what is the > motivation for setting a limit? > > -- Bob Rogers > http://rgrjr.dyndns.org/ > +1 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 simple edit/commit once the issue is settled.
[perl #56614] [TODO] Config hash should be marked read-only
On Sat Jul 05 02:53:11 2008, bernhard wrote: > In runtime/parrot/library/config.pir I encountered the comment. > >XXX hash should probably be marked read-only.. > > This should be investigated. > > Regards, > Bernhard This seems to be a very sane suggestion. It's implemented and has a test test as of r30849. Happily, all other tests passed without any modifications.
[perl #39430] [TODO] Method cache not always invalidated
On Sat May 17 14:55:53 2008, pmichaud wrote: > On Mon Jun 12 16:30:13 2006, jonathan wrote: > > Both Parrot_store_global and store_sub call > Parrot_invalidate_method_cache, > > however the versions of these that take keys (Parrot_store_global_p and > > store_sub_p) fail to do so. > > Is this ticket still relevant after the pdd15oo changes incorporated in > late 2007? If the ticket is not relevant, let's close it. > > Pm > > There's a test that appears to be relevant in t/pmc/object-meths.t, but I'm not sure if it tests for the behavior mentioned in this ticket.
[perl #58636] Must Instantiate Class PMCs Before Using Them in HLL Mappings
# New Ticket Created by chromatic # Please include the string: [perl #58636] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58636 > Patrick's example code for RT #30843 creates an infinite loop (before the workaround checked in approximately as r30847) because registering an Integer mapping requires instantiating an HLL-equivalent Integer when storing the mapping. If the HLL equivalent is an uninstantiated class, attempting to create an instance of the class to store the mapping value creates an infinite loop of trying to look up the value before it's stored. A better solution would avoid this infinite regress. r30847 is a workaround.
[perl #40156] [TODO] - Can't use an Iterator with a DynLexPad PMC
On Tue Feb 05 06:50:24 2008, coke wrote: > On Wed Aug 16 23:09:16 2006, mdiep wrote: > > I don't know how to write a test for this off the top of my head, but > > Iterator and DynLexPad don't play well together atm. When I tried, I > > got this error: > > > > elements() not implemented in class 'DynLexPad' > > > > Is there an easy way to make an arbitrary hash-like PMC (DynLexPad, > > NameSpace, etc.) play well with iterator? > > > > Tcl needs to be able to iterate over the keys to return a list of all > > the variables in the current procedure/lexpad. (See [info vars]) > > > > -- > > Matt Diephouse > > > > A nice cage task would be to write a test demonstrating the use of an > iterator in this case. As of r30844 there's a TODO'd test for this, but some work will need to be done to make DynLexPads (and LexPads, incidentally) iterable. Since DynLexPads are based on Hashes, I imagine most of the work will be in adapting get_iter and get_*_keyed.
[svn:parrot-pdd] r30838 - trunk/docs/pdds
Author: cotto
Date: Sat Sep 6 15:52:59 2008
New Revision: 30838
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
[pdd] make the exception-throwing example in pdd23 work
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Sep 6 15:52:59 2008
@@ -170,7 +170,7 @@
determined by the severity of the exception.
=item 6
-Otherwise terminate the program like C.
+Otherwise terminate the program like C.
=back
@@ -365,10 +365,8 @@
$P0 = new 'String'
$P0 = "something bad happened"
- $P1 = new ['parrot';'exception'], $P0 # create new exception object
- throw $P1 # throw it
-
-{{ The above example doesn't work in r23568 -- see RT#48320. }}
+ $P1 = new 'Exception', $P0 # create new exception object
+ throw $P1 # throw it
=head1 ATTACHMENTS
[perl #48320] [BUG] Example in pdd23 doesn't work
On Sat Sep 06 15:51:16 2008, julianalbo wrote: > Sorry, the code I poste was bad. The valid form is: > > $P1 = new ['Exception'], $P0 # create new exception object > I've changed the example code to use the more common syntax without brackets: $P1 = new 'Exception', $P0 . The code works now, so I'm resolving this ticket.
Re: [perl #58308] [PATCH] Implementation fo string_str_rindex and rindex op.
Last revision of string.pmc patch, and of t/pmc/string.t patch, applied in r30853 See the ticket, several messages where not CCed to the list. -- Salu2
