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: How do you do a lazy map?
Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: map *is* lazy, as are all list builtins that can be lazy (which doesn't include stuff like sort, which has to look at all items anyway). Are you sure that it doesn't imply order of evaluation by default? I'm all for it (to be different from 'for') but worry about backward compatibility. I guess using 'eager' in front will fix the problem if you really wanted ordered side effects, so that won't bother people too much. I also wonder about a general way to give hints or rather constraints, such as whether it can be multi-threaded or merely delayed 'till needed. --John
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 #57996] Make m/.../ syntax for constructing a regex work
On Sat Aug 16 07:36:44 2008, [EMAIL PROTECTED] wrote: > - Update grammar.pg (short-term), or wait for STD.pm integration Done in r30864.
[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: How do you do a lazy map?
John M. Dlugosz wrote:
> Consider something like a 'map' call, only I want it to be lazy.
map *is* lazy, as are all list builtins that can be lazy (which doesn't
include stuff like sort, which has to look at all items anyway).
> I know that a
> list can contain internally iterators that generate elements as needed or
> perhaps in the background. But how do you create such a thing? Something
> like:
>
> @lazy_list := parallel-map { get_info($_) } @filenames;
@lazy_list = @filenames.map: { get_info($_) };
I suppose ;-)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
How do you do a lazy map?
Consider something like a 'map' call, only I want it to be lazy. I know that a
list can contain internally iterators that generate elements as needed or
perhaps in the background. But how do you create such a thing? Something like:
@lazy_list := parallel-map { get_info($_) } @filenames;
--John
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]
Re: [perl #58642] [BUG] Wrong construction/clone of Range.
On Sun, Sep 07, 2008 at 06:33:49AM -0700, Vasily Chekalkin wrote: > Hello. > > By default Range (and probably many other classes) constructed in > non-consistent state. > > Minimal example: > .namespace > .sub 'main' > load_bytecode "perl6.pbc" > $P0 = new 'Range' > $P1 = clone $P0 > say "done" > .end For Rakudo and other PCT-related items we should generally not be using the 'new' opcode to create objects. The correct approach is ## $P1 = Range.new; $P0 = get_hll_global 'Range' $P1 = $P0.'new'() Pm
[perl #58438] [PATCH] nci can't pass NULL string arguments
No objections and no problems, closing ticket.
[perl #58642] [BUG] Wrong construction/clone of Range.
# New Ticket Created by Vasily Chekalkin # Please include the string: [perl #58642] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58642 > Hello. By default Range (and probably many other classes) constructed in non-consistent state. Minimal example: .namespace .sub 'main' load_bytecode "perl6.pbc" $P0 = new 'Range' $P1 = clone $P0 say "done" .end Output: $ ../../parrot range.pir Null PMC access in clone() current instr.: 'parrot;Perl6Object;!cloneattr' pc 630 (src/gen_builtins.pir:415) called from Sub 'parrot;Range;clone' pc 4965 (src/gen_builtins.pir:3365) called from Sub 'main' pc 5 (range.pir:5) -- Bacek
Re: What happened to "err" operator?
TSa (Thomas Sandlaß) thomas-at-sandlass.de |Perl 6| wrote:
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
No, I think code in the CATCH could look at its context/callers and
issue a return from the proper one, that is the call to a().
In particular, it can be done using only the conceptual primitives.
Adding an easy way is just library code, not more primitive concepts
that need to be supported.
In particular, I'd like to have an easy way to get that particularly
interesting context (a special word used for the smart match syntax in
the existing context/caller mechanism) and a fail-as-return method on $!
that encapsulates all that, but always works right and efficiently even
in the face of optimization.
--John
Re: [perl #58644] [BUG] rindex fails on non-string invocant
Patrick R. Michaud (via RT) wrote:
> # New Ticket Created by Patrick R. Michaud
> # Please include the string: [perl #58644]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58644 >
>
>
> The rindex method added in r30858 has a bug:
>
> $ ./parrot perl6.pbc
>> say 85224.rindex('2');
> Method 'reverse_index' not found for invocant of class 'Int'
Added a (skipped) test to t/spec/S29-str/rindex.t
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #58646] [TODO] convert 'new Failure' to '!FAIL'
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #58646]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58646 >
For rakudo builtin functions that are written in PIR, use
.return '!FAIL'('...message...')
instead of the old-style
$P0 = new 'Failure'
.return ($P0)
Functions that have return exception handlers in place
(i.e., those written in Perl 6) should simply call 'fail'
directly:
fail '...';
Pm
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 #58644] [BUG] rindex fails on non-string invocant
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #58644]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58644 >
The rindex method added in r30858 has a bug:
$ ./parrot perl6.pbc
> say 85224.rindex('2');
Method 'reverse_index' not found for invocant of class 'Int'
>
Pm
Re: What happened to "err" operator?
"TSa (Thomas Sandlaß)" schreef:
> Larry Wall:
>> Another potential issue is that CATCH doesn't distinguish exceptions
>> coming from the current block from those coming from the subcall to
>> a(). So it could end up returning Failure from the current block when
>> you intended to force return of Failure from a(). Not sure what
>> to do about that...
>
> I don't understand this issue. I think we have the fact that
> *every* operator is at least conceptually dispatched and as
> such everything in a block is at least one level down in the
> call chain just as a() as a sub call is. This is why a CATCH
> block inside the block is so natural to me.
>
> If I understand your intention correctly you want to be able
> to force a thrown exception from a() into a returned value
> and proceed where this return value is supposed to show up
> in the current block, right? The simplest solution that comes
> to my mind is some form of goto to that position. Or is that
> too inelegant? The point is how the CATCH block knows from
> which subordinate scope the exception originates.
>
>a() proceed: orelse b();
>CATCH
>{
> ... # make $! into return value
> goto proceed;
>}
>
> This kind of needs to know the variable the return value of a()
> is stored into. This is easy if orelse is checking $! anyway.
> But does it? And is it possible to have labels in the middle
> of a line as above?
Maybe the "=" should deliver the normal (=value) part of the
return-stash, and a different deliverer should be used to get other
information out of it.
--
Affijn, Ruud
"Gewoon is een tijger."
Re: What happened to "err" operator?
HaloO,
On Thursday, 4. September 2008 03:39:20 Larry Wall wrote:
> Another potential issue is that CATCH doesn't distinguish exceptions
> coming from the current block from those coming from the subcall to a().
> So it could end up returning Failure from the current block when
> you intended to force return of Failure from a(). Not sure what
> to do about that...
I don't understand this issue. I think we have the fact that
*every* operator is at least conceptually dispatched and as
such everything in a block is at least one level down in the
call chain just as a() as a sub call is. This is why a CATCH
block inside the block is so natural to me.
If I understand your intention correctly you want to be able
to force a thrown exception from a() into a returned value
and proceed where this return value is supposed to show up
in the current block, right? The simplest solution that comes
to my mind is some form of goto to that position. Or is that
too inelegant? The point is how the CATCH block knows from
which subordinate scope the exception originates.
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[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.
List.uniq
There are some tests for List.uniq in the test suite, and pugs
implements it, but it's not in S29.
Damian seems to have though we should have it:
http://groups.google.com/group/perl.perl6.language/msg/4c8c9bd73c862bed
So should we have it? If not, I'll replace the tests with
eval_dies_ok('(1, 2).uniq', 'List.uniq not specced');
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
[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 #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.
[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.
[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
